Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and broken
The 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
I look for relevant experience, personality, and problem solving skills. I start off with questions that'll get me an insight into the person then I give them a written problem that'll take them 10+ minutes to answer. I want to see them work through it, see what they get stuck on, see when they ask questions and what questions they ask. I ignore syntax errors, and similar minutiae. If you don't have good problem solving skills I don't see how you can be a useful member of my team.
The 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