Hacker News new | past | comments | ask | show | jobs | submit login

On the spot. I fully understand that many good engineers could freeze up, myself included. That is the reason the coding question is about a realistic problem. No dynamic programming, graph theory, suffix tree, etc. Also, before the coding, I would talk to the candidates about technologies listed in their resumes. It is mostly like a talk between two engineers in a meetup or a conference, not a technical test. My intention is to build an environment that the candidates can feel like real work environment as much as possible. It also helps to bring up the candidates spirits. We are talking about something we like!

As long as the candidates get the logic flow on the solution, can write code down in well-formatted manner, pay attention to corner cases, it doesn't matter if the candidates actually complete the coding, if I think given enough time in a real work environment that the candidate has no problem in doing it.

There are some red flags I pay attention to. For example, readable code is very important to me since we work in a team and we spend more time reading code than actually writing it. Once we had a candidate. he got the coding right, but his code was very hard to read. It reminded me of some obscure C code in the past that one statement was trying to do many things so that it became very convoluted. For me, it is not "smart". It is bad engineering.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: