Technical interviews are weird

Technical interviews are strange because everyone involved knows they are strange.

The candidate pretends the puzzle resembles work. The interviewer pretends the puzzle reveals something. Then everyone goes back to jobs where the hard part is usually reading existing code, understanding a vague requirement, finding the weird edge case, or asking the person who knows why that table has three nullable dates.

I am not saying there should be no technical evaluation. Obviously you need to know whether someone can program.

I just do not trust the usual ritual very much.

Whiteboard problems mostly find people who practiced whiteboard problems. Timed take-homes often become unpaid work. Pairing with a stranger while they judge every pause is not how I write code. System design interviews can be useful, but they also drift into architecture cosplay very quickly.

The best signals I have seen are boring:

• show me code you wrote and talk through it;
• give a small paid task with clear boundaries;
• talk about a bug that took too long;
• ask how you changed your mind after reading the existing system.

None of this is perfect. Hiring is noisy. People have bad days. Interviewers also have bad days, which the industry likes to ignore.

I mostly want less theater. If the job is changing code in a messy product with other people around, the interview should probably contain some version of that.