Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also:

* People who have been on a team long enough to learn how things should work but lack the skills to really do the coding.

I phone screened a guy fairly recent who had a very long background (~20 years) in a pretty security-conscious field. He did very well in open-ended design discussions and was able to explain his prior work very well. He couldn't code trivial binary tree operations, though. I can only assume that someone else on his team is carrying most of the coding burden. This guy might be great at a PM-type job (or not, I don't interview for those jobs), but not as a dev.



I feel like there is some detail missing here. What constituted doing "very well" on the open-ended questions? How deep into the engineering did you get? Since you mentioned he "might be great at a PM-type job" it sounds like you didn't go very deep on int.


That one was a phone screen, so no it was not the deepest technical dive ever. But in fairness a 1-hour interview is rarely the deepest technical dive possible. I normally pose some big problem like "design a system that accomplishes X at high scale" and then drill into some area iteratively until we're discussing fairly specific details. At the high level I'm looking for the candidate to recognize tradeoffs between centralized/distributed designs, sanely choose the major components, deal with stateful and stateless components, recognize security tradeoffs, etc. As we drill in we might talk about data partitioning, georeplication, or high availability and implementation tradeoffs there. We might get down to the level of something like handling out-of-order change notifications. Rarely do I drill down to the level of file I/O or memory management strategies.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: