Ask HN: How do we even technical interview anymore?

[jdwyah]

I've done 100s of interviews over the years. But haven't been doing any for the past 3.

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.

[justinludwig]

> - 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.

[Leynos]

I prefer to talk through a code review with the candidate. I like to get a feel for how they approach another developer's code, the type of questions they ask, and whether or not they have a sense of situational needs.

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.