I'm hiring a senior developer right now. Our first interview has a 4-question screen, where I ask them to implement a simple function, implement a recursive function, write a simple SQL select (join across two tables), and create a simple object model (how would you represent a car as an object).<p>~70% of the "senior developer" applicants fail<p>We're extremely happy with our process--this is only step 1--and it's been amazing at yielding a great set of candidates for each hire, but two weeks of administering the tech screen to applicants leaves me a bit depressed. (sigh)
Just out of personal curiosity, you should try to find out if any of these failed candidates are actually skilled developers but there's something about the questions or interview that's messing them up?<p>For example I consider myself a reasonable programmer, I can certainly do any project put in front of me. But I failed a YouTube phone interview because they asked me to "say" a function for finding the longest common subsequence of a set of strings.<p>I learned the following issues completely stop me from being able to program:<p>1. Someone waiting on an immediate answer.<p>2. Someone watching/listening to my though process.<p>3. Not being able to experiment with the code on a computer.<p>That didn't cut it for them because apparently at YouTube a lot of your programming is done over the phone (sarcasm).<p>I guess my point is, try to think of the exact tasks this hire would be doing, and ask them to do that. Will they really be writing recursive functions often? Also if possible give them a take home project, so they can work in a more natural environment.
Senior Developer does not always mean coder. It means, in my view, senior-level experience and senior-level judgment.<p>What are the job requirements?<p>I was a manager for 10 years and didn't code except to fix bugs. When I coded, I used C/C++. As a senior manager, I oversaw the JavaEE application strategy at Sun.<p>At any rate, today, I am a Senior Developer at a start up that uses LAMP. I would have no problem answering your questions today but it took me a full month to get back up to speed.<p>It may be that you are focusing on the wrong questions, it may be that your job description is attracting the wrong candidates, or it may be that you are not promoting the job in the right channels.<p>Good luck.
Not depressing at all, completely representative of the job pool.<p>The technique you're using isn't common - a lot of traditional companies don't interview on skill and technique (like Google do).<p>Backing up your 70% of failures, we recently hired a fashion designer at our startup (we're in an interesting market!) I decided we should use the same kind of interview we would for a developer.<p>Everyone we interviewed was completely baffled, but it really sorted out the wheat from the chaff. At least 80% of the people we interviewed couldn't do what they said.<p>Thankfully though, we've ended up with someone who is really incredible. In fact, I think she has the 10x higher productivity that us developer types talk about, and her old employer is trying to hire her back.<p>tl;dr - looks like you've got a normal pool of applicants!
I would be careful with your questions. There's a lot of bias that you can create without being aware of it.<p>I once had an interviewer ask me for the five rules of database normalization. Beat the heck out of me at the time -- I was just drawing a blank. I could do the work all day long, but I couldn't remember the stupid names he was looking for.<p>Similarly, I had a guy ask me to name the seven categories of this course he was interested in that I had taught years ago. Same deal -- just couldn't recall it, although I was very familiar with the material and had no problem teaching it.<p>The problem with memory questions is that they bias against people who don't currently have the answer in working memory. Simply because somebody has done something recently is no indicator of performance. The best interviews warm up on general questions about the material before diving deep. That gives a candidate time to "change gears"<p>I also very interested in "why" questions over "how" questions. Classrooms and cram-lessons are really good at "how" questions -- it takes some degree of actual work to understand the "whys" of something.<p>I've interviewed a lot of developers over the years. 99% of them really aren't anywhere near as good as they think they are. That's sad, but it's also an opportunity for developers who care about their work to get ahead. It doesn't take much ongoing effort to be truly outstanding.
Good developers get hired and removed from the pool. Bad developers go to the next interview.<p><a href="http://lesswrong.com/lw/gy/you_are_not_hiring_the_top_1/" rel="nofollow">http://lesswrong.com/lw/gy/you_are_not_hiring_the_top_1/</a>
do you screen them over the phone? seems to me like it would be much easier and less depressing if you just gave them the work, gave them an hour, and told them to email the results back to you. stuff that is nontrivially difficult such that they can't just search and find answers. they have to know.<p>edit: i think i'd prefer having to do this myself, as well, because i'm a shy person in person and i find myself floundering when i'm on the phone and have to "explain my thought process" to someone as i'm working through it. i'd much rather write down an explanation.
Are you depressed because your filter has proven very effective? It seems you should be happy. ;-)<p>The thing to worry about with a very discriminating filter is, like tocomments post, whether you are filtering for something different from what you really want...
Yes, it is depressing.<p>That said, I've had success with doing the pre-screen in a Campfire room and asking them to Pastie/Gist their code into the room. That way, you eliminate some of the weirdness associated with coding over the phone, but you maintain much of the immediacy.
For my current job (for an entry level position), I took a one hour test asking to do pretty basic coding prior to interviewing with anyone. It asked to find errors/poor practices in a code snippet, some quick logic/binary operations, and a larger question involving linked lists that required a few minutes of planning before I began writing code out.<p>This was a comfortable setting for me. Though in previous interviews, I would completely freeze when someone wanted a technical explanation, simply because I need a moment to collect my thoughts, and it's difficult to do so when someone in front of you is looking for an immediate answer.
The only ones that somewhat depress me is a particular class of bad developer: Fresh out of college, these people have their curriculum <i>nailed</i>... and know <i>absolutely nothing else</i>.<p>One example that really struck me was an interviewee that I asked to write a simple pre-order traversal on a seven-node tree that we print out for our interviews. Instead I got a moderately lengthy and correct description of how to search for a value in a sorted binary tree. Correct, except for A: it wasn't the question I asked and B: immediate visual examination of the tree we were looking would reveal it was clearly not sorted. Other things in this interview led me to the conclusion that I got that answer because this person had studied that topic, but almost couldn't even hear, couldn't perceive a question that wasn't essentially right off an exam.<p>These are the ones who depress me a little, because they have clearly done everything everyone told them to do (study hard, do well on tests, etc) and must have some significant raw intelligence to be able to do this well on a challenging curriculum... yet, for all that, they have walked away with so very little useful knowledge or skills. I also feel some anger at the system that they have learned too well to navigate... but by the time they get to me, it's too late to change anything.<p>I comfort myself in the near-sure knowledge they will find a job somewhere. Some percentage of them will even adapt to the real world and perhaps they will become great programmers. I don't know. I can't know. That's life.<p>But I can't in good conscience give a thumbs up for them. We are willing to train solid developers and we have a track record of hiring people that don't even know the language they will be working in (since they have demonstrated the ability to learn languages in the past), but you can only take that so far.<p>On the other hand, those who sat in college for four+ years and know neither the curriculum, nor any other skills, just barely squeaking by with the necessary grades and forgetting everything as soon as the class is over, well, they had every chance to realize they were in trouble and didn't take it. I don't feel depressed about them at all. That such people exist is just a fact of life.
I'm not sure why that's depressing. You've managed to filter out the majority of people you'd not want to hire with just a simple set of tests.<p>Perhaps a way to screen out many of these people without spending the time administering the screen is to have a simple coding test that these people complete before you'll even have them in for an interview. A couple places I've interviewed with did this, and they both expressed high satisfaction with the reduction in interviews of hopeless candidates that resulted.
Part of it may be your questions, and part may be HOW you're asking (e.g. over the phone, or putting someone on the spot).<p>2) Not a lot of people write SQL by hand anymore. I used MySQL for years, long ago, and never wrote a join. Then ORMs came along and handle joins automatically, so I've still never written one. So not being able to do it without looking it up doesn't really tell you anything. I've written far, far more complex things than an SQL join statement. A more pertinent issue I'd be checking for is whether user input is properly escaped to prevent SQL injection -- again, not an issue with ORMs, but an issue when building SQL query strings by hand.<p>1) A lot of people use languages where recursion is unusual (i.e. NOT Lisp). Even a senior developer (especially of something like PHP) might not recall this, not having actually written a recursive function for years.<p>3) Representing a car as an object: A lot of software people don't know hardware, so the confounding part might be recalling various attributes of cars and how they relate to each other.<p>Also keep in mind that many introverted people get very uncomfortable when someone is waiting on them. This can make it difficult to concentrate at all. Being asked to perform on demand is normal for a musician but foreign to most programmers. On top of that, it's usually in an unfamiliar environment, such as verbally or on a whiteboard -- imagine asking a violinist to play on some lines you drew on a piece of paper.<p>PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files.
Flemlord, a lot of responses seem based on hypotheses about what a good answer would have been. Could you follow up and give examples of what you'd have considered correct?<p>My hobby-programming experience suggests...<p>simple - int add(int a, int b){int result; result = a + b; return result}<p>recursive - um, I like fibonacci sequences: void fib(int term){if term = 1 return 0; if term = 2 return 1, else return fib(term - 1) + fib (term - 2)}<p>SQL join: no idea, I haven't used SQL for years. I assume you mean something like for(i = 0; i < table1.length; i++) do {newTable.fullname[i] = oldtable.firstname[i] + anothertable.lastname[i]}<p>Car as an object: well I guess I'd have a struct with variables for size, weight, power, turning circle and so on, and methods for accelerating, setting direction [steering heading, speed (forward and reverse, or multipliers for forward gearing)] and braking...then I'd have create multiple instances of that object using a table of values...do you make racing games?<p>I'm not looking for a job, but I'm interested in knowing what sort of answers you were after. The above seems super-simplistic to me, I'd feel nervous they were trick questions of some sort and the obvious answers are actually the failing ones.
Steve Yegge's post on this is apt and may help those who haven't read it.<p><a href="http://steve-yegge.blogspot.com/2008/06/done-and-gets-things-smart.html" rel="nofollow">http://steve-yegge.blogspot.com/2008/06/done-and-gets-things...</a>
I have kids, and whenever I do interviewing, I get worried about their future. I think the secret is to get them to feel passionate about something; as long as they have the motivation, they'll want to learn. But how to do that? And what if I fail? I shudder to think they'd have to stay in some of the crappy jobs I've been able to leave.
Outsource Step 1 with an on line programming screen. There are many companies that do this. Sure you'll have to pay for each one, but they will weed out the bottom 90% pretty quickly.
Yes. I used to do the chatty bit first before subjecting interviewees to the "technical evaluation"; it seemed polite to engage people first.<p>That was depressing. At least I found out the technical evaluation was worth giving. An astonishing proportion of people that came off well in less technical conversation would utterly flunk the test.<p>I'm not talking minor errors caused by interview pressure. I mean people with "5 years of C++ experience" writing void reverse_string(char* in) { char b[] = new char; b = in; ... }
I think the best solution is to ask the questions in as many possible ways you can think of.<p>Some people are great at coding, but suck at whiteboard, others aren't comfortable talking about their thought process.<p>So why not give them numerous ways to show their stuff? Have them find bugs, have them code on whiteboard, have them write code in a compiler, etc etc.<p>Your goal is to find a good programmer, not a programmer who is good at white board.
Interviewing leaves me depressed. I just spent most of an hour proving I can't verify whether a tree is binary. Mostly, we didn't focus on anything relating directly to the position or talk about my experience in any way. We proved that there are holes in my education pertaining to basic CS, that I never encounter on a daily basis as a web developer. I guess the rest of the stuff was taken for granted.<p>I understand that these tests can be important, but I can't help but feel that I will fail to qualify for any position that requires me to hold a host of basic CS algorithms in my head, but that I could still do a good job in the position - because I'm very good at learn as you go, and have learned lots of higher level stuff while building elegant, complex systems - without knowing how to verify a tree's binary nature.
I've been working for 3 years as a front-end developer and somehow have managed to pick up all of those skills minus the join (just started learning SQL last week). Maybe your pool of samples is tainted. Where do most of your applicants come from?
My experience has been identical to yours. Ask simple questions, get constant failures. In bad times, the signal to noise ratio is completely out of wack. A recession is the worst time to hire people.