7 ms·

As a programmer currently looking for work, I find this screening process to be draconian and insulting. As a hiring manager, I look for someone who gets thing

by edw519 16y ago

As a programmer currently looking for work, I find this screening process to be draconian and insulting. As a hiring manager, I look for someone who gets things done. No surprise that this takes many things: knowledge, skill, smarts, creativity, experience, team work, and maybe most important: attitude. You have just self-identified your bad attitude. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long. I cannot vouch for it's efficacy as I've never used it when hiring people. I can. Nothing works better. Period. If I have 30 to 60 minutes to find out how well you'll perform, I'll have you code and teach me what you've done. I don't care what you've done before, your state of mind, or even if your code ever runs or compiles. If you're any good at all, I'll find out. If you're a poser, I'll find that out, too. And if you don't want to play along, then either you're a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road. I'm not trying to insult you, just give an honest answer to your (very good) question. This comes up so often, I've responded to it before. A little more light shed here: http://news.ycombinator.com/item?id=89669 http://news.ycombinator.com/item?id=89669 http://news.ycombinator.com/item?id=834513 http://news.ycombinator.com/item?id=834513 http://news.ycombinator.com/item?id=835092 http://news.ycombinator.com/item?id=835092

danilocampos 16y ago
It's a fair point. Unless you've got a body of work that inspires a manager to recruit you with a stack of spicy magazines and a basket full of candies and fruit, there's a specific dance when interviewing. It's like an audition. At issue isn't whether you can do a task. Instead, whoever is hiring wonders can you do a task with me. So there's some jumping through hoops. The hope is that in the process of evaluating and sailing through the hoops, the interview group can establish how you solve problems, how you approach interaction with others, how you take direction, how constructively you can disagree, and maybe, as a smidgeon of the evaluation, how well you actually know your thing. In the end there's plenty you can teach about how to do the job to best suit the task and the company that's hiring. No one can teach you how to be a person, so the fit has to work. It's miserable working with jackasses who are technically competent but personally toxic.
KevinMS 16y ago
I agree with the OP and not with you. What you are doing is arbitrarily selecting a subset of qualified employees. It _looks_ like it works for you, but its probably not efficient, and can probably go wrong. When a developer is screened with tests like that, you are not evaluating them on their product, but rather on some set of skills that might overlap. I cant believe I'm using a sports analogy, since I hate team sports, but think of it this way. What if a football or basketball recruiter went to colleges, and looked at only how fast somebody ran, and how high they jumped, but never looked and how they played the game! Don't laugh, that's exactly what you are doing. You may have some success because you are screening out some dopes, but that's all you are doing. If I was the MVP on a team and some jerk took me aside and asked how high I could jump I'd be insulted. As the OP suggested, looking at the candidates past code is more like looking at how they play the game. If you suspect plagiarism, then have them explain it, beat them over the head with every design decision they made, have them rewrite something with your suggestions, it will become obvious if they wrote it or not, and you'll have a better idea if they know how to actually code, where it counts, at the construction level.
rimantas 16y ago
So your programers spend days coding at the whiteboards? And I guess open source projects don't count as getting things done?
agentultra 16y ago
Thank you for the honest reply. I was hoping someone who uses these techniques in their hiring process would explain what they find so useful about it. I've hired many programmers before myself and I've never used such a rigorous process. I'm just curious why it has become so popular, There's got to be a reason, right? You have just self-identified your bad attitude. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long. Actually my bad attitude has left me with a list of references from customers and managers who'd be happy to tell you that they've been satisfied with my work. Some of them are my best evangelists. What I find insulting is ignorance. In my original comment I mention that it's the rigidity with which the process is enforced which is insulting. I think it's ignorant of the interviewer to not bother reading a candidates' source code when they offer it (the same for their website, etc). You validate that by saying that it doesn't matter what code a candidate has written prior to the interview. That is exactly the ignorance I have a problem with. I suspect that if the goal of this process is to understand what a person's attitude, knowledge, skills and such are really like then reading their source code and blog posts would be the first step in getting to know them. I don't care what you've done before, your state of mind, or even if your code ever runs or compiles. If you're any good at all, I'll find out. If you're a poser, I'll find that out, too. And if you don't want to play along, then either you're a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road. I find that reading someone's commit history in a project can be very illuminating. The logs alone can give you a sense of their commitment to a project, what kind of work they prefer, and even a cursory glance at their skill level (are they fixing small bugs, introducing bugs, reverting a lot?). If you have time to sit down and read a few patches you can certainly see how well they follow coding conventions, whether they understand control and data structures, and perhaps even algorithms if that's what you're looking for. You can learn a lot from the code a person writes. What I was having a hard time understanding is what kind of things can white-board (or pencil and paper) problems tell you. After reading your other comments, I think I have an idea. You want to know if they can talk freely about time vs space constraints, optimization, basic control structures, and data structures. You want to know if they know the fundamentals. I can appreciate that. What I still don't understand about your process is how the candidates' previous code contributions and experiences do not matter. Can you not get the answers you seek from reading their code? If it wasn't just Joe Programmer but Larry Wall or Peter Norvig, would that change your opinion? I just don't think it's a universally applicable tool, but I find many companies that seem to think it is the only way to screen candidates. I think that some flexibility is necessary because you're dealing with human beings. The hiring process isn't an exact science IMO. Just like Agile isn't the ONE TRUE WAY to develop software I don't think you'll find a single process that will find you the best employees.
ams6110 16y ago
You sound like someone I would not like working for. And that, maybe, is just as valuable as anything else. You've got a process that identifies the type of person you've had good luck with in the past. Your process also identifies you as the sort of person I've had bad luck with in the past. It works both ways. You're missing some excellent developers who maybe are not articulate at the whiteboard but do fine at the keyboard, even under pressure. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long. How many times do you have your customers in the office, throwing out arbitrary programming challenges for your developers to solve on the spot at the whiteboard? It's fine if your methodology works for you, but you might consider that it's not the only approach that could work.
JoeAltmaier 16y ago
Sounds like a college-hire interview. With years of experience and sound references, having an interviewer insist on this "baby step" IS demeaning. And it breeds a bad attitude, sure. How about Reading the code the candidate provided? Asking questions about that? Invest some effort in a mature candidate, instead of treating them like a fresh-faced kid. Imagine the difference between interviewing a business-school graduate (What is accounts receivable? How do you track inventory? ) vs interviewing for an executive position.

by edw519 16y ago

danilocampos 16y ago

It's a fair point. Unless you've got a body of work that inspires a manager to recruit you with a stack of spicy magazines and a basket full of candies and fruit, there's a specific dance when interviewing. It's like an audition. At issue isn't whether you can do a task. Instead, whoever is hiring wonders can you do a task with me. So there's some jumping through hoops. The hope is that in the process of evaluating and sailing through the hoops, the interview group can establish how you solve problems, how you approach interaction with others, how you take direction, how constructively you can disagree, and maybe, as a smidgeon of the evaluation, how well you actually know your thing. In the end there's plenty you can teach about how to do the job to best suit the task and the company that's hiring. No one can teach you how to be a person, so the fit has to work. It's miserable working with jackasses who are technically competent but personally toxic.

KevinMS 16y ago

I agree with the OP and not with you. What you are doing is arbitrarily selecting a subset of qualified employees. It _looks_ like it works for you, but its probably not efficient, and can probably go wrong. When a developer is screened with tests like that, you are not evaluating them on their product, but rather on some set of skills that might overlap. I cant believe I'm using a sports analogy, since I hate team sports, but think of it this way. What if a football or basketball recruiter went to colleges, and looked at only how fast somebody ran, and how high they jumped, but never looked and how they played the game! Don't laugh, that's exactly what you are doing. You may have some success because you are screening out some dopes, but that's all you are doing. If I was the MVP on a team and some jerk took me aside and asked how high I could jump I'd be insulted. As the OP suggested, looking at the candidates past code is more like looking at how they play the game. If you suspect plagiarism, then have them explain it, beat them over the head with every design decision they made, have them rewrite something with your suggestions, it will become obvious if they wrote it or not, and you'll have a better idea if they know how to actually code, where it counts, at the construction level.

rimantas 16y ago

So your programers spend days coding at the whiteboards? And I guess open source projects don't count as getting things done?

agentultra 16y ago

Thank you for the honest reply. I was hoping someone who uses these techniques in their hiring process would explain what they find so useful about it. I've hired many programmers before myself and I've never used such a rigorous process. I'm just curious why it has become so popular, There's got to be a reason, right? You have just self-identified your bad attitude. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long. Actually my bad attitude has left me with a list of references from customers and managers who'd be happy to tell you that they've been satisfied with my work. Some of them are my best evangelists. What I find insulting is ignorance. In my original comment I mention that it's the rigidity with which the process is enforced which is insulting. I think it's ignorant of the interviewer to not bother reading a candidates' source code when they offer it (the same for their website, etc). You validate that by saying that it doesn't matter what code a candidate has written prior to the interview. That is exactly the ignorance I have a problem with. I suspect that if the goal of this process is to understand what a person's attitude, knowledge, skills and such are really like then reading their source code and blog posts would be the first step in getting to know them. I don't care what you've done before, your state of mind, or even if your code ever runs or compiles. If you're any good at all, I'll find out. If you're a poser, I'll find that out, too. And if you don't want to play along, then either you're a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road. I find that reading someone's commit history in a project can be very illuminating. The logs alone can give you a sense of their commitment to a project, what kind of work they prefer, and even a cursory glance at their skill level (are they fixing small bugs, introducing bugs, reverting a lot?). If you have time to sit down and read a few patches you can certainly see how well they follow coding conventions, whether they understand control and data structures, and perhaps even algorithms if that's what you're looking for. You can learn a lot from the code a person writes. What I was having a hard time understanding is what kind of things can white-board (or pencil and paper) problems tell you. After reading your other comments, I think I have an idea. You want to know if they can talk freely about time vs space constraints, optimization, basic control structures, and data structures. You want to know if they know the fundamentals. I can appreciate that. What I still don't understand about your process is how the candidates' previous code contributions and experiences do not matter. Can you not get the answers you seek from reading their code? If it wasn't just Joe Programmer but Larry Wall or Peter Norvig, would that change your opinion? I just don't think it's a universally applicable tool, but I find many companies that seem to think it is the only way to screen candidates. I think that some flexibility is necessary because you're dealing with human beings. The hiring process isn't an exact science IMO. Just like Agile isn't the ONE TRUE WAY to develop software I don't think you'll find a single process that will find you the best employees.

ams6110 16y ago

You sound like someone I would not like working for. And that, maybe, is just as valuable as anything else. You've got a process that identifies the type of person you've had good luck with in the past. Your process also identifies you as the sort of person I've had bad luck with in the past. It works both ways. You're missing some excellent developers who maybe are not articulate at the whiteboard but do fine at the keyboard, even under pressure. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long. How many times do you have your customers in the office, throwing out arbitrary programming challenges for your developers to solve on the spot at the whiteboard? It's fine if your methodology works for you, but you might consider that it's not the only approach that could work.

JoeAltmaier 16y ago

Sounds like a college-hire interview. With years of experience and sound references, having an interviewer insist on this "baby step" IS demeaning. And it breeds a bad attitude, sure. How about Reading the code the candidate provided? Asking questions about that? Invest some effort in a mature candidate, instead of treating them like a fresh-faced kid. Imagine the difference between interviewing a business-school graduate (What is accounts receivable? How do you track inventory? ) vs interviewing for an executive position.