We’re Bad at Interviewing Developers – Interview with Kerri Miller
blog.fogcreek.com
We’re Bad at Interviewing Developers – Interview with Kerri Miller
1–10 of 101 posts
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#2[deleted]
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#3perhaps you should not hire developers but people who will own a whole "vertical slice" i.e. do what typically is sliced horizontally between business - product owner - analyst - architect - developer - tester
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#4>We don’t do a really good job of hiring with intent. We decide that we need more people, but we don’t do a really good job of figuring out what we need those people to actually do, and who we actually need to hire.
I don't understand what she's talking about here. Every time I see a job opening, the software hiring manager and the team peers know there's a pain point that needs to be solved. E.g. "We need to an embedded C programmer to make this firmware talk to our USB protocol". "We need a developer to port the Java code to Go." "We need to expose our mainframe transactions as a REST API", etc.
Look at the previous "Who's Hiring" thread. Do those posters look like they post the job slots without a clear intent?
https://news.ycombinator.com/item?id=10152809
>just automatically do, and we don’t think about, “Well, what questions are we trying to answer by asking a candidate to solve a problem?” Are we dinging people for trivia questions, for not remembering, “Oh, I need this third option flag, or an obscure method from a core library.”
I'm not sure where her experience with whiteboarding comes from. In my experience, companies use whiteboarding to sketch out algorithmic thinking. Whiteboarding is the opposite of reciting trivia such as the "3rd parameter to an obscure library function" Interviewers don't care about perfect syntax or missing semicolons.
>Instead, I really want to focus on questions that are asking about decisions that they’ve made, what choices have they made, and what choices would they make again in the future? Are they reflective about mistakes that they’ve made? Are candidates looking for opportunities to improve, and how do they actually go about it? Do they make plans for themselves, like how they would improve a certain skill set, whether that be a technical skill set or a more soft skill set, for example, management, or project shepherding for example. Those are the kinds of questions that I think really get you at the heart of not necessarily what somebody knows, but what they’re capable of.
Those questions are fine but it's wrong to prioritize them over concrete programming questions. Companies are trying to evaluate if the candidate can actually program and those "Emotional Quotient" questions she favors are easy to bs about. Instead, companies need to assess real programming skills and they can start with FizzBuzz and then move on to more comprehensive evaluations -- whether it's the take home programming problem or the onsite whiteboard algorithms discussion.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#5>We don’t do a really good job of hiring with intent. We decide that we need more people, but we don’t do a really good job of figuring out what we need those people to actually do, and who we actually need to hire. I don't understand what she's talking about here. Every time I see a job opening, the software hiring manager and the team peers know there's a pain point that needs to be solved. E.g. "We need to an embe…
I've been in this situation.
Where I'm being told, "Hire more developers! We need more developers!" I respond with, "I don't need any more on my team right now. We can't handle more with our processes and the head count on our other teams."
That's not important though. To the people I was working with, more developers meant you could do more work, even if we didn't have a plan for what that work would be yet. Incredibly frustrating since more devs could actually contribute to gumming up the works if not brought in appropriately.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#6Testing for communication skills is awesome advice and probably rarely ever consciously focused on.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#7>We don’t do a really good job of hiring with intent. We decide that we need more people, but we don’t do a really good job of figuring out what we need those people to actually do, and who we actually need to hire. I don't understand what she's talking about here. Every time I see a job opening, the software hiring manager and the team peers know there's a pain point that needs to be solved. E.g. "We need to an embe…
I'm hiring right now, and I read a lot of job descriptions before I wrote ours. [1] I've definitely seen what she's talking about: generic go-hire-engineers job descriptions. I also think the kind of thing you describe, hiring for a very specific technology, is a similar failure mode. The technological pain point of the moment rarely lasts; the more stable needs are actually organizational. For example, over the next couple of years I want to be able to hire junior engineers, so right now I'm much less concerned with a particular technology stack than with someone who really likes mentoring and working in closely collaborative environments. That way I can bring the junior people rapidly up to speed.
I also have seen whiteboard coding interviews where interviewers are inclined to ding people for not remembering small details, so it's a legitimate concern.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#8Testing for communication skills is awesome advice and probably rarely ever consciously focused on.
As a related note, the best predictor of university physics scores is high school English scores.
Why? Because physics is about making a conceptual model. i.e. telling a story about a problem. And then solving it.
For interviewing, communications skills are a must. People will be working in a team, and must be able to explain themselves. And get along with others.
Another thing rarely checked for is the flip side... understanding explanations. If you have to explain something four times to a candidate, you'll probably have to explain things 1000 times on the job.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#9Testing for communication skills is awesome advice and probably rarely ever consciously focused on.
As a related note, the best predictor of university physics scores is high school English scores. Why? Because physics is about making a conceptual model. i.e. telling a story about a problem. And then solving it. For interviewing, communications skills are a must. People will be working in a team, and must be able to explain themselves. And get along with others. Another thing rarely checked for is the flip side...…
> As a related note, the best predictor of university physics scores is high school English scores.
That's pretty counter-intuitive. Can you give a source?
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#10Testing for communication skills is awesome advice and probably rarely ever consciously focused on.
Yeah, it's one of the big reason I do pair programming interviews. [1] It lets me find out a) whether they can do the work, and b) whether they can communicate about the work they're doing.
Her suggestion for "explain something to me" makes me a little nervous; I'd be worried that the interviewee would have a hard time coming up with a good topic on the spot. But last I interview, one person asked me to pull up one of my open source projects and explain the code to them. That struck me as a very fair test.
[1] Described here: https://www.quora.com/What-are-the-best-programming-intervie...