
Ask HN: What have you found the most useful interview question to be? - kejaed
Hiring or applicant side, is there a question you’ve found that over time has helped you out the most in getting a better understanding about the people on the other side of the table?
======
projectramo
I am considered a great hirer, and it is because of this "one weird trick."

The most useful "question" is any generic task.

It can be as simple as

\-- please put this spreadsheet in alphabetical order

\-- I have misplaced your resume, could you send me another copy?

\-- That sounds like an interesting article, would you send me a copy later on

Even the most trivial task will really illuminate the difference between
candidates. Compared to a task, merely talking is entirely useless. Some very
polished candidates will simply ignore the request and do nothing. Some will
do one of two or three. Some very quiet candidates who are not "impressive"
will do all the requests, thoroughly and with obvious care.

How can someone handle the request to forward an article with care? You have
to see it to understand. They may remind you of the context, say a word about
the article, and add another one for more context for example.

~~~
bashmydotfiles
I can get the first task, but what is your reasoning behind the two other
tasks?

~~~
projectramo
I use the verbal ones for interviews where I haven't had time to prepare, or
they are not there in person.

Really, listening to a request and following up is just one of those key
things. If I had them come in and do a longer interview which I had prepared
for, I still find it useful!

------
EnderMB
In interviews I like to try and get a reaction, and the best way to do that is
to sit down with a coffee or two (or three) and just chat about their
experience over the last few years, in a judgement-free zone - dev to dev.

In terms of an actual question, the only useful ones are ones that come from
this chat, because it's where we have a back-and-forth conversation about tech
decisions, what issues they had, what they had to overcome, and what decisions
that particular dev made. My goal is to get a reaction, negative or positive,
and dig into why that situation happened, what they did to overcome it, and
what they'd do with hindsight.

Not only does it make an interview more interesting for all involved, it tells
you more about the candidate than a quiz would. You learn what they do under
pressure, what pisses them off, and what experience they have for the kind of
work you do, because you've been using your experience against theirs in
conversation. Sometimes, to make it fair, I tell them (without dropping client
names) issues I've had recently, and I see if any of the solutions were raised
by the team, or are ultimately the solution we went for.

I've had enough success with this approach that (when I did interviews) this
was my approach:

1\. A really basic take home test, probably in a language they don't use, just
to see if they can write any code. Literally something that takes an hour to
do. A favourite of mine was to get them to write an application in a given
language to hit an endpoint, with a given code and their email address. When
done correctly, an email is sent to our HR team, who then set up an interview.
Based on our logs, you'd be surprised at how many candidates couldn't do this
- by which I mean had clearly worked on the test, submitted something, and had
failed to send a PUT request with the correct data.

2\. A relaxed interview, like above, in neutral ground like a coffee shop. I
use the walk from office to coffee shop to handle company questios, and the
standard interview stuff,

~~~
kstenerud
I would have failed your test. I'd have assumed that you didn't want your
server inundated by requests, set up my own server to verify what my client
was doing, and then submitted the code.

Even if you specifically told me that I must actually hit your server, I'd
still test on my own server, and then possibly forget to change the endpoint
before submitting (no way to unit test that). Shit happens, and you lose
someone on a technicality.

Also, what if your server stops working? Now you're wasting people's time.

Don't rely on magic; it eventually bites you in the ass.

~~~
insomniacity
Not GP, but I would say that lack of attention to detail is a negative mark.
Depending on GP's industry or team, that could be a dealbreaker.

If you can't connect to the server, or it returns a fatal HTTP error, a
reasonable candidate would reach out via other means (assuming they aren't
deliberately hidden or unavailable).

~~~
ManlyBread
If I would see that the server is unreachable I wouldn't contact anyone, I
would interpret that as a red flag. The company would have no problem with
deeming me unfit to work for them if I fail to complete the task - why should
I consider working for that company when it's their fault that I'm unable to
complete the task? What if this situation illustrates how the company works on
the inside (no one takes care of the environments, things are constantly
broken)? Is it worth it to find out?

~~~
Maert
That's a lot of jumping to conclusions. A simple "Hey guys, the server seems
to be down, not sure if you're aware. Can you let me know when it's back up so
I can submit my request, as intended?"

Shows understanding, shows willingness to reach out and solve problems, shows
ability to delegate responsibility.

~~~
ManlyBread
My approach is merely a reverse take on "it is better to pass up a good
candidate than to hire a bad one" that most companies seem to utilize. I'd
rather refrain from continuing the interview (even if the company wouldn't end
up being that bad) than wasting several months in a bad place.

------
kstenerud
"Tell me about one or two projects you've done in the past that stand out for
some reason. Maybe you learned a new technology over the course of it, got to
interact with cool people, got shipped off to a different country, had weird
clients, got a killer contact. Maybe the project was a total disaster. Doesn't
matter what happened or how long ago, just something you found memorable."

Get them talking about what things they get emotionally invested in. You learn
a lot about someone this way.

The trick to good interviewing is putting the candidate at ease. When
someone's future is on the line, they behave very differently, and preform
worse than they would in a regular work environment.

Asking questions like "what have you done well" and "what mistakes have you
made" will favor narcissists, because they will embellish, whereas those more
on the neurotic side will take more blame, and dislike taking credit.

So put them at ease. You'll get far more real answers that way.

~~~
andrewf
> Get them talking about what things they get emotionally invested in.

Yep. I ask something similar and explicitly tell the candidate I'm NOT
necessarily after "tell me a time you delivered strong business impact", "tell
me a time you added a new skill to your resume", or the other stereotypical
things that make a good "interview story".

------
seanwilson
I find this one short and useful: "so you know language X and Y, can you
compare some features between them that you like and dislike?". If they get
into deep comparisons about the tradeoffs between type safety, state,
maintainability, multithreading, undefined behaviour, functional vs OO,
libraries etc. that's a good indicator to me.

~~~
estomagordo
+1

I've been asked this question in interviews on more than one occasion. I find
it gives me a good opportunity to show off some knowledge, and with a good
interviewer, it's a very good conversation starter for something that can end
up being quite deep diving.

------
basseq
Hiring side.

"Tell me more about what _you_ did." Can be asked off almost any line of
conversation. I'm seeking two outcomes:

1\. Candidate's ability to quickly articulate a complex process, organization,
problem, etc. to someone who has absolutely no understanding of it (i.e., me).

2\. An understanding of their specific role and impact, as well as how the
team worked together. You often have to coach people through the latter, as
many candidates will default to the royal-we.

The other one I'm playing with is, "Let's say you start working here, but six
months later, you leave for another opportunity. Why would you leave?"

I'm still figuring out the delivery on that one, but you get an interesting
insight into what matters to the candidate.

~~~
vkou
The honest answers to the second question aren't very nice, and have
everything to do with the character of the persons employed at a firm.

Why would I leave a firm in six months? Most likely because my boss is an
asshole. Am I daft enough to get into that with an interviewer, who may be
that boss? No.

~~~
tilolebo
I'd rather not get a job that very probably do not fit me anyway, instead of
finding out after having left that my new boss is an asshole.

The overhead of starting again the job search from scratch, explaining why I
want to quit after 6 months (for real this time) is much bigger.

~~~
vkou
Just because my interviewer asks me that question, doesn't make him an ass.

Likewise, just because they would interpret that answer as a black mark,
doesn't make him an ass. Maybe the reason I run into asses all the time, is
because I am one. Even if they don't interpret it as a black mark, it's a
pretty daft way to start a professional relationship.

There's too many unknowns, so the correct course of action is to make up some
non-confrontational lie.

------
neerkumar
Ironically, when interviewers talk about how they interview, they pretty much
all seem to believe they are very good in evaluating candidates. But when
candidates talk about job interviews, they all seem to agree interviews are
done badly.

A rule I have is that everyone is good in something and bad in something else.
So, if by the end of the interview I haven't found a topic where the candidate
excels and a topic where sucks, the interview hasn't been effective.

~~~
ishjoh
If you've found what they're good at, and it matches what your needs are, does
the information on what they suck at help you decide between multiple
candidates?

------
snowwrestler
From the hiring side:

"Tell me about a result or achievement you're very proud of. How did it come
to be a goal for you, and what did you do to accomplish it?"

(Crucial followup after they answer) "Now tell me about a mistake you made
along the way and how you overcame it."

Talking about real work provides insight into motivations and enthusiasms, and
gives you permission to dive into details as they talk. It also helps show
whether they have a healthy attitude about mistakes. This question can also
provide some insight into team dynamics since very few big things are
accomplished solo these days.

From the applicant side:

"Let's say I get hired and I do an amazing job. You're going to write my
6-month or annual review--what would you write?"

Like Amazon's trick of writing the press release first, this helps hiring
managers get specific about their expectations for the hire. It's amazing how
often companies hire folks with only a vague sense of what success should look
like.

------
sageabilly
Applicant side: "What's the biggest struggle that you're currently working
through?" coupled with "Tell me a bit about how you're working through that
struggle."

I find this tells me a lot about the person who's interviewing me and the
current climate they're operating in. Asking follow-up questions helps a lot
here too. It's a good way to find out if the interviewer (frequently the
hiring manager) is struggling with an unmotivated team, overly-onerous
bureaucracy, lack of funding, staff turnover, outdated software, etc.

------
laurentl
I have a generic question which I ask in all interviews, whether hiring for a
dev, manager, project leader. It works wonders for me.

For each position in the candidate's resume (or the last 3 if the resume is
too long) I ask "what did you like about the job? what did you dislike? What
made you happy to go to work and what made you drag your feet? It can be
anything: boss, coworkers, how work was organized, office politics or lack
thereof, visibility/interest of the job, commute time, offices... There are no
wrong answers". Then I let them talk.

When it's done right, I find this is a great way to understand what motivates
them and to make sure their intrinsic motivation is aligned with the position
they're applying for and the company context. For instance, for a developer
I'll be interested in someone who likes fixing problems; for a project
manager, being result-oriented is usually a good thing. Someone who likes
having a clear set of steps to follow is probably not a good match for my
management style. Another thing that I can check is how they coped with a
situation they disliked. Did they try to address it, work around it, or did
they give up/avoid it?

I was first exposed to this approach as a candidate. I remember spending 90
minutes talking about all my previous positions, reflecting about what I'd
liked and disliked for each of them, and coming out of there knowing more
about myself than I did going in.

------
elmarschraml
Having them do a code review (about 10-15 minutes), i.e. have a short (about
50-80 lines) piece of real code, that I have prepared with plenty of problem,
messes, non-idiomatic code, or little ugly things.

NOT a test as in "find the 10 hidden mistakes", but an invitation to talk
about ways to improve the code. I make it clear to the candidate that it's not
about the syntax, or any algorithm, but about quality.

It's really good to see what kinds of things they care about (e.g. do they
look into low-level performance, or more into things like variable naming and
method length), how deep their knowledge of the language is (e.g. do they
recognize non-idiomatic code, and suggest more modern approaches), if they are
more of a high-level thinker or more detail-oriented etc. And of course, it
nicely weeds out the (surprisingly high) number of people who cannot really
program, without relying on any memorization of keywords. Plus, it's pretty
realistic - nobody ever writes code on a whiteboard, but doing code reviews of
code somebody else wrote is something that happens all the time.

Most candidates find that task quite fun - and with really good candidates I
quite frequently learn something new myself.

I was planning to do a blog post about why and how I do that review - let me
know if that would be of interest to you.

~~~
filoeleven
I would love to be asked to do a code review during the interview process.
What a great idea.

I can imagine that another good thing about it is that it takes enough focus
and is a familiar enough task that even if I’m in nervous-applicant mode, it
will kick me over into acting like I’m already working there.

------
7402
When interviewing someone for a more senior position, I would always ask,
"What was your worst [work-related] mistake?" If they couldn't come up with
anything, they were either lying or they just coasted through their previous
jobs. If their answer was mostly about how it was really someone else's fault,
then I'd consider them lacking in the kind of attitude I consider important in
a co-worker.

~~~
mbrock
I wonder if it’s okay for an interviewee to ask something like “What’s the
worst thing about this company?”

------
athst
On the applicant side, one of the more interesting questions I've been asked
(as a product manager) was something to the effect of:

"What is something you believe about product management that differs from
conventional wisdom (or what the majority of other product managers believe?)"

I thought it was a good question, because it gives the chance for the
candidate to talk about how they think, and it gives them a license to speak a
little more honestly than they ordinarily would say in a normal interview. It
shows you how much thought the person has given to their profession and how
they approach their job.

If you were asking this during hiring, I think it should be done with care on
your end, because I could see it easily being misinterpreted by the wrong
team/interviewer.

For example, if someone came in and said something like "Compared to others, I
think A/B testing is a waste of time", it would behoove you to dive in a
little bit more to understand why they think that. It shouldn't be
disqualifying if you're a team that does a lot of A/B testing.

------
zer00eyz
For me there are two critical questions I ask of a candidate.

1\. I tell them the story about a massive screw up in my career (its funny)
about how I thought I was getting fired about being frank about it... etc. I
then ask "do you have a story about a major screw up in your career. The
answer should say a lot. Dealing with crisis, dealing with mistakes, can you
laugh about traumatic things (a great coping mechanism as a programer). I'm
looking for insight into you in a professional setting. There have been
occasions that this one question takes up the BULK of my allotted time and has
on occasion gone over.

2\. Can you read and talk about a piece of code GIVEN to you. The bulk of the
battle for most devs is READING existing code and trying to figure out where
to fit fixes in, or how to integrate what they are doing into a larger,
standing system. The provided sample should have errors, room for improvement
and plenty of ambiguity where the reader has to make assumptions or ask
questions.

------
elmarschraml
Generally, asking opinions rather than specific technical answers.

Asking "Do you have experience with technology X" is useless - everybody knows
that "yes" is the expected answer.

Asking specific technical questions is random - they might or might not have
come across that particular problem. Also, in practice the answer would simply
be looked up, and you don't want to hire for memorization.

Instead, ask things like"How did you find working with <technology X>? Can you
compare it to <common alternative>, or <similar tech also listed on their
resume>?". Or maybe "what worked really well with <technology X>? What
pitfalls did you fall into? Anything for which you would, or would not,
recommed it?"

This kind of info is hard to fake, gives you good insight into their thought
process and priorities, or just gets people talking about their projects more
easily than a generic "tell me about your work on project y".

------
gvand
More important than trying to find a question of adamantine perfection and
blinding luster is the knowledge that regardless of how many hours you have to
interview a candidate, your opinion will still be partial, influenced by
biases and to some degree wrong.

~~~
gvand
More on topic, interviewee side: Describe me a typical day here.

Expected answer contains: Overall process, roles distribution (who does what),
project management style, issues triage, etc...

------
paulcole
When interviewing someone, "What will your next job be after this one and how
can we help you get there?"

My follow-up is usually something like, "Explain that job title/position to
me. What does that person do? What skills do they have?"

------
darkhorn
When they ask "Do you live with your family? What jobs your family members
have? What are your hobbies? Where you were born? Are you married? How old are
you?" then I know that I don't want to work there.

~~~
sns989
not sure if you live/work in the United States, but the majority of those
questions are illegal to ask.

------
tboyd47
I can answer on the hiring side when it comes to programming jobs.

In a 100% honest world, you wouldn't even need to interview for technical
positions; you could look at the person's resume and tell instantly whether or
not they are capable of doing the job. But people lie a lot and over-
embellish. So best questions to ask are about the items listed on their
resume, because you find out who's telling the truth and who's not.

------
pwaivers
From the applicant side: Why are you hiring for this role? Is it a new
position, or did someone leave it?

~~~
insomniacity
Yes, always my number one applicant question.

I even had one interview where that question basically lead to the interviewer
explaining just how bad it was, and how unlikely it was that I actually wanted
the job (and I had no reason to believe that was a trick or bluff). I
certainly left feeling like I dodged a bullet.

------
JSeymourATL
_Let 's use our time together well. I know you've read the position summary.
Met with HR and members of our team here. What questions do you have for me? _

Behind the question-- I'm probing for curiosity and intellection. Also, what's
important and top of mind to them.

------
tmaly
I like to ask about a project, could even be something from university days. I
ask them to explain how they approached the problem, what were the challenges,
how did they overcome them, and what was the final result of the project.

------
itronitron
Applicant side (and software focused), asking interviewers how new
functionality is defined, developed, and deployed gives a lot of insight to
how the team works within the organization.

------
avitzurel
1) Tell me a little bit about yourself. 2) Tell me about an interesting
challenge you had in your current position and how you solved it.

------
palidanx
"Tell me about the last time you failed"

It usually reveals character on how a person deals with tough situations.

