5 ms·

Serious question, if whiteboard interview aren't the best or helpful at all, what are the successful/useful alternatives for engineering interviews?

by devy 8y ago

romaniv 8y ago
Letting candidates to do actual coding on a computer.
- jonathankoren 8y ago
  Yeah, but that's also stupid. All to often it comes down to "Make standup a completly working client server system for this arbitrary problem from scratch in 30 minutes, starting... NOW!" You end up spending all your time dicking around with missed semicolons and looking up library routines and shit like that. Sure, it's all stuff you have to do as part of a job, but it's also all trivial stuff. The last time I had to do this, I spent time googling how to open up a port in python, and then read from stdin. It's just a waste of time. All this does is test the wrong things.
  - romaniv 8y ago
    Find a reasonably self-contained problem that doesn't involve too many interactions with the "environment". For example, ask the candidate to refactor an existing piece of code.
    - jonathankoren 8y ago
      Well the interviewee doesn't get to choose do they?
lfowles 8y ago
My favorite interviews have been those that had a small project as a screener and then proceeded to have you modify and/or explain decisions regarding the project at the in-person stage.
KallDrexx 8y ago
I haven't had the opportunity yet but I really want to take a piece of code from our system, de-optimize it a bit and add some bugs, then give users a unit test around it. Most of what we do as engineers is trying to read code to figure out what it's doing, how to fix it and how to enhance it. Going through real code with a candidate and assessing their ability to understand brand new code (and what questions they ask) seems like it would give good insight to how they would perform on the job.
- cableshaft 8y ago
  In one of the best interviews I had, the interviewer had printed off an actual (undocumented) class in one of their projects (I got the job, so I confirmed it later), then asked me to tell him what it did, and if there was anything I would do to improve it. I think he might have added a couple of logic or syntax issues as well, but I can't quite remember anymore. I've been on dozens of interviews, and that's the only time I've ever encountered that, but I think it does a really good job representing the job, as that's invariably what I'm going to have to do when you hire me, is sit down and familiarize myself with the code base. He also asked me a handful of questions, said "Okay I know you know enough to do the job, let's see how much you really know," asked me a bunch of really low level stuff, and proceeded to teach me concepts when I told him I didn't know certain things. I walked out of that interview knowing more than when I walked in, something else that has never happened in all the other interviews I've had (except maybe I learned a new term that I never heard before that I was apparently supposed to regurgitate back because that's what was written down as the answer on HR's answer sheet).
iamNumber4 8y ago
Coding challenges either take home or live session. Most whiteboard questions are always some esoteric algorithm any engineer worth their salt would in real life would look up before ever consider using to verify their own understanding before using it. Putting someone on the spot saying whiteboard x is not ok. However if the test is to see if they can take part in a meeting, then by all means do a white board, but ask them draw a workflow diagram or some other 40,000 foot type of diagram. Do not ask them to put code on a whiteboard.
- ubernostrum 8y ago
  It's not just that real working engineers would go look it up. It's that the culture around these "prove you can code" problems got into an arms race, where companies kept trying to come up with ever more difficult problems and stringent requirements on solutions. It finally reached the point where, at some companies which use them, the bar for "can you code at all" is actually "given a problem you've never seen before, can you match or beat the absolute best solution the world's best CS researchers have ever come up with, in twenty minutes, on this whiteboard". If you aren't able to, they label you a bozo who can't even write a for loop, and pronounce you unqualified to do any type of programming, and pat themselves on the back for having kept "fake coders" out of their company. (and if you wonder how anyone ever gets hired there, the answer is: by cheating. If you're going to interview at one of those places, odds are their interview problem and an accepted solution will be online somewhere, so you just go look up and memorize)
  - sbov 8y ago
    Yes, my favorite was a while back, someone's list of algorithmic interview questions got posted on here, and a couple of his answers were wrong! And he STILL insisted they were good interview questions! Our field is full of some of the smartest morons on the planet.
  - Ancalagon 8y ago
    You absolutely nailed it.
optimuspaul 8y ago
The best I have come up with if you are requiring them to write actual code is to give them a problem to solve for with code prior to interviewing. Have them bring that code along and then have them explain the code and why they did things the way they did. It is not 100% verifiable that they wrote the code, but being able to talk to why things were done the way they were tends to be good enough. I have also found that understanding how people approach life and problems in general are more telling of how good they will be than actually evaluating their coding skills. Monitoring coding exercises will weed out many good candidates as well as the poor ones in my experience.
- ordinaryperson 8y ago
  Exactly. During my recent job search I was asked many questions I didn't know the secret algorithm to, but if those companies had given me the problem ahead of time and allowed me to research it -- just like what happens in real life -- I could have coded solutions to all of them. And if you're worried about people just plagiarizing existing solutions, have them talk through it, as you say. Should be fairly clear if they understand each line or not.
FLUX-YOU 8y ago
I really wish we had multiple formats that the candidate could choose from: 1) Whiteboard 2) Review and technical discussion of existing code or projects 3) Paid take-home project 4) Pair programming on live code 5) Technical discussion only for rare cases for those Top Secret/NDA candidates that really can't discuss their past projects but are also time constrained Some people do actually like to whiteboard. Keeping it around is kind of like legacy support for people who practiced hard to excel in those interviews. This is pretty much the union of technical interviews that are well-known. If you switch out a technical interview format and can't get meaningful insights into a candidate, you're testing for the wrong things.
mountainofdeath 8y ago
We could be like real Engineers (civil, certain classes of mechanical and electrical) and require a license. One 8 hour exam covering fundamentals and application of them along with simple project management and soft skills.
keithnz 8y ago
Depends on "why" you are recruiting and what the end result of employing someone is. So much of the technical hiring process tends to be about trying to find people that match what you expect people to be. Which might be fine, you need to fill a particular position which requires a specific set of skills. You need to validate those skills. You do that by doing something semi realistic while trying to minimize the pressure of an interview situation. But, then there is the other kind of approach where you are looking to see what the candidate can offer, trying to find people who know different things to you and do things differently than you, in this scenario you are more inquisitive and let the candidate direct the interview process and get them to show you things that sound interesting (including coding). The first approach is all about finding specific skills. The second approach is all about being clear about the values you are looking for. The second approach requires more skill and more time while wearing the hat of a technical recruiter. You may need a little bit of both approaches. So the big thing is to be clear about who you want to work with at the end of the process.
mushka 8y ago
Just talk. Have a conversation. There is no point in trying to put someone outside of his comfort zone. You should take him to the very center ot it, and then see how well he can managd. Any question that the interviewer already knows the answer to is not a good question.

Serious question, if whiteboard interview aren't the best or helpful at all, what are the successful/useful alternatives for engineering interviews?

by devy 8y ago

Serious question, if whiteboard interview aren't the best or helpful at all, what are the successful/useful alternatives for engineering interviews?

romaniv 8y ago

Letting candidates to do actual coding on a computer.

jonathankoren 8y ago
Yeah, but that's also stupid. All to often it comes down to "Make standup a completly working client server system for this arbitrary problem from scratch in 30 minutes, starting... NOW!" You end up spending all your time dicking around with missed semicolons and looking up library routines and shit like that. Sure, it's all stuff you have to do as part of a job, but it's also all trivial stuff. The last time I had to do this, I spent time googling how to open up a port in python, and then read from stdin. It's just a waste of time. All this does is test the wrong things.
- romaniv 8y ago
  Find a reasonably self-contained problem that doesn't involve too many interactions with the "environment". For example, ask the candidate to refactor an existing piece of code.
  - jonathankoren 8y ago
    Well the interviewee doesn't get to choose do they?

lfowles 8y ago

My favorite interviews have been those that had a small project as a screener and then proceeded to have you modify and/or explain decisions regarding the project at the in-person stage.

KallDrexx 8y ago

I haven't had the opportunity yet but I really want to take a piece of code from our system, de-optimize it a bit and add some bugs, then give users a unit test around it. Most of what we do as engineers is trying to read code to figure out what it's doing, how to fix it and how to enhance it. Going through real code with a candidate and assessing their ability to understand brand new code (and what questions they ask) seems like it would give good insight to how they would perform on the job.

cableshaft 8y ago
In one of the best interviews I had, the interviewer had printed off an actual (undocumented) class in one of their projects (I got the job, so I confirmed it later), then asked me to tell him what it did, and if there was anything I would do to improve it. I think he might have added a couple of logic or syntax issues as well, but I can't quite remember anymore. I've been on dozens of interviews, and that's the only time I've ever encountered that, but I think it does a really good job representing the job, as that's invariably what I'm going to have to do when you hire me, is sit down and familiarize myself with the code base. He also asked me a handful of questions, said "Okay I know you know enough to do the job, let's see how much you really know," asked me a bunch of really low level stuff, and proceeded to teach me concepts when I told him I didn't know certain things. I walked out of that interview knowing more than when I walked in, something else that has never happened in all the other interviews I've had (except maybe I learned a new term that I never heard before that I was apparently supposed to regurgitate back because that's what was written down as the answer on HR's answer sheet).

iamNumber4 8y ago

Coding challenges either take home or live session. Most whiteboard questions are always some esoteric algorithm any engineer worth their salt would in real life would look up before ever consider using to verify their own understanding before using it. Putting someone on the spot saying whiteboard x is not ok. However if the test is to see if they can take part in a meeting, then by all means do a white board, but ask them draw a workflow diagram or some other 40,000 foot type of diagram. Do not ask them to put code on a whiteboard.

ubernostrum 8y ago
It's not just that real working engineers would go look it up. It's that the culture around these "prove you can code" problems got into an arms race, where companies kept trying to come up with ever more difficult problems and stringent requirements on solutions. It finally reached the point where, at some companies which use them, the bar for "can you code at all" is actually "given a problem you've never seen before, can you match or beat the absolute best solution the world's best CS researchers have ever come up with, in twenty minutes, on this whiteboard". If you aren't able to, they label you a bozo who can't even write a for loop, and pronounce you unqualified to do any type of programming, and pat themselves on the back for having kept "fake coders" out of their company. (and if you wonder how anyone ever gets hired there, the answer is: by cheating. If you're going to interview at one of those places, odds are their interview problem and an accepted solution will be online somewhere, so you just go look up and memorize)
- sbov 8y ago
  Yes, my favorite was a while back, someone's list of algorithmic interview questions got posted on here, and a couple of his answers were wrong! And he STILL insisted they were good interview questions! Our field is full of some of the smartest morons on the planet.
- Ancalagon 8y ago
  You absolutely nailed it.

optimuspaul 8y ago

The best I have come up with if you are requiring them to write actual code is to give them a problem to solve for with code prior to interviewing. Have them bring that code along and then have them explain the code and why they did things the way they did. It is not 100% verifiable that they wrote the code, but being able to talk to why things were done the way they were tends to be good enough. I have also found that understanding how people approach life and problems in general are more telling of how good they will be than actually evaluating their coding skills. Monitoring coding exercises will weed out many good candidates as well as the poor ones in my experience.

ordinaryperson 8y ago
Exactly. During my recent job search I was asked many questions I didn't know the secret algorithm to, but if those companies had given me the problem ahead of time and allowed me to research it -- just like what happens in real life -- I could have coded solutions to all of them. And if you're worried about people just plagiarizing existing solutions, have them talk through it, as you say. Should be fairly clear if they understand each line or not.

FLUX-YOU 8y ago

I really wish we had multiple formats that the candidate could choose from: 1) Whiteboard 2) Review and technical discussion of existing code or projects 3) Paid take-home project 4) Pair programming on live code 5) Technical discussion only for rare cases for those Top Secret/NDA candidates that really can't discuss their past projects but are also time constrained Some people do actually like to whiteboard. Keeping it around is kind of like legacy support for people who practiced hard to excel in those interviews. This is pretty much the union of technical interviews that are well-known. If you switch out a technical interview format and can't get meaningful insights into a candidate, you're testing for the wrong things.

mountainofdeath 8y ago

We could be like real Engineers (civil, certain classes of mechanical and electrical) and require a license. One 8 hour exam covering fundamentals and application of them along with simple project management and soft skills.

keithnz 8y ago

Depends on "why" you are recruiting and what the end result of employing someone is. So much of the technical hiring process tends to be about trying to find people that match what you expect people to be. Which might be fine, you need to fill a particular position which requires a specific set of skills. You need to validate those skills. You do that by doing something semi realistic while trying to minimize the pressure of an interview situation. But, then there is the other kind of approach where you are looking to see what the candidate can offer, trying to find people who know different things to you and do things differently than you, in this scenario you are more inquisitive and let the candidate direct the interview process and get them to show you things that sound interesting (including coding). The first approach is all about finding specific skills. The second approach is all about being clear about the values you are looking for. The second approach requires more skill and more time while wearing the hat of a technical recruiter. You may need a little bit of both approaches. So the big thing is to be clear about who you want to work with at the end of the process.

mushka 8y ago

Just talk. Have a conversation. There is no point in trying to put someone outside of his comfort zone. You should take him to the very center ot it, and then see how well he can managd. Any question that the interviewer already knows the answer to is not a good question.