But now we're scaling, so need to figure out how to do a technical interview again. But... man, all my technical interview methods feel obsolete / inadequate. Seems pretty silly to not let a candidate use Cursor/Claude when I would 100% be expecting them to use it every day. But also if we just vibe something together it'll be darn hard to figure out what they actually know.
Looking for a process for mid to sr level.
Anybody feel like they've figured this out yet?
- "Take a look at this PR / codebase" doesn't age well, because "claude make me a powerpoint that ELI5s this codebase" is better.
- Simple coding puzzle was never very good, but at least showed they could type. All of this is just LLM fodder now, do I really care?
- Complex system debug / comprehension type questions are always hit-or-miss in my experience. I feel like any setup I do to make a tough to solve problem will be trivial for Claude, so doesn't feel authentic either.
- System design at ~whiteboard still feels reasonable / CS basics.
Bingo. Timeless classic for good reason.
Code review also can be good, not in a "can you spot the 17 bugs" way, but rather as a tool for discussing what makes code good, what make a code-review good, what are the tradeoffs in this particular section of code, what tests or other safety checks might you want to add to this particular code, etc.
It's worked well for me so far.
I'm not a fan of whiteboarding or on-the-spot code examinations. I feel the ability to communicate effectively about code and algorithms, critique in an empathic fashion is far more important.
Similarly, I feel that curiosity is one of the strongest skills a developer can have, and this is not something that can be demonstrated through coding exercises.