
Coding Problems from Programming Job Interviews - javinpaul
http://www.java67.com/2018/05/top-75-programming-interview-questions-answers.html
======
lqet
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.

~~~
theseatoms
> 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?

~~~
indigo945
In addition to what the other commenters wrote, take-home assignments are also
negative for diversity as they pre-select against candidates with less free
time, which likely includes single parents and people from low-income
backgrounds.

~~~
conanbatt
Gotta be honest about this. You are applying to a job of 40 hours a week and 6
figure salaries, and you cant make time for 10 hours of work?

~~~
celestialjeu
You might currently be working a job that is 50 hours a week -- or 60! Also
with the example of a single parent they often can't make room for yet another
10 hours of a work in a week because they need to spend time with their
children/take them to activities/cook dinner etc. Manageable when you are
working 40 hours a week but it quickly becomes unreasonable. To me a job that
wants me to work for them before I have an actual job offer is a red flag. I
don't even work for them yet and they don't respect my time. What's it going
to be like when I do work for them?

~~~
conanbatt
Sorry, this triggers no empathy to me. This is alledgedly a workforce that
requires years of study ,training and practice.

Being unable to work 10 hours to prove it shows you are a pauper, all the
other excuses are complacency.

~~~
ball_of_lint
Quitting your job or dropping some other responsibilities might he reasonable
for some people who can live off of their parents money or their own savings,
but for many people that means losing their home, their car, or even their
children. Indigo945 isn't making excuses for them or himself; he's telling you
that for them to make that 10 hours would cost them far more than the new job
might give.

Also, if anyone should be able to make another 10 hours in their week to work
in tech why not say Steve who works at $BigTechCo? Now I know we just asked
Steve for another 10 hours, but lets go ask him for another 10. No, the
circumstances shouldn't matter, he's making 6 figures after all. Let's ask him
again. And again, And again. Oh, Steve quit? What a pauper.

~~~
firstplacelast
The same can be said for requiring candidates to have a github or using a
college degree as a filter. Not everyone has the luxury to take out 10's of
thousand in debt and spend 4+ years of their life learning instead of earning.

So unless you advocate for completely blind interviews that do not rely on a
resume and only take up 3 hours of someone's day, your point is moot.

~~~
ball_of_lint
It's a part of hiring someone to have them send in a resume and verify that
they have the skills needed to do the job. I contest that it is not fair to
disqualify candidates because they cannot meet arbitrary and unreasonable
demands for their time. A phone interview is almost always reasonable. A 10
hour work sample due this week would often be unreasonable. It depends a lot
on context and conanbatt discarded that.

------
robbrit
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
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.

~~~
robbrit
You're right, a lot of these metrics aren't as useful for startups and small
companies as they are for bigcos.

> Having an "objective" process is near impossible

You're completely right here, however there are plenty of biases that can be
avoided by attempting some level of objectivity.

> I doubt this process is risk averse

The risk-aversion is about avoiding hiring people that can't write code.
You're right that it doesn't filter for character, which you will discover
very quickly when working at larger companies! However a lot of the processes
such as code review and design reviews help mitigate some of the bad character
quirks that impact software. These processes are often not present at smaller
companies, so the impact of character flaws is much larger there.

> Relevancy seems like a joke in your list

I'd say it's one of the most important ones on the list, especially for
startups. When I was hiring for startups, I would get loads of people who
could talk the talk but couldn't write a line of code. "Relevancy" means that
your interview confirms that the candidate can actually code rather than just
talk about it.

~~~
siphor
Interesting on the relevancy stand point. As an iOS developer, I had to learn
a whole new set of skills for the interviews... I can count on one hand the
number of times I needed to use techniques needed for the algorithm questions.
I feel like the skills around making large scale apps is more about being able
to reason about large scale projects and keeping everything clean and tidy.

I haven’t really met anyone yet who could talk the talk but couldn’t write
code... I’ve definitely met people who have tried... maybe I have a good BS
detector, or maybe I’ve been lucky? All people I’ve hired without doing the
BST/linked list/DP problems, Ended up working out great. They probably can’t
do those problems still, but they can code a damn good app. Guess it goes back
to not caring about false negatives

------
ken
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.

------
tzs
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
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.

------
rubicon33
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.

------
logfromblammo
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.

~~~
jowdones
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.

~~~
logfromblammo
I thought about including the answer that doesn't require branching, but
didn't, because it sounded too fucking clever even just proofreading it. The
N(N+1)/2 and summation is the answer they _probably expect_. Gimmicky XOR
tricks set you slightly ahead of the pack. Magical bit-twiddling answers and
branch elimination make you look pretentious, unless you're literally Carmack.

My point was that solving the problem as posed does not solve the problem
inherent in posing the problem. Finding the one missing number in an array of
otherwise consecutive numbers means that you were already storing N-1 numbers
instead of the one number you wanted. If you stored the missing number
instead, it's trivial to construct an array from 1 to N that skips over it.
Save space, save time.

And if the profiler says that this problem is on a critical path in an inner
loop, optimizing the heck out of it still won't help as much as unmaking the
problem entirely, pulling all the cumbersome calculations out into less-used
code. If the profiler says that it barely ever gets hit, then there should be
zero algorithmic tricks, and the code should be optimized for human
readability instead.

As an interview question, it might as well be a cryptic crossword clue,
because the solutions that would be put in place by perfectly good developers
are not the ones in the back of the textbook.

------
crdrost
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
> 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.

~~~
crdrost
Now that's very interesting. I think you're right that within those first
questions you do get some sort of perception about technical capacity in some
raw form. Maybe it's even worth not trying to disprove that hypothesis by
asking a separate question.

But what I'm confused about, that I'd like to hear your opinion on, is why if
you have this confidence that your first three questions contain 90% of the
signal, that you spend the rest of the interview doing anything vaguely
related to that? Like it sounds to me that you just told me, "I get a 90%
accurate measurement in the first, say, 30% of the interview, and then I waste
my time for the remaining 70% trying to up it from 90 to 98%," and that just
doesn't seem like a great use of your time after that point. Can you help me
understand -- why don't you pivot to something like trying to evaluate their
conscientiousness or openness to learning or emotional intelligence or
ownership of their previous projects and mistakes and such? Or do you mean
that you ask these programming-type questions and you indirectly learn about
those other dimensions of success?

Also, I'd be curious to know what you do about teachability for some of the
skills -- I know that sometimes it's just "we're hiring for a senior role and
we cannot accept a junior/intern at this time," but very often it seems like
it's just "we're growing in general" and then you _are_ open to saying "hey we
don't have an opening for you as a mid-level developer but we would be willing
to hire you on as a junior-level dev and if you are as good as you say you are
we'd also consider promoting you after your 90-day-review when we've seen you
really shine." Are you trying to assess the level of the role that you would
offer the candidate with your questions, in other words? Or are you just
judging fitness for a fixed role?

~~~
Mc91
> why if you have this confidence that your first three questions contain 90%
> of the signal, that you spend the rest of the interview doing anything
> vaguely related to that?

When interviewing people maybe one in six answer questions correctly and in-
depth, one in six do very poorly, and the other two thirds do so-so. The two
thirds are all kind of interchangeable - they can answer most simple questions
in a basic manner, missing a few here and there, but can't go into much depth
on things.

I would say it is kind of a strict culling thing. The purpose is to find the
one in six who can answer the questions well. There's not much reason to
change it up much with the twelfth interview who is doing so-so, because if I
interviewed twelve people I probably just talked to two people who are a
standard deviation above the person doing so-so. So I want to talk more with
them, not the one who doesn't know anything in-depth.

On the interviews where they're really stumbling, sometimes I have felt like
standing up after only a few questions and going back to my work. Initially I
am never focused on one particularly area, I am jumping around in case the
last question was in some area they have a gap in, and perhaps they have a
strength in some other area. I use their resume, and ask them directly about
the areas of strength, to guide this. If they tell me they are strong in an
area I will certainly ask them some questions in that area. If I know early I
will say no, but keep asking questions any how, I suppose I stay the minimum
amount of time I can without seeming rude.

The one in six who do well, those are the ones that I "pivot to something like
trying to evaluate their conscientiousness or openness to learning or
emotional intelligence or ownership of their previous projects and mistakes
and such". Or more broadly, get a sense of their personality, how they will
fit on the team, what their expectations are etc. I suppose it is almost the
pattern as the technical questions - one in six will have some obvious
personality quirk (they really don't listen to what we're saying at all, or
they are very obnoxious, or they seem uptight beyond being nervous at an
interview - or they take a pen out and start writing on different objects in
the office, and the the boss comes by later and asks who wrote over everything
and you say the interview subject, and the boss asks why you didn't stop them
from writing on desks, walls, machines etc. with a pen - yes, this happened),
two-thirds seem normal, and one in six is very friendly and/or seems like a
real go-getter with a lot of accomplishments under their belt. I'm pretty
lenient at this stage, although others are less so (also, I wouldn't mind
having a teammate who would gripe about features and projects they thought
were BS, but maybe my team lead or manager would mind - so a pass by me for
this type might be a block by them).

So in short, I don't even try to fathom their "emotional intelligence" if
they're stumbling on easy questions.

Insofar as teachability, we're usually hiring for a role. They're also being
interviewed by multiple people - my technical assessments of the one in six
who are good usually matches my coworkers. I tend to be more lenient on
personality, emotional intelligence etc., they will say no to people I say yes
to. So even if I was more lax, they are not, and they won't get in. Usually
there is not much leeway, we are hiring for set roles. The main leeway people
get is if they know someone in the group already. If their friend works in our
IT group, and they know the subject but not in-depth, we often OK them on the
basis of the recommendation that this person is the type that will get up to
speed.

------
lexda15
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
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
How to check a lying person on an interview?

~~~
scaryclam
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.

------
Bokanovsky
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.

------
king_magic
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.

~~~
sonnyblarney
"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."

The point of the interview is to determine if they are in fact a 'solid
candidate'!

Also, sometimes very experienced engineers have difficulty thinking,
communicating and writing code coherently even if they can 'discuss' project
issues in detail.

Here's a famous and interesting article on that [1]

[1] [https://blog.codinghorror.com/why-cant-programmers-
program/](https://blog.codinghorror.com/why-cant-programmers-program/)

~~~
king_magic
Oh, I had an edit to my original post that included something about coding
challenges (either homework or pair programming) - didn’t want to give the
impression that should be ignored - forgot to submit that change to my post.

------
dariusj18
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.

------
auiya
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.

~~~
jmalicki
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/executi...](https://www.reddit.com/r/AskCulinary/comments/2qw1rp/executive_chef_threatened_to_have_me_make_him_an/)

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.

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

------
cutler
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.

------
pojzon
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
No Fizz Buzz?

