4 ms·
> I recommend that you make a plan for what you want to learn about the candidate, e.g. “are they good at acquiring new skills?” or “do they share the same valu
by mjr00 3y ago
> I recommend that you make a plan for what you want to learn about the candidate, e.g. “are they good at acquiring new skills?” or “do they share the same values as the team?” and then structure the interview around that.
Generally what I want to learn about a candidate is "are they good at understanding plain-English requirements, can talk through their thought process as they problem solve, convert that solution into something that resembles working software, and we can have a decent conversation about what was built." As it turns out, whiteboard-type algorithms and system design questions are very good at this.
Asking if someone keeps up with tech news (and call it a red flag if they don't) is just a way to keep your candidates within a certain social bubble. Which, honestly, is preferable if you're a < 50 person startup. But this doesn't scale. Plenty of software devs at IBM, Amazon, etc are just clocking in and out of their shifts and do a fine job of it. Not everyone needs to make career advancement in the tech industry their life.
- lentil_soup 3y ago> can talk through their thought process as they problem solve Why? Why can't I have a moment to think and focus without talking?
- mjr00 3y agoTaking a moment to think is totally fine. But it's important to be able to explain what you're going to build before you actually build. Writing up clear design docs and architecture is critical in most senior technical positions. Obviously the expectation here changes on leveling--with juniors if they just code in silence before explaining their solution at the end, I'm less concerned. But if a senior just starts coding on the whiteboard I'll interrupt them and ask them to explain what their approach is, in English, before coding it up.
- ipaddr 3y agoDo you think that's how coding happens? That's something you might see in a movie or rehearsed talk.
- mjr00 3y agoI mean... yes? Have you only worked at a company with a single-digit number of engineers? At some point communication is critical and you need to be able to write up a design document before making major changes or additions to code or infrastructure.
- xboxnolifes 3y ago> At some point communication is critical and you need to be able to write up a design document before making major changes or additions to code or infrastructure. ... which is typically written after hours of understanding the problem and then minutes to hours of writing out the document. Not 5 minutes after reading a problem statement.
- lentil_soup 3y ago> At some point communication is critical and you need to be able to write up a design document before making major changes or additions to code or infrastructure. Not sure I've ever had to do that on a whiteboard or under pressure though. Also don't think being good at doing that correlates with writing good documentation