Comment by stickfigure
1 day ago
Interviews aren't always confrontational. I have been using the same pair programming exercise for roughly the last hundred interviews. There are no tricky algorithms, just walking through the implementation of a basic rest endpoint. It's cooperative and I want the candidate to ask questions. If you can code at fizzbuzz level, are comfortable writing tests, and know a little about databases, it's easy.
There are probably great programmers out there that think pairing is horrible and stressful and this is the interview from hell. I accept that, but I also think that being able to pair and communicate is an important job skill. I want a team, not brilliant lone wolves.
The pair programming thing works great as an actual work sample test. I think it works best when neither person knows the answer though.
If one of you already knows what they want to see, it’s not really pair programming.
Either way though your process is already better than 90% of companies.
For the most part I think this is right though I'm not opposed to a quick screener. It reminds me more of the traditional engineering interview, which is more about how you think. Knowledge is good, but it usually isn't hard to obtain. But the way you think? That's much harder to change. I'd love to optimize for both, but if I have to pick I'd rather have someone who has a good engineering mind. Seems even more important these days, because if I just wanted to optimize for knowledge I'd just use an LLM and RAG.
My last three jobs all did pair programming so we structured our interviews to be similar, and they’re still my favorite interviews I’ve conducted. Many candidates also praised the format, whether they were hired or not.
This is how I've conducted a few interviews at a startup. I take pains to emphasize that:
1. I'm just looking for pseudocode, nobody cares about whether you do length(items) or items.size(), etc. The code won't even be run.
2. Invent functions without necessarily defining them, I'll object if doAllTheWork() needs to be fleshed out.
3. The problem/docs presented are the whole thing for the interview. There might be bugs to uncover, but there's no secret second phase to the boss battle.
Ultimately, I'm looking for them to assemble the basic building blocks, and see what suggestions they have when I point out issues like error, handling, stale data, security, etc.