Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and brokenThe irony is whenever someone posts some esoteric "gotcha" programming trick here on HN, inevitably there'll be comments like "have to include this in our next interviews."
So what would you do differently? This is a genuine question after I came off 3 months of interviewing daily. I'm curious what does represent a good developer and how to decide this in 30 minutes over the phone? What's important?
- Past projects?
- Communication?
- Open source contributions?
- Ability to write code?
- Telling me how they'd Google a problem?
- How to break down problems?
- Some % combination of these?
My interviews are generally structured:
10 min: introduction to the role, expectations, motivations, try to start a conversation, get a feel for the candidate, nerves etc
15 min: technical questions:
- fundamentals on the job's tech stack (must provide code)
- turning a requirement into a design
- troubleshooting issues (db performance, web server issues)
5 min:
- wrap up, q&a