4 ms·

> In short, the findings suggest that companies are missing out on really good programmers because those programmers aren’t good at writing on a whiteboard and

> In short, the findings suggest that companies are missing out on really good programmers because those programmers aren’t good at writing on a whiteboard and explaining their work out loud while coding. In most of my programming jobs, explaining your work was most of the job and writing code was less important. The whiteboard environment is a bit unnatural but I don’t want to hire someone who gets the right answer if they can’t explain it to me.

dsr_ 6y ago
Most of the job: was that explaining while you write the code, under time pressure, or explaining your debugged code after you've tested it a bit and have confidence in it?
- klodolph 6y ago
  > The whiteboard environment is a bit unnatural…
timmytokyo 6y ago
So have them explain it to you after they complete the problem with you out of the room.
- klodolph 6y ago
  If I’m in the room, I will steer them away from dead ends and ask leading questions when they get stuck. The point of the interview is to give the interviewee as much of a chance as possible to demonstrate their skills. I’ll say for sure, not everyone interviews this way. A lot of devs running interviews think of it as a “test” with pass/fail. I’d say the better interviewers see it as an opportunity to dig around and figure out how to get evidence of the candidate’s skills. That means being creative, that means responding to what the candidate says and finding opportunities to focus on their strengths.
  - Apocryphon 6y ago
    The problem is that there's lack of transparency in the process. Candidates don't know the "real" rubric that interviewers use, so anxiety could make the situation far more antagonistic than it is. And to some point, it is inherently antagonistic; the interviewee is being judged, vulnerable to being rejected, by someone who may or may not be unfair. So the anxiety ratchets up. This can lead to all sorts of bad behaviors like candidates not asking questions for fear of revealing ignorance or looking stupid. And a lot of interviewers as you say, especially at the top firms, don't really care about "how a candidate thinks" at all; they want to see correctness, they want to see efficiency, they want to see whiteboard code that can compile. I don't think this necessarily means the "answer question alone and present answer after" approach is the right solution to interviewing, but it does show that interviewers might need to take some steps to make the process less opaque and daunting to lower candidates' potential anxiety.
    - klodolph 6y ago
      > And a lot of interviewers as you say, especially at the top firms, don't really care about "how a candidate thinks" at all; From my direct knowledge of some “top firms”, if you only cared about correctness then you wouldn’t be able to fill out the interview feedback form. Transparency may help, but in my experience, that’s what recruiters actually do and some of them are fairly good at it. The recruiter has a strong incentive to get you hired (they get bonuses for hiring people!) and will explain as much of the process as they can, if you are willing to listen. That said, there seems to be a fair bit of turnover in tech recruiting. And, as you said, every interviewer will be different. But I don’t see a way to fix that without eliminating technical interviews altogether. You are being judged, the interviewers are subjective, they do disagree about the rubric, and a bunch of money is on the line. It’s completely reasonable to be anxious. I don’t really see a way out.
      - Apocryphon 6y ago
        > And, as you said, every interviewer will be different. But I don’t see a way to fix that without eliminating technical interviews altogether. You are being judged, the interviewers are subjective, they do disagree about the rubric, and a bunch of money is on the line. It’s completely reasonable to be anxious. I don’t really see a way out. Perhaps what we should be working towards is making it more transparent- it's still ubiquitous for candidates to be rejected without feedback- and more objective, and improving the technical interview process further. I'm not arguing for throwing out the baby with the bathwater.
fzeroracer 6y ago
There is a world of difference in explaining your work to someone you've never met before on a problem you've never seen in an environment you've never worked in. Versus explaining your code to your coworker whom you've worked with for the past X time who understands some of your eccentricities or idiosyncrasies and without a pass/fail judgment lingering over your head like a sword of Damocles.
RivieraKid 6y ago
I would definitely not want to work for you, I think there's something deeply ineffective when most of the job is explaining your code. I say that as someone who cares a lot about writing easy to read code and has no problem explaining it. Also, I'm very bad at solving a problem while being required to think out loud.
- danans 6y ago
  The skill of explaining your work is a very important one in practically any creative problem solving field. This only increases as the technical complexity of the problems faced increases. Sometimes this explaining happens in textual format, like code reviews and design specifications, but often it happens verbally. Absent an explanation, it's hard to build consensus among the parties involved (co-workers, users, management) that your solution (as manifested by the resulting code) is the right one, and for anything non-trivial, you surely can't expect others to just assume that it is the right one.
  - gmtx725 6y ago
    explanation is important but its unreasonable to expect someone to do it on the spot in a time-pressured environment. Often you have to go away and think about it alone in order to come up with a good way of explaining things to others.
- klodolph 6y ago
  > Also, I'm very bad at solving a problem while being required to think out loud. There’s a simple strategy for this, which works fairly well in both interviews and meetings. You give people time to focus and think about the problem and solving it, and don’t force people into discussions right away. It’s not a panacea but in practice it is very effective. The reason why this is important in meetings, as someone running a meeting, if you don’t give people time to think, it will always be the same one or two voices in the room. This is why brainstorming sessions suck. The same thing applies when you are choosing who will take responsibilities—the same few people always speak up first.
jasonlotito 6y ago
> explaining your work was most of the job and writing code was less important. That's not what is being asked. It's explaining your thought process while actively doing the work in an "unnatural" environment. > The whiteboard environment is a bit unnatural I don't know anyone that codes on a whiteboard. > but I don’t want to hire someone who gets the right answer if they can’t explain it to me. Again, that's not what is being asked. They are being asked to explain their work before they get an answer.
- klodolph 6y ago
  > That's not what is being asked. It's explaining your thought process while actively doing the work in an "unnatural" environment. In short, that’s a limitation of the study. The study is comparing “explain your thought process aloud as you solve the problem” against “solve the problem by yourself and don’t explain anything”. There’s a whole range of sensible middle options, like “solve the problem by yourself and explain it afterwards” or “solve the problem with the interviewer and then explain it”.

dsr_ 6y ago

Most of the job: was that explaining while you write the code, under time pressure, or explaining your debugged code after you've tested it a bit and have confidence in it?

klodolph 6y ago
> The whiteboard environment is a bit unnatural…

timmytokyo 6y ago

So have them explain it to you after they complete the problem with you out of the room.

klodolph 6y ago
If I’m in the room, I will steer them away from dead ends and ask leading questions when they get stuck. The point of the interview is to give the interviewee as much of a chance as possible to demonstrate their skills. I’ll say for sure, not everyone interviews this way. A lot of devs running interviews think of it as a “test” with pass/fail. I’d say the better interviewers see it as an opportunity to dig around and figure out how to get evidence of the candidate’s skills. That means being creative, that means responding to what the candidate says and finding opportunities to focus on their strengths.
- Apocryphon 6y ago
  The problem is that there's lack of transparency in the process. Candidates don't know the "real" rubric that interviewers use, so anxiety could make the situation far more antagonistic than it is. And to some point, it is inherently antagonistic; the interviewee is being judged, vulnerable to being rejected, by someone who may or may not be unfair. So the anxiety ratchets up. This can lead to all sorts of bad behaviors like candidates not asking questions for fear of revealing ignorance or looking stupid. And a lot of interviewers as you say, especially at the top firms, don't really care about "how a candidate thinks" at all; they want to see correctness, they want to see efficiency, they want to see whiteboard code that can compile. I don't think this necessarily means the "answer question alone and present answer after" approach is the right solution to interviewing, but it does show that interviewers might need to take some steps to make the process less opaque and daunting to lower candidates' potential anxiety.
  - klodolph 6y ago
    > And a lot of interviewers as you say, especially at the top firms, don't really care about "how a candidate thinks" at all; From my direct knowledge of some “top firms”, if you only cared about correctness then you wouldn’t be able to fill out the interview feedback form. Transparency may help, but in my experience, that’s what recruiters actually do and some of them are fairly good at it. The recruiter has a strong incentive to get you hired (they get bonuses for hiring people!) and will explain as much of the process as they can, if you are willing to listen. That said, there seems to be a fair bit of turnover in tech recruiting. And, as you said, every interviewer will be different. But I don’t see a way to fix that without eliminating technical interviews altogether. You are being judged, the interviewers are subjective, they do disagree about the rubric, and a bunch of money is on the line. It’s completely reasonable to be anxious. I don’t really see a way out.
    - Apocryphon 6y ago
      > And, as you said, every interviewer will be different. But I don’t see a way to fix that without eliminating technical interviews altogether. You are being judged, the interviewers are subjective, they do disagree about the rubric, and a bunch of money is on the line. It’s completely reasonable to be anxious. I don’t really see a way out. Perhaps what we should be working towards is making it more transparent- it's still ubiquitous for candidates to be rejected without feedback- and more objective, and improving the technical interview process further. I'm not arguing for throwing out the baby with the bathwater.

fzeroracer 6y ago

There is a world of difference in explaining your work to someone you've never met before on a problem you've never seen in an environment you've never worked in. Versus explaining your code to your coworker whom you've worked with for the past X time who understands some of your eccentricities or idiosyncrasies and without a pass/fail judgment lingering over your head like a sword of Damocles.

RivieraKid 6y ago

I would definitely not want to work for you, I think there's something deeply ineffective when most of the job is explaining your code. I say that as someone who cares a lot about writing easy to read code and has no problem explaining it. Also, I'm very bad at solving a problem while being required to think out loud.

danans 6y ago
The skill of explaining your work is a very important one in practically any creative problem solving field. This only increases as the technical complexity of the problems faced increases. Sometimes this explaining happens in textual format, like code reviews and design specifications, but often it happens verbally. Absent an explanation, it's hard to build consensus among the parties involved (co-workers, users, management) that your solution (as manifested by the resulting code) is the right one, and for anything non-trivial, you surely can't expect others to just assume that it is the right one.
- gmtx725 6y ago
  explanation is important but its unreasonable to expect someone to do it on the spot in a time-pressured environment. Often you have to go away and think about it alone in order to come up with a good way of explaining things to others.
klodolph 6y ago
> Also, I'm very bad at solving a problem while being required to think out loud. There’s a simple strategy for this, which works fairly well in both interviews and meetings. You give people time to focus and think about the problem and solving it, and don’t force people into discussions right away. It’s not a panacea but in practice it is very effective. The reason why this is important in meetings, as someone running a meeting, if you don’t give people time to think, it will always be the same one or two voices in the room. This is why brainstorming sessions suck. The same thing applies when you are choosing who will take responsibilities—the same few people always speak up first.

jasonlotito 6y ago

> explaining your work was most of the job and writing code was less important. That's not what is being asked. It's explaining your thought process while actively doing the work in an "unnatural" environment. > The whiteboard environment is a bit unnatural I don't know anyone that codes on a whiteboard. > but I don’t want to hire someone who gets the right answer if they can’t explain it to me. Again, that's not what is being asked. They are being asked to explain their work before they get an answer.

klodolph 6y ago
> That's not what is being asked. It's explaining your thought process while actively doing the work in an "unnatural" environment. In short, that’s a limitation of the study. The study is comparing “explain your thought process aloud as you solve the problem” against “solve the problem by yourself and don’t explain anything”. There’s a whole range of sensible middle options, like “solve the problem by yourself and explain it afterwards” or “solve the problem with the interviewer and then explain it”.