7 ms·

> "As opposed to fox-and-hare looped link lists or implementing a binary tree or something else I’ve done a hundred times in an interview and not once in my ac

> "As opposed to fox-and-hare looped link lists or implementing a binary tree or something else I’ve done a hundred times in an interview and not once in my actual job." This. Interviewers, stop asking questions that only a fresh college grad should have at the forefront of their mind. One of the best interview's I've had, was actually for a job I didn't get. It was for a game development company, and they actually posed problems and questions one might face in their day to day work. For example, writing an efficient collision detection algorithm.

wutbrodo 10y ago
> This. Interviewers, stop asking questions that only a fresh college grad should have at the forefront of their mind. These aren't questions "only a college grad should know" they're often questions that are baseline knowledge for understanding programming vs just having a few rote cargo cult "skills". I have been on both sides of the interview process at Google, and I remember when I was prepping to conduct my first interview, one of my teammates gave me some advice. He suggested I open with something along the lines of "merge two sorted lists". Someone who couldn't do this with a minimum of effort barely fits the definition of "knowing how to program" (let alone being a good engineer). And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test. Bear in mind that this was at Google, and these were candidates who had already made it past the first line filter.
- _RPM 10y ago
  Consider the fact that coding under pressure is hard and it probably doesn't mean that the candidate is incapable of merging two sorted lists. Right now I can think of a way to do it: var ar = []; ar1.map(function() { ar.push(arguments[0]); } ar2.map(function() { ar.push(arguments[0]); } However, under pressure it's so much different than responding to a comment. This is for sure a great question to ask.
  - jaredsohn 10y ago
    FYI, this doesn't merge two _sorted_ lists. The correct answer would be to loop while neither list is empty and always put the smaller element into the new array and remove it from the original list. Then you iterate over each of the lists individually (one of them will already be empty) and copy over the remaining elements at the end. Edit: See http://stackoverflow.com/questions/5958169/how-to-merge-two-sorted-arrays-into-a-sorted-array http://stackoverflow.com/questions/5958169/how-to-merge-two-... for some solutions (in one of the answers there, they made the same mistake.)
    - _RPM 10y ago
      Oh shit. I just failed the interview then. I'm just not that smart, more of a code monkey type, not really a mathematician computational type programmer. I want to be better, but I think I'm just cut out for line of business type things where you don't need any CS knowledge even though I will have a CS degree soon.
      - wutbrodo 10y ago
        That's what I mean, just because the question is abstracted to be pure numbers doesn't mean that it's mathematician computational type stuff. This is a basic enough task (data structures, iteration) that someone who can't do it wouldn't meet any reasonable definition of "knowing how to code". By the way, I don't think that group includes you: I'm quite sure you'd be able to pass it in an interview context. You'd probably be paying more attention to the details of the question in an interview and I usually give sample input/output to reduce the chance of a candidate accidentally overlooking a word in the question.
        lazaroclapp 10y ago
        I would correct to 'any reasonable definition of being a professional software developer'. There are tons of programming tasks that require coding literacy but do not require even knowing what a linked list is (e.g. simulations written by really smart people pursuing a Physics Ph.D., perl scripts done by wise UNIX-beard sysadmins, etc). That said, I agree this is a reasonable sanity-check test for someone who is asking about a developer job at a software company, and I also agree that it is easy to make mistakes in commenting an off-the-cuff answer to it on an online forum that one wouldn't make in a real interview. I mean, I've gotten 3rd grade arithmetic wrong in my own HN comments before! ;)
- vonmoltke 10y ago
  > Bear in mind that this was at Google, and these were candidates who had already made it past the first line filter. Are you sure that Google's first line filter is actually good?
  - wutbrodo 10y ago
    I don't think super highly of it in an objective sense, but I do think that they have the resources (and probably the know-how) to do a better job at it than the vast majority of hiring situations (smaller companies, etc). And I do have a high opinion of the engineering talent at Google, who are involved in the phone interview process (which I guess I was lumping together with actual HR first-line resume screening).
- kevan 10y ago
  >He suggested I open with something along the lines of "merge two sorted lists". We (my team at Amazon) don't start with a softball, but we try to make sure every question can be down-leveled if someone is struggling. My current one degenerates to: "insert numbers in a sorted list, then find the index of a number in the list". A surprising number of people struggle with this. I know lots of people get tripped up by graph and tree problems (myself included) because they don't use them in real life often, but simple lists are another story. At FaceGoogAzon scale you can't always rely on array.sort().
  - emmelaich 10y ago
    For a sysadmin/devopsy position I asked the interviewees to write a program in any language that gave the average of numbers given as command line args. Not one did it successfully. Most didn't even try. The best one assumed five numbers given. But we had to hire someone, and it wasn't this one. The deciders just hired the nicest person.
    - jean_engineer 10y ago
      Wow. Were these candidates with CS degrees? What was the problem? Did they not know how to parse command line args in any language? Not know how to compute an average? Not know how to do anything on the command line (or outside an IDE)? Something else?
      - emmelaich 10y ago
        We didn't go into it unfortunately. I don't want to ask it of the one we hired because I don't want to cause bad blood. :-( It's possible that what little programming they did in their 'information science' (or whatever degree, not straight CS) only involved Windows programming, and nothing on the command line.
- rubicon33 10y ago
  > " And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test." And yet, I'd be surprised if almost all of those who didn't pass his "basic test" went on to be gainfully employed, and successful, building X app at X company instead of at Google.
  - wutbrodo 10y ago
    That may be true, but I've never been at a company that was desperate enough to hire cargo cult programmers. Interview jitters aside (that's an unfortunate artifact of the coding interview), not having a grasp of loops, iteration, and the most basic of data structures is a low, low, low bar for "knows how to program". I'm not even being particularly picky here. Big companies can be notorious for hiring CS grads from great programs and never having them do any actual computer science, and I agree that that bar is unnecessary for good engineering. But this filter isn't _unrelated_ to the job of being an engineer (or even a code monkey!), it's basic, basic programming. I'd imagine it does a great job of removing the kind of candidates who are capable of trivially avoidable bugs that become time bombs down the road.
    - uola 10y ago
      Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult. Many of Googles products implode shortly after getting released making software quality irrelevant. Also many successful Google products were originally made by other companies, presumably with different hiring processes, that joined Google. That said, from what I've heard it isn't the questions themselves so much as the overall interview process that puts people off.
      - GrumpyYoungMan 10y ago
        >Hiring people based on things they won't use seems an awful lot like a cargo cult. Yes, but in this case, it's a cargo cult of over-qualification. Hardly a bad thing. >Many of Googles products implode shortly after getting released making software quality irrelevant. That is a function of leadership and poor product planning and has nothing to do with the quality of the engineers there.
- hesarenu 10y ago
  Would the candidates just clear the interview by mugging up on algorithms.
- namaemuta 10y ago
  In "merging" it is assumed that there won't be any repeated values? that is the first question that came to my mind.
  - wutbrodo 10y ago
    That's just an implementation detail whose answer wouldn't really change the difficulty of the question much. When actually interviewing (at any company), I'm always much more precise about the question and usually give representative sample input/output.
cardine 10y ago
We ask a couple difficult algorithms questions in our interviews but I also think that is pretty indicative of the day to day work you might have to be doing at positions we hire for. If someone is offended by being asked to code something like this then they are probably going to be offended by the work they'll have to do once they start employment. Of course there are other parts of our interview as well, but I've found an initial interview with a difficult algorithms problem does a great job filtering out bad programmers. Once we've filtered out the bad programmers we'll do a second interview that involves code from a project we've used in production before.
- namaemuta 10y ago
  > If someone is offended by being asked to code something like this then they are probably going to be offended by the work they'll have to do once they start employment. I don't agree with you because it's not the same context. In a day to day job context, you can focus on doing it correctly while in an interview there are a lot of factors that can affect your focus/creativity/attention.
  - adrianratnapala 10y ago
    In my experience it is the opposite. At a whiteboard inteview, you can focus on the code and the algorithm. In the real process, you might on any given day also have to wrangle with your build system, meetings, the structure of existing code, the test setup, colleauges who need help, debugging tools. Now that might be an argument for why a whiteboard interview is inadequate. But not for why an whiteboard interview is distracting.

wutbrodo 10y ago

> This. Interviewers, stop asking questions that only a fresh college grad should have at the forefront of their mind. These aren't questions "only a college grad should know" they're often questions that are baseline knowledge for understanding programming vs just having a few rote cargo cult "skills". I have been on both sides of the interview process at Google, and I remember when I was prepping to conduct my first interview, one of my teammates gave me some advice. He suggested I open with something along the lines of "merge two sorted lists". Someone who couldn't do this with a minimum of effort barely fits the definition of "knowing how to program" (let alone being a good engineer). And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test. Bear in mind that this was at Google, and these were candidates who had already made it past the first line filter.

_RPM 10y ago
Consider the fact that coding under pressure is hard and it probably doesn't mean that the candidate is incapable of merging two sorted lists. Right now I can think of a way to do it: var ar = []; ar1.map(function() { ar.push(arguments[0]); } ar2.map(function() { ar.push(arguments[0]); } However, under pressure it's so much different than responding to a comment. This is for sure a great question to ask.
- jaredsohn 10y ago
  FYI, this doesn't merge two _sorted_ lists. The correct answer would be to loop while neither list is empty and always put the smaller element into the new array and remove it from the original list. Then you iterate over each of the lists individually (one of them will already be empty) and copy over the remaining elements at the end. Edit: See http://stackoverflow.com/questions/5958169/how-to-merge-two-sorted-arrays-into-a-sorted-array http://stackoverflow.com/questions/5958169/how-to-merge-two-... for some solutions (in one of the answers there, they made the same mistake.)
  - _RPM 10y ago
    Oh shit. I just failed the interview then. I'm just not that smart, more of a code monkey type, not really a mathematician computational type programmer. I want to be better, but I think I'm just cut out for line of business type things where you don't need any CS knowledge even though I will have a CS degree soon.
    - wutbrodo 10y ago
      That's what I mean, just because the question is abstracted to be pure numbers doesn't mean that it's mathematician computational type stuff. This is a basic enough task (data structures, iteration) that someone who can't do it wouldn't meet any reasonable definition of "knowing how to code". By the way, I don't think that group includes you: I'm quite sure you'd be able to pass it in an interview context. You'd probably be paying more attention to the details of the question in an interview and I usually give sample input/output to reduce the chance of a candidate accidentally overlooking a word in the question.
      - lazaroclapp 10y ago
        I would correct to 'any reasonable definition of being a professional software developer'. There are tons of programming tasks that require coding literacy but do not require even knowing what a linked list is (e.g. simulations written by really smart people pursuing a Physics Ph.D., perl scripts done by wise UNIX-beard sysadmins, etc). That said, I agree this is a reasonable sanity-check test for someone who is asking about a developer job at a software company, and I also agree that it is easy to make mistakes in commenting an off-the-cuff answer to it on an online forum that one wouldn't make in a real interview. I mean, I've gotten 3rd grade arithmetic wrong in my own HN comments before! ;)
vonmoltke 10y ago
> Bear in mind that this was at Google, and these were candidates who had already made it past the first line filter. Are you sure that Google's first line filter is actually good?
- wutbrodo 10y ago
  I don't think super highly of it in an objective sense, but I do think that they have the resources (and probably the know-how) to do a better job at it than the vast majority of hiring situations (smaller companies, etc). And I do have a high opinion of the engineering talent at Google, who are involved in the phone interview process (which I guess I was lumping together with actual HR first-line resume screening).
kevan 10y ago
>He suggested I open with something along the lines of "merge two sorted lists". We (my team at Amazon) don't start with a softball, but we try to make sure every question can be down-leveled if someone is struggling. My current one degenerates to: "insert numbers in a sorted list, then find the index of a number in the list". A surprising number of people struggle with this. I know lots of people get tripped up by graph and tree problems (myself included) because they don't use them in real life often, but simple lists are another story. At FaceGoogAzon scale you can't always rely on array.sort().
- emmelaich 10y ago
  For a sysadmin/devopsy position I asked the interviewees to write a program in any language that gave the average of numbers given as command line args. Not one did it successfully. Most didn't even try. The best one assumed five numbers given. But we had to hire someone, and it wasn't this one. The deciders just hired the nicest person.
  - jean_engineer 10y ago
    Wow. Were these candidates with CS degrees? What was the problem? Did they not know how to parse command line args in any language? Not know how to compute an average? Not know how to do anything on the command line (or outside an IDE)? Something else?
    - emmelaich 10y ago
      We didn't go into it unfortunately. I don't want to ask it of the one we hired because I don't want to cause bad blood. :-( It's possible that what little programming they did in their 'information science' (or whatever degree, not straight CS) only involved Windows programming, and nothing on the command line.
rubicon33 10y ago
> " And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test." And yet, I'd be surprised if almost all of those who didn't pass his "basic test" went on to be gainfully employed, and successful, building X app at X company instead of at Google.
- wutbrodo 10y ago
  That may be true, but I've never been at a company that was desperate enough to hire cargo cult programmers. Interview jitters aside (that's an unfortunate artifact of the coding interview), not having a grasp of loops, iteration, and the most basic of data structures is a low, low, low bar for "knows how to program". I'm not even being particularly picky here. Big companies can be notorious for hiring CS grads from great programs and never having them do any actual computer science, and I agree that that bar is unnecessary for good engineering. But this filter isn't _unrelated_ to the job of being an engineer (or even a code monkey!), it's basic, basic programming. I'd imagine it does a great job of removing the kind of candidates who are capable of trivially avoidable bugs that become time bombs down the road.
  - uola 10y ago
    Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult. Many of Googles products implode shortly after getting released making software quality irrelevant. Also many successful Google products were originally made by other companies, presumably with different hiring processes, that joined Google. That said, from what I've heard it isn't the questions themselves so much as the overall interview process that puts people off.
    - GrumpyYoungMan 10y ago
      >Hiring people based on things they won't use seems an awful lot like a cargo cult. Yes, but in this case, it's a cargo cult of over-qualification. Hardly a bad thing. >Many of Googles products implode shortly after getting released making software quality irrelevant. That is a function of leadership and poor product planning and has nothing to do with the quality of the engineers there.
hesarenu 10y ago
Would the candidates just clear the interview by mugging up on algorithms.
namaemuta 10y ago
In "merging" it is assumed that there won't be any repeated values? that is the first question that came to my mind.
- wutbrodo 10y ago
  That's just an implementation detail whose answer wouldn't really change the difficulty of the question much. When actually interviewing (at any company), I'm always much more precise about the question and usually give representative sample input/output.

cardine 10y ago

We ask a couple difficult algorithms questions in our interviews but I also think that is pretty indicative of the day to day work you might have to be doing at positions we hire for. If someone is offended by being asked to code something like this then they are probably going to be offended by the work they'll have to do once they start employment. Of course there are other parts of our interview as well, but I've found an initial interview with a difficult algorithms problem does a great job filtering out bad programmers. Once we've filtered out the bad programmers we'll do a second interview that involves code from a project we've used in production before.

namaemuta 10y ago
> If someone is offended by being asked to code something like this then they are probably going to be offended by the work they'll have to do once they start employment. I don't agree with you because it's not the same context. In a day to day job context, you can focus on doing it correctly while in an interview there are a lot of factors that can affect your focus/creativity/attention.
- adrianratnapala 10y ago
  In my experience it is the opposite. At a whiteboard inteview, you can focus on the code and the algorithm. In the real process, you might on any given day also have to wrangle with your build system, meetings, the structure of existing code, the test setup, colleauges who need help, debugging tools. Now that might be an argument for why a whiteboard interview is inadequate. But not for why an whiteboard interview is distracting.