3 ms·
Have you made any bad hires that way? I used to think that I could gauge someone's depth of understanding by asking pointed questions about past projects, but a
by dnr 6y ago
Have you made any bad hires that way? I used to think that I could gauge someone's depth of understanding by asking pointed questions about past projects, but after doing that several times and following it up with a simple coding problem that they totally flailed around on, or having a colleague tell me that they failed a simple coding problem in their interview, I realized that some people are just very good at faking understanding at that level (talking about code but not actually coding). Especially if it's on their "own" project that they're familiar with and have practiced responses to.
- kaiju0 6y agoSo far its been pretty solid. My key approach is to ask about the last task they were working on. Then keep asking further questions on it to gauge their depth of understanding. For someone I want to hire there is almost always a "Beautiful Mind" moment. They stop trying to distill information and start just start talking about all the little details they needed to iron out to get it working right. That when I know they actually did the work and are not just a taking credit for being on a project. Why did you choose that over other approaches? Did you use an ORM or raw queries? What was the O(n) on that operation? What kind of database did you access? How did you add that to the CI/CD pipeline? Just flex the questions for whatever and the people that did not do the work fall apart. Then you have solid devs that show up every day and do the work. You also get the bonus of the dev knowing their new boss knows their shit.