5 ms·
I'm going to disagree with you on a number of reasons. 1. A lot of studies out there show that the most important factor for a hiring success is culture, not s
by animal531 9y ago
I'm going to disagree with you on a number of reasons.
1. A lot of studies out there show that the most important factor for a hiring success is culture, not skill.
2. Are you even measuring skill with your test? It doesn't matter if it should only take 2h for a candidate to complete your test, if they're nervous or want to impress they're going to spend 12h on it. How can you tell the difference?
3. What about the really good candidate that doesn't want to spend 2h on your test, because he also went to 2 other interviews in the same day where no tests were demanded of him. You're again not testing for skill, but willingness (and against other employer's testing regimes).
4. What is your test about? As a random example implement Web Service X that does Y. Is it important for you that candidates know how to implement X from the ground up? Will they be doing a lot of Y? Why spend 2 hours effectively answering 2 questions, where you could have interviewed him in 2 hours covering his whole history of computing experience, what he loves about it, why, what code he's written, what he's into, what he thinks about X,Y,Z etc.
5. Your job is not to impress him with your knowledge (not that I'm saying this is what you're doing, just a general remark on interviewers out there), but to determine what his is, where he's strong and where not, and how the person will fit into your structure. Making your test the big determining factor is a failure.
6. There's a reason fizzbuzz for example makes a great starter test. It immediately weeds out people that can't complete it, and allows you to see the interviewee reason through it. He goes for example, well, I take this and that, then I have to do this; oh yeah and so so etc. It allows you to see a lot more than just the end answer. After that you can apply more interesting/harder questions, but focus rather on how they do it than if they can complete it in the allotted 5 minutes.
- shortoncash 9y agoRegarding #2, I believe your observations and concerns are correct and valid. However, in these situations where the candidate spills his technical heart out, you really start to see the difference between good candidates and bad candidates. Good candidates just have a deep sense of the problem space, can enumerate issues, document such things, etc.
- cimmanom 9y agoI find code review-style discussion of a simple coding challenge to be great for assessing both culture fit and skill. What we administer is like a web app equivalent to FizzBuzz in terms of difficulty level. But unlike a whiteboard FizzBuzz, it doesn't put the developer on the spot. As an extra bonus, unlike FizzBuzz, you'll get different results from the kid who just successfully finished a CS degree and the grizzled veteran who's built and maintained complex systems for decades. The right challenge can be completed in an hour or so by a mid-level developer in a brute-force manner. It will weed out those who simply can't code (or don't grok how the web works or how apps are constructed); and also highlight candidates who are capable of more sophisticated work. If being up to speed on a specific technology from Day 1 isn't important, you can give the developer their choice of framework or language or whatever. Then when you do a code review in person you can get a feel for both how the developer approaches code (a skill) -- but more importantly, how they take critique. Do they get defensive? Do they riff off your ideas? Do they suggest improvements/refactorings they would have made if they had more time? You can also explore other cultural factors - for instance, how did they approach constraint trade-offs in terms of time vs. completeness vs. sophistication? How clearly are they able to communicate about technical concepts?
- hamidhasan 9y agoThis actually sounds really interesting, putting some code up for one interview or take home assignment, and then asking them to walk through a code review. You could also throw refactoring into the mix, ask them to actually refactor it if needed. It also got me thinking: what if you just had some generic code, which was low quality, or a prototype front end app, and then asked them to refactor or code review it? That could spark some interesting discussion and be less stressful, but may be easily bsed I think.
- cimmanom 9y agoYeah, that is an interesting idea. Might be harder to come up with, though.
- gowld 9y ago> . A lot of studies out there show that the most important factor for a hiring success is culture, not skill. No! Studies show that above an sufficient baseline level, having a baseline of soft skills matters more than marginal differences in tech skills.