I've said much in the last few years on the trend toward using code projects like the one you were given to suss out an Engineers ability, unfortunately though this method is light years better than live white board exercises it is still not the optimal way to suss out an Engineers talent.
The best way to suss out Engineering talent gives you an efficient understanding of these key abilities that you require in a real world Engineering scenario. 1) Tenacity. 2)Problem solving ability. 3) Time management.
That's it. Nothing else matters in any Engineering role on the job. Not if the Engineer can write out Dykstra or a* or any other algorithm. Not if they can tell you how garbage collection works. Not if they even know how to use a particular obscure feature in the tool de jour... Tenacity, Problem solving ability and time management.
The fastest way to get at all three is not to ask them to waste their time on your behalf and without pay (which is immoral IMO) for the hope of being pushed to the next step but to ask for an EXISTING project of theirs that they are proud of that can be used to exercise the three key talents listed above.
For tenacity, you can ask "In this project, did you have any problems that you first thought were impossible but figured out? How did you realize you could solve the problem?" Their answer will zero in on those issues for the project and you can assess if what they deemed difficult matched with your and your teams conception...thus sussing technical fit.
For problem solving skill you can ask "What are the steps you go through to solving a new problem that you've never seen before?" This gets you to the 1, 2, 3 of solving a problem. Do they have some idea in their head already and get going? Do they start with R&D by hitting google and stack overflow? This gets you an idea of how fast they go from clean slate to skeleton project actively being fleshed out.
For time spend you ask how long the project took to complete, how did they task out their work and manage their development process. This gets you an idea of how quickly they can work and if they can do the necesary work on time. To a company this is probably the most important factor as time is money.
Everything else is fraught with bias...of single points of failure (One Engineer) disqualifying good or great candidates because of gotchas put into live coding challenges or discounting people for being nervous while live coding ...it's all fracked. As part of my consulting company I take part in hiring drives and have interviewed many Engineering candidates and I find the best are the ones who excel in the three traits described above...even when they don't have a project that I can look at the code for.
I've said much in the last few years on the trend toward using code projects like the one you were given to suss out an Engineers ability, unfortunately though this method is light years better than live white board exercises it is still not the optimal way to suss out an Engineers talent.
The best way to suss out Engineering talent gives you an efficient understanding of these key abilities that you require in a real world Engineering scenario. 1) Tenacity. 2)Problem solving ability. 3) Time management.
That's it. Nothing else matters in any Engineering role on the job. Not if the Engineer can write out Dykstra or a* or any other algorithm. Not if they can tell you how garbage collection works. Not if they even know how to use a particular obscure feature in the tool de jour... Tenacity, Problem solving ability and time management.
The fastest way to get at all three is not to ask them to waste their time on your behalf and without pay (which is immoral IMO) for the hope of being pushed to the next step but to ask for an EXISTING project of theirs that they are proud of that can be used to exercise the three key talents listed above.
For tenacity, you can ask "In this project, did you have any problems that you first thought were impossible but figured out? How did you realize you could solve the problem?" Their answer will zero in on those issues for the project and you can assess if what they deemed difficult matched with your and your teams conception...thus sussing technical fit.
For problem solving skill you can ask "What are the steps you go through to solving a new problem that you've never seen before?" This gets you to the 1, 2, 3 of solving a problem. Do they have some idea in their head already and get going? Do they start with R&D by hitting google and stack overflow? This gets you an idea of how fast they go from clean slate to skeleton project actively being fleshed out.
For time spend you ask how long the project took to complete, how did they task out their work and manage their development process. This gets you an idea of how quickly they can work and if they can do the necesary work on time. To a company this is probably the most important factor as time is money.
Everything else is fraught with bias...of single points of failure (One Engineer) disqualifying good or great candidates because of gotchas put into live coding challenges or discounting people for being nervous while live coding ...it's all fracked. As part of my consulting company I take part in hiring drives and have interviewed many Engineering candidates and I find the best are the ones who excel in the three traits described above...even when they don't have a project that I can look at the code for.
Links:
sent2null.blogspot.com/2014/05/liv...
sent2null.blogspot.com/2013/02/gra...
sent2null.blogspot.com/2013/01/rub...
sent2null.blogspot.com/2012/03/eng...