
How to talk about yourself in a developer interview - NickLarsen
https://stackoverflow.blog/2017/04/27/how-to-talk-about-yourself-in-an-interview/?utm_content=buffer74fe2&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
======
lettersdigits
> What is the hardest technical problem you have run into?

I never seem to find a quick good answer for this.

Maybe I just almost never work on REAL hard things.

So my question to you, HNers, is :

What is the hardest technical problem YOU have run into?

I am really interested to know what you would consider 'hardest'.. It's
probably not going to be something like 'I changed the css property value from
"display: block" to "display: inline-block"..'

~~~
luu
I have no idea how to answer this question. There have been some problems
where someone was stuck for weeks, and I came in and coded up a solution in a
day. That seems, in some sense, good evidence of being hard, but those
problems never seem hard to me. The reverse happens to me too, where someone
else solves a problem that was hard for me, and it's easy to them. Is that a
hard problem? It was hard to me, but the problem was easy if I saw it the
right way, which I didn't.

Last year, I came up with a solution to a problem that we'd been solving sub-
optimally for years. My solution is arguably optimal (given a certain set of
assumptions) and requires multiple orders of magnitude less code than the
previous solution. The solution is the core part of a paper that was recently
accepted to a top conference in its field. That sounds like it might be good
evidence the problem was a hard problem, but in fact the solution just
involved writing down a formula that anyone who was exposed to probability in
high school could have written down, if it had occurred to them that the
problem could be phrased as a probability problem (that is, the solution
involved multiplying a few probabilities and then putting that in a loop).
When I described the idea to a co-worker (that you could calculate the exact
probability of something, given some mildly unrealistic but not completely
bogus assumptions), he immediately worked out the exact same solution. It
wasn't an objectively hard problem because it's a problem many people could
solve if you posed the problem to them. The hardest part was probably having
the time to look at it instead of looking at some other part of the system,
which isn't a hard "technical problem".

Another kind of problem I've solved is doing months of boring work in order to
produce something that's (IMO) pretty useful. No individual problem is hard.
It's arguably hard to do tedious work day in and day out for months at a time,
but I don't think people would call that "technically hard".

I'm with you. Maybe I never work on "REAL hard things"? How would I tell?

~~~
sheetjs
It's all relative. Sometimes solutions require insights. Other times solutions
involve a ton of grinding. Many people have a tendency to overemphasize the
first and greatly underemphasize the second, even though the grinding may
actually be harder than devising clever solutions.

We build tools that read and write Excel files (open source library:
[https://github.com/sheetjs/js-xlsx](https://github.com/sheetjs/js-xlsx))
There are plenty of very difficult problems involving ill-specified aspects of
the various file formats and errors in specifications, but it is largely a
matter of grinding and finding files in the wild that capture the behavior you
want to understand. Those are "difficult" in the sense that people still get
these things wrong (related: recently a bug in the Oracle SmartView corrupted
US Census XLS exports, which boiled down to an issue in calculating string
lengths with special characters) but they don't feel difficult since most of
the work didn't involve any really clever insights.

IMHO the hardest problem is now fairly straightforward: How do you enable
people to test against confidential files? The solution involves running the
entire process in the web browser using FileReader API:
[https://developer.mozilla.org/en-
US/docs/Web/API/FileReader](https://developer.mozilla.org/en-
US/docs/Web/API/FileReader) , and that is an obvious technical solution in
2017 but few thought it was even possible when we started.

~~~
aidos
That's actually my default response when people intimate the work I do must be
complex / I must be clever - it's really just hard graft. Sometimes you just
have to be willing / stubborn enough to chip away at a problem that initially
seems insurmountable. Sure, the more knowledge you accumulate, the faster you
can figure out when to look, but often enough you just need to roll up your
sleeves and bisect your search space.

I can imagine you get some pretty warty excel files. I mostly get PDF for my
sins. I'm sure, like me, you've spent hours taking bits out of files until
they work as expected and then figuring out what the difference is :-)

------
wallflower
If you don't agree with this slightly-contrived (I'm talking about the 'start
with punchline', specifically) storytelling technique endorsed here, at the
very least, please be aware of the STAR technique commonly used in behavioral
interviews.

One benefit of using the STAR technique is that you are not going to ramble.
It should not take you more than 1 minute to fully lay out the Situation,
Task, Action, Result. After that "executive summary", if they want you to go
more in depth, the interviewer(s) can ask you.

[https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Resul...](https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Result)

~~~
dahart
You _could_ use the RATS technique. ;)

I feel like STAR is important in the same way and for the same reason as
'start with the punchline'. Both are good ideas, and both are aiming for 'keep
it short and relevant.' Which, having interviewed and hired many people over
the years, I'd have to say is reasonably good advice.

There are plenty of exceptions to both of these ideas though. I probably have
more trouble getting engineers to elaborate on something than I have with them
going on for too long. I quite enjoy a candidate who will help me carry a
conversation, who will ask questions of me, who will offer and inject relevant
or interesting side-details into their story. Going on a tangent isn't a bad
thing unless it's negative or irrelevant.

------
tn135
This is one of the best blogs on the topic and as someone who has easily
cracked all big tech company interviews I can say this is a good piece of
advice.

I will make following broad points:

1\. Never walk into that room without practicing. Practice before a mirror,
practice before a friend, practice in a car. Have a written script and
optimise it to remove redundancy, highlight achievements etc.

It is not about repeating what you have practiced but having a free flowing
conversation where you don't have to struggle for words, sentences all while
maintaining a confident posture.

2\. Converse not interview

A lot of people fail to keep the conversation going. It is not like a FBI
investigation. It is more like a friendly banter. Think of a scenario where
you are talking to a potential roomie. It is okay to walk out of that
interview without an offer but then you should feel good about having
conversed with another geek just like you.

\---

Maintain the mindset outside of interview preparation. Most people fail at
this.

Good interview preparation begins months ahead. You need to look at your co-
worker's code, give them feedback, learn to make needless improvements in your
existing code, solve algorithms and discuss technical problems on stack
overflow and else where. Built a mindset where you are able to talk about
technical work to other people. Speak more, listen more and advice more at
least 3 months ahead.

~~~
hueving
If that's what it takes to get a job as an engineer at the big companies, it's
not particularly surprising that the quality of their engineers has declined
as they've grown.

The skills of a con artist are not related to the ability to build good
systems.

~~~
alpha_squared
Conversely, the skills to build good systems are not related to working
effectively with others. There's probably a balance that needs to be struck,
though they're also not mutually exclusive.

~~~
dasil003
> _the skills to build good systems are not related to working effectively
> with others_

Yes they are if you're talking about the types of systems that large companies
have. It is in fact so difficult that I believe it's a considerable advantage
to have scopes small enough to be manageable by a single engineer, but
inherent complexity is often well beyond that, especially for very profitable
business engines.

------
a3n
> If you’ve been through interviews at some companies that are not as good at
> interviewing, then you probably had some questions on your list such as

> Where do you see yourself in 5 years?

 _Dead_.

> Why do you want to work here?

 _You have money._

> How do you handle disagreements with coworkers?

 _Attempt constructive engagement, and if that doesn 't work then shun them._

~~~
foo101
What are your strengths and weaknesses?

~~~
a3n
Honesty and honesty.

~~~
nercht12
You forgot "humor".

------
dahart
I see some criticism on this point, but for me this passage is a gem.

> In general, real stories are told chronologically backwards. This is why we
> start off with a punchline. In contrast, practiced stories are told
> chronologically forwards. It’s a solid indication as the interviewer that
> the person is reciting something they have committed to memory if they tell
> the story forwards, and in turn it’s significantly more likely that the
> story isn’t entirely true.

I have a friend who - bless his heart, I adore him, but can't get a quick
story out to save his life. Every point he makes he reserves the punchline for
last, and he starts by going on a back-story tangent first which usually forks
into multiple back-stories. I've been trying to nudge him to turn it around
and give away the punchline first, but he's deeply convinced that good stories
are like movies and need to have a backstory followed by a narrative arc that
doesn't make it's final point until most of the way through act 3.

~~~
inanutshellus
Oh man, that's me for sure. I always backstory my tales to death. It does
successfully take a minor conversation and turn it into an elaborate and
interesting discourse but yes, as you say, it's not focused on the original
punch line.

~~~
ma2rten
I never realized it until now, but I think I might be doing that as well. I
will try to be mindful of that. Thanks.

------
sweezyjeezy
> If you give them a resume, expect questions about stuff you worked on at
> your past jobs. If you gave them a link to your Github profile, expect
> questions about your projects. If you gave them a link to your Stack
> Overflow account, expect questions about some of your answers.

On my Linkedin (and also resume etc.) I give a link to my blog / github. Every
time I've been asked about it in an interview setting, it was actually when
_I_ was the one conducting the interview, and the interviewee was trying to
impress. Much as it pains me to say, I don't think side projects are a good
way to bolster your CV, at least in my field.

~~~
wccrawford
I've only asked questions about Github projects when they have something on
there wasn't obviously from schooling or just garbage they threw on there to
keep for later. I'm pretty certain we're in a different industry, but I'm
still surprised nobody has asked about your Github stuff, assuming you've put
decent things on there.

------
digoM
Google has published some of their data on this and behavioral questions about
teamwork (e.g. handling disagreements) are reasonable and can be valuable.
Software development is usually a team activity. The rest of this post is a
useful, if anecdotally sourced, guide to answering the more technical class of
behavioral questions. It should include a block on follow up questions. Good
behavioral interviewers, like you might find at Google or Amazon, will ask
specific follow ups for each question. See:
[http://www.businessinsider.com/google-laszlo-bock-
interview-...](http://www.businessinsider.com/google-laszlo-bock-interview-
questions-2015-4)

~~~
NickLarsen
Thanks for posting this. One thing I didn't write about is the objectiveness
of interviews (felt like a different topic). Just about any question can be
okay as long as it follows a few simple rules. 1) if you ask a question, you
should have an expectation of what you're looking for as a result in some
quantifiable way and 2) how does that result affect your decision to hire or
not. The worst interviewers usually don't have an answer for #1 there and they
probably decided to hire you or not very soon after you opened your mouth for
the first time. This article fails to state why each of these questions is
valuable and what you should be looking for as a result of asking any of them.
With the addition of that, it would be a much better article.

------
cletus
Let's translate shall we?

> What is the hardest technical problem you have run into?

"Tell me an unverifiable story in which you're the hero."

I really hate this question:

> Where do you see yourself in 5 years?

Any post on HN about interviews draws a ton of comments, and they're usually
the same comments as every other post on the subject.

Honestly at this point having gone through a reasonably large number of
interviews I think it comes down to brushing up on basic CS knowledge and,
more importantly, whether or not they like you. As much as we like to make
interviews dispassionate assessments of proficiency it really does seem like
basic chemistry is the key issue. And honestly that makes a certain amount of
sense: most people don't want to work with someone they dislike.

~~~
GoToRO
Also, how bad they need to fill that position. You will get waaay less
bullshit if they are in hurry.

------
ganley
Good advice. My first (sometimes only) question when I interview people is:
Tell me about your favorite project.

~~~
TheCowboy
This is a good question if your goal is to hire people who can talk a good
talk about an unverified favorite project. It also assumes that someone has a
clear favorite project ready to discuss. People who do not are put at a
disadvantage. (Though I do understand this question is well-intentioned.)

The article doesn't really justify the process people go through as a good
one. People who think they have a good approach to interviewing, but their
sample size is too small to back it up or worse, present an opportunity to
people who are good at telling stories but may not have the skills to go along
with the story in the end. People who hire based on the story-telling
experience will eventually get burned.

I think someone should read this and feel a little worried. This is story-
telling. People who might argue that telling a story is being able to
communicate---it's merely one form of communication of many that are needed
depending on the work environment, and results in a blind spot for your team's
hiring process.

~~~
existencebox
Having done many interviews, mentored interns and full employees, I'd argue
storytelling is a _key aspect_ of performing our job in a larger team. Perhaps
I'm being too liberal in my definitions, but I see substantial overlap between
"talk about your last project" (and then digging into pitfalls, hacks,
workarounds, conflicts; and mind you, I don't mean just PASSION projects,
literally any work prior one can speak fluently on) and "tell me how you want
to spec this architecture; why".

Much of how we discuss what we do can't be empirically precise, unambiguous,
and scientific. Certainly the more social and abstract aspects of our jobs
begin to sound, as you put it, like storytelling.

(To be clear, it's far from the only thing I look for, and can be
taught/learned to a degree, but I consider it as a key skill in the broader
bucket of "communication"; alongside problem solving and base competencies.
And like programming itself, having some experience helps.)

~~~
TheCowboy
As I mentioned, this is playing into the fallacy that telling a story during
the interview is equivalent to the communication skills required for
performing the job.

It confuses story-telling performance during an interview, and the stresses of
a success/fail situation, with the type required to perform real work.

Mistaking "overlap" for all-encompassing. Sure, there's overlap. There's
overlap in being able to type up a coherent response to a post on Hacker News,
but it doesn't make me more qualified for your position.

It fails because it assumes that the candidate has a single defined favorite
project. If you try to make the question more broad, then it becomes so open-
ended that it is hard to equally compare candidates on it. It becomes random
chance that a candidate discusses a project in a way conducive to doing the
job. Where if more precise or structured, it might weed out people who can
talk passionately about a personal project from those who can constructively
explain to a manager the challenges of a project.

It also starts stretching it into saying that everything is story-telling so
as to make the term meaningless. I agree it is to some degree, but it's
important to try to stick with meaningful mental models that can make
predictive assessments about candidates.

The huge problem is there are people without the skills who can tell a good
story. This process let's these people through, while ignoring good candidates
who may not perform well on this interview question.

~~~
scient
All I see here is excuses. A good software engineer has to be able to
communicate freely and be confident and decisive in what they say. Asking a
question like this expresses all of these things, and being an experienced
interviewer also allows you to notice when its a little forced (when a person
is very introverted), or when they are making stuff up (thats why you ask more
specific follow up questions) etc.

I see more people having the skills but not being able to tell the story or
communicate in a meaningful way. Seems to be a huge deal with software
engineers, the communication piece is just disregarded in most cases. Thats
when you end up with engineers who are locked away in their own rooms and not
put in contact with any external stakeholders.

~~~
TheCowboy
To be a good engineer requires a number of skills. You named one. Knowing what
arbitrary conclusion a random interviewer wants to hear and will draw is not
one of those.

You can be a great communicator AND frequently not answer this question in a
way that an interviewer wants to hear. There are more excuses for bad
interview practices than anything else here.

People vastly overestimate their ability to detect lying and shouldn't rely on
that. How do you know when someone fooled you? You don't. Why risk that when
there are alternative and better methods?

Many engineers don't realize they are self-rationalizing their own interview
process without any rigorous evidence. This is the opposite of good
engineering.

------
andy_ppp
Never talk about yourself; steer the interview to being about a problem they
are solving with work and help them run through how you would solve the
problem as if it's a meeting and you are working with them. Rarely fails.

~~~
erikb
I'd say it's not either or. Do both. Give a short summary of who you are with
related projects you worked on. Explain shortly how these experiences made you
an authority on their problem. Then explain how you would handle that problem
of theirs.

------
codingdave
>In all likelihood, the interviewer doesn’t know what they are looking for
with these questions, and they are just being used to fill time.

Wait a sec -- just because the author of the article doesn't know how to get
value from those questions doesn't mean that those questions hold no value. It
is true that they won't give you information to help you in a tech screen, or
to gauge the value of where to initially place a candidate on a team. But if
you are trying to decide between a few candidates of equal skill, and trying
to figure out which one will work better in a team environment, which will fit
more smoothly into the personal dynamics between team members, who will grow
better as the company grows, who might be a better leader or follower, and
what their trajectory might be as the company and team evolves, these
questions can lead you down those paths.

Dismissing those questions as useless makes me think the author doesn't care
about the people as individuals, but just as machines to be plugged in to
produce code. And that doesn't sound like someone I would want to work for.

~~~
jakewins
It's ironic actually. The author touts told stories of prior work as key, and
degrades attempts at measuring candidate conscientiousness. Meanwhile,
strongest known measures of job performance are an actual work sample (r=.26),
rather than ability to describe a prior project, and measures of
conscientiousness (r=.15).

On conscientiousness:

Barrick, Murray R., and Michael K. Mount. "The big five personality dimensions
and job performance: a meta‐analysis." Personnel psychology 44.1 (1991): 1-26.

On work samples:

Roth, Philip L., Philip Bobko, and L. Y. N. N. McFARLAND. "A meta‐analysis of
work sample test validity: Updating and integrating some classic literature."
Personnel Psychology 58.4 (2005): 1009-1037.

------
midgetjones
I was updating my CV recently. I don't have the longest employment history
(switched careers, then stayed at a job for 5 years), so I padded it out with
a few short paragraphs of projects I'd worked on.

It actually worked really well - it brought some projects I'd forgotten about
back into my mind making it easier to talk about them, and gave the
interviewers specifics to latch on to.

~~~
bphogan
More importantly, it shows accomplishments, not job duties. And that's what
everyone wants to see - how your wins there will translate into wins here.

------
bitwize
I find I'm more willing to talk about myself if engaged in meaningful
dialogue.

For example, I get this a lot as an opening question, mainly from crooters
(actual hiring managers almost never do this): "What are your skills?"

You mean like numchuck skills, bow-hunting skills? If you don't know what kind
of skills I have that could possibly be germane to the positions I'm looking
for, you obviously didn't even read my résumé, which means you don't have a
clue, which means I am hanging up on you because obviously you can't help me.

If you say "Can you tell me about your role at company X, what sort of
challenges you had, etc." I'm more willing to open up.

------
Tharkun
Being prepared to talk is important. Knowing when to shut up is equally
important.

Recently interviewed a candidate who seemed promising, until they started to
rant. I didn't want to interrupt them because I was hoping there was a point
to be made at the end of the rant ... but in the end it was just 5+ minutes
worth of "my current job isn't fair and everything sucks and everyone who is
better than me really sucks too".

Didn't hire.

------
freshflowers
All that matters is having a good conversation and not appearing completely
incompetent.

After an enjoyable conversation, the hiring person will rationalize wanting
you all by themselves, even if they have to make up / project qualities you've
never demonstrated.

95% of the time, there's nothing rational about hiring.

------
nercht12
For younger candidates, how about questions like: "Do you have a passion for
this industry? Why?" and "What have you done in the past that demonstrates
your commitment to completing anything you set your mind to?" For older
candidates, how about questions like: "What do you consider your driving
factor?" (with possible answers like "good benefits" or "complex challenges"
or "teamwork") and "What sort of challenges do you see in this field/industry
and how would you go about solving them?" (with acceptable answers from
technical development solutions to "let's outsource" or something creative -
something that demonstrates their wisdom, even if the field isn't their
expertise).

------
kafkaesq
_What is the hardest technical problem you have run into?_

Almost always asked from companies that don't have problems to offer even
remotely comparable to the "war stories" they're expecting to you rattle off
-- at least not for the position _you 're_ applying for, anyways.

------
samlittlewood
Also, As well as words, I would recommend practising the key diagrams that
represent the projects(s) - so you leave enough space for the important
elements, and don't fall of edge of page/board.

------
southphillyman
I think behavioral and "tell me a time when" questions can easily be gamed, so
I question the effectiveness of asking them. Sometimes I forget specific
domain knowledge around a project I worked on 1+ companies ago. But I still
have to list it on my resume and thus be able to speak to it...... so I just
approximate the details. I imagine you could just full on lie as long as you
can detail a technical problem and provide a solution to it.

------
tejtm
> What is the hardest technical problem you have run into?

well technically, the hardest problems I have encountered are not technical

------
ruleabidinguser
Is this actually useful to people? Please don't give me non-answers like "well
it got upvoted.."

------
martimoose
When I read articles about job interviews, I always wonder what is the
correlation coefficient between "being good at interviews" and "being good at
doing your actual job".

------
mwcampbell
Interesting. I naively assumed that the most important part of preparing for a
developer job interview was to prepare for the coding exercises -- the
stereotypical algorithm stuff.

------
bob1122
This is incredible, thanks for sharing!

