5 ms·

I think the author is saying we should do interviews like nearly every other industry. Look at past experience, and ask the candidate to talk about that experi

by learc83 12y ago

I think the author is saying we should do interviews like nearly every other industry. Look at past experience, and ask the candidate to talk about that experience to verify that they aren't lying. If someone has 5 years experience working at Google, and they can talk coherently about technical aspects of the projects they worked on, there is no reason to ask them to code on a whiteboard. The way it currently works is this: I see you have a CS, degree and 10 years experience at a well known company. Excellent. Now you have 2 eggs and a 100 story skyscraper. Tell me the minimum number of egg drops you'll have to perform to discover the minimum height that will break the egg. Every engineer no matter how experienced has to answer questions like they just left school yesterday, no other industry does this. >Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz. 99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.

mahyarm 12y ago
This is why I like to give laptops to engineers and ask to make something simple, that might require logic, but doesn't require any sort of specialized knowledge. They can even look up documentation. Like make a table view that has word counts for a string. Or make this simple puzzle game. Or make a simple address book app.
- jaredsohn 12y ago
  Just an FYI -- working on someone else's laptop can often be an unpleasant experience (weird keyboard configuration, different software installed, etc.) My current opinion on this would be to offer a laptop so you aren't disadvantaging candidates who don't have one too badly, but let people use their own if they have one (and let them know ahead of time that it will be an option and what they should be set up for.)
  - jghn 12y ago
    We tell candidates up front that they'll be doing some live coding and welcome them to bring their own laptop if they would like. We have a backup around with just about every reasonable IDE and editor installed for our languages but even then I agree, it's definitely not the same using someone else's computer.
    - iopq 12y ago
      I program on my desktop with two monitors, I wouldn't be comfortable on a laptop without at least two extra large monitors hooked up to it already. And a normal keyboard, don't give me that laptop keyboard crap.
      - mpercy 12y ago
        Wow... I understand that you'd be much more productive with a large monitor and good keyboard, but to the extent that you couldn't perform in a coding interview? Give me a break... In the past, I've used CollabEdit for "phone screens" and the whiteboard for in-person interviews. I try to ask some "coding" questions (identify a better data structure / algo for a particular scenario and then implement it in code) and some problem-solving conversational questions. Seems to work pretty well, but I'm always on the lookout for better approaches. Part of the problem is that the software field is so broad that it's hard to get a sense of a person's abilities with such a limited amount of time to ask questions.
      - jghn 12y ago
        Sure, we'd all want an ideal setup but ideal isn't possible in an interview situation - both sides need to compromise a bit for practical reasons. And really, while we say "laptop" if someone wanted to lug in their desktop with two monitors and keyboard we wouldn't stop them. In fact, it'd probably earn them points for being extra nerdy ;) Would you rather a laptop w/ standard editors and IDEs or would you prefer a google doc, collabedit or a whiteboard like many places do?
      - mahyarm 12y ago
        One company I know of says bring your own laptop as a result, and another says they do a day of pair programming as the interview.
  - yitchelle 12y ago
    Hmm..This just pop into my mind as I read your comment. Could you use this specific scenario to view how the candidate would react? If he starts to complain that the right tools are not on the laptop, or he is unfamiliar with environment, does it is signify that he is focusing too much on the tools rather than on solving the problem? Maybe his time management skills needs some work, ie limited time to solve the problem and too much time worrying about environment.
jghn 12y ago
"Look at past experience, and ask the candidate to talk about that experience to verify that they aren't lying. If someone has 5 years experience working at Google, and they can talk coherently about technical aspects of the projects they worked on, there is no reason to ask them to code on a whiteboard." I always argue for this, and about 98% of the time people look at me like I'm sort of crazy man and our company is going to go down in flames. Everyone has an anecdote, "well, there was this one time ....", yet I'm convinced that there's roughly 0 real value add from all of the hoops and hurdles most interviews provide in terms of accurately identifying strong candidates. I always try to make the argument that if someone can talk intelligently about a wide range of programming knowledge in an actual conversation - for instance, knowing that data type X would be a logical segue from the current point, and do that throughout the interview, personally I think the likelihood of them being an idiot are slim. However, most people I argue this to are always afraid of this, afraid that some interloper will sneak through unless we put them through a gauntlet of questions regarding things they'll never do in their day to day life.
ansible 12y ago
Well, we don't do the puzzle questions, and I agree that those are not useful to determine the level of software engineering experience a candidate has. However... 99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on. That does not work for us. We must put each and every candidate in front of a keyboard, and bang out at least a little code. We had one candidate, recently graduated with an MS in CS. Nice personality, good talker in general. The candidate seemed to understand CS and could explain how to solve problems. However, even with repeated prompting, I could not get this person to even type in a loop to start to solve the problem presented. We've interviewed multiple candidates with a BS in CS or similar who also spectacularly failed at doing even basic coding tasks. Some people are really great talkers. They really do sound like they know what they are doing. But that does not mean they can actually do anything.
- mattmanser 12y ago
  How is this relevant to the parent? You're talking about someone with a CS degree, which means they have no experience. How can you ask them about the technical aspects of what they did on a project. "What parts of the system did you write? And what problems did you hit. What solution or bug were you proud of solving?". A degree is not experience, CS != programming.
  - ansible 12y ago
    Nearly all the the candidates that we've interviewed have at least a little job experience, such as an internship. And even for the ones that don't, they all have worked on team-based projects as part of their coursework. So we end up asking them all those sorts of questions.
    - vidarh 12y ago
      Working on team-based projects as part of coursework does not mean they've ever written a line of code in their life. Going through a CS degree without learning to code is easy. Depending on your CS course you may hardly have touched any code beyond extremely entry level courses where you're being hand-held the entire way, if you pick the "right" subject. CS is not software engineering. Similar with internships. For both those situations, I can understand that you want to verify ability to actually write code.

by learc83 12y ago

mahyarm 12y ago

This is why I like to give laptops to engineers and ask to make something simple, that might require logic, but doesn't require any sort of specialized knowledge. They can even look up documentation. Like make a table view that has word counts for a string. Or make this simple puzzle game. Or make a simple address book app.

jaredsohn 12y ago
Just an FYI -- working on someone else's laptop can often be an unpleasant experience (weird keyboard configuration, different software installed, etc.) My current opinion on this would be to offer a laptop so you aren't disadvantaging candidates who don't have one too badly, but let people use their own if they have one (and let them know ahead of time that it will be an option and what they should be set up for.)
- jghn 12y ago
  We tell candidates up front that they'll be doing some live coding and welcome them to bring their own laptop if they would like. We have a backup around with just about every reasonable IDE and editor installed for our languages but even then I agree, it's definitely not the same using someone else's computer.
  - iopq 12y ago
    I program on my desktop with two monitors, I wouldn't be comfortable on a laptop without at least two extra large monitors hooked up to it already. And a normal keyboard, don't give me that laptop keyboard crap.
    - mpercy 12y ago
      Wow... I understand that you'd be much more productive with a large monitor and good keyboard, but to the extent that you couldn't perform in a coding interview? Give me a break... In the past, I've used CollabEdit for "phone screens" and the whiteboard for in-person interviews. I try to ask some "coding" questions (identify a better data structure / algo for a particular scenario and then implement it in code) and some problem-solving conversational questions. Seems to work pretty well, but I'm always on the lookout for better approaches. Part of the problem is that the software field is so broad that it's hard to get a sense of a person's abilities with such a limited amount of time to ask questions.
    - jghn 12y ago
      Sure, we'd all want an ideal setup but ideal isn't possible in an interview situation - both sides need to compromise a bit for practical reasons. And really, while we say "laptop" if someone wanted to lug in their desktop with two monitors and keyboard we wouldn't stop them. In fact, it'd probably earn them points for being extra nerdy ;) Would you rather a laptop w/ standard editors and IDEs or would you prefer a google doc, collabedit or a whiteboard like many places do?
    - mahyarm 12y ago
      One company I know of says bring your own laptop as a result, and another says they do a day of pair programming as the interview.
- yitchelle 12y ago
  Hmm..This just pop into my mind as I read your comment. Could you use this specific scenario to view how the candidate would react? If he starts to complain that the right tools are not on the laptop, or he is unfamiliar with environment, does it is signify that he is focusing too much on the tools rather than on solving the problem? Maybe his time management skills needs some work, ie limited time to solve the problem and too much time worrying about environment.

jghn 12y ago

"Look at past experience, and ask the candidate to talk about that experience to verify that they aren't lying. If someone has 5 years experience working at Google, and they can talk coherently about technical aspects of the projects they worked on, there is no reason to ask them to code on a whiteboard." I always argue for this, and about 98% of the time people look at me like I'm sort of crazy man and our company is going to go down in flames. Everyone has an anecdote, "well, there was this one time ....", yet I'm convinced that there's roughly 0 real value add from all of the hoops and hurdles most interviews provide in terms of accurately identifying strong candidates. I always try to make the argument that if someone can talk intelligently about a wide range of programming knowledge in an actual conversation - for instance, knowing that data type X would be a logical segue from the current point, and do that throughout the interview, personally I think the likelihood of them being an idiot are slim. However, most people I argue this to are always afraid of this, afraid that some interloper will sneak through unless we put them through a gauntlet of questions regarding things they'll never do in their day to day life.

ansible 12y ago

Well, we don't do the puzzle questions, and I agree that those are not useful to determine the level of software engineering experience a candidate has. However... 99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on. That does not work for us. We must put each and every candidate in front of a keyboard, and bang out at least a little code. We had one candidate, recently graduated with an MS in CS. Nice personality, good talker in general. The candidate seemed to understand CS and could explain how to solve problems. However, even with repeated prompting, I could not get this person to even type in a loop to start to solve the problem presented. We've interviewed multiple candidates with a BS in CS or similar who also spectacularly failed at doing even basic coding tasks. Some people are really great talkers. They really do sound like they know what they are doing. But that does not mean they can actually do anything.

mattmanser 12y ago
How is this relevant to the parent? You're talking about someone with a CS degree, which means they have no experience. How can you ask them about the technical aspects of what they did on a project. "What parts of the system did you write? And what problems did you hit. What solution or bug were you proud of solving?". A degree is not experience, CS != programming.
- ansible 12y ago
  Nearly all the the candidates that we've interviewed have at least a little job experience, such as an internship. And even for the ones that don't, they all have worked on team-based projects as part of their coursework. So we end up asking them all those sorts of questions.
  - vidarh 12y ago
    Working on team-based projects as part of coursework does not mean they've ever written a line of code in their life. Going through a CS degree without learning to code is easy. Depending on your CS course you may hardly have touched any code beyond extremely entry level courses where you're being hand-held the entire way, if you pick the "right" subject. CS is not software engineering. Similar with internships. For both those situations, I can understand that you want to verify ability to actually write code.