←back to thread

Looking for a Job Is Tough

(blog.kaplich.me)
184 points skaplich | 1 comments | | HN request time: 0.255s | source
Show context
thw09j9m ◴[] No.42132752[source]
This is the toughest market I've ever seen. I easily made it to on-sites at FAANG a few years ago and now I'm getting resume rejected by no-name startups (and FAANG).

The bar has also been raised significantly. I had an interview recently where I solved the algorithm question very quickly, but didn't refactor/clean up my code perfectly and was rejected.

replies(12): >>42132828 #>>42132878 #>>42132900 #>>42132935 #>>42133185 #>>42133278 #>>42138532 #>>42138559 #>>42139442 #>>42140920 #>>42143310 #>>42145184 #
joshuaturner ◴[] No.42133185[source]
I think a lot of this comes down to AI. In a recent hiring round we experienced multiple candidates using AI tooling to assist them in the technical interviews (remote only company). I expect relationship hires to become more common over the next few years as even more open-discussion focused interview rounds like architecture become lower signal.

So with that in mind I'll see you all at ReInvent

replies(1): >>42133235 #
rsanek ◴[] No.42133235[source]
If you're giving remote interviews, your loop should assume candidates can use AI. it's like giving a take home math test that assumes people won't use calculators at this point
replies(2): >>42133482 #>>42136958 #
joshuaturner ◴[] No.42133482[source]
I disagree. We pretty explicitly ask candidates to not use AI.

While it's fine when doing the job the purpose of the interview is to gauge your ability to understand and solve problems, while AI can help you with that you understanding how to do it yourself signals that you'll be able to solve other more complex wider-spanning problems.

Just like with a calculator - it's important for candidates to know _why_ something works and be able to demonstrate that as much as them knowing the solution.

replies(6): >>42134372 #>>42136181 #>>42136639 #>>42137164 #>>42137819 #>>42140896 #
jjav ◴[] No.42137164[source]
> Just like with a calculator - it's important for candidates to know _why_ something works and be able to demonstrate that as much as them knowing the solution.

And this is why I never give coding-puzzle interviews. I just have a chat about your past projects (based on resume). We'll go deep into the technical details and it is easy in such a conversation to get a feel for whether you actually contributed significantly to the things the resume says you did.

replies(2): >>42143907 #>>42151702 #
1. jkaplowitz ◴[] No.42151702[source]
Only sometimes is your historical deep-dive approach going to give you the right signal.

I’ve been out of work for a couple of years due to complicated immigration reasons, and I was most recently a people manager (although with a few direct technical tasks still). I honestly don’t remember many of the deep technical details of things to which I genuinely contributed significantly as an individual contributor or tech lead, despite those being entirely real and despite me still being a capable hands-on technical person. I’ve had so many jobs recently reject me for reasons like this without giving me a chance to actually demonstrate what I can do.

Memory tests are biased toward people who did the work recently, and biased against people with ADHD (who often have worse long-term memory for such details without being worse hires).

The coding interview shouldn’t be just a blind submit and wait for feedback, nor a live rushed and high-pressure puzzle test (you’re quite right in that regard). Ideally it should be the candidate doing what’s expected to be 1-3 hours of work asynchronously at their convenience within a period of a few days, and then discussing (maybe even presenting/demoing) live in a way that shows deep technical understanding and good communication skills. That avoids conflating memory tests with technical tests. Certain live coding tests can also be okay, but I agree it’s easy to make them unnecessarily uncomfortable with a false signal either way.