Hmm, maybe we should 'equalize' the playing field then: Give everyone something from left field that pretty much all people bomb, that'll see how quick they learn.
Exp: You must code in an unfamiliar language (Fortran 1988, for example) and do something simple in it. At least then you'll know that people are all starting from scratch. Time it, make sure it doesn't last more than 2 hours, see how laughably slow we all are, pick those that get the furthest.
I've worked somewhere where we used this approach for one of the 5 interview sections.
Even being upfront about our low expectations and providing very friendly and helpful people to pair and guide, it lead to record numbers flipping the table and stomping off premises before the completion of the interview.
I don't use this approach now, as I don't think its a good use of time (and I think an interview should be a positive experience even for those that fail), but it did provide, I believe, a fairly strong signal of the attitude with which a candidate approached learning new things (but not really anything else).
Wow, alright, this is exactly what I was thinking. The 'novel coding' test was just one test, that it was forewarned to be laughably hard, and that you all were friendly about it. I really do want to know more about how this all went as I thought this would be a really good way to interview coders, but unfortunately I am totally wrong. I want to know why my thoughts are totally off-base.
> I thought this would be a really good way to interview coders, but unfortunately I am totally wrong.
It's not that you're wrong, it absolutely is a really good way of finding out how someone reacts to being asked to learn something new in a stressful situation. And that is a valuable thing to know - I love working with people who get excited about an opportunity to learn something.
It's just that you have to be prepared to give so much help and the question has to be so easy because it's all completely new that you can't test competence in any meaningful way. Which means that at the end of the 90 minutes or whatever, you know exactly one thing more - their attitude to learning under pressure, but you have relatively little time with them, and you probably need to learn multiple things per session.
Maybe this cockamamie way of doing interviews is the correct one then? Each company tries their own thing, and if you get flustered and bomb it, we'll both parties know it not a good fit. Some companies value the ability to learn and be cool under fire, some like GPAs, some like HW tests. The sorting occurs and is not 'fun' but works in it's own way.
I like to pose technical problems that can scale to the candidate's level of experience. If I sense I'm hitting the candidate's comfort level, I can back off. Otherwise, I can take the problem even deeper with more technical questions. Either way the candidate still has a positive experience.
This is my approach as well. Ask really easy questions and get more complicated as they do well. I also try to increase difficulty in line with the strengths espoused on their resumes. If they are fantastic with databases, I might make sure the problem can be solved well with a database oriented solution.
> Even being upfront about our low expectations and providing very friendly and helpful people to pair and guide, it lead to record numbers flipping the table and stomping off premises before the completion of the interview.
You also have to be careful when in the interview you throw this. A bad hit like this can throw a candidate off for the rest of the interview even if they are quite acceptable.
That would still not level the playing field for several reasons:
1) Some people may find Fortran easier to understand than others even if they haven't touched it before. This was the case when my University decided to use Haskell* as the first language to teach students in order to level the playing field. It did help somewhat, it leveled the field for those with little and those without any prior programming knowledge. But to those who had already come to terms with recursion etc it was a very tiny stumbling block.
2) Some people need to dive deeper and gain a greater understanding of things before they feel at ease using them, but once they have reached that level, they will often outperform most other people.
* This was 20+ yrs ago and Haskell was not so well known back then.
I’d probably pick the ones who interrupt the coding exercise, tell me how ridiculous it is, and tell me about the ways they’d solve it in plain English / pseudo code.
I love this idea. Testing how well someone can learn new skills can be just as important as the skills they've already learned. However, the problem is that as soon as it becomes known that Google is giving tests in Fortran 1988, applicants will study Fotran 1988 and thereby reduce the efficacy of the test. It will also have the sad side effect of incentivizing people to waste time studying Fortran 1988 rather than building skills useful to their job. It seems to be a good interview needs to satisfy the following properties:
* Predictive of job performance
* Either (1) difficult to optimize against or (2) easy to optimize against but in a way that doesn't reduce predictive value
> However, the problem is that as soon as it becomes known that Google is giving tests in Fortran 1988, applicants will study Fotran 1988 and thereby reduce the efficacy of the test.
How about "Google is giving tests in these 25 languages"? They could even choose languages that are purposefully dissimilar from any language that you've claimed familiarity with.
Exp: You must code in an unfamiliar language (Fortran 1988, for example) and do something simple in it. At least then you'll know that people are all starting from scratch. Time it, make sure it doesn't last more than 2 hours, see how laughably slow we all are, pick those that get the furthest.