5 ms·

While this looks like a well developed feature, I despise the concept of coding in a phone interview too much to not worry about this enabling more of it just b

While this looks like a well developed feature, I despise the concept of coding in a phone interview too much to not worry about this enabling more of it just because it's more convenient. Especially for research-heavy positions, the amount of nonsense exercises really makes or breaks a company impression for me. case 1) Have a serious technical conversations with questions testing my understanding, asking about my projects, ideas and interests. case 2) 3 minutes of smalltalk while the interviewer reads out some points from my CV so I can repeat them back. Then 'alright, let's do a coding exercise'. Learn nothing about the team, their process, their vision in the phone rounds.

drdaeman 9y ago
This. Real-time interviews are the worst of two worlds (emergency fast coding and live demonstration at the same time) and barely show anything about how one normally does things. E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. It helped me a few times when the servers were on fire and I needed to fix stuff fast and think later. But that's incompatible with live demonstration, unless the purpose is to embarrass myself and make me look completely incompetent or diffident.
- vram22 9y ago
  >E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment. A real-life example of what I said in the last few lines above: A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser): # init 0 (which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...
  - yardie 9y ago
    Oh, I can only guess. A well run shop will have performance bonuses that the floor employees may depend on for vacation funding, college funding, or a down payment on a house. A shutdown like that can impact a weekly, quarterly or annual bonus severely. He may have inadvertently prevented someone from financing the house they wanted
- jswizzy 9y ago
  It's definitely a skill that doesn't translate to actual development. Before I was a programmer I was a Navy nuclear power plant operator and they did boards like that. In that situation, it made sense because you needed to be able to remember causality procedures during an emergency. Coding, on the other hand, doesn't have that requirement often if at all.
- gt5050 9y ago
  Real time coding interviews are really necessary to avoid hiring people who dont have basic proficiency in coding ( https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) The problem given in a coding interview should be a simple one and the candidate should be allowed to choose the solution language.
  - daenney 9y ago
    A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Or having to feel guilty about reaching for Stack Overflow and wondering how that would affect their interviewer's opinion of them. Sure they could Google the question but then give them something that requires a litte bit of creativity on their side and ask them to talk through their submission. In an interview I'm much more interested in hearing how people would structure and architect applications, how they think about and would deal with tech debt, how they'd iterate and improve, how they think about reliability, instrumentation, testing and what not than having them solve a simple question in 30m. I'm not hiring people for a position that boils down to "solve a simple problem in 30m" either.
    - wildfire 9y ago
      > A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Who is paying for that time? As someone who has interviewed a lot of people; if I am going to ask someone to perform some coding, I offer them the fact that my entire TEAM (5+ people) will be there for them to ask questions of. That is us being serious about hiring. It isn't just a single person who is interviewing - but a large amount of the engineering team.
colinjoy 9y ago
On the contrary, for positions that require getting your hands dirty with implementation, I find it very valuable to be able to look at a code example with the applicant. How do they approach making sense of legacy code. Do they spot code smells? How familiar are they with the technology at hand? Are they comfortable with asking questions when things are not clear? None of this must involve solving algorithmic puzzles under pressure ... but having a conversation around code can be of value.
- naturalgradient 9y ago
  I wouldn't mind that, but I have never encountered that. Cracking the coding interview-exercises only.
- jsjohnst 9y ago
  I agree with this approach a lot, being able to speak about code intelligently is very important. But live coding by fire on some esoteric random brain teaser is not effective, imho.
paulddraper 9y ago
> Especially for research-heavy positions Sure. But if you're hiring general purpose noon-senior software engineers, live coding exercises separate the wheat and the chafe very quickly. Lots of people lie on resumes and are smooth talkers, but lack basic skills for their job. A coding exercise is a really fast way to find these. Then you can move on to more interesting things.
- dmoy 9y ago
  Yup, I don't enjoy coding interviews, but the number of people I've interviewed with ostensibly many years of programming experience who can't actually write some basic code with a for loop and a couple of variables makes me extremely hesitant to hire without a coding interview. If you haven't run across people like this yet, you simply haven't done enough interviews yet, or have somehow entered into an alternate fairytale land where everyone is honest (and if so please take me with you!).
  - jsjohnst 9y ago
    > or have somehow entered into an alternate fairytale land where everyone is honest This won't likely be a popular answer, but more likely than what you described above is simply that you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand. It's perfectly understandable that many don't have this skill as it's rarely ever taught before you start doing interviews at an employer.
    - paulddraper 9y ago
      > you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand I'm sure we could figure out a non-code non-marker way. I'm also sure I could figure out a commute involving only right turns. But why would I arbitraily constrain my solution like that?
      - jsjohnst 9y ago
acangiano 9y ago
At IBM, I review hundreds of resumes and interview dozens of candidates each year (mostly students or new graduates). I used to ask tough algorithmic questions, require a small coding assignment, etc. I no longer do that. Today, I have technical conversations like you describe. I don't need you to remember that 415 is Unsupported Media Type. But I need you to be able to discuss how REST works, the difference between 400s and 500s error codes, and maybe even REST vs GraphQL advantages and tradeoffs, if you mention the latter on your resume. Occasionally I get a surprised "This was so nice. I was expecting a coding interview". It was a coding interview, just not the kind the candidate is used to. You can look up specific answers on Google, but you can't quickly google your way out of a conceptual discussion, your involvement with past projects, technologies that excite you, etc. Generally speaking, I can tell within 5 minutes who is a great candidate. Luck might have played a part, but I have not had a single bad hire with this method so far. In fairness, I'm selective with the candidates I decide to interview, from usually large pools. For these, I also tend to review code they've written in the past if they specify a GitHub account on their resume.
- jsjohnst 9y ago
  I've done hundreds of interviews for candidates over the past twenty years and couldn't agree with you more. The ultra rare occurrence that someone can talk their way through and elude b/s detectors is usually caught later in the interview process anyway.
- audessuscest 9y ago
  Same. Hired 12 developers so far with this method and I made only one mistake, others are all great developers.
  - necrodome 9y ago
    What does "the mistake" look like?
    - coob 9y ago
      You can't always easily tell when someone is going to be a pain to work with on an interpersonal level.
rdiddly 9y ago
Yep, obviously there are good ways and bad ways to use any tool. And the shiny shiny lures a lot of people into using new tools poorly when they already know how to use old tools well.

drdaeman 9y ago

This. Real-time interviews are the worst of two worlds (emergency fast coding and live demonstration at the same time) and barely show anything about how one normally does things. E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. It helped me a few times when the servers were on fire and I needed to fix stuff fast and think later. But that's incompatible with live demonstration, unless the purpose is to embarrass myself and make me look completely incompetent or diffident.

vram22 9y ago
>E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment. A real-life example of what I said in the last few lines above: A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser): # init 0 (which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...
- yardie 9y ago
  Oh, I can only guess. A well run shop will have performance bonuses that the floor employees may depend on for vacation funding, college funding, or a down payment on a house. A shutdown like that can impact a weekly, quarterly or annual bonus severely. He may have inadvertently prevented someone from financing the house they wanted
jswizzy 9y ago
It's definitely a skill that doesn't translate to actual development. Before I was a programmer I was a Navy nuclear power plant operator and they did boards like that. In that situation, it made sense because you needed to be able to remember causality procedures during an emergency. Coding, on the other hand, doesn't have that requirement often if at all.
gt5050 9y ago
Real time coding interviews are really necessary to avoid hiring people who dont have basic proficiency in coding ( https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) The problem given in a coding interview should be a simple one and the candidate should be allowed to choose the solution language.
- daenney 9y ago
  A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Or having to feel guilty about reaching for Stack Overflow and wondering how that would affect their interviewer's opinion of them. Sure they could Google the question but then give them something that requires a litte bit of creativity on their side and ask them to talk through their submission. In an interview I'm much more interested in hearing how people would structure and architect applications, how they think about and would deal with tech debt, how they'd iterate and improve, how they think about reliability, instrumentation, testing and what not than having them solve a simple question in 30m. I'm not hiring people for a position that boils down to "solve a simple problem in 30m" either.
  - wildfire 9y ago
    > A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Who is paying for that time? As someone who has interviewed a lot of people; if I am going to ask someone to perform some coding, I offer them the fact that my entire TEAM (5+ people) will be there for them to ask questions of. That is us being serious about hiring. It isn't just a single person who is interviewing - but a large amount of the engineering team.

colinjoy 9y ago

On the contrary, for positions that require getting your hands dirty with implementation, I find it very valuable to be able to look at a code example with the applicant. How do they approach making sense of legacy code. Do they spot code smells? How familiar are they with the technology at hand? Are they comfortable with asking questions when things are not clear? None of this must involve solving algorithmic puzzles under pressure ... but having a conversation around code can be of value.

naturalgradient 9y ago
I wouldn't mind that, but I have never encountered that. Cracking the coding interview-exercises only.
jsjohnst 9y ago
I agree with this approach a lot, being able to speak about code intelligently is very important. But live coding by fire on some esoteric random brain teaser is not effective, imho.

paulddraper 9y ago

> Especially for research-heavy positions Sure. But if you're hiring general purpose noon-senior software engineers, live coding exercises separate the wheat and the chafe very quickly. Lots of people lie on resumes and are smooth talkers, but lack basic skills for their job. A coding exercise is a really fast way to find these. Then you can move on to more interesting things.

dmoy 9y ago
Yup, I don't enjoy coding interviews, but the number of people I've interviewed with ostensibly many years of programming experience who can't actually write some basic code with a for loop and a couple of variables makes me extremely hesitant to hire without a coding interview. If you haven't run across people like this yet, you simply haven't done enough interviews yet, or have somehow entered into an alternate fairytale land where everyone is honest (and if so please take me with you!).
- jsjohnst 9y ago
  > or have somehow entered into an alternate fairytale land where everyone is honest This won't likely be a popular answer, but more likely than what you described above is simply that you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand. It's perfectly understandable that many don't have this skill as it's rarely ever taught before you start doing interviews at an employer.
  - paulddraper 9y ago
    > you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand I'm sure we could figure out a non-code non-marker way. I'm also sure I could figure out a commute involving only right turns. But why would I arbitraily constrain my solution like that?
    - jsjohnst 9y ago

acangiano 9y ago

At IBM, I review hundreds of resumes and interview dozens of candidates each year (mostly students or new graduates). I used to ask tough algorithmic questions, require a small coding assignment, etc. I no longer do that. Today, I have technical conversations like you describe. I don't need you to remember that 415 is Unsupported Media Type. But I need you to be able to discuss how REST works, the difference between 400s and 500s error codes, and maybe even REST vs GraphQL advantages and tradeoffs, if you mention the latter on your resume. Occasionally I get a surprised "This was so nice. I was expecting a coding interview". It was a coding interview, just not the kind the candidate is used to. You can look up specific answers on Google, but you can't quickly google your way out of a conceptual discussion, your involvement with past projects, technologies that excite you, etc. Generally speaking, I can tell within 5 minutes who is a great candidate. Luck might have played a part, but I have not had a single bad hire with this method so far. In fairness, I'm selective with the candidates I decide to interview, from usually large pools. For these, I also tend to review code they've written in the past if they specify a GitHub account on their resume.

jsjohnst 9y ago
I've done hundreds of interviews for candidates over the past twenty years and couldn't agree with you more. The ultra rare occurrence that someone can talk their way through and elude b/s detectors is usually caught later in the interview process anyway.
audessuscest 9y ago
Same. Hired 12 developers so far with this method and I made only one mistake, others are all great developers.
- necrodome 9y ago
  What does "the mistake" look like?
  - coob 9y ago
    You can't always easily tell when someone is going to be a pain to work with on an interpersonal level.

rdiddly 9y ago

Yep, obviously there are good ways and bad ways to use any tool. And the shiny shiny lures a lot of people into using new tools poorly when they already know how to use old tools well.