Quote:
Originally Posted by suzzer99
I'm just honestly curious if it's possible that a good developer could've failed the task of creating a 2D array that badly. If so then I feel like you have to question everything about the current standard process for interviewing programmers. Maybe there's some kind of market inefficiency – where good developers are slipping through the cracks – that could be exploited here.
Quote:
Originally Posted by adios
Stop wondering, competent people flub interviews even if the person is asked to code in a more natural programming environment than on a whiteboard. I have no data to to back this up but I would think that recommendations from developers you know to competent are much more reliable than how someone codes on a whiteboard in an interview in predicting success as an employee.
I think it's interesting how wildly interview experiences can vary. At the company I started at late last year, my interview involved some whiteboard stuff (which I found very unnatural, my usual method of working through problems is stabbing at random code that doesn't solve it until my brain works through why it doesn't work and what would have to change in order for it to work) with a problem involving in-place data transformation. I figured out a good algorithm to solve it but in terms of writing out code to get the job done, was getting stuck in the mud on a few random details. In the course of solving that problem in an actual job environment it would hardly matter, but when you have only 30-60 minutes to solve something it could be a major impediment. Luckily, the guy interviewing me could tell that I understood the big picture and captured that as the important takeaway. In the months since then though it's funny to sometimes hear other engineers tell nightmare stories about people utterly failing at the problem in other interviews and wondering how close I was to being in that room with someone who might have been more concerned with the fact that I didn't ultimately come up with working code, even if I did grasp what the solution was.
The entire interview process though (which involved talking with a few different developers and solving a few different problems) was mostly focused on general programming problems. A lot of stuff at this company is new to me - everything's on Macs (which I had never used before), our source control is git (always used Perforce before), and I've had to get familiar with a lot of Unix type stuff. A couple months in, my manager (I use "manager" loosely, he's a programmer and the managing is mostly just in name/for organizational purposes) was talking about a guy he was interviewing to join our team, and apparently he asked him a ton of questions about Unix stuff, build processes and tools, and nitty-gritty kind of details. This guy, who I believe is pretty happy with my work so far since I joined, would have
killed me had I interviewed with him!
Anyway, it's opened my eyes a little to how inexact the science is of finding qualified developers. It's very easy for me to see the potential ways in which my interview could have gone differently and I may have not even been hired for a job I'm doing very well at.