|
You can judge programmer's ability in 60 minutes. Can someone program? 60 minutes is way more than enough. How great of a programmer are they? You're going to need more than 60 minutes, unless already had a chance to look at their prior code base. What's difficult to judge is, are they organized? are they hard working? how do they handle stress? how's their communication and attitude? do they write great documentation? do they test their code? are they a great team player? how creative are they? Due to time constraint of an interview, someone might be more sloppy than usual. Their might be the interview stress which is different from regular work stress, interview stress can impact their communication, etc. But if we focus plainly on technical skills, you can flush that out in 60 minutes. I'm a hiring manager, and I have never failed in hiring someone who didn't have the required tech skills. Technical ability I can always hit spot on, the tough one is determination and soft skills. Some of the folks I took chance on, who displayed terrible soft skills during interview turned out to be champs, communicate great, work hard, etc. A few that were very eloquent during interviews were a disappointment, sloppy in development, poor communication in practice, etc. People also grow, so someone that was a bad fit/interview for you, could in a few years grow and become great. Potential is also difficult to spot. |
Last year, I interviewed with a well-known media company, and they gave me a take-home coding challenge which was essentially about building a notes application in Rails that philosophically replicated a file system; notes could exist in any part of a hierarchy of directories, but no same file could exist in multiple directories at once.
Seems pretty simple, right? Anyone with a fair amount of experience with Rails would probably whip up some models for folders and notes, folders would has_many :folders and has_many :notes, and notes would belong_to :folder, etc. A solution along those lines would probably have sufficed for the coding challenge, as it would demonstrate knowledge of Rails.
But I couldn't just leave it there. That kind of solution would have been extremely crappy in a situation where there is a huge amount of notes in deep directories. After a few hours of careful thought, I came up with a solution similar to how Amazon S3 works, where directories are really just keys in a database and the stored files(or notes in this case) are the values of those keys.
My solution had the advantage that directories and their files could be queried through simple string matching, meaning that queries scale linearly with deep and complex directory structures rather than exponentially. The only case where things might be less optimal is during directory renames, in which case all sub-directories and files would have to be found and updated, but I considered that a compromise since renames happen less often than reads and writes.
They liked my solution enough that they flew me out for an on-site interview, and they said that nobody else came up with that solution.
Would I have come up with that solution if I was given 60 minutes and had someone looking over my shoulder? Probably not. Such limitations prevent taking time to think and letting the mind ponder, which is valuable.
If that challenge was done in 60 minutes, they would have assessed that I knew Rails but probably wouldn't know how I actually approach problems.