
Coding Interview Cheatsheet - yangshun
https://github.com/yangshun/tech-interview-handbook/blob/master/preparing/cheatsheet.md
======
sethammons
As far as a general behavior checklist, this one is fairly accurate in my
interviewer experience. It is surprising how often candidates do many of the
"Don'ts" in the list.

In the end, I'm looking for candidates I can see myself working with. If we
were to pair up on a task or project, I want to be reasonably sure I'm not
going to dread the event; I should look forward to it.

One example was a candidate from one of the Big 4. He was having trouble in
Java (his preferred language) handling 400 and 500 level errors in an HTTP
request that was part of the interview problem. I told him at the beginning
that he can use whatever resources he wants, etc. I also told him that I am
not a Java person but would help him where I could (we are not a Java shop).
While he was reading documentation, I googled how to handle the errors, and
said something along the lines of, "it looks like you should be able to do
such-n-such with whatever class's method." He just said, "no." A few minutes
later, still stuck, I suggested that he give it a try. "That's not how that
works." We had to eventually skip the error handling to get back on track.

What I got out of that part of our interaction was that he wouldn't likely be
pleasant to work with. He could have said why my proposal would not work or
anything beyond simply dismissing my attempt to help. I got the distinct
feeling of, "this guy is kind of a jerk." He was applying for a senior
developer position. Part of that role would be mentorship and leveling up your
team (this was explained early on in the process, before the on site). With
our limited time together, he did not convey anything of the sort.

Post interview, he mentioned to our interview organizer / in-house recruiter
that it was apparent I did not understand Java development. Post interview, I
also took his submitted code and implemented my suggestion and it worked.

In short, I think much of the post's checklist is accurate. Behavior during an
interview counts. It is not just technical aptitude.

~~~
izacus
I wonder if that's the reason why he wasn't at one of the big 4 anymore :)

~~~
cema
But he did end up there somehow in there first place. What was his interview
them like, I wonder?

------
kevmo314
> Defensive coding. Check for nulls, empty collections, etc.

While this is important to avoid bugs in your algorithm, I've had candidates
who spent way too long on this and it comes across as inexperienced. I don't
really care that you know how to check null-ness, if you just mention "assume
the parameter is not null", it's more than sufficient to me.

~~~
munchor
Which is why the best thing is to ask. I always tell my candidates that the
most important thing is how they approach the problem and not how careful they
are with their coding. However, if the interviewer doesn't explain that, the
best thing is not to do "Defensive Coding" as per the linked article, but
instead to _ask_.

~~~
eradicatethots
I think it’s be better if interviewers and interviewees wrote code like they
would in the job - no excessive commenting/checking ... just write effective,
clean concise code and minimize time wasted

In reality it might be risky to do this, but I’d like to see that change.

------
reddit_clone
I would rather coding interviews went like this.

Give the candidates a non-trivial problem, which might take a few days to
complete. Everything documented and checked into github. Call them for
interviews and review design/code with them. Make sure it was not all copy-
pasta and someone else didn't write it for them.

To make sure of that, introduce a slight variation in spec and ask them to do
it on the spot.

This way, you get to review their entire development process, How they
approach problems, code quality, unit tests, code performance , usage of
source control system, CI/CD usage etc. At this point you will know for sure
if you want them or not (They might also know they want to work for you or not
.. :-). )

~~~
lithos
Sounds like a great way to filter people who have other responsibilities, or
are an attractive enough candidate to be busy interviewing for other firms.

~~~
darth_mastah
Absolutely. I second that. I would be willing to spend a couple of hours on an
interview task, which could give the interviewer an idea about my skills, but
more than that I would see as an overkill. Besides, in my view, showing some
OS repos on GitHub can be a good alternative.

------
tzhenghao
A couple small touches that have helped me power through these interviews:

\- Food intake prior to the interview. If I get phone interviews later in the
day, especially after lunch, I avoid eating heavy and greasy food that can put
me in a food coma. It has negatively impacted my performance in a couple of
interviews back during my college days. Controlling my caffeine consumption
before an interview helps too. I had a pretty bad "crash" in one of my
onsites.

\- If I'm expected to do puzzle questions, it's best for me to warm up 45 mins
before the interview just to get my mind in a problem solving state.

------
theprotocol
>Stay calm and composed.

Ironically, reading this makes me hyperaware.

>Sound enthusiastic! Speak with a smile and you will naturally sound more
engaging.

In my experience, some people force this and it comes off a bit creepy. I've
had better luck not thinking about this.

IMHO don't treat the social side the same way you treat the technical side
(i.e. preparation similar to homework). The social side should not be overly
deliberate. Don't overthink it, just be polite.

~~~
heidar
You're right, I feel like a lot of stuff on this list will just cause
overthinking. Just be yourself, don't be weird.

------
everdimension
Isn't all this just common sense? It basically says "be a nice person to
communicate with". But split up into a huge table of checks and crosses.

~~~
arielm
Yes, but you’d be surprised how many candidates either get too nervous or are
too shy to do most of these.

Phone interviews are hard to begin with but you also have a lot of flexibility
so it’s less stressful, but in-person interviews with real programming on a
computer can put many into a really stressed state.

------
nsxwolf
Should add: spend effort making lots of industry friends and contacts. Tell
them you’re looking for a job. Skip coding interview.

~~~
nojvek
Coding interview is a very elemental part. You can deffo skip phone interview.

------
stablemap
This document is new but here’s a discussion of the repo from a couple weeks
ago:

[https://news.ycombinator.com/item?id=15341566](https://news.ycombinator.com/item?id=15341566)

------
arielm
We do a lot of technical interviews and have seen enough candidates skip on
many of these, so in that respect I like that there is a list they can
reference. However, doing for the sake of following a list can come off as
inexperienced/dishonest (or creepy, like one of the comments suggested).

Having seen those first hand as well I can tell you I really dislike such
interviews and that they always make me and whoever else is interviewing with
me uncomfortable.

My advice is to go through this list and reflect on your last interview. What
did you do, what didn’t you do, why? And try to practice some of the things
you didn’t.

Also, keep in mind some of these are double edged swords. Example, speaking
with enthusiasm. Don’t do it at all and you’ll be boring everyone, but do it
too much and you’ll look like you can’t concentrate.

Practice makes perfect, so work on it.

------
munchor
One thing that's missing here is video camera feed. As an interviewer, I don't
turn on my webcam and I don't expect the candidate to do it (although they can
if they want to). However, I've heard different people have different opinions
on this. It's definitely something that could go on this list for phone
interviews.

Of course, intra-US interviews are usually done over the phone but when the
interviews are across countries, tools such as Google Hangouts are normally
used.

~~~
codingvelocity
This seems quite odd to me. I work with people remotely and on site, and it's
amazing how much better communication is when both parties turn their webcam
on. Body language conveys things that tone, and words don't

~~~
tome
> communication is when both parties turn their webcam on

Not least because the individuals concerned can't goof off doing something
else at the same time.

------
cpsharp
Probabaly the most concise list of useful tips I've seen since I started
interviewing at the big four. Yes to all.

------
pavlov
I can’t think of any other field where highly paid adult professionals
willingly submit to interviews that treat them like autistic 15-year-olds.
Makes sense for the companies, of course.

~~~
ekidd
I've interviewed a fair number of programmers over the years. There's a
surprising number of people who interview well and who have good resumes, but
who can't actually code. (By "can't code", I mean, "Can't sum an array of
numbers in their favorite programming language.") And checking references is
hit-or-miss in the US, where many employers will only confirm title and dates
of employment.

I know of three possible ways to evaluate coding ability:

1\. Ask coding questions in interviews. This is biased against people with
performance anxiety.

2\. Give people take-home "work samples". This uses up more of a candidate's
time, and it may filter out high performers with multiple offers. Plus, if you
give anything that takes more than a few hours, it really ought to be paid.

3\. Ask for a GitHub profile with open source contributions. This is biased
against people who leave work at work, or whose previous employers don't
contribute to open source projects.

It's been a few years since I last interviewed candidates, but if I were
designing the interview process, I'd probably want at least one of the above
before hiring a candidate. Maybe the candidate could choose? "If you have
public open source contributions, please submit a link and a description. If
you don't, no worries! We'll can do a coding test instead."

~~~
mrfusion
Why not let candidates choose between 1,2 and 3?

~~~
UncleMeat
Because then it is hard to have a consistent and fair method of judging
candidates.

~~~
mrfusion
Seems like you can’t compare even if you stick to one method. Some people have
performance anxiety or social anxiety and can’t do 1. Others thrive on 1.

~~~
eradicatethots
You might want to filter out those people.

------
raisyer
"Ask about your interview performance. It can get awkward." Maybe it's just
me, but I always find that to ask for/give feedback is better(if asked), as
recruiters almost never respond if you have not cleared the round and if there
is opportunity to give feedback so that candidate has an idea on what to work
on.

Also I have found that when asking for feedback, it can lead to interesting
discussions which might make the interviewer change his/her mind.

This of course is personal preference...

~~~
gregmac
One of the problems is you are not likely to get truly honest feedback. That
opens things up to dispute, and that puts the interviewer in an awkward
position: if they cannot articulate a point properly, even if valid, the
interviewee is left feeling they should have "passed". In the worst case, they
could claim the interviewer was prejudiced against them and file a labor
dispute or lawsuit.

It's also often highly subjective, for example:

"I don't think you demonstrated the depth of knowledge in (technology x) we're
looking for in this position"

"Well I've developed several applications that work, so clearly I do know it"

What you can do along the way is ask questions like "Would you like me to
elaborate on that?" or "did I answer your question adequately?" if you get the
sense you may not have. For code, the list on the page is actually decent -
ask up front about the assumptions, how much you should focus on defensive
coding, etc.

------
raverbashing
> There were times I had to restart Chrome to get Hangouts to work again.

Yes, this seems to be a generalized problem

------
paulus_magnus2
This fixes the wrong problem. Has anyone seen a whiteboard managing interview
for IT managers?

------
watwut
> Immediately announce that you are done coding.

Why?

~~~
Fargren
Because if you immediately announce that you are done coding, you cannot do
any of the other things on the list, which are all good ideas. After you've
done them all, you should announce you are ready. It's probably a good idea to
tell the interviewer what you are doing, don't just stand there looking at
your code in silence if you can avoid it.

