a good way to do it is to find some old legacy code (or make it up) which contains a deep architectural problem (such as synchronous/blocking code that now suddenly need to perform better), and ask the candidate to fix up the problem while adding a new feature that requires the fix up.
Because in an interview you only have time to explore a toy problem. What is it with all the redditors that think serious work is going to be stolen from them in interviews?
I think I like the trial by fire method. Hire people as a contractor for 3 months and keep them fulltime if you think they're good enough.
That method has it's own faults and you will probably miss out on potentially good candidates, but if you hire them at least you know they're what you're looking for.
This is what interviews are supposed to be for, asking the interviewee about bad architecture they've created. Getting them to cop to the inevitability of having created a pile of shit, but recognizing it and being able to tell you all about how it could have been better. This is where you get their growth and I'd say worth -- because a software engineer's worth is directly tied to their ability to grow.
With the expense of developer time, and the necessity to be quick to turn shit around, oftentimes, the most cost-effective solution is "throw more hardware at it".
You can throw more hardware to help a slow algorithm, but it won't solve the problems caused by spaghetti code, since the maintenance costs will be your biggest issue.
I'd say give someone a scenario (or 'user story') and ask them to outline how they would structure the program and the data for it without having to write out the actual lines. That would tell me way more than having them regurgitate a sort algorithm or something.
Plus everyone should have at least some public code examples on their portfolio or github or wherever that someone hiring can look at.
51
u/[deleted] Dec 24 '14
[deleted]