4 ms·
Another way to do this is to already have an existing mini project with a bunch of unit tests. It should be functional but contains known bugs, of which, some
by junto 11y ago
Another way to do this is to already have an existing mini project with a bunch of unit tests.
It should be functional but contains known bugs, of which, some are easy for junior developers, and some are much harder for senior devs. Whilst I don't like checking broken unit tests into source control, leaving a broken unit test in the source code is also another good test of the candidate, to see if they can fix the code to match the assertion.
It would also contain methods that a senior dev should be able to look at and then appreciate that there is a optimization that could be made to improve performance.
Everything is in a private Github repo that the candidate can be given access to and a week to play around with, giving people time (some people have families and busy lives) to complete.
They should issue a pull request when they are finished and their changes should be well documented.
Most companies have an existing product and developers are needed to support, fix and extend those existing products. It isn't often developers get greenfield development. They need to fix code written by other developers.
The really good developers:
- figure out how to clone the repo
- comment their changes well
- fix all the bugs
- figure out how to run the unit tests
- fix the unit tests that don't work
- optimize the poor performing methods
- manage to issue a pull request
If the developer is junior, then they might miss a few bugs and the potential optimizations, but if they can get to the point of issuing a pull request with some bug fixes and good documentation, then they have done pretty well.
Most importantly, check the developer's knowledge beforehand. For example, they might not have had Git experience before. If they can figure things out for themselves, then it shows they can solve things for themselves without someone else having to hover over them constantly.
Finally, if they ask questions to validate their assumptions, the developer isn't going to be one of those devs that goes off on left-field for 3 days, only to find out they got the wrong end of the stick. People that think they understand but don't, are dangerous and expensive to your organisation in the long run.
- erikb 11y agoHaving a pet project for a team is a really important thing. You have some way to bond that is not so stressful, you have something to show for, some reason to spend friday nights and weekends with colleagues, can show of some of _your_ skills to potential hires, and a good chance for an interview task.
- hocuspocus 11y agoAtlassian does something pretty close. Once you've successfully passed the first step (automated online assignment), you receive a maven project by email 15 minutes before the interview and then use Skype screen sharing to show what you're doing. It starts with writing a unit test to show that some method is misbehaving, then fixing it, and it goes on. I really enjoyed it even though I failed miserably, and I believe I would have done much better if it hadn't been done in one hour. The exercise was really novel to me after having interviewed with a dozen companies who think Google-style coding questions are a silver bullet.
- ahstilde 11y agoWhat company uses this methodology?
- twic 11y agoe2x did exactly this. We had a tiny web app with one controller, and the candidate had to implement some small feature. Looks easy. But some tests are failing, some are passing incorrectly, there's misnamed code, dead code, and various other traps. We did quite a bit of rescue work on projects screwed up by other consultancies, so it was even somewhat realistic. At Pivotal Labs, we have an interview project where the code works and is tested, but is a horrifying big ball of mud. We ask the candidate to add a few features, but really, they need to refactor heavily first.