Hacker News Reader

Comment by harel | Hacker News Reader

There is one thing mentioned there that I've never considered for some reason (and it's quite obvious in retrospect): Giving a candidate a code review exercise instead of (or in addition to) a code writing one. A code review can reveal a lot of how a candidate pays attention to details, looks at (and deals with) other people's code, reads code etc.

View on HN

Agreed, if hiring processes involved less questions about CS/algorithms, and more day-to-day skills like "use git to do <x>", "how would you unit test this?", or "given these use-cases, how would you design the API?", a lot of places would be hiring better engineers and building better products.

I don't think you build better products if you hire someone who knows how to use git. It doesn't fit in with the rest of the skills you're listing.

I would disagree when it's a clear requirement of the work to be done (and often tossed haphazardly onto a resume). There can be some real time sinks that are not towards making someone productive in a code base as you have to stop and teach them how to think about Git. There's also the fun of having to use advanced Git magic to untangle their PR into something sensible because they've done odd merges along the way where they should have rebased their commits. People that still are from centralized source control only world still exist and getting them to work Git well is a skill that's worth interviewing/filtering over if it's a day 0 expectation.

I agree that testing for knowledge of specific tools is probably not what you want, but I find that among people who do have significant experience with git, ability to use it effectively seems to correlate pretty strongly with overall programming ability and productivity.

I mainly have experience with git, but I assume this generalizes to other version control systems. I also think that version control is a pretty fundamental skill for software engineers (comparable to unit testing), so I think substituting that for "use a version control system to do x" would fit in with with other skills.

https://news.ycombinator.com/item?id=12018965

Generated a few comments but not many. I put in by thoughts on why code reviews are so much more better at gauging expertise. I have since adopted that and found that it led to much more productive interviews. Even candidates that do not make it thru' appreciate the fact that they were treated as peers rather than being 'questioned'.

I'd like to also add something else that I've adopted -- the solve-at-home question, if we do go with one, is never just a lazy spec. document. It is an unfinished bit of code with tests etc. This way the candidate is not intimidated/overwhelmed/have analysis-paralysis and it feels more natural. Again, insights from submission to those are better than from-scratch assignments IMO.

Can vouch for its efficacy as an indicator for the traits you might want.

I use a small application that demonstrates some anti patterns / questionable design choices and ask candidates to talk me through their thoughts.

Reply on news.ycombinator.com