10 ms·

I once got knocked out of the running by a whiteboard-coding interview question that went something like "How would you find all triples from a list of a millio

I once got knocked out of the running by a whiteboard-coding interview question that went something like "How would you find all triples from a list of a million integers, where the first two numbers add up to the third?" I said, "Hmmm that sounds like an O(N^3) problem." Interviewer: "Can you think of any way to do it in smaller big-O?" Me: "Not off the top of my head, no." For some reason that company insisted on only doing interviews at 7:00 AM, and my brain doesn't come fully online until after 9:00 anyway. I felt annoyed later when the answer came to me that afternoon, too late: put the list in a hashtable, add all pairs of numbers for O(N^2) complexity, and check if each answer occurs in the hashtable. Much later after that, I realized that all the other red flags I'd picked up on while interviewing there added up to an impression that their corporate culture was seriously f'ed up, and that I probably dodged a bullet by getting passed over quickly in the process.

jldugger 8y ago
Three sum is what google uses for their video 'how to do a google code interview': https://www.youtube.com/watch?v=XKu_SEDAykw https://www.youtube.com/watch?v=XKu_SEDAykw
vthallam 8y ago
Or you could do top 100 questions on leetcode or hackerrank and you would have solved the question in a minute. It's kinda sad that you could remember the top 100 solutions and clear interviews in almost all big tech companies.
- autokad 8y ago
  its kinda sad you think professionals should memorize useless tricks that dont generalize to the profession in order to be considered for a job. The skill takes a long time to practice, and quickly evaporates once you stop doing it. Yet none of our work is anything like that. a more real world situation is reading documentation or SO for the function concat_ws that will turn an array column to a concatenated string. however, the system that is, and one that you seem to think is ok, is one that discriminates people on many levels. Its a skill you do not get good at by working, so you must practice this in your free time. Now you just discriminated against men and women with families, people from less fortunate backgrounds, and others who otherwise do not have the time in the day to dedicate to a skill that is only useful to coding interviews. as far as a comment above, I was a DBA for 10 years and can do pretty complicated queries off the top of my head, know how to optimize my indexes, worked with both structured and unstructured data in the multi tb size, ect ect, but I have no recollection on what ACID stands for. I dont really care. Sure, you may hire someone who memorizes useless crap, but then they have no idea why the IO has gone through the roof when inserting IDs out of order on a clustered index.
  - achileas 8y ago
    I don't read anything about OP's post as saying they think people should memorize or that this practice is okay, as evidenced by their final sentence that it's sad that you could do so and pass many technical interviews.
  - AndyNemmity 8y ago
    Exactly, I as well have been doing technical work for my whole life, and sitting here right now, I could more easily explain to you how to optimize the planner cache, and what hints are required to get a given result than I could explain to you which joins do what. I just look up joins when I need them, and it's straight forward, but ask me in an interview and I sound like an idiot.
  - bigtunacan 8y ago
    I didn't take the parent's post the same way. The situation is more that if you do leetcode or hackerrank then you pass the interview. So once again the interview process has failed; instead of identifying good candidates you identify candidates that do hackerrank in their free time.
    - autokad 8y ago
      thanks for the clarification, i read it as "its sad they cant do it, whats wrong with them?" kinda way, but what you said is probably what he/she meant
- yodsanklai 8y ago
  I recently interviewed at a big tech company (phone interview). I spent quite some time practicing on leetcode (completed at least 150 problems). During the interview, it took me a few minutes of thinking before completing the assignments with what I think was the expected solution. We discussed the complexity and a few possible variations. The interview sounded satisfied and I really had the feeling that I had nailed these assignments. I wasn't rejected but I've been asked to retake a phone interview. Apparently, the interviewer had very good feelings about me, but found that I was "out of practice" as far as coding goes. I wonder if my age is an issue (40+) or if they have a really high level of expectation. Are most other candidates super fast at solving these kinds of problems. I'm a bit disappointed because I'm not sure that I've got much room for improvement at that stage.
  - deleted 8y ago
    [deleted]
  - rhizome 8y ago
    found that I was "out of practice" as far as coding goes. They want 23 year olds who just did their finals. You know, real stallions.
    - bradknowles 8y ago
      And who don’t care that they’re going to get paid less than minimum wage, and work over 120 hours per week. You know, real pegacorns.
  - d1zzy 8y ago
    As someone that does lots of coding phone interviews I can say that yes, time is a factor. But it's relative, ie I'm comparing you to the time it took other candidates to solve the same problem. After all, we have to evaluate you, over the phone, in the course of less than an hour. If 2 candidates arrive to the optimal solution, the one that did it much faster is the better candidate. It sounds to me like you did pretty well so don't give up.
    - 8y ago
- deleted 8y ago
  [deleted]
- d1zzy 8y ago
  I would say that if you know the answers to 100 top coding questions (and understand them, a good interviewer will poke you to determine that) then you are a pretty good coder and you should be hired. Seems working as intended :) For many tech companies where they get a lot more candidate applications than they have positions for, the goal of the interview process isn't to avoid losing good candidates, it's to not hire bad candidates.
  - jaggederest 8y ago
    That's like saying that if you can retype The Great Gatsby, then you're a great writer. So much more goes into software engineering than "Can solve tiny example problems in an examination system"
    - d1zzy 8y ago
      Like I said, a good interviewer ensures you understand the solutions of those problems (the problem might even be formulated in a different form than the exact form you learned) not just typing out text verbatim. If you do understand the solutions of top 100 coding questions, I think you have a good start. Part of solving the problem in an interview will also be being able to code, so it's also testing your coding ability in a given programming language. True that software engineering is more than that, but those other things largely depend on in-house company processes, tools and policies so you would learn them afterwards.
- Clubber 8y ago
  Yes, because nothing says top notch developer more than "I can memorize stuff and regurgitate it."
lawn 8y ago
Interviewer: "Can you think of any way to do it in smaller big-O?" Me: "I would first google it" It annoys me that the good answer if you actually encounter the problem during the job is never accepted during an interview.
- sanderjd 8y ago
  I'm as critical of how we interview in this industry as anybody, but I've never found this particular criticism compelling or charitable. It's implicit that you know the correct first answer is to seek prior art. Making that explicit is fine but a bit pedantic. The follow-up question is: "ok great, now say that you can't find any satisfying prior art for this on Google, how would you reason through your own solution?". They aren't looking for people who don't know to start by doing some research, they're looking for people who won't be completely stuck when that research doesn't turn up the answer.
  - gmarx 8y ago
    Maybe but I once had an interview in which I was asked how to find how similar two text strings were (for search). I answered that I would use one of the algorithms from Apache commons text or within Lucerne which implement one or several of the appropriate distance algorithms. He told me he had written his own. I asked why he would do that when these algorithms were written by people who did intense research and the implementations in these libraries have been tested by more eyes than his could ever be. He said “what if I want it to run in Ruby?”...I was interviewing but this is a guy I would not hire. He was wasting time for his own amusement. Never assume people know to do the research on existing solutions. Many developers would rather work on their own toy solutions while avoiding the actual unsolved problems in their domain
    - sanderjd 8y ago
      Sure, your mileage may vary and there are definitely bad apples, but my claim is that the vast majority of interviewers aren't looking for people who like reinventing wheels, but are rather trying to suss out the extent to which you can reason through a problem. So I think that's the charitable assumption to make.
codingdave 8y ago
>"Not off the top of my head, no." They were probably looking for the answer of, "Lets talk through it and figure out a better answer". Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc. So from their perspective, they asked you to try harder on a problem, and you just said, "No." And they dropped you for it. FWIW, I had similar questions in some interviews where we hashed through similar problems, and together collaborated down to a "No" answer... but we spent 15 minutes exploring the problem and seeing how well a couple coders can work through it before saying no. And I got the offer despite an otherwise rusty performance.
- JackFr 8y ago
  > They care about how you approach it, how you think through it, what you do when challenged, etc. I was asked to sketch the proof for the irrationality of sqrt(2) in a quant programming interview. I kind of froze, and explained that though I had learned it, I could not recall. He prompted me with "Well, what does it mean to be irrational?", and with that little hint I did the rest. Though ultimately I did not end up working there, it was very satisfying to have answered it.
  - williamdclt 8y ago
    A friend of mine didn't understand how he could have done better than me in a "write a quick sort" interview (we were still students) when I knew the algo and he never heard of it (and obviously struggled more). Well, in one case (me), all the information the interviewer had was "this guy happens to know how to implement a quick sort by heart. K.". In the other case (my friend), he got "this guy is able to understand and implement an algo he never saw before in a reasonable time", which is much more impressive
  - rajacombinator 8y ago
    Errr in the set of numbers that complete the rationals wrt to standard metric? I guess you have to show it’s not rational so you probably did a proof of upper/lower converging bounds always having nonzero difference for 1/n increments or something? I would definitely not get this in a pressure interview situation.
monksy 8y ago
That actually sounds like a very reasonable senario to not do so well in. The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well) The answer to that item would be: (with scala) > datasource.window(3,1).filter((a,b,c)=> a+b == c) I mean if you knock it out of the park and know the internals of window.. then asking the bar raiser question is appropriate as a curiousity. There are other problems as well: Those are the ones where they have an expected answer, response, and reiterate. I've seen that with tree problems. That's where they would low-key ask for the recursive version and then get you to say stackoverflow exception.
- enedil 8y ago
  So is it actually O(n^2)? Because that is a solution that can be implemented.
  - monksy 8y ago
    That all depends on the sliding function and if it stores in a buffer. (If it does this is o n)
- jcadam 8y ago
  My personal opinion on what a senior dev interview should be is: open with a fizzbuzz-level 'bozo filter' coding question, then step away from the whiteboard and spend the rest of the interview speaking to each other like normal, functional adults.
  - monksy 8y ago
    I actually implemented fizzbuzz in Scala recently.. It's a lot easier to do it in a language that has good pattern matching. Doing that in c++/Java is pretty annoying
jcadam 8y ago
Had the same thing happen to me. Simple problem: find out if two strings are anagrams of each other. My immediate solution: Sort the two strings and then compare them: (defn anagrams? [x y] (= (sort x) (sort y))) or some such. I was fortunate in that they didn't make me implement the sort (because it's been a long time for me) :) "Ok, what's the efficiency of that solution?" "Well, assuming the library sort functions I'm using are sane, I'll take a guess and say O(n log n)" "Can you come up with a more efficient solution." Off the top of my head, on the spot, I couldn't. Later, during the plane ride home, the obvious occurred to me: Don't sort the strings, just scan through each string once and build a hash table, keeping track of the number of occurrences of each letter in each string. Then compare the occurrences for each string. Not as elegant to express in code, but faster. As it turns out, they later declined to hire me, giving me an excuse that made it clear they weren't really serious about hiring anyone for the position (as is the case at least half the time, it seems). And thus ended my latest round of failed interviews. I cancelled the last one I had scheduled (probably another fake) and decided to take a break for a while (I mean, I do have a job right now, so it isn't urgent).
- mindhash 8y ago
  on a tangent, one way could be assign a number code to each alphabet. Add the numbers that occur in the strings. IF the sum matches, they are anagrams.
  - aquateen 8y ago
    I don't see how the sum would be unique to a particular combination of letters.
    - LyndsySimon 8y ago
      “ad” = “bc” You’re right.
    - jcadam 8y ago
      I briefly mused about just summing the ASCII codes for each letter in the strings. But quickly discarded the idea for this reason :)
ljw1001 8y ago
>For some reason that company insisted on only doing interviews at 7:00 AM, and my brain doesn't come fully online until after 9:00 anyway. Reminds me of my final round at Amazon, which they always do in Seattle. I woke before 4 AM west coast time having flown out the night before from the East, and 12 hours later was still coding on a white board. After writing (to my surprise) a correct merge sort, they asked my to write a program to do basic math with, IIRC, binary numbers. I was like, um. I'm out.

jldugger 8y ago

Three sum is what google uses for their video 'how to do a google code interview': https://www.youtube.com/watch?v=XKu_SEDAykw https://www.youtube.com/watch?v=XKu_SEDAykw

vthallam 8y ago

Or you could do top 100 questions on leetcode or hackerrank and you would have solved the question in a minute. It's kinda sad that you could remember the top 100 solutions and clear interviews in almost all big tech companies.

autokad 8y ago
its kinda sad you think professionals should memorize useless tricks that dont generalize to the profession in order to be considered for a job. The skill takes a long time to practice, and quickly evaporates once you stop doing it. Yet none of our work is anything like that. a more real world situation is reading documentation or SO for the function concat_ws that will turn an array column to a concatenated string. however, the system that is, and one that you seem to think is ok, is one that discriminates people on many levels. Its a skill you do not get good at by working, so you must practice this in your free time. Now you just discriminated against men and women with families, people from less fortunate backgrounds, and others who otherwise do not have the time in the day to dedicate to a skill that is only useful to coding interviews. as far as a comment above, I was a DBA for 10 years and can do pretty complicated queries off the top of my head, know how to optimize my indexes, worked with both structured and unstructured data in the multi tb size, ect ect, but I have no recollection on what ACID stands for. I dont really care. Sure, you may hire someone who memorizes useless crap, but then they have no idea why the IO has gone through the roof when inserting IDs out of order on a clustered index.
- achileas 8y ago
  I don't read anything about OP's post as saying they think people should memorize or that this practice is okay, as evidenced by their final sentence that it's sad that you could do so and pass many technical interviews.
- AndyNemmity 8y ago
  Exactly, I as well have been doing technical work for my whole life, and sitting here right now, I could more easily explain to you how to optimize the planner cache, and what hints are required to get a given result than I could explain to you which joins do what. I just look up joins when I need them, and it's straight forward, but ask me in an interview and I sound like an idiot.
- bigtunacan 8y ago
  I didn't take the parent's post the same way. The situation is more that if you do leetcode or hackerrank then you pass the interview. So once again the interview process has failed; instead of identifying good candidates you identify candidates that do hackerrank in their free time.
  - autokad 8y ago
    thanks for the clarification, i read it as "its sad they cant do it, whats wrong with them?" kinda way, but what you said is probably what he/she meant
yodsanklai 8y ago
I recently interviewed at a big tech company (phone interview). I spent quite some time practicing on leetcode (completed at least 150 problems). During the interview, it took me a few minutes of thinking before completing the assignments with what I think was the expected solution. We discussed the complexity and a few possible variations. The interview sounded satisfied and I really had the feeling that I had nailed these assignments. I wasn't rejected but I've been asked to retake a phone interview. Apparently, the interviewer had very good feelings about me, but found that I was "out of practice" as far as coding goes. I wonder if my age is an issue (40+) or if they have a really high level of expectation. Are most other candidates super fast at solving these kinds of problems. I'm a bit disappointed because I'm not sure that I've got much room for improvement at that stage.
- deleted 8y ago
  [deleted]
- rhizome 8y ago
  found that I was "out of practice" as far as coding goes. They want 23 year olds who just did their finals. You know, real stallions.
  - bradknowles 8y ago
    And who don’t care that they’re going to get paid less than minimum wage, and work over 120 hours per week. You know, real pegacorns.
- d1zzy 8y ago
  As someone that does lots of coding phone interviews I can say that yes, time is a factor. But it's relative, ie I'm comparing you to the time it took other candidates to solve the same problem. After all, we have to evaluate you, over the phone, in the course of less than an hour. If 2 candidates arrive to the optimal solution, the one that did it much faster is the better candidate. It sounds to me like you did pretty well so don't give up.
  - 8y ago
deleted 8y ago
[deleted]
d1zzy 8y ago
I would say that if you know the answers to 100 top coding questions (and understand them, a good interviewer will poke you to determine that) then you are a pretty good coder and you should be hired. Seems working as intended :) For many tech companies where they get a lot more candidate applications than they have positions for, the goal of the interview process isn't to avoid losing good candidates, it's to not hire bad candidates.
- jaggederest 8y ago
  That's like saying that if you can retype The Great Gatsby, then you're a great writer. So much more goes into software engineering than "Can solve tiny example problems in an examination system"
  - d1zzy 8y ago
    Like I said, a good interviewer ensures you understand the solutions of those problems (the problem might even be formulated in a different form than the exact form you learned) not just typing out text verbatim. If you do understand the solutions of top 100 coding questions, I think you have a good start. Part of solving the problem in an interview will also be being able to code, so it's also testing your coding ability in a given programming language. True that software engineering is more than that, but those other things largely depend on in-house company processes, tools and policies so you would learn them afterwards.
Clubber 8y ago
Yes, because nothing says top notch developer more than "I can memorize stuff and regurgitate it."

lawn 8y ago

Interviewer: "Can you think of any way to do it in smaller big-O?" Me: "I would first google it" It annoys me that the good answer if you actually encounter the problem during the job is never accepted during an interview.

sanderjd 8y ago
I'm as critical of how we interview in this industry as anybody, but I've never found this particular criticism compelling or charitable. It's implicit that you know the correct first answer is to seek prior art. Making that explicit is fine but a bit pedantic. The follow-up question is: "ok great, now say that you can't find any satisfying prior art for this on Google, how would you reason through your own solution?". They aren't looking for people who don't know to start by doing some research, they're looking for people who won't be completely stuck when that research doesn't turn up the answer.
- gmarx 8y ago
  Maybe but I once had an interview in which I was asked how to find how similar two text strings were (for search). I answered that I would use one of the algorithms from Apache commons text or within Lucerne which implement one or several of the appropriate distance algorithms. He told me he had written his own. I asked why he would do that when these algorithms were written by people who did intense research and the implementations in these libraries have been tested by more eyes than his could ever be. He said “what if I want it to run in Ruby?”...I was interviewing but this is a guy I would not hire. He was wasting time for his own amusement. Never assume people know to do the research on existing solutions. Many developers would rather work on their own toy solutions while avoiding the actual unsolved problems in their domain
  - sanderjd 8y ago
    Sure, your mileage may vary and there are definitely bad apples, but my claim is that the vast majority of interviewers aren't looking for people who like reinventing wheels, but are rather trying to suss out the extent to which you can reason through a problem. So I think that's the charitable assumption to make.

codingdave 8y ago

>"Not off the top of my head, no." They were probably looking for the answer of, "Lets talk through it and figure out a better answer". Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc. So from their perspective, they asked you to try harder on a problem, and you just said, "No." And they dropped you for it. FWIW, I had similar questions in some interviews where we hashed through similar problems, and together collaborated down to a "No" answer... but we spent 15 minutes exploring the problem and seeing how well a couple coders can work through it before saying no. And I got the offer despite an otherwise rusty performance.

JackFr 8y ago
> They care about how you approach it, how you think through it, what you do when challenged, etc. I was asked to sketch the proof for the irrationality of sqrt(2) in a quant programming interview. I kind of froze, and explained that though I had learned it, I could not recall. He prompted me with "Well, what does it mean to be irrational?", and with that little hint I did the rest. Though ultimately I did not end up working there, it was very satisfying to have answered it.
- williamdclt 8y ago
  A friend of mine didn't understand how he could have done better than me in a "write a quick sort" interview (we were still students) when I knew the algo and he never heard of it (and obviously struggled more). Well, in one case (me), all the information the interviewer had was "this guy happens to know how to implement a quick sort by heart. K.". In the other case (my friend), he got "this guy is able to understand and implement an algo he never saw before in a reasonable time", which is much more impressive
- rajacombinator 8y ago
  Errr in the set of numbers that complete the rationals wrt to standard metric? I guess you have to show it’s not rational so you probably did a proof of upper/lower converging bounds always having nonzero difference for 1/n increments or something? I would definitely not get this in a pressure interview situation.

monksy 8y ago

That actually sounds like a very reasonable senario to not do so well in. The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well) The answer to that item would be: (with scala) > datasource.window(3,1).filter((a,b,c)=> a+b == c) I mean if you knock it out of the park and know the internals of window.. then asking the bar raiser question is appropriate as a curiousity. There are other problems as well: Those are the ones where they have an expected answer, response, and reiterate. I've seen that with tree problems. That's where they would low-key ask for the recursive version and then get you to say stackoverflow exception.

enedil 8y ago
So is it actually O(n^2)? Because that is a solution that can be implemented.
- monksy 8y ago
  That all depends on the sliding function and if it stores in a buffer. (If it does this is o n)
jcadam 8y ago
My personal opinion on what a senior dev interview should be is: open with a fizzbuzz-level 'bozo filter' coding question, then step away from the whiteboard and spend the rest of the interview speaking to each other like normal, functional adults.
- monksy 8y ago
  I actually implemented fizzbuzz in Scala recently.. It's a lot easier to do it in a language that has good pattern matching. Doing that in c++/Java is pretty annoying

jcadam 8y ago

Had the same thing happen to me. Simple problem: find out if two strings are anagrams of each other. My immediate solution: Sort the two strings and then compare them: (defn anagrams? [x y] (= (sort x) (sort y))) or some such. I was fortunate in that they didn't make me implement the sort (because it's been a long time for me) :) "Ok, what's the efficiency of that solution?" "Well, assuming the library sort functions I'm using are sane, I'll take a guess and say O(n log n)" "Can you come up with a more efficient solution." Off the top of my head, on the spot, I couldn't. Later, during the plane ride home, the obvious occurred to me: Don't sort the strings, just scan through each string once and build a hash table, keeping track of the number of occurrences of each letter in each string. Then compare the occurrences for each string. Not as elegant to express in code, but faster. As it turns out, they later declined to hire me, giving me an excuse that made it clear they weren't really serious about hiring anyone for the position (as is the case at least half the time, it seems). And thus ended my latest round of failed interviews. I cancelled the last one I had scheduled (probably another fake) and decided to take a break for a while (I mean, I do have a job right now, so it isn't urgent).

mindhash 8y ago
on a tangent, one way could be assign a number code to each alphabet. Add the numbers that occur in the strings. IF the sum matches, they are anagrams.
- aquateen 8y ago
  I don't see how the sum would be unique to a particular combination of letters.
  - LyndsySimon 8y ago
    “ad” = “bc” You’re right.
  - jcadam 8y ago
    I briefly mused about just summing the ASCII codes for each letter in the strings. But quickly discarded the idea for this reason :)

ljw1001 8y ago

>For some reason that company insisted on only doing interviews at 7:00 AM, and my brain doesn't come fully online until after 9:00 anyway. Reminds me of my final round at Amazon, which they always do in Seattle. I woke before 4 AM west coast time having flown out the night before from the East, and 12 hours later was still coding on a white board. After writing (to my surprise) a correct merge sort, they asked my to write a program to do basic math with, IIRC, binary numbers. I was like, um. I'm out.