3 ms·
The broader principle I'm seeing is, when it comes to competence, a small company is probably best off looking for reasons to accept, not reasons to reject. Sm
by chrchang523 7y ago
The broader principle I'm seeing is, when it comes to competence, a small company is probably best off looking for reasons to accept, not reasons to reject. Small companies aren't subject to the same corruption-control constraints that large companies are, so they have more flexibility in onboarding someone who doesn't fit in one of the usual boxes but nevertheless can probably provide more than enough value to the business.
(Incidentally, the main reasons I'd reject an engineer candidate who did seem individually competent and motivated enough relate to trust and team collaboration.)
- scottlamb 7y agoThat's a good point. I work for a large, famous company, though. I'm expected to do a standard 45-minute interview with a prescribed focus area (most commonly system design or algorithms/coding) and to evaluate candidates in relatively standard ways. If anyone has tips for putting a nervous candidate at ease in this situation, I'm all ears. One thing that I think helps is that I ask markedly simpler questions than other interviewers often do. (We can see each other's notes.) This takes away some of the time pressure and lets the candidate and me go through requirements gathering, verbal/whiteboard descriptions of the problem/algorithm, and a few revisions of the code and debugging and such together if necessary. It also avoids the "candidates need to bring their own finer-tipped whiteboard markers to write the solution on the board" sorts of ridiculousness. It might mean I can't reliably tell the difference between "hire" and "omg best I've ever seen hire hire hire" based on the few lines of simple code a good candidate might ultimately write but I don't care about that.