3 ms·
In my experience interviews are not the main place to evaluate technical skills, people get nervous and asking too specific technical questions is not good also
by mingodad 10y ago
In my experience interviews are not the main place to evaluate technical skills, people get nervous and asking too specific technical questions is not good also, some people can be good at remembering then but can not do anything with then.
I came to the idea that to interview/hire/select a software engineer he/she should show at least three bug fixes on any opensource project and if the fixes are way back the interview/job advert the better. So one can at least have a concrete idea of the candidate skills/interest when confronted with a third party code base and how she/he understood/solved the problem.
This way the interview can be used to access other important aspects of the candidate.
I interviewed several people that seem to have paid someone to write their C.V. very well but when in person was a lost of time.
- Cthulhu_ 10y agoBug fixes and such don't really tell much either though. We do hiring via an assessment, where people need to implement (parts of) an application similar to a real-life thing; involves things like creating a REST / JSON api, etc. The trick is we don't tell them exactly how to implement it (language, environment, secondary requirements are all left up to the applicant). This really weeds out the candidates; better than fizzbuzz, better than live coding. Of course there's a chance that someone copies stuff off the internet, but that's what the actual interview(s) are for, just ask some questions about the implementations and the why and such. We've hired people that did it in python, node, ruby, even J2EE. Language doesn't matter, it's the thought and reasonings behind it that count.