6 ms·

I’m going to show some vulnerability… this happened to me this week. I’m probably like a lot of you here: professional software developer for 20 years, have shi

I’m going to show some vulnerability… this happened to me this week. I’m probably like a lot of you here: professional software developer for 20 years, have shipped countless products in multiple languages / technologies. Work has appeared on tv and print media multiple times. Have generated millions and millions in cost savings and revenue for employers and clients. But I totally failed a technical screen. It’s been a week of reflection as a result. I nearly canceled the interview to begin with because the entire process felt like a cattle call - totally cold, the company had shared no information about themselves or the role. There were ten minutes of rapid fire (“you have one minute to answer this question.”) followed by the proclamation that the next 45 minutes would be spent on “as many coding problems as we can get through.” Within the first few minutes I was able to describe a general solution to the problem, but over the next 40 I totally struggled to produce a working solution. Now, sitting here I could likely write it in 5 minutes. The problem was: --I was completely frustrated by the experience from the beginning --I was in a code editor that I wasn’t familiar with --I had limited access to documentation --An interviewer looking over my shoulder harassing me --I realized that while the problem was simple, there were things I’d just never needed in that particular language before, so didn’t have a complete understanding of what was available to me. --I focus on design before implementation, where the interviewer just wanted me to jump in and bang out code. --I realized that the last time I wrote this particular bit of code was 20+ years ago, as a college freshman, and certainly not in the language I was using today. So I agree with the other commenters: we should all check our premises before we disregard another experienced programmer as as hopeless hack. I wrote a long blog article this week about what I think the interview process should be, will be posting it soon. There are ways to fix this process.

psyc 9y ago
There's no shame in it. Same thing happened to me last week, and I was furious about it. I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing. We're composers, but we're being tested as if we're live concert pianists. Then companies complain that there's a talent shortage! This hurts everybody, and it needs to stop. For my part, I will refuse to participate any further.
- the-pigeon 9y ago
  > I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing. Depends on the job. I'm currently hiring and the live coding exercise is a must for the position because I want to see how the person problem solves while under stress. Because stuff happens. My team works on mission critical systems that can have issues that we sometimes must resolve quickly which is very stressful. If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately. Maybe that's not true for everyone but I haven't heard of a better filter. Not every position is like this. But that's the big thing I think people miss. Different software positions require different skillets beyond just tech stacks. And the interview process should measure for the particular software engineer skills needed for that position. I've also hired people who if you just reviewed their code after the exercise you'd think they were terrible. But I'm not testing whether they are good at coding exercises, the test is a tool to see their ability to problem solve under pressure and to see their level of experience with the particularly tech stack.
  - psyc 9y ago
    I agree this point is valid, but I think it's much more exceptional than whiteboard interviews are. I've personally never applied for such a job, since I typically work on consumer products at BigCos with a glacial development pace.
  - admax88q 9y ago
    > If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately. Those are two very different kinds of stress. In one situation you're stressed because you feel like your every action and step is being judged. Every moment you spend floundering you feel is being docked against you, you can't help but worry about how the person breathing down your neck is expecting you to approach the problem. In the other situation you are a part of a team, you have each others backs and trust each other to make sound judgement calls. You're working together for a common goal rather than judging each others every movement. Your hiring method sounds like hazing, you're putting interviewees though unnecessary stress to see if they crack. Stress that isn't the same as they would feel on the job, at least I hope you don't also treat your employees the same way.
seige 9y ago
It happens to a lot of us and sometimes fear that is just how the industry is. I have heard senior engineers just stop interviewing and often switch jobs via their network/friends.
- Clubber 9y ago
  >I have heard senior engineers just stop interviewing and often switch jobs via their network/friends. Count me in that group. I have no desire to go through that BS. Seems like the bozos have taken over and ruined development work.
monocasa 9y ago
So a little more on the interview. I've got a laptop setup with eclipse, all rigged up with an integration test and filled out function signatures. I show the interviewee what to press to compile, and the subsequent failing tests. The code builds in it's initial state, but the tests fail. I also show them on the desktop that the original source is squirreled away in case they fat finger and erase everything (I've totally done that too, lol. Source control is a beautiful thing in the real world). Then I peace out for a few minutes to give them space (I know I'm close to an order of magnitude worse at typing when someone is looking over my shoulder). Given the negative response we've had in the past about take home assignments for senior devs (their time is pretty valuable, so I try spend the same time they do), I'm not sure what else to do to accommodate.
- poulsbohemian 9y ago
  Todd, is that you? Sounds a lot like the process used by someone I worked with years ago. It sounds to me like you’ve done some careful thinking about this, and it doesn’t sound unreasonable. One of my beefs really gets down to the interview process turning into a one-way grilling, dehumanizing the candidate into a “code monkey.” It sounds to me like you are trying really hard to evaluate their technical skills, but in a way that is collaborative.
  - athenot 9y ago
    > dehumanizing the candidate into a “code monkey.” Bingo. A hiring process that attempts to convert the multidimensionality of humans to a handful of numeric variables is essentially trying to hire the best drone out there, not the best human fit for the job. I learn more about candidates from the types of questions they ask me, and their reply to open-ended questions I ask them, than from any technical grilling test.
    - ConceptJunkie 9y ago
      A dev manager I work with insists that one of the best indicators, along with all the usual things you try to suss out about a software development candidate is whether or not he does any software development in his spare time. Not everyone who's good does, but there's a good correlation between people who would be good at writing software, and people who do it for fun. So I would take writing software for fun as a plus, but would not take not writing software for fun as a minus.
maxxxxx 9y ago
I am sympathetic to this but I have dealt with very senior candidates that could not demonstrate any coherent thought about a given problem over a whole interview. Others don't get code done but at least they can express a clear understanding of the problem and have an intelligent conversation. I don't care if they can write the code but I want to see some level of engagement with the problem and some understanding.
deleted 9y ago
[deleted]
pnw_hazor 9y ago
What you experienced is called hazing. Illegal in many contexts but for some reason it still thrives in tech land.
DoofusOfDeath 9y ago
Similar thing happened to me in a Google phone screen with coding exercise. Not sure what happened inside my brain, but I simply froze and couldn't solve a fairly trivial coding problem. That only thing that makes me feel better is that it was a one-time problem.
- s2g 9y ago
  I did phone screens with google and facebook. Felt like Facebook went kinda bad. Turned out good enough, went onsite. Failed. Oh well. Tried again a while later. Failed FB phone screen, got told Google wanted a second. That was the point I said fuck it and cancelled. shrug
nvarsj 9y ago
Only way to code under pressure like that is with practice. I turn into an idiot non-coder in these situations, but I've gotten much better over time, to where I always pass a live coding session. In the real world, I spend a fair amount of time thinking and teasing a problem apart before I actually start coding. This is hard to do in an interview - even if the interviewer says "think about it for a few minutes", they will inevitably step in and offer a suggestion after 30s of silence. It's like you have to code by pure instinct. Which is doable with practice. But it's hugely skewed towards people who have the time or desire to practice such things. This is why advice for passing the Google/etc. interview usually boils down to: Quit your job for a month and do competitive coding, and you will pass with ease.
- mncolinlee 9y ago
  This. I noticed that I have gone for over fifteen years through some pretty tough jobs, but never needed to write any Leetcode binary tree problem from scratch in thirty minutes in my work while being questioned. I normally freeze up because I worry about current best practices every step of the way. In the end, I scored a job with a FAANG company literally because I didn't want to work there. A friend warned me away before the interview for work-life reasons, but I decided to go ahead with the interview anyway as practice and I nailed it. There's no reason to stress if you don't want the job. Another friend who worked there later convinced me to take the offer. What bothers me is: you're basically the same coder both before and after competitive coding practice. You're only more marketable with the same skills.
  - preordained 9y ago
    >What bothers me is: you're basically the same coder both before and after competitive coding practice. You're only more marketable with the same skills. Yup. You keep keep measuring that thing..I don't think you're measuring what you think you're measuring.
tytytytytytytyt 9y ago
> I wrote a long blog article this week about what I think the interview process should be, will be posting it soon. There are ways to fix this process. I really hope that's true. Every solution I've heard so far is unrealistic at best, like using take home assignments, as if no one would cheat or complain about those.
aidenn0 9y ago
Failing a high-stress technical screen and being unable to write fizz-buzz in pseudo-code are two very different things though.

psyc 9y ago

There's no shame in it. Same thing happened to me last week, and I was furious about it. I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing. We're composers, but we're being tested as if we're live concert pianists. Then companies complain that there's a talent shortage! This hurts everybody, and it needs to stop. For my part, I will refuse to participate any further.

the-pigeon 9y ago
> I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing. Depends on the job. I'm currently hiring and the live coding exercise is a must for the position because I want to see how the person problem solves while under stress. Because stuff happens. My team works on mission critical systems that can have issues that we sometimes must resolve quickly which is very stressful. If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately. Maybe that's not true for everyone but I haven't heard of a better filter. Not every position is like this. But that's the big thing I think people miss. Different software positions require different skillets beyond just tech stacks. And the interview process should measure for the particular software engineer skills needed for that position. I've also hired people who if you just reviewed their code after the exercise you'd think they were terrible. But I'm not testing whether they are good at coding exercises, the test is a tool to see their ability to problem solve under pressure and to see their level of experience with the particularly tech stack.
- psyc 9y ago
  I agree this point is valid, but I think it's much more exceptional than whiteboard interviews are. I've personally never applied for such a job, since I typically work on consumer products at BigCos with a glacial development pace.
- admax88q 9y ago
  > If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately. Those are two very different kinds of stress. In one situation you're stressed because you feel like your every action and step is being judged. Every moment you spend floundering you feel is being docked against you, you can't help but worry about how the person breathing down your neck is expecting you to approach the problem. In the other situation you are a part of a team, you have each others backs and trust each other to make sound judgement calls. You're working together for a common goal rather than judging each others every movement. Your hiring method sounds like hazing, you're putting interviewees though unnecessary stress to see if they crack. Stress that isn't the same as they would feel on the job, at least I hope you don't also treat your employees the same way.

seige 9y ago

It happens to a lot of us and sometimes fear that is just how the industry is. I have heard senior engineers just stop interviewing and often switch jobs via their network/friends.

Clubber 9y ago
>I have heard senior engineers just stop interviewing and often switch jobs via their network/friends. Count me in that group. I have no desire to go through that BS. Seems like the bozos have taken over and ruined development work.

monocasa 9y ago

So a little more on the interview. I've got a laptop setup with eclipse, all rigged up with an integration test and filled out function signatures. I show the interviewee what to press to compile, and the subsequent failing tests. The code builds in it's initial state, but the tests fail. I also show them on the desktop that the original source is squirreled away in case they fat finger and erase everything (I've totally done that too, lol. Source control is a beautiful thing in the real world). Then I peace out for a few minutes to give them space (I know I'm close to an order of magnitude worse at typing when someone is looking over my shoulder). Given the negative response we've had in the past about take home assignments for senior devs (their time is pretty valuable, so I try spend the same time they do), I'm not sure what else to do to accommodate.

poulsbohemian 9y ago
Todd, is that you? Sounds a lot like the process used by someone I worked with years ago. It sounds to me like you’ve done some careful thinking about this, and it doesn’t sound unreasonable. One of my beefs really gets down to the interview process turning into a one-way grilling, dehumanizing the candidate into a “code monkey.” It sounds to me like you are trying really hard to evaluate their technical skills, but in a way that is collaborative.
- athenot 9y ago
  > dehumanizing the candidate into a “code monkey.” Bingo. A hiring process that attempts to convert the multidimensionality of humans to a handful of numeric variables is essentially trying to hire the best drone out there, not the best human fit for the job. I learn more about candidates from the types of questions they ask me, and their reply to open-ended questions I ask them, than from any technical grilling test.
  - ConceptJunkie 9y ago
    A dev manager I work with insists that one of the best indicators, along with all the usual things you try to suss out about a software development candidate is whether or not he does any software development in his spare time. Not everyone who's good does, but there's a good correlation between people who would be good at writing software, and people who do it for fun. So I would take writing software for fun as a plus, but would not take not writing software for fun as a minus.

maxxxxx 9y ago

I am sympathetic to this but I have dealt with very senior candidates that could not demonstrate any coherent thought about a given problem over a whole interview. Others don't get code done but at least they can express a clear understanding of the problem and have an intelligent conversation. I don't care if they can write the code but I want to see some level of engagement with the problem and some understanding.

deleted 9y ago

[deleted]

pnw_hazor 9y ago

What you experienced is called hazing. Illegal in many contexts but for some reason it still thrives in tech land.

DoofusOfDeath 9y ago

Similar thing happened to me in a Google phone screen with coding exercise. Not sure what happened inside my brain, but I simply froze and couldn't solve a fairly trivial coding problem. That only thing that makes me feel better is that it was a one-time problem.

s2g 9y ago
I did phone screens with google and facebook. Felt like Facebook went kinda bad. Turned out good enough, went onsite. Failed. Oh well. Tried again a while later. Failed FB phone screen, got told Google wanted a second. That was the point I said fuck it and cancelled. shrug

nvarsj 9y ago

Only way to code under pressure like that is with practice. I turn into an idiot non-coder in these situations, but I've gotten much better over time, to where I always pass a live coding session. In the real world, I spend a fair amount of time thinking and teasing a problem apart before I actually start coding. This is hard to do in an interview - even if the interviewer says "think about it for a few minutes", they will inevitably step in and offer a suggestion after 30s of silence. It's like you have to code by pure instinct. Which is doable with practice. But it's hugely skewed towards people who have the time or desire to practice such things. This is why advice for passing the Google/etc. interview usually boils down to: Quit your job for a month and do competitive coding, and you will pass with ease.

mncolinlee 9y ago
This. I noticed that I have gone for over fifteen years through some pretty tough jobs, but never needed to write any Leetcode binary tree problem from scratch in thirty minutes in my work while being questioned. I normally freeze up because I worry about current best practices every step of the way. In the end, I scored a job with a FAANG company literally because I didn't want to work there. A friend warned me away before the interview for work-life reasons, but I decided to go ahead with the interview anyway as practice and I nailed it. There's no reason to stress if you don't want the job. Another friend who worked there later convinced me to take the offer. What bothers me is: you're basically the same coder both before and after competitive coding practice. You're only more marketable with the same skills.
- preordained 9y ago
  >What bothers me is: you're basically the same coder both before and after competitive coding practice. You're only more marketable with the same skills. Yup. You keep keep measuring that thing..I don't think you're measuring what you think you're measuring.

tytytytytytytyt 9y ago

> I wrote a long blog article this week about what I think the interview process should be, will be posting it soon. There are ways to fix this process. I really hope that's true. Every solution I've heard so far is unrealistic at best, like using take home assignments, as if no one would cheat or complain about those.

aidenn0 9y ago

Failing a high-stress technical screen and being unable to write fizz-buzz in pseudo-code are two very different things though.