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

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