13 ms·

Coding Problems from Programming Job Interviews

178 points by javinpaul 8y ago

jenscow 8y ago
Tip: If you feel the need to memorise these algorithms in order to get a job, then perhaps you'll struggle if they hired you.
- jbreiding 8y ago
  Whose failing would that be though? The interview should gauge capability and motivation which should accrue towards fit for the team and role. There should be some expectation of learning in the role and not just hit the ground running.
- drugme 8y ago
  then perhaps you'll struggle if they hired you. Actually, no. Though problems like these do (occasionally) occur IRL, the conditions under which you're expected to solve these problems in interviews ("on the spot, while I stare and grin at you, and occasionally interrupt you - and your result better be near-perfect, or GTFO!") -- have basically no relation to real-life development work.
  - asianthrowaway 8y ago
    Being able to solve complex problems quickly is a sign of high intelligence, which is basically what these coding interviews are meant to detect.
  - jenscow 8y ago
    I agree - doing these under "interview conditions" is a farce. It tests for other attributes which are probably not relevant to the job (and not a good thing if they are).
- corpMaverick 8y ago
  I agree with you. I have interviewed people who clearly memorized some of these solutions. They just write the algorithm straight down almost without thinking. But completely fail with other simpler problems.They will struggle on any real life situation.
  - munk-a 8y ago
    Then stop asking these questions. During an interview you should be determining if a candidate is a good fit for the job they're going to have, talk to them to suss out their fit with the existing team and maybe bring up a few issues you recently hit in your day to day work (or that were recently hit by people doing what this hire will be doing). A beautiful hidden point in this, assuming this task wasn't solved entirely in isolation by one person then discussing what the company did after hearing their thoughts will demonstrate the sort of communication levels the candidate could expect if they accepted the position. By asking rote questions like this you're much more likely to decrease your chances of getting people who are good team builders as the lack of a focus on team cohesion will turn a lot of people off.
    - corpMaverick 8y ago
      I do agree. For this reason I try to come up with my own problems. But these problems are good because they are easy to explain but they stop being useful once people have memorized them.
lqet 8y ago
I personally sat next to my boss in some of our few "classic" job interviews. Questions like the ones mentioned in this article were never brought up, because it would've felt extremely unnatural, even ridiculous. We usually took day-to-day real-world problems that weren't abstract and asked the candidates how they would approach them. Some of the best software engineers I have seen in my life were not trained computer scientists and would've failed many of the questions presented in this article. Not because they weren't highly intelligent, but because terms like "bubble sort" meant nothing to them. E: The company had around 10 employees. "Interview" processes often went like this: 1) Establish first mail contact (either because they are applying for a job, or because the company found out about an interesting tool they wrote, or met them somewhere, or...) 2) Discuss skills of candidate, decide whether the skillset fits the companies needs 3) If so, take a programming job fitting their skillset (usually some low-priority ticket) and give it to them as a freelance job 4) If delivered in good quality, pay them and discuss future job options. If delivered in bad quality, pay them and don't discuss job options. If not delivered, ignore. Which I always thought was a very reasonable approach. Very often, the people weren't even interested in a job, but wanted to continue to work as freelancers.
- munk-a 8y ago
  That's a very sane approach, it's one of the only ways I've seen to get an actual good work sample out of someone that doesn't exploit either party - good on you guys!
- theseatoms 8y ago
  > give it to them as a freelance job I've always wondered why this isn't more common. It's win-win to be able to test the waters in this way. What downsides am I not seeing?
  - normal_man 8y ago
    Difficult to hire people who already have a job and aren't interested in moonlighting.
  - deleted 8y ago
    [deleted]
rubicon33 8y ago
It's an interesting thought to approach these types of coding questions from a different angle - If I wanted to become a better programmer, what would be the best way of doing that? In other words, if I practice this style of problem solving day in and day out, will that make me 10x more efficient at my day job? Honest question... I don't know the answer, although, I doubt it will.
lexda15 8y ago
Sometimes I think that interviews steal business time. They don't show what a person can do exactly. Your qualification shows your test work, trial days. So, you have to show how you are in the job. Because interviews create a stressful environment. These questions in the article show that you can memorize answers and tell them immediately. Very soon AI will check our skills and fit us with the most relevant projects for us. I see it's the future. For example, two startups as https://talent.works https://talent.works and https://periodix.net https://periodix.net . Their AI algorithms check a CV of a candidate and match them with open positions. It really works! First one is for searching for full-time jobs. The second project is for remote and freelance workers. I believe that AI destroys interviews in a wink.
- wuunderbar 8y ago
  How do you account for people inflating or lying about their work on their CV? I think those sites you mentioned only get you to the point of actually having your skills vetted. It's not a solution to the proposed problem of interviewing.
  - mrtdex15 8y ago
    How to check a lying person on an interview?
    - DavidTNcl 8y ago
      They're dead on the first day.
    - scaryclam 8y ago
      Ask them a few questions. It's pretty easy to figure out that that AWS "expert" has just clicked around on the console for a while and doesn't really understand things by simply talking to them about it. Or if someone says they've been programming in python for 10 years, make them talk about the projects they've done, how the code was structured, etc.
  - jenscow 8y ago
crdrost 8y ago
So it's almost HN cliche to complain about these sorts of questions, and that's a fairly earned failure, but I just want to reiterate that these sorts of questions are one or two orders of magnitude more meaningful than the nebulous questions you sometimes see, "estimate how many auto mechanics serve Portland" or "I shrink you to the size of a pea and throw you in a blender, how will you survive?" or the like. At the core, what you should be doing if you want to hire properly, is to take a break approximately 10-15 minutes into the interview. Go get a bottle of water or something. During the next 1-5 minutes, jot down on a piece of paper your initial impressions of the candidate, your suspicions and biases. Some studies show that based on folks viewing the first five minutes of an interview, they can usually predict the outcome. One can interpret that in several ways, but the more cynical is to just say that most interviews are exercises in confirmation bias: you get some suspicion of the candidate, you spend the rest of the interview looking for evidence of your suspicions so you can feel good about your eventual predetermined decision. If you want to do better, it's very simple: do what a scientist does and flip this on its head. Write down your suspicions and then try to disprove them. You think that this person is too egocentric for your company? Then ask them to talk about how they have worked with others, ask what they'd do if a coworker was struggling with a personal issue, try to gather evidence that they can actually be compassionate and empathic. You think that this person cannot program their way out of a bag? Throw them a softball programming question like FizzBuzz. You think that they have encyclopedic knowledge of algorithms? OK, then ask them to implement a Dijkstra's algorithm and if they don't know what that is, a breadth-first traversal. What people are really sick of is that people use these tools as crystal balls into their own psyche: You as an interviewer tend towards "he got QuickSort wrong!" if you subjectively didn't want him in your company, "she got QuickSort almost right, except for some finagling around the pivot!" if you subjectively did want her. What's missing is deliberateness: choose what you want to know deliberately, choose the question deliberately to satisfy some goal: either saying "yeah my hunch was wrong about that, they did pretty well" or else "no, I really tried to give them every opportunity to show me that they can code and even trying to give them the benefit of the doubt I am still unconvinced."
- Mc91 8y ago
  > Some studies show that based on folks viewing the first five minutes of an interview, they can usually predict the outcome. One can interpret that in several ways I have interviewed dozens of people, possibly hundreds of people. I do get an impression within the first three questions. Some people I ask three questions covering different areas, and they knock all three questions out of the park. Some I ask three questions of and they kind of fumble around and give a very limited answer for two of the questions, and can't answer the third at all. In my experience, I can't recall ever seeing a divergence after this. If they fumble through the first three questions, they will fumble through the rest of the interview. If they can answer the first three questions coherently and in-depth, they will be able to answer virtually all of the subsequent questions coherently and in-depth. I'm not really confirming biases because I generally ask everyone the same questions. The only time I mix it up is if they're answering all the easy questions correctly, I start asking slightly more difficult questions which I don't ask much. I don't ask them much because if someone is stumbling over the easier questions, there's no reason to ask them tougher questions. Also, my first technical question is almost always an incredibly easy, standard question. I just ask it so they can answer one quickly and correctly and relax a little. But maybe 20% of people botch even this.
tzs 8y ago
It includes the cycle detection in a linked list problem, and even has an illustration of the classic algorithm of Floyd using the tortoise and hare. It's kind of fun and interesting to look at what is actually required for that algorithm to work. It's almost always presented as having the tortoise and the hare start on the same node, with the tortoise advancing one node per iteration and the hare advancing two nodes per iteration. Let's call this a (1,2) stepping version. That suggests the first question to explore: for what positive integers n, m does an (n, m) stepping always work, when the tortoise and hare start from the same node? A lot of people from what I've seen think that n and m have to be relatively prime, but that is not correct. The surprising answer is that an (n, m) stepping works for any positive n and m as long as n != m. This is surprising, because you might expect that if you were using something like a (2, 4) stepping, and the cycle length was a multiple of 2, you could get the tortoise and hare stuck in non-intersecting loops. E.g., if the cycle length is 8 and we number the nodes in the cycle 0, 1, ..., 7, and the nodes before we reach the cycle are -1, -2, -3, ..., couldn't we end up where the tortoise gets stuck in looping over 0, 2, 4, 6, and the hare gets stuck out of phase with the hare looping over 1, 5? It turns out that there is no way for the hare to enter the loop at 1 without the tortoise also entering the loop at 1, which puts the tortoise on the 1, 3, 5, 7, and it will meet the hare. This is a consequence of the tortoise and hare starting from the same node. That suggests the second question to explore: what is required for an (n, m) stepping to guarantee it works regardless of the starting nodes of the tortoise and hare? The answer there is the difference in speed, m-n, has to be relatively prime to the cycle length. Note that (1, 2) is a stepping that works universally. If the tortoise and hare start at the same node, it works because 1 != 2. If they start on different nodes, it works because 2-1 = 1, and 1 is relatively prime to every possible cycle size. But (1,2) is not the only stepping that works universally. (n, n+1) works for the same reason. That suggests a third question to explore: are there circumstances where it is better to use an (n, n+1) stepping with n > 1 than to use (1, 2)?
- lordnacho 8y ago
  The linked list cycle problem was an open question for many years in the mid 20th century. You may have discovered why: it's not actually as easy as it seems when you know the answer. There's a blog post about this somewhere, how it's not actually a great question to ask.
logfromblammo 8y ago
A company that asks these types of questions has likely never critically examined its own interview process. For every last one of them, my first thought was "why was this data structure chosen, and could this specific problem be solved architecturally rather than algorithmically?" First question: "How would you find the missing number in an array?" Easy answer: If there's only one missing number, XOR every number in the array together and XOR that with your expected result, from XORing every number you expected to have been there. That's the missing number. It even works with nonconsecutive numbers, which your n(n+1)/2 solutions won't get. And for consecutive numbers, to get the XOR of the whole list from 1 to N, switch on N % 4, returning 0: N, 1:1 , 2: N+1, 3: 0 . Hard answer: I can't think of any real-world situation in which the developer couldn't solve this problem better by ensuring it never needs solving at all. Keep track of numbers that were never added, or later removed. What are the missing numbers? Return the list. Fix the problem upstream, and you won't have to recover missing information later.
- anyfoo 8y ago
  > I can't think of any real-world situation in which the developer couldn't solve this problem better by ensuring it never needs solving at all. That's assuming a lot already. The array might have come in externally, with no control over the cadence and format it arrives in, so no way to "keep track" until you are handed the final state.
- postalrat 8y ago
  Your hard answers the question by asking it again or assuming something is wrong with needing a solution.
- jowdones 8y ago
  Fucking Christ, both the OP's answer and logfromblammo's one are all that's wrong with this industry: really zero field experience and requiring the academic, PhD-thesis level clever fucking answer. A seasoned professional would use a fucking map and get the job done. No XOR tricks, no clever arithmetic, no niche BitSet crap. FOR i=1 to 100 occurences_map[x[i]]++. FOR i=1 to 100 if occurences_map[i] == 0, found the fucking number. Of course giving this answer WHICH SOLVES THE FUCKING PROBLEM gets me instantly disqualified for not being cumbersome enough for the liking of the rookies running the industry.
robbrit 8y ago
A take from someone who asks these types of questions in interviews on a regular basis: 1) Don't just memorize this list. The fact that this list is publicly available means that we know not to ask these specific questions. 2) This is a very good way to practice the types of problems that are often asked in interviews, so if you can tackle these then you should be good to go. A lot of people on HN and in real life (I've had people get angry for asking them to write code in an interview) hate these types of interviews. There's a lot of research done on this topic and so far, it's kinda like democracy. A crappy system, except for all the others. For all the complaints about this, I have never seen anybody propose something that satisfies the long list of requirements for interview questions. Here's the list, pasted from an HN comment I made a few years back on a similar discussion: Objective - the process avoids human bias (this guy was in my frat, therefore is awesome). Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview. Risk Averse - Avoids false positives. Relevant - it properly tests the abilities needed for a coding job, and not irrelevant ones (like the ability to write an impressive resume). Scales - this will be used for tens of thousands of interviews. Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding.
- siphor 8y ago
  Leadership ability, communication ability, team-work ability are probably more important factors than algorithmic ability in getting a project done, depending on the team. It seems the big-cos have figured that stuff out enough in order to make the development process as much of a meat-market as possible. However, these interviews would probably not select a maximal team for a startup. The big-cos are also leaving a lot of talent on the table -- which makes it silly when they talk about a "talent-shortage." But, they're also paying enough where people WILL game these interviews in order to get the job... So the best argument I've seen for why these interviews work is that it selects people who work hard at learning this type of problem solving, to get the job... which correlates well with how hard they will work at the job. Having an "objective" process is near impossible... and in fact probably not something one should strive for. Everything we do has humans has intuition behind it, whether good or bad. I think intuition is very important for finding a maximal team, especially a small one. "Inclusivity" is kind of weird here.. most often you'll want someone with domain knowledge to get a project going quickly.. It's definitely less important for big-cos, but you still end up interviewing for a web job, an iOS job, etc.. so domain knoweledge does come into play.. at least at the big companies I've interviewed for (google, fb, lyft, uber, etc..) I doubt this process is risk averse... you'll find people smart enough, but you learn little about their character. Relevancy seems like a joke in your list... unless all you need is people to iterate on a small set of already solved algorithms in slightly different ways. I'd say that applies to zero companies. Except maybe leetcode, which helps people study for these tests. The process scales well, and is easy to do, i think thats its strong suit... it's mostly effective across a ton of people. So in summary, I agree that it seems like the best known process for these big companies. but I doubt it's as risk-averse as you think, and if you truly have a talent shortage, it's an artificial shortage created by your interview process. You might need to take some risks on people if you need to grow faster... That being said, having that big-co process is great for startups! There's a lot of exceptional talent out there that will fail at the big-cos interviews, but will be better than their engineers for your team :) (There's also exceptional talent that will succeed at those interviews too, but would rather work at a startup) It might be a matter of using your intuition to find them... it's definitely a hard game. I think this recent data-driven trend that is spreading across all realms of companies is poisonous in some areas where it does not belong... Human intuition still wins in a lot of areas, if it's good.
ken 8y ago
The given answer to #1 is incorrect. It proposes to find the missing number in a range 1, 2, 3, ..., N by computing the sum of 1+2+3+...+N and then subtracting the sum of the given numbers. It tries to use the old Gauss formula Nx(N+1)/2, but gets the implementation wrong: int expectedSum = totalCount * ((totalCount + 1) / 2); In Java, of course, "/" means "divide by 2 and throw away the remainder", so if you happen to use this for an even number (like 100, as in the original problem), you'll get 5000 rather than 5050. It happens to work for their sample program because they used N=5 with the array [1, 2, 4]. Had they picked N=4 with [1, 2, 4], this program will say that the missing number is 1. I didn't get any further in their list of questions.
king_magic 8y ago
There's literally no question in that list (or questions like those) I would bother asking during an interview to any candidate at any career level. My expectation simply is that a solid candidate would be able to figure out anything on that list given a reasonable amount of time commensurate to their career level. I've been interviewing software engineer/dev candidates for 10+ years, and I would be extremely concerned if these kinds of questions either sunk or swam a candidate on their own. Obviously if someone couldn't figure out any of these, they'd be a bad hire - but I've found simply discussing work/projects people have done before, peeling the onion away layer by layer, to be a far more effective way of determining skill/fit/critical thinking skills.
- thereare5lights 8y ago
  > Obviously if someone couldn't figure out any of these, they'd be a bad hire Patently false.
  - king_magic 8y ago
    No, I think it’s quite true. My deal is: I’m not going to ask you condescending, useless questions like these, but you gotta know your stuff. Not unreasonable, IMO.
    - thereare5lights 8y ago
      You can think it's true all you want. That doesn't make it true. Plenty of people don't know the answers to all those questions and they do great work. Your biases reflect the way you think the world should work, not the way it actually does.
      - king_magic 8y ago
        I think you’re actually arguing my side. All I’m saying is the candidates should be smart and capable enough to figure out those problems, which is more than enough for me. I’m not going to hire someone who can’t solve one of these problems if they absolutely needed to: these are pretty basic computer science problems at the end of the day. I’m looking for problem solving capability, not rote memorization. But at the same time I’m not going to ask them because they are condescending; it’s like asking someone with a math degree interviewing for a teaching job to explain basic algebra in an interview, which would be absurd. And if they really couldn’t do basic algebra, it’d come out through other lines of questioning.
auiya 8y ago
If you were trying to hire Jimi Hendrix to play guitar for you, would you make him audition by playing Mary Had a Little Lamb? Don't dictate what they should play, let them show you what they got.
- aczerepinski 8y ago
  Jimi Hendrix would absolutely crush Mary Had a Little Lamb.
- arwhatever 8y ago
  Stevie Ray Vaughn played a pretty funky Mary Had a Little Lamb. :-)
- jmalicki 8y ago
  This is sort of like how if you want to hire a chef for a Michelin star restaurant, you ask them to make an omelette, not come up with an innovative dish. https://www.reddit.com/r/AskCulinary/comments/2qw1rp/executive_chef_threatened_to_have_me_make_him_an/ https://www.reddit.com/r/AskCulinary/comments/2qw1rp/executi... It's something that virtually everyone knows, and is a test that they have a very solid command of the basics as a foundation to build more complex things on.
pojzon 8y ago
I would immediately put a X mark on a company which asks as stupid interview questions as those... Thats not how you look for developers with passion - people that care about you as a customer and want to solve your problems the best way possible. Thats how you hire coding monkeys which produce sub bar code and dont care about their job..
kelvin0 8y ago
No Fizz Buzz?
cutler 8y ago
As DHH said: "I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles." I tend to agree.
chooseaname 8y ago
What about graph problems? Admittedly, I only did a 10 second scan, but nothing jumped out.
Bokanovsky 8y ago
In my role I've frequently had to interview software developers for the company I work for. We ask similar questions to this as the type of software we write needs an understanding of what's going on at a basic level. We've interviewed developers who are amazing on paper, but can't answer simple questions that are mainly around enumerating a collection of integers. I'd say communication is something we look for. Can you articulate why solution x is better than solution y? What are the compromises? Do you need to ask for more information? So many candidates don't know an interview is an invitation to a conversation. You need to be able to engage with the people who are interviewing you. Ask questions to clarify if required. The key advice I'd give developers is to be humble. I've met and worked with developers who are very talented, but also difficult to work with because of their personalities, we filter for this as a result.
dariusj18 8y ago
Just the first two question's solutions are wrong. Did not bother reading past that. I assume whoever wrote this article either, a) wants to make sure other people fail these types of interviews, or b) is trying to hire people and wants anybody who google this to get these wrong.

178 points by javinpaul 8y ago

Tip: If you feel the need to memorise these algorithms in order to get a job, then perhaps you'll struggle if they hired you.

jbreiding 8y ago
Whose failing would that be though? The interview should gauge capability and motivation which should accrue towards fit for the team and role. There should be some expectation of learning in the role and not just hit the ground running.
drugme 8y ago
then perhaps you'll struggle if they hired you. Actually, no. Though problems like these do (occasionally) occur IRL, the conditions under which you're expected to solve these problems in interviews ("on the spot, while I stare and grin at you, and occasionally interrupt you - and your result better be near-perfect, or GTFO!") -- have basically no relation to real-life development work.
- asianthrowaway 8y ago
  Being able to solve complex problems quickly is a sign of high intelligence, which is basically what these coding interviews are meant to detect.
- jenscow 8y ago
  I agree - doing these under "interview conditions" is a farce. It tests for other attributes which are probably not relevant to the job (and not a good thing if they are).
corpMaverick 8y ago
I agree with you. I have interviewed people who clearly memorized some of these solutions. They just write the algorithm straight down almost without thinking. But completely fail with other simpler problems.They will struggle on any real life situation.
- munk-a 8y ago
  Then stop asking these questions. During an interview you should be determining if a candidate is a good fit for the job they're going to have, talk to them to suss out their fit with the existing team and maybe bring up a few issues you recently hit in your day to day work (or that were recently hit by people doing what this hire will be doing). A beautiful hidden point in this, assuming this task wasn't solved entirely in isolation by one person then discussing what the company did after hearing their thoughts will demonstrate the sort of communication levels the candidate could expect if they accepted the position. By asking rote questions like this you're much more likely to decrease your chances of getting people who are good team builders as the lack of a focus on team cohesion will turn a lot of people off.
  - corpMaverick 8y ago
    I do agree. For this reason I try to come up with my own problems. But these problems are good because they are easy to explain but they stop being useful once people have memorized them.

lqet 8y ago

I personally sat next to my boss in some of our few "classic" job interviews. Questions like the ones mentioned in this article were never brought up, because it would've felt extremely unnatural, even ridiculous. We usually took day-to-day real-world problems that weren't abstract and asked the candidates how they would approach them. Some of the best software engineers I have seen in my life were not trained computer scientists and would've failed many of the questions presented in this article. Not because they weren't highly intelligent, but because terms like "bubble sort" meant nothing to them. E: The company had around 10 employees. "Interview" processes often went like this: 1) Establish first mail contact (either because they are applying for a job, or because the company found out about an interesting tool they wrote, or met them somewhere, or...) 2) Discuss skills of candidate, decide whether the skillset fits the companies needs 3) If so, take a programming job fitting their skillset (usually some low-priority ticket) and give it to them as a freelance job 4) If delivered in good quality, pay them and discuss future job options. If delivered in bad quality, pay them and don't discuss job options. If not delivered, ignore. Which I always thought was a very reasonable approach. Very often, the people weren't even interested in a job, but wanted to continue to work as freelancers.

munk-a 8y ago
That's a very sane approach, it's one of the only ways I've seen to get an actual good work sample out of someone that doesn't exploit either party - good on you guys!
theseatoms 8y ago
> give it to them as a freelance job I've always wondered why this isn't more common. It's win-win to be able to test the waters in this way. What downsides am I not seeing?
- normal_man 8y ago
  Difficult to hire people who already have a job and aren't interested in moonlighting.
- deleted 8y ago
  [deleted]

rubicon33 8y ago

It's an interesting thought to approach these types of coding questions from a different angle - If I wanted to become a better programmer, what would be the best way of doing that? In other words, if I practice this style of problem solving day in and day out, will that make me 10x more efficient at my day job? Honest question... I don't know the answer, although, I doubt it will.

lexda15 8y ago

Sometimes I think that interviews steal business time. They don't show what a person can do exactly. Your qualification shows your test work, trial days. So, you have to show how you are in the job. Because interviews create a stressful environment. These questions in the article show that you can memorize answers and tell them immediately. Very soon AI will check our skills and fit us with the most relevant projects for us. I see it's the future. For example, two startups as https://talent.works https://talent.works and https://periodix.net https://periodix.net . Their AI algorithms check a CV of a candidate and match them with open positions. It really works! First one is for searching for full-time jobs. The second project is for remote and freelance workers. I believe that AI destroys interviews in a wink.

wuunderbar 8y ago
How do you account for people inflating or lying about their work on their CV? I think those sites you mentioned only get you to the point of actually having your skills vetted. It's not a solution to the proposed problem of interviewing.
- mrtdex15 8y ago
  How to check a lying person on an interview?
  - DavidTNcl 8y ago
    They're dead on the first day.
  - scaryclam 8y ago
    Ask them a few questions. It's pretty easy to figure out that that AWS "expert" has just clicked around on the console for a while and doesn't really understand things by simply talking to them about it. Or if someone says they've been programming in python for 10 years, make them talk about the projects they've done, how the code was structured, etc.
- jenscow 8y ago

crdrost 8y ago

So it's almost HN cliche to complain about these sorts of questions, and that's a fairly earned failure, but I just want to reiterate that these sorts of questions are one or two orders of magnitude more meaningful than the nebulous questions you sometimes see, "estimate how many auto mechanics serve Portland" or "I shrink you to the size of a pea and throw you in a blender, how will you survive?" or the like. At the core, what you should be doing if you want to hire properly, is to take a break approximately 10-15 minutes into the interview. Go get a bottle of water or something. During the next 1-5 minutes, jot down on a piece of paper your initial impressions of the candidate, your suspicions and biases. Some studies show that based on folks viewing the first five minutes of an interview, they can usually predict the outcome. One can interpret that in several ways, but the more cynical is to just say that most interviews are exercises in confirmation bias: you get some suspicion of the candidate, you spend the rest of the interview looking for evidence of your suspicions so you can feel good about your eventual predetermined decision. If you want to do better, it's very simple: do what a scientist does and flip this on its head. Write down your suspicions and then try to disprove them. You think that this person is too egocentric for your company? Then ask them to talk about how they have worked with others, ask what they'd do if a coworker was struggling with a personal issue, try to gather evidence that they can actually be compassionate and empathic. You think that this person cannot program their way out of a bag? Throw them a softball programming question like FizzBuzz. You think that they have encyclopedic knowledge of algorithms? OK, then ask them to implement a Dijkstra's algorithm and if they don't know what that is, a breadth-first traversal. What people are really sick of is that people use these tools as crystal balls into their own psyche: You as an interviewer tend towards "he got QuickSort wrong!" if you subjectively didn't want him in your company, "she got QuickSort almost right, except for some finagling around the pivot!" if you subjectively did want her. What's missing is deliberateness: choose what you want to know deliberately, choose the question deliberately to satisfy some goal: either saying "yeah my hunch was wrong about that, they did pretty well" or else "no, I really tried to give them every opportunity to show me that they can code and even trying to give them the benefit of the doubt I am still unconvinced."

Mc91 8y ago
> Some studies show that based on folks viewing the first five minutes of an interview, they can usually predict the outcome. One can interpret that in several ways I have interviewed dozens of people, possibly hundreds of people. I do get an impression within the first three questions. Some people I ask three questions covering different areas, and they knock all three questions out of the park. Some I ask three questions of and they kind of fumble around and give a very limited answer for two of the questions, and can't answer the third at all. In my experience, I can't recall ever seeing a divergence after this. If they fumble through the first three questions, they will fumble through the rest of the interview. If they can answer the first three questions coherently and in-depth, they will be able to answer virtually all of the subsequent questions coherently and in-depth. I'm not really confirming biases because I generally ask everyone the same questions. The only time I mix it up is if they're answering all the easy questions correctly, I start asking slightly more difficult questions which I don't ask much. I don't ask them much because if someone is stumbling over the easier questions, there's no reason to ask them tougher questions. Also, my first technical question is almost always an incredibly easy, standard question. I just ask it so they can answer one quickly and correctly and relax a little. But maybe 20% of people botch even this.

tzs 8y ago

It includes the cycle detection in a linked list problem, and even has an illustration of the classic algorithm of Floyd using the tortoise and hare. It's kind of fun and interesting to look at what is actually required for that algorithm to work. It's almost always presented as having the tortoise and the hare start on the same node, with the tortoise advancing one node per iteration and the hare advancing two nodes per iteration. Let's call this a (1,2) stepping version. That suggests the first question to explore: for what positive integers n, m does an (n, m) stepping always work, when the tortoise and hare start from the same node? A lot of people from what I've seen think that n and m have to be relatively prime, but that is not correct. The surprising answer is that an (n, m) stepping works for any positive n and m as long as n != m. This is surprising, because you might expect that if you were using something like a (2, 4) stepping, and the cycle length was a multiple of 2, you could get the tortoise and hare stuck in non-intersecting loops. E.g., if the cycle length is 8 and we number the nodes in the cycle 0, 1, ..., 7, and the nodes before we reach the cycle are -1, -2, -3, ..., couldn't we end up where the tortoise gets stuck in looping over 0, 2, 4, 6, and the hare gets stuck out of phase with the hare looping over 1, 5? It turns out that there is no way for the hare to enter the loop at 1 without the tortoise also entering the loop at 1, which puts the tortoise on the 1, 3, 5, 7, and it will meet the hare. This is a consequence of the tortoise and hare starting from the same node. That suggests the second question to explore: what is required for an (n, m) stepping to guarantee it works regardless of the starting nodes of the tortoise and hare? The answer there is the difference in speed, m-n, has to be relatively prime to the cycle length. Note that (1, 2) is a stepping that works universally. If the tortoise and hare start at the same node, it works because 1 != 2. If they start on different nodes, it works because 2-1 = 1, and 1 is relatively prime to every possible cycle size. But (1,2) is not the only stepping that works universally. (n, n+1) works for the same reason. That suggests a third question to explore: are there circumstances where it is better to use an (n, n+1) stepping with n > 1 than to use (1, 2)?

lordnacho 8y ago
The linked list cycle problem was an open question for many years in the mid 20th century. You may have discovered why: it's not actually as easy as it seems when you know the answer. There's a blog post about this somewhere, how it's not actually a great question to ask.

logfromblammo 8y ago

A company that asks these types of questions has likely never critically examined its own interview process. For every last one of them, my first thought was "why was this data structure chosen, and could this specific problem be solved architecturally rather than algorithmically?" First question: "How would you find the missing number in an array?" Easy answer: If there's only one missing number, XOR every number in the array together and XOR that with your expected result, from XORing every number you expected to have been there. That's the missing number. It even works with nonconsecutive numbers, which your n(n+1)/2 solutions won't get. And for consecutive numbers, to get the XOR of the whole list from 1 to N, switch on N % 4, returning 0: N, 1:1 , 2: N+1, 3: 0 . Hard answer: I can't think of any real-world situation in which the developer couldn't solve this problem better by ensuring it never needs solving at all. Keep track of numbers that were never added, or later removed. What are the missing numbers? Return the list. Fix the problem upstream, and you won't have to recover missing information later.

anyfoo 8y ago
> I can't think of any real-world situation in which the developer couldn't solve this problem better by ensuring it never needs solving at all. That's assuming a lot already. The array might have come in externally, with no control over the cadence and format it arrives in, so no way to "keep track" until you are handed the final state.
postalrat 8y ago
Your hard answers the question by asking it again or assuming something is wrong with needing a solution.
jowdones 8y ago
Fucking Christ, both the OP's answer and logfromblammo's one are all that's wrong with this industry: really zero field experience and requiring the academic, PhD-thesis level clever fucking answer. A seasoned professional would use a fucking map and get the job done. No XOR tricks, no clever arithmetic, no niche BitSet crap. FOR i=1 to 100 occurences_map[x[i]]++. FOR i=1 to 100 if occurences_map[i] == 0, found the fucking number. Of course giving this answer WHICH SOLVES THE FUCKING PROBLEM gets me instantly disqualified for not being cumbersome enough for the liking of the rookies running the industry.

robbrit 8y ago

A take from someone who asks these types of questions in interviews on a regular basis: 1) Don't just memorize this list. The fact that this list is publicly available means that we know not to ask these specific questions. 2) This is a very good way to practice the types of problems that are often asked in interviews, so if you can tackle these then you should be good to go. A lot of people on HN and in real life (I've had people get angry for asking them to write code in an interview) hate these types of interviews. There's a lot of research done on this topic and so far, it's kinda like democracy. A crappy system, except for all the others. For all the complaints about this, I have never seen anybody propose something that satisfies the long list of requirements for interview questions. Here's the list, pasted from an HN comment I made a few years back on a similar discussion: Objective - the process avoids human bias (this guy was in my frat, therefore is awesome). Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview. Risk Averse - Avoids false positives. Relevant - it properly tests the abilities needed for a coding job, and not irrelevant ones (like the ability to write an impressive resume). Scales - this will be used for tens of thousands of interviews. Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding.

siphor 8y ago
Leadership ability, communication ability, team-work ability are probably more important factors than algorithmic ability in getting a project done, depending on the team. It seems the big-cos have figured that stuff out enough in order to make the development process as much of a meat-market as possible. However, these interviews would probably not select a maximal team for a startup. The big-cos are also leaving a lot of talent on the table -- which makes it silly when they talk about a "talent-shortage." But, they're also paying enough where people WILL game these interviews in order to get the job... So the best argument I've seen for why these interviews work is that it selects people who work hard at learning this type of problem solving, to get the job... which correlates well with how hard they will work at the job. Having an "objective" process is near impossible... and in fact probably not something one should strive for. Everything we do has humans has intuition behind it, whether good or bad. I think intuition is very important for finding a maximal team, especially a small one. "Inclusivity" is kind of weird here.. most often you'll want someone with domain knowledge to get a project going quickly.. It's definitely less important for big-cos, but you still end up interviewing for a web job, an iOS job, etc.. so domain knoweledge does come into play.. at least at the big companies I've interviewed for (google, fb, lyft, uber, etc..) I doubt this process is risk averse... you'll find people smart enough, but you learn little about their character. Relevancy seems like a joke in your list... unless all you need is people to iterate on a small set of already solved algorithms in slightly different ways. I'd say that applies to zero companies. Except maybe leetcode, which helps people study for these tests. The process scales well, and is easy to do, i think thats its strong suit... it's mostly effective across a ton of people. So in summary, I agree that it seems like the best known process for these big companies. but I doubt it's as risk-averse as you think, and if you truly have a talent shortage, it's an artificial shortage created by your interview process. You might need to take some risks on people if you need to grow faster... That being said, having that big-co process is great for startups! There's a lot of exceptional talent out there that will fail at the big-cos interviews, but will be better than their engineers for your team :) (There's also exceptional talent that will succeed at those interviews too, but would rather work at a startup) It might be a matter of using your intuition to find them... it's definitely a hard game. I think this recent data-driven trend that is spreading across all realms of companies is poisonous in some areas where it does not belong... Human intuition still wins in a lot of areas, if it's good.

ken 8y ago

The given answer to #1 is incorrect. It proposes to find the missing number in a range 1, 2, 3, ..., N by computing the sum of 1+2+3+...+N and then subtracting the sum of the given numbers. It tries to use the old Gauss formula Nx(N+1)/2, but gets the implementation wrong: int expectedSum = totalCount * ((totalCount + 1) / 2); In Java, of course, "/" means "divide by 2 and throw away the remainder", so if you happen to use this for an even number (like 100, as in the original problem), you'll get 5000 rather than 5050. It happens to work for their sample program because they used N=5 with the array [1, 2, 4]. Had they picked N=4 with [1, 2, 4], this program will say that the missing number is 1. I didn't get any further in their list of questions.

king_magic 8y ago

There's literally no question in that list (or questions like those) I would bother asking during an interview to any candidate at any career level. My expectation simply is that a solid candidate would be able to figure out anything on that list given a reasonable amount of time commensurate to their career level. I've been interviewing software engineer/dev candidates for 10+ years, and I would be extremely concerned if these kinds of questions either sunk or swam a candidate on their own. Obviously if someone couldn't figure out any of these, they'd be a bad hire - but I've found simply discussing work/projects people have done before, peeling the onion away layer by layer, to be a far more effective way of determining skill/fit/critical thinking skills.

thereare5lights 8y ago
> Obviously if someone couldn't figure out any of these, they'd be a bad hire Patently false.
- king_magic 8y ago
  No, I think it’s quite true. My deal is: I’m not going to ask you condescending, useless questions like these, but you gotta know your stuff. Not unreasonable, IMO.
  - thereare5lights 8y ago
    You can think it's true all you want. That doesn't make it true. Plenty of people don't know the answers to all those questions and they do great work. Your biases reflect the way you think the world should work, not the way it actually does.
    - king_magic 8y ago
      I think you’re actually arguing my side. All I’m saying is the candidates should be smart and capable enough to figure out those problems, which is more than enough for me. I’m not going to hire someone who can’t solve one of these problems if they absolutely needed to: these are pretty basic computer science problems at the end of the day. I’m looking for problem solving capability, not rote memorization. But at the same time I’m not going to ask them because they are condescending; it’s like asking someone with a math degree interviewing for a teaching job to explain basic algebra in an interview, which would be absurd. And if they really couldn’t do basic algebra, it’d come out through other lines of questioning.

auiya 8y ago

If you were trying to hire Jimi Hendrix to play guitar for you, would you make him audition by playing Mary Had a Little Lamb? Don't dictate what they should play, let them show you what they got.

aczerepinski 8y ago
Jimi Hendrix would absolutely crush Mary Had a Little Lamb.
arwhatever 8y ago
Stevie Ray Vaughn played a pretty funky Mary Had a Little Lamb. :-)
jmalicki 8y ago
This is sort of like how if you want to hire a chef for a Michelin star restaurant, you ask them to make an omelette, not come up with an innovative dish. https://www.reddit.com/r/AskCulinary/comments/2qw1rp/executive_chef_threatened_to_have_me_make_him_an/ https://www.reddit.com/r/AskCulinary/comments/2qw1rp/executi... It's something that virtually everyone knows, and is a test that they have a very solid command of the basics as a foundation to build more complex things on.

pojzon 8y ago

I would immediately put a X mark on a company which asks as stupid interview questions as those... Thats not how you look for developers with passion - people that care about you as a customer and want to solve your problems the best way possible. Thats how you hire coding monkeys which produce sub bar code and dont care about their job..

kelvin0 8y ago

No Fizz Buzz?

cutler 8y ago

As DHH said: "I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles." I tend to agree.

chooseaname 8y ago

What about graph problems? Admittedly, I only did a 10 second scan, but nothing jumped out.

Bokanovsky 8y ago

In my role I've frequently had to interview software developers for the company I work for. We ask similar questions to this as the type of software we write needs an understanding of what's going on at a basic level. We've interviewed developers who are amazing on paper, but can't answer simple questions that are mainly around enumerating a collection of integers. I'd say communication is something we look for. Can you articulate why solution x is better than solution y? What are the compromises? Do you need to ask for more information? So many candidates don't know an interview is an invitation to a conversation. You need to be able to engage with the people who are interviewing you. Ask questions to clarify if required. The key advice I'd give developers is to be humble. I've met and worked with developers who are very talented, but also difficult to work with because of their personalities, we filter for this as a result.

dariusj18 8y ago

Just the first two question's solutions are wrong. Did not bother reading past that. I assume whoever wrote this article either, a) wants to make sure other people fail these types of interviews, or b) is trying to hire people and wants anybody who google this to get these wrong.