4 ms·

Coding on the spot might seem surprising to those outside of the software industry, but it’s standard practice. Sounds like wishful thinking to me. At least I

by dkarl 16y ago

Coding on the spot might seem surprising to those outside of the software industry, but it’s standard practice. Sounds like wishful thinking to me. At least I wish it were true. I've been involved in a lot of interviews at my company, and I'm the only one who ever asks anyone to write code.

wtracy 16y ago
Every interview I've gone through that lasted more than about fifteen minutes involved writing out code. <shrug>
adamdecaf 16y ago
I know this attitude won't win very many friends, but I wouldn't accept a position where I wasn't asked to write code during the interview. I'm going to be writing code for money and they don't want me to prove that I can before hand? That's like hiring a "farmer" from the inner-city.
- code_duck 16y ago
  I'd take a look at a candidates github account or other open source work. That might preclude the need to ask for code during the interview.
  - gcb 16y ago
    most of my github account is filled with trash that i start for one day, barely learn something completely new to me, sometime a new language, then forget and move on. if I find said thing promising, i'd usually came back some weekends later and do something more complex, but again, basically junk. oh, and did i mention nothing looks finished? Now, take anything i code behind the closed doors at my employer or i contribute to some open source projects. It will shine like nothing you will ever see in my github or googlecode or such.
    - cdavid 16y ago
      I think you are not looking at it the right way: sure, a lot of stuff on github is crap, but if you have something good on it where you are a significant contributor, then it surely is a good sign.
    - ghshephard 16y ago
      Good grief -you have a github account that you put code on. You've already put yourself ahead of 90% of the candidates applying for a position as a developer - don't sell yourself short.
- mavelikara 16y ago
  +1. If I am not asked to write code in the interview, it is likely that other employees of the firm were not asked to in their interviews either. In the absence of other indicators (like open source code published by the firm), I will take this to mean that the codebase I have to work with, should I accept the position, is likely not to be stellar.
roc 16y ago
That's been my experience as well. I had one phone-interview with a west coast firm looking for a local-to-my-area contractor that included coding. But as for every other interview I've done in and from the midwest, the closest they came to 'code' was one group asking obnoxious syntax questions. From the other side of the table, the firm I'm with now only has a pseudo-code step in the interviewing process if and when I run it. The director for my group doesn't even put the question forward if I can't make an interview appointment. Even though he agreed that it was a great tool that did filter out a couple duds that might well have been hires without it, and likely would have filtered out the one spectacularly bad fit that made it through before my time.
ajg1977 16y ago
If you can comment, I would be interested on the standard of coding that successful candidates exhibit once employed. Personally, if I could only ask a candidate one question, it would be something that involved writing code. Too many times I've seen candidates with impressive resumes, technical knowledge, or conversation skills, fail miserably to implement trivial (e.g. stricmp) functions.
- ultrasaurus 16y ago
  On the other hand, I don't understand how non-technical interviewers can tolerate not knowing how good a non-technical applicant is for the same reasons you mentioned. Do teams ever recruit athletes without watching them play?
  - morganw 16y ago
    http://www.kottke.org/08/05/gladwell-on-the-mismatch-problem http://www.kottke.org/08/05/gladwell-on-the-mismatch-problem "One subject in Outliers is what Gladwell calls the "mismatch problem," which refers to his idea that the qualifications which people look for/companies require in candidates when hiring often do not necessarily have any correlation to successful job performance - and often leads to poor hiring decisions." He's also written on the problems in scouting athletes & picking teachers in the New Yorker.
- dkarl 16y ago
  If you can comment, I would be interested on the standard of coding that successful candidates exhibit once employed. Good ones write good code; the ones we shouldn't have hired write poor code or don't code at all. As for how to tell the difference, I pay a lot of attention to candidates' questions, comments, and attitude while writing code. That part carries over pretty directly to how they do their real job and how pleasant they are to work with. As for quality of code, my rough impression is that the more meaningful details they take care of in their whiteboard code, the more productive they are. Getting syntax and library function names right or wrong doesn't tell you much (except how recently they wrote code that used that syntax or those functions) but getting other details right does matter. Which details matter is a matter of judgment. My attitude is that some errors are trivial but should be corrected if attention is called to them. For example, off-by-one errors in array indices are easy to miss on a whiteboard if they only affect one line of code or just make the output a little incorrect -- that's no big deal -- but when a candidate gets stuck or confused because of an off-by-one error he made a few lines up, he should be able to figure it out, correct the error, and correct any related errors. Good things to watch out for (besides asking good questions to make sure the problem is well specified): 1. The candidate doesn't start writing a complete solution without having a decent idea where it's going. If he doesn't see a solution immediately, he takes some time to understand the problem, possibly working an example by hand, sketching out possible solutions, or talking through the problem verbally. 2. The candidate draws logical inferences about his own code. "Oops, this function signature is wrong, because in these two cases the same arguments are passed, but the output needs to be different. I need to pass in more information." 3. If the candidate takes the wrong path, he backs up as far as necessary to get back on the right track. He reminds himself of the problem statement and reevaluates his decisions up to that point. Bad things to watch out for (besides having a bad attitude or failing to ask questions): 1. The candidate launches right into coding a solution without understanding how the problem can be solved. (Those candidates usually end up boxing themselves in, so they really better be good at backing up and starting fresh.) 2. The candidate spends a long time trying to impossible code, such as trying to implement the body of a function when the arguments he has specified for it don't contain enough information. 3. If the candidate takes the wrong path, he doesn't back up far enough to recover. For example, he doesn't question anything he decided more than five minutes ago, so he starts to treat his initial steps in solving the problem as if they were part of the problem statement. (I have seen the opposite mistake also, where a candidate encounters a problem that is clearly local to a small part of his code, but he interprets it as invalidating his whole approach. That mistake is usually just a mistake; people are going to make mistakes under pressure. It doesn't show a lack of intellectual flexibility like the opposite behavior. Depending on the circumstances I might interpret it as a lack of persistence, but usually not.)
igrekel 16y ago
I met someone who complained about how he was required to write code to solve simple problems in an interview. He took that as an offense, saying that he was a websphere something something expert and shouldn't be bothered with little things like coding. I did waste my time trying to explain to him that small coding questions are often the easy way to weed out the people who pretend to have technical expertise and that these are more frequent that he'd think. I still think the coding questions are useful and I don't ind losing such a candidate.
Periodic 16y ago
I was asked to write very little code for my current position. One of the questions was being presented with some code and figuring out what it did. I didn't realize how apropos that question was at the time. I just got done doing a series of 10 1-hour interviews for contractors for an enterprise Java web application contract lasting about 6 months. Only 2-3 of them could write correct Java on a white board for simple questions. We had three who weren't even close to Java syntax. Code quality seemed to be directly relational to algorithm quality, in that those with better syntax also knew how to solve the algorithms best, and those with terrible syntax were way off on the algorithms. Up until we asked these candidates to write code on the board, a few of them sounded like great hires. They could rattle on about design decisions and enterprise web application stacks, about configuration and organization. But when it came to the white board at least one of them just stood there and left it mostly blank. Some of the positions here have had interviews where the candidate is expected to write code but only one, if even that, interviewer asked to see any code. And even then the managers don't seem too worried when I tell them the person can't code, because everyone else likes them so much.
- blacksmythe 16y ago
  Did you have a chance to rate the performance of the candidates that were hired that had trouble writing code at a whiteboard in the interview? Were any of them productive in a different setting? I am more inclined to give people a chance to work at a terminal (with internet access) instead of a whiteboard.
  - ghshephard 16y ago
    It's rare that someone who can write excellent code on a whiteboard can't do so on a terminal. The goal of an interview, in my experience, isn't usually to find a way to let the candidate shine, but find only the best person for the position. If the candidate draws a blank writing code on a whiteboard, that indicates they have poor whiteboard skills - which is a pretty important skill to have in a team environment.
- jackowayed 16y ago
  Could you give an example or two of questions on the same level as those "simple questions"?
brown9-2 16y ago
I've been involved in a lot of interviews at my company, and I'm the only one who ever asks anyone to write code. Would you consider the primary output and product of your company software? Perhaps you are just working in a position creating software in a non-software company.

by dkarl 16y ago

wtracy 16y ago

Every interview I've gone through that lasted more than about fifteen minutes involved writing out code. <shrug>

adamdecaf 16y ago

I know this attitude won't win very many friends, but I wouldn't accept a position where I wasn't asked to write code during the interview. I'm going to be writing code for money and they don't want me to prove that I can before hand? That's like hiring a "farmer" from the inner-city.

code_duck 16y ago
I'd take a look at a candidates github account or other open source work. That might preclude the need to ask for code during the interview.
- gcb 16y ago
  most of my github account is filled with trash that i start for one day, barely learn something completely new to me, sometime a new language, then forget and move on. if I find said thing promising, i'd usually came back some weekends later and do something more complex, but again, basically junk. oh, and did i mention nothing looks finished? Now, take anything i code behind the closed doors at my employer or i contribute to some open source projects. It will shine like nothing you will ever see in my github or googlecode or such.
  - cdavid 16y ago
    I think you are not looking at it the right way: sure, a lot of stuff on github is crap, but if you have something good on it where you are a significant contributor, then it surely is a good sign.
  - ghshephard 16y ago
    Good grief -you have a github account that you put code on. You've already put yourself ahead of 90% of the candidates applying for a position as a developer - don't sell yourself short.
mavelikara 16y ago
+1. If I am not asked to write code in the interview, it is likely that other employees of the firm were not asked to in their interviews either. In the absence of other indicators (like open source code published by the firm), I will take this to mean that the codebase I have to work with, should I accept the position, is likely not to be stellar.

roc 16y ago

That's been my experience as well. I had one phone-interview with a west coast firm looking for a local-to-my-area contractor that included coding. But as for every other interview I've done in and from the midwest, the closest they came to 'code' was one group asking obnoxious syntax questions. From the other side of the table, the firm I'm with now only has a pseudo-code step in the interviewing process if and when I run it. The director for my group doesn't even put the question forward if I can't make an interview appointment. Even though he agreed that it was a great tool that did filter out a couple duds that might well have been hires without it, and likely would have filtered out the one spectacularly bad fit that made it through before my time.

ajg1977 16y ago

If you can comment, I would be interested on the standard of coding that successful candidates exhibit once employed. Personally, if I could only ask a candidate one question, it would be something that involved writing code. Too many times I've seen candidates with impressive resumes, technical knowledge, or conversation skills, fail miserably to implement trivial (e.g. stricmp) functions.

ultrasaurus 16y ago
On the other hand, I don't understand how non-technical interviewers can tolerate not knowing how good a non-technical applicant is for the same reasons you mentioned. Do teams ever recruit athletes without watching them play?
- morganw 16y ago
  http://www.kottke.org/08/05/gladwell-on-the-mismatch-problem http://www.kottke.org/08/05/gladwell-on-the-mismatch-problem "One subject in Outliers is what Gladwell calls the "mismatch problem," which refers to his idea that the qualifications which people look for/companies require in candidates when hiring often do not necessarily have any correlation to successful job performance - and often leads to poor hiring decisions." He's also written on the problems in scouting athletes & picking teachers in the New Yorker.
dkarl 16y ago
If you can comment, I would be interested on the standard of coding that successful candidates exhibit once employed. Good ones write good code; the ones we shouldn't have hired write poor code or don't code at all. As for how to tell the difference, I pay a lot of attention to candidates' questions, comments, and attitude while writing code. That part carries over pretty directly to how they do their real job and how pleasant they are to work with. As for quality of code, my rough impression is that the more meaningful details they take care of in their whiteboard code, the more productive they are. Getting syntax and library function names right or wrong doesn't tell you much (except how recently they wrote code that used that syntax or those functions) but getting other details right does matter. Which details matter is a matter of judgment. My attitude is that some errors are trivial but should be corrected if attention is called to them. For example, off-by-one errors in array indices are easy to miss on a whiteboard if they only affect one line of code or just make the output a little incorrect -- that's no big deal -- but when a candidate gets stuck or confused because of an off-by-one error he made a few lines up, he should be able to figure it out, correct the error, and correct any related errors. Good things to watch out for (besides asking good questions to make sure the problem is well specified): 1. The candidate doesn't start writing a complete solution without having a decent idea where it's going. If he doesn't see a solution immediately, he takes some time to understand the problem, possibly working an example by hand, sketching out possible solutions, or talking through the problem verbally. 2. The candidate draws logical inferences about his own code. "Oops, this function signature is wrong, because in these two cases the same arguments are passed, but the output needs to be different. I need to pass in more information." 3. If the candidate takes the wrong path, he backs up as far as necessary to get back on the right track. He reminds himself of the problem statement and reevaluates his decisions up to that point. Bad things to watch out for (besides having a bad attitude or failing to ask questions): 1. The candidate launches right into coding a solution without understanding how the problem can be solved. (Those candidates usually end up boxing themselves in, so they really better be good at backing up and starting fresh.) 2. The candidate spends a long time trying to impossible code, such as trying to implement the body of a function when the arguments he has specified for it don't contain enough information. 3. If the candidate takes the wrong path, he doesn't back up far enough to recover. For example, he doesn't question anything he decided more than five minutes ago, so he starts to treat his initial steps in solving the problem as if they were part of the problem statement. (I have seen the opposite mistake also, where a candidate encounters a problem that is clearly local to a small part of his code, but he interprets it as invalidating his whole approach. That mistake is usually just a mistake; people are going to make mistakes under pressure. It doesn't show a lack of intellectual flexibility like the opposite behavior. Depending on the circumstances I might interpret it as a lack of persistence, but usually not.)

igrekel 16y ago

I met someone who complained about how he was required to write code to solve simple problems in an interview. He took that as an offense, saying that he was a websphere something something expert and shouldn't be bothered with little things like coding. I did waste my time trying to explain to him that small coding questions are often the easy way to weed out the people who pretend to have technical expertise and that these are more frequent that he'd think. I still think the coding questions are useful and I don't ind losing such a candidate.

Periodic 16y ago

I was asked to write very little code for my current position. One of the questions was being presented with some code and figuring out what it did. I didn't realize how apropos that question was at the time. I just got done doing a series of 10 1-hour interviews for contractors for an enterprise Java web application contract lasting about 6 months. Only 2-3 of them could write correct Java on a white board for simple questions. We had three who weren't even close to Java syntax. Code quality seemed to be directly relational to algorithm quality, in that those with better syntax also knew how to solve the algorithms best, and those with terrible syntax were way off on the algorithms. Up until we asked these candidates to write code on the board, a few of them sounded like great hires. They could rattle on about design decisions and enterprise web application stacks, about configuration and organization. But when it came to the white board at least one of them just stood there and left it mostly blank. Some of the positions here have had interviews where the candidate is expected to write code but only one, if even that, interviewer asked to see any code. And even then the managers don't seem too worried when I tell them the person can't code, because everyone else likes them so much.

blacksmythe 16y ago
Did you have a chance to rate the performance of the candidates that were hired that had trouble writing code at a whiteboard in the interview? Were any of them productive in a different setting? I am more inclined to give people a chance to work at a terminal (with internet access) instead of a whiteboard.
- ghshephard 16y ago
  It's rare that someone who can write excellent code on a whiteboard can't do so on a terminal. The goal of an interview, in my experience, isn't usually to find a way to let the candidate shine, but find only the best person for the position. If the candidate draws a blank writing code on a whiteboard, that indicates they have poor whiteboard skills - which is a pretty important skill to have in a team environment.
jackowayed 16y ago
Could you give an example or two of questions on the same level as those "simple questions"?

brown9-2 16y ago

I've been involved in a lot of interviews at my company, and I'm the only one who ever asks anyone to write code. Would you consider the primary output and product of your company software? Perhaps you are just working in a position creating software in a non-software company.