I worked for a German startup too and our main problem was not vetting interviewees but finding people who want to interview at all. In the five year history of the company I think only one single person was hired who was not already friends with someone at the company.
Other people just never applied. I remember manning the booth at one of those college campus events and it was very lonely. I probably talked to three students that day. Nobody followed up with us. I even had the distinct feeling that students avoided eye-contact with us and made beelines for the booths of the big established companies.
In the end, our hiring interview process for interns was 'do you want to work for us? yes? you're in' and for full-time applicants it was simply non-existent. I think in the last three years we did not interview a single person.
I often wondered why that is but I have never found a good answer. In the end it worked out for us. The company was acquired by Google.
Still, I would have liked to have some applicants and interviews once in a while because I keep reading so much about them and I wanted to practice being an interviewer to avoid pitfalls as described in the article.
Was your company offering "business solutions" by any chance? I remember once walking across an IT fair in Munich and being floored at the extreme boringness of all the company banners. They all seemed to provide "solutions" - whatever, no details about what they were doing (solutions for what?), nothing special going on. My brain was completely drained after the walk.
Just saying, maybe a better presentation could help. Also working in a software company is a kind of dreadful outlook, even today (neon lights, specs filled with hundreds of pages, dreary meetings...).
Maybe it varies between regions. We were based near Mannheim, and it was hard to find interesting software startups. Our town even has a technical university which meant that graduates were always looking for jobs in a market that didn't have that much to offer. In the web world, developers mainly had the choice between working for an advertising agency or work at a very small shop with less than 5 people. Non-web devs would have to choose either IBM in Mainz or SAP in Walldorf as a matter of course. At least that's what it looked like from my perspective, I could be wrong. So yeah, we got a lot of CVs for any job postings and people were also sending them in when we had no openings. I guess the region was just starved.
I have heard this anecdote from many of my friends as well. So my advice would be : any devs frustrated with jobs in their country head over to Germany ! It's a beautiful place with a comfortable work culture ...
When we advertised our job posts through different media nobody reacted. Headhunters would send us candidates which were too expensive for what they were worth.
So I ended up hiring ex-colleagues and friends who I convinced to start working for us. In the mean time we took 2 interns a year offering a job to the suitable candidate(s). This we we were able to hire staff.
The slow hiring process meant I needed to outsource some projects abroad to off shore development companies.
Ah Germany - where I just gave up applying for jobs.
"Oh, yeah, I see - you've got 10 years of experience. But what's that? You don't have a diploma? Nor a 'Ausbildung'? Sorry, in this case I just won't look at your prior work - no matter how cool it might be. Have a gut day, sir! No job for you."
The only hiring process I have found to work for developers is to sit down and work on real code together.
This gets to the heart of the matter, and you very quickly feel out someone's knowledge, ability, and most importantly, how well they collaborate on a problem. Because in a startup you will need collaboration, and likely under the highest stress moments you've seen in your life.
I also feel like this gives applicants a much better opportunity to learn about their possible future company and coworkers, and whether they themselves would like the fit. If you have not done this sort of interview, even if you have never pair programmed, try it out. It's very effective.
What I'm still trying to learn, is what screening process to use ahead of this. Sadly, you can't invite everyone for an on site day long interview. The best I've come to is to look at what applicants have made on their own time or alternately how they talk over the phone about topics and problems they're excited about. Resumes are nearly useless.
The spare time issue is an interesting one. One one side we have companies saying that they look for programmers who are working on projects after they get off work and on weekends. On the other side we have companies having employees sign a contract claiming that everything they do 24/7 belongs to the company. Often both sides are the same company.
It's not an issue for me only because I work for my own firm, something I had to do to get out of such bizarre situations. But it's an issue for many programmers who are told that working on their own projects is stealing time and mental energy from the company. I can certainly sympathize with the talented developer who, told that the company owns all his private projects done in his own time on his own equipment, simply chooses to leave at 5 and spend time with his family rather than have passionate private work seized and shelved by a firm who had nothing to do with its creation. It's really the rational choice if you think about it and something very valuable in a developer is rational thinking.
To be honest everywhere that I have applied as a programmer has either had the 24/7 rule or a contract so unspecific that it leads me to think that they will try to take ownership of something I write if it does indeed lead to a valuable product. As such I am usually working on projects in my free time but I rarely want to tell them about a real project for fear of them trying to take it. It creates a difficult situation in an interview, when I have projects but I dont want to discuss them.
And in some states (like washington), by law, work done on your own time with your own equipment that does not directly compete is yours too. (And the law even says you have to put it in the contract!)
My previous employer (http://thefrontiergroup.com.au) had a process where candidates would come and spend a day onsite. You'd be paid for the day.
The process was to work together with a senior coder on problems of escalating difficulty. Starting with
1.upto 10 do |i| { print i }
"What does this do?"
And ending with "Here's a legacy application we maintain. Add a new widget to the dashboard. Think aloud."
During the day you had lunch with the team.
Even so, that process didn't work perfectly for them. They hired me and about 6 months later they decided to fire me.
Subsequently they've focused on hiring people they already knew. For example, they've hired Darcy Laycock (http://sutto.net/), who they've known through the Rails community for years.
... and in all fairness I'd sack about 5 of me to get a Darcy on board.
In my previous "day" job, I probably interviewed more than 100 candidates and hired about 15-20. Here's what worked for me:
1. Phone screen (~45-60 mins). I'd spent ~15 mins going over what the company does, what the work environment is like, the team structure, the personalities, the technologies, etc... I'd try to "sell" our opportunity to jazz up the candidate and get them at least curious and hopefully very interested. I'd weave in a little of why-are-you-changing-job, what-was-your-experience-like, or what-would-you-prefer, and then ultimately we spent the majority of time on a recent project that he/she can talk about in depth. I pushed on a few related technical aspects to those projects to see if the candidate could clearly explain himself/herself technically.
2. First round (1.5-2 hrs). If I liked the candidate's potential after the phone screen, I'd invite him/her to our office to meet me and another engineer. We'd go into more depth about their recent project(s), and then go through a design/code exercise for a web application (the company builds web apps). The exercise was very open-ended (there's really no one correct way to do it). The design/coding choice depended on many factors, and we helped steer the conversations so the candidate could talk about those factors and what he/she would do to handle each of them (including when not to handle certain situations).
Along the way, we also probed into how he/she would work with other team members, how/whether to "challenge" another colleague, what/if any development process he/she would follow.
There was no trickery, no reversing a string, no linked lists. But I might ask how one would deal with concurrency conditions (two users trying to claim a single resource), how to scale with traffic, etc...
The candidate was encouraged to ask questions throughout the interview. It was a two-way street after all.
3. Second round (another 1.5-2 hrs). If first round went well, I'd invite the candidate back to meet a few other employees (e.g., another engineer, a Product Manager, a designer for example). I asked these other employees to ask anything they'd like, but at the end be able to tell me if this candidate would a) be smart, b) get things done, and c) have right cultural fit. If anyone had strong objection from this round, it almost always resulted in no-hire.
Equally important to hiring well is to let employees go quickly if they don't fit. That's a separate subject worth its own post.
Seems to me you just shouldn't ask typical "CS problems". The problem with those is that a positive result doesn't necessarily mean that the candidate knows anything. It could be that they've just interviewed so many times that they know a few common answers to memorize.
I still think asking coding questions is extremely important. Programming is one job where you can actually test skill in the interview (unlike management for example, where you mostly have to rely on personality, work history, and references). I don't know why you woulnd't take advantage of that opportunity.
As for culture fit, obviously you need to do that too, but that's somewhat orthogonal to what else you ask about in the interview.
I agree that these types of questions can lead to false positives, but what about the negatives? Don't these have some value as filters? After all, if I can't answer a simple question like string reversal, it suggests that I can't code AND I'm not enterprising enough to do some rudimentary Googling to practice technical interview questions.
If you assume the goal of an interview is to hire "good" people then you're right. If you assume the goal of an interview is to not hire "bad" people, then I think you're wrong.
I think in practice it's almost impossible to determine if someone is a "good" hire based solely on an interview (regardless of technique). It is possible to determine is someone is a "bad" hire based on an interview however.
Despite having written tens of thousands of lines of open source code, I have yet to have an interviewer who has looked at that code and asked me about it.
That speaks volumes about the interviewer(s) and their company. Did no one look at your resume before speaking with you?? If not, that's inexcusably inefficient.
Do you mention it in your resume or cover letter? We try to look up information about people (blogs, open source contributions, etc.) before or between interview rounds, but it depends on how much the candidate pushes it and how much time the interviewer has to look into it.
Just having committed to an open source project would put you way ahead of most of the people we interview.
Whenever I see a resume with open source code, I always visit and try to read some of their code. I rarely ask them about it (there's little time), but it does inform which questions I want to ask in the interview and my overall impression of their skills.
My last interview at the company I'm at now went somewhat like this: "Your CV looks fine, we wouldn't care if you're an axe murderer, now what would you like to do/tackle?". Should have been a warning sign: interesting company to be at.
Speaking from personal experience, a bad job can leave your "passion" somewhat lacking. I think if you asked anyone I work with today, they would definitely describe me as passionate. There are indicators that I am doing well there. I can't agree more with this article. I absolutely hate doing tech interviews. I can not code under pressure. Even in the most high pressure situations with an outage or huge customer issue, I always take a step back, think, and try to see what else might be affected before doing anything.
I hate tech interviews so much, that I never do them. I mostly do unconsciously what this article lays out. I would say personally I've experienced better than average hires if I happen to be positive on the person, doing what this article suggests in an interview. I have missed good people (was overridden) and have failed tons of tech interviews where I thought I would be an excellent fit on the other qualifications.
You'll have to ask my co-workers if I'm good, but they tell me I am.
While at my last job I was tasked with being apart of the interview process. My favorite question was "how do you keep up with web technology and trends? (web development)" and I was surprised at how many people had no answer for that simple question.
My response to my manager was "this dude wont work"
I've experienced the same thing while conducting interviews. The flip side is that some people have great answers and they often open up and show their passion for programming when they get to talk about the things that interest them and aren't as focused on how nervous they are trying to answer your question correctly.
I've also has people tell me that they read the study guides for the Microsoft certification exams. I'm not trying to start an argument about the value of certifications. I think it is questionable though when asked how someone keeps up with the latest technology, they reply that they read books with content of questionable real world application, from a single company, that are updated every three or four years.
Here's my 2c's on this as a 12 yrs Software Eng and a startup founder:
1) Software development is a TEAM work, so asking one questions like "how did you design this or that" is just pointless. We did design that on that specific period of time...Our motivation was ...
2) Good Developers Copy, Great Developers Steal (altered from P.Picasso), so we all use Google, HN, GitHub, wikipedia and alike to innovate our solution, so if you ask me B-Tree algos, I'm sorry, but I've to look at wikipedia...
3) Hiring process is just a scumbag for both parties, you impose big, the other party imposes big. So what? You're not Google, and he's not Kevin Mitnick...
4) I think, companies should try to get the personality, not the KLOCs of applicants. If you gonna ask programming puzzles, please be authentic and ask something related to you. Not just copy a Googlr interview question because you liked it.
1) Simple programming challenge (< 30 minutes) by email. To see if they can actually write good code. Resume/age/experience/location mostly disregarded.
2) Casual discussion-style interview to get to know how they think and behave.
3) Short term contract with a predefined project (< 3 months) to see how they work over time.
If (3) is working for you, great; however, bear in mind that it's a seller's market for talent right now. I'd neg an offer contingent on doing a 3 month contract first, and I'd advise my friends to do the same; why should I shoulder that risk, if there are 2-3 other good positions open that will take it on for me by offering FT right away?
I once learned a shocking lesson about the influence of my preconceptions when I accidentally took a developer through three rounds of interviews because he previously worked for Pivotal Labs and had a German (aka technical) accent.
It wasn't until the third interview that I asked him to write an algorithm to sort an array and when he couldn't I suggested instead writing an algorithm to see whether the array was already sorted. When he couldn't do that either he told me I was asking the wrong questions and not letting him show off the code he was good at.
To this day I have wondered and never discovered what type of code doesn't involve arrays, loops and comparisons however I do now ask candidates to write code right at the start of the interview loop. I simply never anticipated how many non-programmers would apply for programming positions.
It seems fairly obvious that a pure tech interview doesn't screen for cultural fit, and that you need to have some form of behavioral/cultural assessment as part of the interview process.
Depending on how much time you have to interview (and I suggest you take the time if you're going to hire someone!) the "standard" dev interview can do pretty well at weeding out candidates who clearly lack basic skills. Joel Spolsky is a proponent of this and I agree.
I've found that passion is a great indicator of future success, and you can usually get a good quick read on whether they are serious about software development by asking people about their favorite projects, what they spend their time working on, and what interesting things they see happening in the field.
I once decided to skip the standard programming problem during the interview process, and I ended up regretting it extremely. The person we hired was nice, and a good "culture" fit, but couldn't code for beans. We had to let them go and I felt pretty bad about it.
Programming questions certainly aren't the be all and end all, but as a filter they are useful.
Programming questions seem also useful for companies trying to make a good impression on the candidates. I find that companies with really interesting technical questions are more likely to spark my interest than companies whose hardest question is "How would you reverse a string in Java?"
I never really understood why companies don't just take a non-trivial real problem that they have run into during development. Just ask the candidate to talk it out, see if they are able to at least get on their feet toward a solution or an idea of possible solutions.
I've never hired anyone, but I can tell you that I could write a linked list in a handful of languages. I can also tell you that it doesn't say much about what I know (or perhaps more importantly, don't). Problem solving is what is important, more important than ability to write code on a whiteboard.
Definitely agree with this post. I've been interviewing for the last couple months and one of the better/more fair interviews I've had involved a nice back and forth (mostly the types of questions posed in the article, including a lot of stuff about my outside projects).
Then they brought me in for a tech interview where they plunked me down in front of a computer to architect a small application for a type of problem I might encounter on the job. I thought it was fair and it probably gave them reasonable insight into how I code/think/present my solutions.
I've had a lot of "write a linked list" style and they're draining. The quality of the applicant being pulled in to do CS trivia is going to be all over the place since that type of an interview can be gamed fairly easy if someone has a desire to do so.
I was very impressed when an employer used an open notes, take home exam in the second interview. Initially, they had tried a written, proctored exam during the first interview.
Although I was the only candidate among many who did not claim any experience in the actual technologies listed in the position, I was also the only candidate who turned in the take home exam. I also completed my working code in 8 hrs rather than the week time limit. The others all quit the exam at various stages because they did not possess the tenacity to hunt down technical knowledge online required to implement the proof of concept software. At the third interview, they asked me how I came to my solution and why I chose certain methods in order to validate that I completed the work myself.
This seemed like an great alternative to other exam experiences I'd had. At another interview, a non-technical company officer asked me a technical question and then couldn't explain it. The question was so opaque that it took thirty minutes of probing and badgering him to even understand the question. By this point, I was ready to write them off and leave. They lost their largest customer the next week and I would've been laid off if I'd joined them.
Writing code is just another type of conversation. Sure, you're going to ask many questions. Having a candidate code a bit in front of you, going back and forth, provides a lot of info.
As far as "CS puzzles" - binary search, trees, linked lists, hashtables, etc: None of those should be puzzles. If you're giving interviews that people can "memorize" an answer to, then the problem is how you're doing the interview. A proper conversation, including code, will quickly sort out if the person just memorized a one-line Haskell quicksort, or actually knows what they're talking about.
Do you actually find people that expect candidates to implement quicksort?
I've certainly implemented it, but there's no way I have it memorized, it's not an obvious algorithm at all. I'd be flabbergasted to be asked to implement it from memory with no warning. It seems clear to me that one would be testing for if the person happened to have looked at the algorithm recently, not if they were competent.
Bit offtopic but that CSS made reading the article a complete pleasure. With the mixture of nice readability and interesting content this post turns out as a really good essay.
I have to disagree about the uselessness of a technical interview. I'm 100% with RethinkDB that any competent programmer should be able to figure out how to reverse a singly-linked list in some reasonable time. (http://www.rethinkdb.com/blog/2010/06/will-the-real-programm...).
" Some were shooting their pre-canned answers at me with unreasonable speed."
This should not be possible for all questions in a technical interview. Especially if you are a startup, you can use your own original problems, especially ones you've actually had to solve. Aim for actual coding questions though rather than too puzzling ones that are often just memorized (implement quicksort, detect cycle in linked list in O(1) space, the random puzzles companies love to ask).
Of the people I've worked with, there is a high correlation to job performance to performance in a tech interview. (which for new grads is strongly correlated to their college CS grades).
Of course, passion is also a decent indicator, but it is highly correlated with raw competance. That said, I wouldn't hire anyone lacking either.
Disclaimer: I'm coming from the background of a systems company. For those making CRUD apps, tough coding questions might be less relevant.
[+] [-] sp_|15 years ago|reply
Other people just never applied. I remember manning the booth at one of those college campus events and it was very lonely. I probably talked to three students that day. Nobody followed up with us. I even had the distinct feeling that students avoided eye-contact with us and made beelines for the booths of the big established companies.
In the end, our hiring interview process for interns was 'do you want to work for us? yes? you're in' and for full-time applicants it was simply non-existent. I think in the last three years we did not interview a single person.
I often wondered why that is but I have never found a good answer. In the end it worked out for us. The company was acquired by Google.
Still, I would have liked to have some applicants and interviews once in a while because I keep reading so much about them and I wanted to practice being an interviewer to avoid pitfalls as described in the article.
[+] [-] Tichy|15 years ago|reply
Just saying, maybe a better presentation could help. Also working in a software company is a kind of dreadful outlook, even today (neon lights, specs filled with hundreds of pages, dreary meetings...).
[+] [-] Udo|15 years ago|reply
[+] [-] currywurst|15 years ago|reply
[+] [-] toadi|15 years ago|reply
So I ended up hiring ex-colleagues and friends who I convinced to start working for us. In the mean time we took 2 interns a year offering a job to the suitable candidate(s). This we we were able to hire staff.
The slow hiring process meant I needed to outsource some projects abroad to off shore development companies.
[+] [-] guruz|15 years ago|reply
[+] [-] ulrich|15 years ago|reply
It is a give and take. If developers are in high demand, it is the companies turn to show their value to the employee in advance.
[+] [-] mrich|15 years ago|reply
[+] [-] leon_|15 years ago|reply
"Oh, yeah, I see - you've got 10 years of experience. But what's that? You don't have a diploma? Nor a 'Ausbildung'? Sorry, in this case I just won't look at your prior work - no matter how cool it might be. Have a gut day, sir! No job for you."
[+] [-] lwat|15 years ago|reply
[+] [-] jasonwatkinspdx|15 years ago|reply
This gets to the heart of the matter, and you very quickly feel out someone's knowledge, ability, and most importantly, how well they collaborate on a problem. Because in a startup you will need collaboration, and likely under the highest stress moments you've seen in your life.
I also feel like this gives applicants a much better opportunity to learn about their possible future company and coworkers, and whether they themselves would like the fit. If you have not done this sort of interview, even if you have never pair programmed, try it out. It's very effective.
What I'm still trying to learn, is what screening process to use ahead of this. Sadly, you can't invite everyone for an on site day long interview. The best I've come to is to look at what applicants have made on their own time or alternately how they talk over the phone about topics and problems they're excited about. Resumes are nearly useless.
[+] [-] bugsy|15 years ago|reply
It's not an issue for me only because I work for my own firm, something I had to do to get out of such bizarre situations. But it's an issue for many programmers who are told that working on their own projects is stealing time and mental energy from the company. I can certainly sympathize with the talented developer who, told that the company owns all his private projects done in his own time on his own equipment, simply chooses to leave at 5 and spend time with his family rather than have passionate private work seized and shelved by a firm who had nothing to do with its creation. It's really the rational choice if you think about it and something very valuable in a developer is rational thinking.
[+] [-] PlayerJ|15 years ago|reply
[+] [-] perlgeek|15 years ago|reply
The company can claim inventions you made during work hours, and can forbid you to compete with them directly in your free time. That's it.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] elai|15 years ago|reply
[+] [-] bioh42_2|15 years ago|reply
[deleted]
[+] [-] jacques_chester|15 years ago|reply
The process was to work together with a senior coder on problems of escalating difficulty. Starting with
"What does this do?"And ending with "Here's a legacy application we maintain. Add a new widget to the dashboard. Think aloud."
During the day you had lunch with the team.
Even so, that process didn't work perfectly for them. They hired me and about 6 months later they decided to fire me.
Subsequently they've focused on hiring people they already knew. For example, they've hired Darcy Laycock (http://sutto.net/), who they've known through the Rails community for years.
... and in all fairness I'd sack about 5 of me to get a Darcy on board.
[+] [-] grammaton|15 years ago|reply
My answer would be "bombs with syntax error," assuming this isn't something that just looks like Ruby.
[+] [-] blub|15 years ago|reply
[+] [-] tt|15 years ago|reply
1. Phone screen (~45-60 mins). I'd spent ~15 mins going over what the company does, what the work environment is like, the team structure, the personalities, the technologies, etc... I'd try to "sell" our opportunity to jazz up the candidate and get them at least curious and hopefully very interested. I'd weave in a little of why-are-you-changing-job, what-was-your-experience-like, or what-would-you-prefer, and then ultimately we spent the majority of time on a recent project that he/she can talk about in depth. I pushed on a few related technical aspects to those projects to see if the candidate could clearly explain himself/herself technically.
2. First round (1.5-2 hrs). If I liked the candidate's potential after the phone screen, I'd invite him/her to our office to meet me and another engineer. We'd go into more depth about their recent project(s), and then go through a design/code exercise for a web application (the company builds web apps). The exercise was very open-ended (there's really no one correct way to do it). The design/coding choice depended on many factors, and we helped steer the conversations so the candidate could talk about those factors and what he/she would do to handle each of them (including when not to handle certain situations).
Along the way, we also probed into how he/she would work with other team members, how/whether to "challenge" another colleague, what/if any development process he/she would follow.
There was no trickery, no reversing a string, no linked lists. But I might ask how one would deal with concurrency conditions (two users trying to claim a single resource), how to scale with traffic, etc...
The candidate was encouraged to ask questions throughout the interview. It was a two-way street after all.
3. Second round (another 1.5-2 hrs). If first round went well, I'd invite the candidate back to meet a few other employees (e.g., another engineer, a Product Manager, a designer for example). I asked these other employees to ask anything they'd like, but at the end be able to tell me if this candidate would a) be smart, b) get things done, and c) have right cultural fit. If anyone had strong objection from this round, it almost always resulted in no-hire.
Equally important to hiring well is to let employees go quickly if they don't fit. That's a separate subject worth its own post.
[+] [-] btmorex|15 years ago|reply
I still think asking coding questions is extremely important. Programming is one job where you can actually test skill in the interview (unlike management for example, where you mostly have to rely on personality, work history, and references). I don't know why you woulnd't take advantage of that opportunity.
As for culture fit, obviously you need to do that too, but that's somewhat orthogonal to what else you ask about in the interview.
[+] [-] msluyter|15 years ago|reply
[+] [-] aplusbi|15 years ago|reply
I think in practice it's almost impossible to determine if someone is a "good" hire based solely on an interview (regardless of technique). It is possible to determine is someone is a "bad" hire based on an interview however.
[+] [-] michaelchisari|15 years ago|reply
[+] [-] yannk|15 years ago|reply
As an interviewer, Open Source contribution is one of the first thing I look for about a candidate.
[+] [-] limist|15 years ago|reply
[+] [-] mryall|15 years ago|reply
Just having committed to an open source project would put you way ahead of most of the people we interview.
[+] [-] zlopid|15 years ago|reply
[+] [-] joelhaasnoot|15 years ago|reply
[+] [-] cpt1138|15 years ago|reply
I hate tech interviews so much, that I never do them. I mostly do unconsciously what this article lays out. I would say personally I've experienced better than average hires if I happen to be positive on the person, doing what this article suggests in an interview. I have missed good people (was overridden) and have failed tons of tech interviews where I thought I would be an excellent fit on the other qualifications.
You'll have to ask my co-workers if I'm good, but they tell me I am.
[+] [-] emehrkay|15 years ago|reply
My response to my manager was "this dude wont work"
[+] [-] markkanof|15 years ago|reply
I've also has people tell me that they read the study guides for the Microsoft certification exams. I'm not trying to start an argument about the value of certifications. I think it is questionable though when asked how someone keeps up with the latest technology, they reply that they read books with content of questionable real world application, from a single company, that are updated every three or four years.
[+] [-] bugsy|15 years ago|reply
[+] [-] krakensden|15 years ago|reply
[+] [-] eaxitect|15 years ago|reply
1) Software development is a TEAM work, so asking one questions like "how did you design this or that" is just pointless. We did design that on that specific period of time...Our motivation was ... 2) Good Developers Copy, Great Developers Steal (altered from P.Picasso), so we all use Google, HN, GitHub, wikipedia and alike to innovate our solution, so if you ask me B-Tree algos, I'm sorry, but I've to look at wikipedia... 3) Hiring process is just a scumbag for both parties, you impose big, the other party imposes big. So what? You're not Google, and he's not Kevin Mitnick... 4) I think, companies should try to get the personality, not the KLOCs of applicants. If you gonna ask programming puzzles, please be authentic and ask something related to you. Not just copy a Googlr interview question because you liked it.
[+] [-] staunch|15 years ago|reply
1) Simple programming challenge (< 30 minutes) by email. To see if they can actually write good code. Resume/age/experience/location mostly disregarded.
2) Casual discussion-style interview to get to know how they think and behave.
3) Short term contract with a predefined project (< 3 months) to see how they work over time.
4) Full time hire with salary + equity.
[+] [-] tptacek|15 years ago|reply
[+] [-] spamizbad|15 years ago|reply
[+] [-] petenixey|15 years ago|reply
It wasn't until the third interview that I asked him to write an algorithm to sort an array and when he couldn't I suggested instead writing an algorithm to see whether the array was already sorted. When he couldn't do that either he told me I was asking the wrong questions and not letting him show off the code he was good at.
To this day I have wondered and never discovered what type of code doesn't involve arrays, loops and comparisons however I do now ask candidates to write code right at the start of the interview loop. I simply never anticipated how many non-programmers would apply for programming positions.
[+] [-] joshsegall|15 years ago|reply
Depending on how much time you have to interview (and I suggest you take the time if you're going to hire someone!) the "standard" dev interview can do pretty well at weeding out candidates who clearly lack basic skills. Joel Spolsky is a proponent of this and I agree.
I've found that passion is a great indicator of future success, and you can usually get a good quick read on whether they are serious about software development by asking people about their favorite projects, what they spend their time working on, and what interesting things they see happening in the field.
[+] [-] dminor|15 years ago|reply
Programming questions certainly aren't the be all and end all, but as a filter they are useful.
[+] [-] jharjono|15 years ago|reply
[+] [-] ianbishop|15 years ago|reply
I've never hired anyone, but I can tell you that I could write a linked list in a handful of languages. I can also tell you that it doesn't say much about what I know (or perhaps more importantly, don't). Problem solving is what is important, more important than ability to write code on a whiteboard.
[+] [-] okaramian|15 years ago|reply
Then they brought me in for a tech interview where they plunked me down in front of a computer to architect a small application for a type of problem I might encounter on the job. I thought it was fair and it probably gave them reasonable insight into how I code/think/present my solutions.
I've had a lot of "write a linked list" style and they're draining. The quality of the applicant being pulled in to do CS trivia is going to be all over the place since that type of an interview can be gamed fairly easy if someone has a desire to do so.
[+] [-] mncolinlee|15 years ago|reply
Although I was the only candidate among many who did not claim any experience in the actual technologies listed in the position, I was also the only candidate who turned in the take home exam. I also completed my working code in 8 hrs rather than the week time limit. The others all quit the exam at various stages because they did not possess the tenacity to hunt down technical knowledge online required to implement the proof of concept software. At the third interview, they asked me how I came to my solution and why I chose certain methods in order to validate that I completed the work myself.
This seemed like an great alternative to other exam experiences I'd had. At another interview, a non-technical company officer asked me a technical question and then couldn't explain it. The question was so opaque that it took thirty minutes of probing and badgering him to even understand the question. By this point, I was ready to write them off and leave. They lost their largest customer the next week and I would've been laid off if I'd joined them.
[+] [-] MichaelGG|15 years ago|reply
As far as "CS puzzles" - binary search, trees, linked lists, hashtables, etc: None of those should be puzzles. If you're giving interviews that people can "memorize" an answer to, then the problem is how you're doing the interview. A proper conversation, including code, will quickly sort out if the person just memorized a one-line Haskell quicksort, or actually knows what they're talking about.
[+] [-] bugsy|15 years ago|reply
I've certainly implemented it, but there's no way I have it memorized, it's not an obvious algorithm at all. I'd be flabbergasted to be asked to implement it from memory with no warning. It seems clear to me that one would be testing for if the person happened to have looked at the algorithm recently, not if they were competent.
[+] [-] joakin|15 years ago|reply
[+] [-] usaar333|15 years ago|reply
" Some were shooting their pre-canned answers at me with unreasonable speed."
This should not be possible for all questions in a technical interview. Especially if you are a startup, you can use your own original problems, especially ones you've actually had to solve. Aim for actual coding questions though rather than too puzzling ones that are often just memorized (implement quicksort, detect cycle in linked list in O(1) space, the random puzzles companies love to ask).
Of the people I've worked with, there is a high correlation to job performance to performance in a tech interview. (which for new grads is strongly correlated to their college CS grades).
Of course, passion is also a decent indicator, but it is highly correlated with raw competance. That said, I wouldn't hire anyone lacking either.
Disclaimer: I'm coming from the background of a systems company. For those making CRUD apps, tough coding questions might be less relevant.