

Ask HN: What are interviewers looking for when they give you puzzles? - cmorgan8506

I&#x27;ve been doing some programming interviews lately, and they&#x27;ve all included &quot;typical&quot; programming challenges. A lot of them can be done through brute force, but it&#x27;s evident they are looking for the optimal solution ie. O(n).<p>I&#x27;m curious, do these companies want to see if you&#x27;ve already done a similar questions and are able to re-apply the solution? Or are they looking for you to produce a novel approach to the problem? If the latter, is it a typical expectation for a Software Engineer to be able to produce optimal solutions in short periods of time like that?<p>I&#x27;ve been spending a lot of time studying these types of interview questions, but I continue to run into puzzles I&#x27;ve never seen. I&#x27;m concerned that they are looking for a degree of problem solving skills that I might not have.
======
gregjor
I have concluded the main value of these tests and interview puzzles is
humiliation. It's like a fraternity hazing -- if you can survive without
losing your cool you get to join the club. If you've been hired after one of
these nasty tech interviews you've probably sat around with your new co-
workers hearing them make fun of the candidates who didn't make the grade.

If someone interviewing you has a CS degree from MIT they may want to show off
to you and everyone else how much they know and how clever they are. It's
possible the job requires deep computer science expertise, but most
programming jobs simply don't.

A few years ago Google -- famous for their tech interviews -- revealed that
they had found no correlation between the interview tests and puzzles and job
performance.

My own experience (36 years) working with many, many programmers in all kinds
of environments is that some are good at puzzles and enjoy them, and others
aren't. It doesn't appear to have much to do with their ability to write the
bread-and-butter type of code that most of us spend our careers writing. Sure,
it's good (maybe essential in some contexts) to know if an algorithm is O(n)
or O(n^2). I've worked on projects where recognizing a better algorithm made
the code faster or cleaner. But these are edge cases for most programmers, who
are mostly shuffling data from one format to another and trying to get their
build system to run on their laptop.

Of course you can ask the interviewers what they expect to learn from sweating
you over puzzles, or how many times they have had to move Mt. Fuji in their
day-to-day work, but challenging the interview process is probably not going
to help your prospects.

~~~
avinassh
> A few years ago Google -- famous for their tech interviews -- revealed that
> they had found no correlation between the interview tests and puzzles and
> job performance.

Any articles/links on this one?

~~~
gregjor
[http://www.nytimes.com/2013/06/20/business/in-head-
hunting-b...](http://www.nytimes.com/2013/06/20/business/in-head-hunting-big-
data-may-not-be-such-a-big-deal.html?pagewanted=all&_r=1)

"On the hiring side, we found that brainteasers are a complete waste of time.
How many golf balls can you fit into an airplane? How many gas stations in
Manhattan? A complete waste of time. They don’t predict anything. They serve
primarily to make the interviewer feel smart."

From an interview with Laszlo Bock, senior vice president of people operations
at Google.

------
mrcold
Most of them do it because everybody else is doing it. Every time some poor
soul gets tasked with interviewing candidates, he just fires up a google
search to find good interview questions. He reads about puzzles, fizzbuzz and
_" analyzing your candidate's though process"_. And with nothing else in
sight, he accepts them as the golden standard.

The best part is that each and every one of these interviewers thinks they're
special. Like they are somehow clever and intelligent by asking this type of
questions. They don't even realize that they are using the same lazy approach
everybody else is taking.

The truth is, tech interviews revolve around your interviewer. How you make
HIM feel. I've seen idiots get hired because they were enthusiastic. And
extremely intelligent people rejected because _" they couldn't communicate the
way I like it"_.

So in an interview forget about your skills, experience and anything else
related to the job. It doesn't matter. Just woo the person across the table
and you will get an offer. This works most of the time for shitty companies
with lazy interviewers. And that's most of them.

Personally, I found that that companies that allow this type of interviewing
behavior will overwork and underpay you. Because they don't care. They just
want to push things out to make a quick buck. If you want to be treated like
an expert that has a brain in his skull, avoid them completely.

Instead, find the companies that trust your experience. That act like you're
as good as you say. And just make a quick check to see if you know what you're
talking about. They are rare and most of them are startups. But the higher pay
and better work environment is completely worth it.

~~~
jhildings
Yes what truly would make them stand out is if they ask about some problem
they are having in their business(redundant network access, too many tests or
whatever) and ask you how to solve that and in which steps

------
giaour
You're right to think that's there's almost always a trick, but interviewers
generally are more interested in watching your work process than in seeing if
you can get it.

When a candidate is struggling or even just asks me, "is there a trick to this
that I'm not seeing?," I will give them pretty big hints. They get bonus
points for knowing when to ask for help and/or for being able to incorporate
new information into their code quickly. I've always been offered the same
courtesy when on the other side of the table.

That said, I personally don't give much weight to challenges or tests and
would be surprised to hear if anyone considered them more important than
relevant experience.

~~~
bostik
> * You're right to think that's there's almost always a trick, but
> interviewers generally are more interested in watching your work process
> than in seeing if you can get it.*

This is true, and certainly my approach to doing interviews.

I tend to ask two kinds of questions. There are easy ones, with lots of
different solutions. On those I do want to see a working answer (because they
are supposed to be easy), but I explicitly track how the candidate arrived at
their particular answer. I get an idea how they think, and what kinds of
solutions they consider, not to mention how they deal with bad approaches.

And then there are the hard ones. They usually have exactly one correct
solution, but finding that is not required. Instead I focus on how the
candidate approaches the problem, and how they deal with different tradeoffs.
The interesting bits are generally false path eliminations, the kinds of hints
they need, and quite often how they formulate the problem to themselves.

Once a candidate has shown that they pass a definite baseline requirement for
proficiency, the rest is mostly about trying to see how they approach problem
solving in general.

------
wikwocket
Okay, so there's sort of a spectrum, with true _puzzles_ (like "How many golf
balls would fit inside a jumbo jet") on one side, and true work sample tests
(like "Work with us to address a programming challenge typical of what we do")
on the other side.

True puzzles do not provide very much useful information, as they are often
based on a trick, and don't actually overlap a lot with what we do. Even
algorithmic puzzles are pretty dumb.

But problem solving, O(n), and composing algorithms _is_ very important to
what we do. So what I'm looking for when I ask you to write a function so
solve X is:

\- Can you understand a problem and critically think about it?

\- Can you handle super-basic logic to work out a solution?

\- Do you at least vaguely understand performance concerns, i.e. can you
identify whether a given input is problematic, or talk about possible ways to
improve it?

~~~
cmorgan8506
I feel like there's always a "trick" to them though. For example, find the
only non repeating number in the following sequence: 1,2,3,99,3,2,1. This can
be done in O(n) time and 0(1) space if you use bitwise operators. Now, you
either have experience with bitwise operations, or you don't (no pun
intended). If you don't, you are very unlikely to approach it from that angle
and likely won't get the optimal solution.

~~~
wikwocket
No, I would never ask a question with a trick in mind. I am not interviewing
for people who know tricks, because approximately zero percent of our business
problems can be solved with tricks. I am looking for competent execution,
because that's what matters day-to-day.

If I had asked a question like that, and if you can do some bitwise voodoo to
solve it in O(n), great. But what I'd be looking for is, can you solve it all?
Do you understand the problem statement enough to write a general sort of
algorithm? If your first pass is O(n^4) and I point it out, can you understand
this, and think of ways to improve? If I point out a problematic or erroneous
input, can you reason about what will happen? Etc.

I think this is what we need to look for in interviews. Certainly not, can you
solve this brain teaser I read in a magazine.

------
davismwfl
I don't ask many of these anymore but even when I do and have in the past it
is never to humiliate anyone. To that point I don't even care if they give the
right answer, what I want someone to do is talk out how they'd figure it out.

So at least in my opinion it is about seeing how you think not whether you can
solve some complex problem in 5 minutes. This is also why I have changed how I
ask and what I ask. I've moved to telling people up front that I don't care if
they get the right answer, I just want them to show me their thought process
and how they would go about solving it. And I will also participate and
provide feedback and talk through it with you like we would as team members.
This way we can see how good or bad we might work together.

~~~
cmorgan8506
What type of characteristics constitute a positive result, for a situation
like that?

~~~
davismwfl
Overall, did you successfully walk me through your thought process to come to
an answer (right or wrong). Did you engage me, ask me questions, challenge my
assumption if you felt I was wrong etc. Did you act as a team member trying to
figure out the goal or not, did you bounce ideas off people while thinking
through the problem. Were you able to eliminate possibilities because you know
of limitations or issues that might come up. And really most importantly, did
you come up with many, most or all of the key decision points regardless if
you go the "correct" answer.

So at least for me, and my team, its never about can you state that a hash
table is O(1) for access but O(n) for search vs a b-tree is O(log n) for both
etc. It is more about can you think through a problem well enough to give us
the best solution and will you work with us to find it. e.g. puzzle questions
IMO used to be a lot about self gratification to the interviewer's own ego,
now we use them to see thought processes and to be interactive to see how we
all work together.

------
JSeymourATL
What are interviewers looking for>

You can tell a great deal about the interviewers sophistication, business
acumen, and level of seniority by the types of questions they ask.

The puzzler question may come off amateurish. Sometimes the interviewer is
simply probing for emotional intelligence and good humour. They want to know
if you'll be a cultural fit and accretive to the team. Play along, it's part
of the process.

Sadly, the first level of interviews are often done by low-level types, even
worse...HR flunkies.

------
theaccordance
Different companies have different reasons for code tests. Generally speaking,
here's what you should expect they're evaluating:

\- That you're able to take ownership of a task and see it to completion

\- That you can work with the tech stack that the company uses

\- That you can actually do what you say you can do

------
ColinWright
Some interviewers just want to humiliate you and exercise their power over
you.

Maybe.

Personally, I do use questions like this, and I'm looking for a combination of
things.

Firstly, how much reading have you done, and how many of these things have you
come across before? If you know them all, that tells me you have to hand an
arsenal of techniques to bring to bear on a problem, and you care enough to
have done considerable outside reading and preparation. That's a good sign.

Secondly, if there's a problem you've not met before, what do you do? Do you
freeze? Do you go thoughtful? Do you ask questions to clarify? Do you look to
step around the problem? Are you sufficiently confident in yourself to simply
get to work, or are you worried that your inability will be seen as an excuse
not to hire you?

Thirdly, as you start to work on it, what's your intuition like? What
techniques do you bring to bear? Do you assume there's one, right, trick
answer, or do you treat this as a challenge to be played with?

Finally, how do you react to contributions from others? Do you welcome working
together and relish discovering stuff, or do you want to work alone, seeing
how you get on?

All of these have positive and negative aspects when weighed against a given
possible job. What I'm looking for is that balance between someone who brings
new skills and knowledge to the team, and the ability to work with the team,
and to have enough in common to be able to communicate effectively. Some
people love puzzles, some hate them. Some are great at theoretical analyses,
some aren't. Some people can devise or adapt algorithms, and some can't. A
good team needs a balance, and asking these sorts of questions of people is
part of finding out their strengths and weaknesses, to see how they'll fit in
a team.

Do you want my advice?

Work on your abilities. Be professional in your personal development in
whatever area you are interested in, as well as other related areas. Read
widely, work on projects, work with people, and expose yourself to
technologies outside your comfort zone. When faced with puzzles and problems
like these, be yourself. Ask what's expected, and work with your interviewer
in a professional manner - an interview should be a dialogue. At the end of
the interview ask yourself - do I want to work with these people?

If they don't hire you for who you are and what you bring to the table then
you would likely not be a good fit, and would likely not enjoy your work
and/or the environment. If they offer you the position, you've learned a bit
about what they are like to work with, so you are in a position to decide if
you want the job.

But this is not an ideal world, so you will need to decide what compromises
you're willing to make.

~~~
ThrustVectoring
"Arsenal of techniques" favors one style of thinker over another.
Specifically, I'm talking about synthesis vs analysis - whether you approach
problems by trying to build a solution out of pieces from other areas, or by
breaking the overall thing into pieces and figuring out what the pieces look
like.

I'm heavily in the synthesis camp, and that kind of inquiry is something that
favors my style of thinking over more analysis-oriented folks. I'm not even
sure how you'd go about pulling analytic strength out of people.

~~~
ColinWright
Either way, giving you things to think about and work on allows you to
demonstrate your strengths. And whether you "approach problems by trying to
build a solution out of pieces from other areas," or by "breaking the overall
thing into pieces and figuring out what the pieces look like", either way, you
will have techniques for doing what you're doing, and such techniques are
visible when you work on a problem.

------
anon3_
They're a gimmick.

Startups in the valley are notorious for following these. It's based off the
misguided assumption that it equates to a candidate's future quality,
throughput and they can mold you into any stack.

The real value comes from learning algorithms when you can actually apply
them. You'll real learn things when the time comes - and self-interest in your
own software / task will keep you engaged enough continue optimizing speed.

If you truly were a master at o(n) this, quadratic that and shipped voluminous
amounts of code - take that and apply for a quant job.

