
How to pass a programming interview (2016) - davidjnelson
https://triplebyte.com/blog/how-to-pass-a-programming-interview
======
elteto
Funny, I just went through a pre-screen assessment for one of the big ones and
it was not one but _two_ DP problems. I could have probably come up with a
slow solution using recursion and a bit more of time, but was given only 90
minutes. And I thought to myself, what exactly did they learn about _me_ after
this exercise? Absolutely nothing, except that I can't solve DP problems on
the spot. What a waste of time.

And the funny thing is, I work as an embedded developer and actually have to
look up a topic or two from CLR at least once a year for work stuff (which is
not very common). But DP? I've never needed it or used it. Why the emphasis in
it then?

It feels a lot like software interviewing is just a bunch of rain dances and
cargo culting and those that know the dance get through the hoop. I guess I'll
have to order Elements of Rain Dancing from Amazon and get to practicing.

~~~
donw
I have yet to find an interview process that works better than RPI (Rob's
Pairing Interview)[1] plus a day-in-the-life[2].

It gives both the employer and the candidate a chance to evaluate each other
in context.

As an employer, you get to see how the candidate performs on two different
real-world tasks, as well as how they interact with existing employees.

As an employee, you get to see what the company is _really_ like to work with.
No amount of whiteboarding can deliver that.

And at the end of the day, if that relationship feels good, both parties can
choose to continue onwards towards full employment.

On the other hand, computer science trivia, by which I mean "implement
Dijkstra or quicksort on a whiteboard", is a very poor means indeed by which
to test for the ability to do real-world work in a real-world context.

Sure, it's valuable to have a broad understanding of algorithms and data
structures. But whiteboard interviews on those types of problems only tests
how well you would do competing in an ACM (Association for Computing
Machinery) challenge, not how well you can deal with "here is a totally new-
to-you problem that lacks a precise solution, now work productively with a
team to solve it under the constraints of an operating business"

[1] [https://builttoadapt.io/the-developer-hiring-process-is-
brok...](https://builttoadapt.io/the-developer-hiring-process-is-
broken-672bf273c183)

[2] [https://blog.jonrshar.pe/2016/Dec/05/pivotal-
interviews.html](https://blog.jonrshar.pe/2016/Dec/05/pivotal-interviews.html)

~~~
kyberias
This is absolutely horrible.

"We believe coding is a social activity. In fact, we’re testing you to see how
social you can be around coding."

~~~
Huggernaut
It's worth understanding that Pivotal are hiring for a work environment that
is almost entirely pair-programming, with teams of 2 to 8 engineers that
rotate pairs almost every day. With that in mind, it's absolutely critical
that Pivotal consider the social side of candidates while pairing.

That makes the process less suitable for other types of working environments.

~~~
amd121
It seems to me that "programming" there means glorified devops and the primary
goal is a headcount of young compliant workers to show off to investors.

Probably activity is valued higher than progress.

They are certainly not looking for Knuth, who would likely fail the interview.

~~~
ses1984
Unless your business goal is to advance computer science research, why would
you want to hire Knuth and why would he want to work for you?

------
joeax
_They eat large sprawling problems for breakfast, but they balk at 45-min
algorithm challenges._

If a candidate can solve large, complex problems but bombs your interview, the
problem is your interview. TripleByte should focus on this problem and educate
these companies on effective interviewing techniques. For example, if your
interview overemphasizes coding challenges, puzzles, quizzes, or otherwise
feels more like being on Jeopardy than real-world applicable, you're doing it
wrong.

Candidates should be focused on their skill set and filling in gaps (i.e. I've
toyed with Python but I see it being in demand so let me get better at syntax,
packages, thinking in pythonic way).

~~~
LanguageGamer
Okay, but the problem is, 45-60 minutes is usually all hiring managers have to
assess a candidate. What can you do in that amount of time to assess someone‘s
real world performance? Having a high level conversation about technology and
problem solving approach helps but often doesn’t translate into writing code.
Tech-stack specific challenges are no good because general programming ability
is more important, you can learn a new language on the job. Algorithm puzzle
problems aren’t great because then we’re selecting for people who spend a lot
of time on hackerrank or whatever.

Maybe effective programmer hiring is just an unsolved problem.

~~~
asark
What's so friggin' different about hiring software developers that we've gotta
get all weird about it and come up with some brand new thing? What's the
hiring process like for other office workers? How about for other technical or
specialist roles that are somewhat similar to software developer? Engineers of
various sorts, maybe? Accountants? Hell, lawyers even? There's got to be some
set of existing practices that'll fit this _just fine_. It's simply not. That.
Special.

~~~
strken
My brother is a mechanical engineer, and his org hires by bringing in
graduates on a low salary, moving the competent ones to roles that make use of
their competencies, and moving the incompetent ones to roles that are pretty
much the same as unskilled technicians. Sometimes the boss meets a candidate
at a conference or over beers and fast-tracks them. They have literally no
women in the entire engineering department.

I'm not defending whiteboarding the knapsack problem so much as I'm defending
the difficulty of hiring skilled workers from different walks of life. Tech
isn't special, hiring is just hard, and a lot of other industries are actually
worse.

~~~
jmchuster
The software engineer analogue of this would be consulting. You hire everyone
out of college. Start them off at a salary such that they are still net
positive even if they only ever stay at the lowest possible billable rate. If
you get good enough to command higher rates (or the effective rate through
increasing the success rate of projects), you'll keep on getting commensurate
raises.

------
frfl
A recent experience I've had with programming screens, not whiteboard
interviews specifically, is the lack of feedback. I'm given a programming
problem (or a set of problem), given about 2 hours to do it, I do it in the
allotted time, check my code, verify to the best of my ability that what I've
come up with in the limited time is correct, I verify I'm passing the provided
test cases and some test cases I come up with. Then it's basically a coin flip
whether anyone follows up. No feedback, no reason why they're not moving
forward besides maybe some generic HR response about my qualifications or
'decided to go in another direction'. Quite annoying and a waste of time on my
end. Is this it? Is this really the best way to filter down the pool of
resumes? Feels like it's a very high false positive rate and one that pushes
all the time costs onto the applicant (multiply ~2hr by say 5 companies that
want you to do a coding challenge).

~~~
chrisseaton
I've gotten feedback, and even more frustrating than no feedback is
demonstrably false feedback.

Google said I should try contributing to an open source project to improve my
resume... when I had literally a million lines of code in a major open source
project, and that was written on my resume.

Was it a mistake? Was there a mixup and had they interviewed me thinking I was
someone else? Did they have a corrupt copy of my resume? More likely was it a
throwaway comment from someone just saying something to be polite? No idea,
but it's more frustrating than just 'no thanks' because it didn't even make
any sense.

Imagine if you tried to improve yourself based on that feedback, applied
again, and then they overlooked it again and gave you the same feedback!

~~~
frfl
I could see how this might be an issue with someone early in their career who
has a low-profile project or two, but your resume would stand out very quickly
among the rest so for this to happen is alarming.

Feels like a very similar occurrence to what happened to the homebrew dev who
got reject by google (albeit different circumstance to your false feedback)

~~~
tom_
The homebrew guy was subsequently hired by Apple, but later left, saying in a
(now deleted) tweet that big company life wasn't his bag. Link from around
that time:
[https://news.ycombinator.com/item?id=12276219](https://news.ycombinator.com/item?id=12276219)

There's a non-zero chance that the Google interviewers were able to pick up on
this. Those of us not directly involved only ever got one side of this
particular story.

------
aphextron
The best part about these types of interviews is how they don't even treat you
like a human being. There's absolutely zero interest in you whatsoever, and
moreso every single word that comes out of your mouth is by default treated as
a lie until they've had you submit to their Leetcode questions and determined
you to be worthy of even speaking to. It's why I've become so incredulous at
even being asked anything in the first round; anything I have to say here is
completely meaningless and has no bearing whatsoever on any kind of hiring
decision until that test has been passed. The utterly degrading inhumanity of
this process had driven me to an emotional breaking point until I started
interviewing outside the bay area. And what do you know? It's a completely
different world. To anyone else stuck in this nightmare, just leave. Another
20% take home pay is simply not worth your sanity.

~~~
frfl
When you say outside the bay area, do you also mean companies are not 'tech-
first' type companies? (companies that hire devs, but their primary domain is
not just some app/website/saas) I've applied to many jobs in Canada, but I've
still noticed a large tendency for companies to put you through a screen even
before they speak to you.

------
_robbywashere
I like to imagine the movie trailer voice over guy

“Do you have what it takes?”

“Do think you’re tough enough!?”

“You call yourself a....”

“PROGRAMMER?”

“Then... SORT... MY... LIST... WHILE... TALKING... OUT... LOUD”

But really, I feel like the whole process is uniquely American, kind of like
crossfit. Very intense very trying. Like Nike; “JUST DO IT!”

The problem about this very intense “game” of interviewing is it’s for a job,
for you to eat, to afford healthcare, to survive. To afford basic necessities
and save for retirement. To buy a house. To start a family. To afford a car.
Or even simply to not be just another body stepped over on Market street.

You've probably enjoyed 7 some years as a web developer, as a productive team
member or consulting for happy clients. Now some stranger is dangling a carrot
in front of your face telling you to implement an LRU cache under bright
fluorescent lights while badgering you with “what are you thinking, I need to
know what you’re thinking” ... after you’ve just spent the last 5 hours
talking about your work history etc

------
fma
#1 on that list is enthusiasm for the company. Really...? So, you gotta be a
good bullsh!tter? I can see this for small startups, because passion will take
you to places. But for large companies, their software products are so
diverse.

I work for a manufacturing company and my application space has nothing to do
with manufacturing. Every space has their challenges and pitfalls. As long as
you have good tech, good people, and aren't doing anything unethical, I'll
want to work for you.

Also, I've thought about the interviewing problem a bit. I don't do the
interview for my team...but if I have the opportunity to interview and was
given free range, I think I would create a small application using our tech
stack. Put some bugs in there, put some bad practices, and let the interviewee
fix it. Talk about the tech stack, how to scale it, design trade offs, etc.
IMHO reading code and maintaining code is more important than knowing bfs and
dfs by heart.

~~~
rayvy
This is a decent start, but then again remember you only have 60 minutes. And
what might seem relatively easy to you, might not be so easy to someone with a
time limit (60 mins), and pressure (trying to get a job you want).

------
daxfohl
I'd say rather than practicing interview questions, work on a side project
that really stretches your technical ability. And a _hard_ project, something
that you don't even know where to start, not just "I'm going to rewrite this
todo app in vue.js". I think that gives your brain more of a workout than
droning through interview questions day after day. Even though you could say
"you don't run marathons to practice for a sprint", just in my experience it
works better. The interview practice websites are too easy to get distracted
from, or look up the answer, or whatever, and your brain really doesn't get
the workout that a solid long-term low level project gives it.

Plus, at the end, at least you have a project you've done.

~~~
kyleblarson
[https://twitter.com/mxcl/status/608682016205344768?lang=en](https://twitter.com/mxcl/status/608682016205344768?lang=en)

~~~
daxfohl
Yeah that occurred to me just after I submitted the post. I'll still stand by
my own experience though. I felt so much more prepared on this latest round of
interviews after having worked on a type inference engine side project for the
previous couple months, than I ever did after spending a couple months
stressing over leet. Just, brain felt stronger for whatever reason.

And I think it makes sense too. When I conduct interviews, I look more for how
is this person thinking about the problem, than can they solve the question in
isolation in the allotted time. Because unlike leet, it's _not_ in isolation.
There's always some back and forth, and that's where I think leet's
shallowness shows.

------
balls187
> To do well in an interview, then, you need to be able to solve small
> problems quickly, under duress, while explaining your thoughts clearly.

The under duress part is the dumbest part of coding interviews.

I understand the approximation of small coding challenges, why explaining your
thoughts is beneficial, as is understanding how a candidate approachs problem
solving.

Causing duress to a candidate purposefully has no value what-so-ever in the
workplace.

~~~
bootlooped
I think the interview process itself causes duress to candidates
intrinsically. There is probably no way to eliminate it completely.

That said, there probably is a reason for testing candidates under duress.
Some companies may want to push people hard, and knowing they can deal with
stress is valuable.

~~~
balls187
I don't agree that programming interviews are conducted to see how well
candidates will fare in a dysfunctional workplace.

Anecdotally, programmers thrive in quiet environments where they can have
focused uninterrupted time. As open-offices have become the norm, most
programmers have headphones they use to isolate background sounds.

Constantly peppering candidates with questions while they are trying to do a
task that is mentally intensive is not close to the type of stress candidates
face on the job.

Even the most work-life balanced places do these same types of interviews.

------
jonaf
PSA: if you take TripleByte's online quiz, they don't have the capability of
giving you the results of the quiz. At least, that's what I was told when I
took the online quiz -- they couldn't share the results with me because the
quiz is "adaptive" and scores and questions vary each time the quiz is taken.
(I have no idea how they're able to do anything useful with the quiz results
if they don't record them and the scores vary so greatly.)

I have no faith in TripleByte or their process at this point, especially since
I feel I was somewhat taken advantage of (I did the online quiz expecting to
get some feedback -- isn't that the point?). I'm certain they will use the
collected data from my quiz to build their product, though.

~~~
bootlooped
I did it within the last week and got scored in 6 areas. It's just a whole
number out of 5 points in each area, no further info.

I did the 2hr phone interview later and received my interviewer's notes on my
performance, which were more detailed and helpful.

------
tickthokk
> These are concepts that are far more common in interviews than they are in
> production web programming

So of course let's talk about a dozen different types of them!

Welcome to Ford! To be considered for this position, please list every GM
Model from 1983 to 1987.

------
Mc91
The last good paying work I had I somehow passed the coding interview, but I
bombed out of the last few I had and went back to basics. I signed up to
Project Euler and Hacker Rank and have been doing problems from them.

What I do is start the Linux program "recordmydesktop", and then go about
solving the problem as if I am interviewing, i.e. on the clock.

One thing I noticed is these programs use maps, characters, use 64 bit long
numbers, do string manipulation, do certain type conversions and so on more
than I usually do programming. Some of these things I would usually look up,
such as how to type convert a character '7' to an integer, or create and
populate a multi-array and things like that. So I made sure how to memorize
how to do these test-tending things.

Then I watched over my recordmydesktop sessions to see where I ran into
trouble. I noticed array one-offs were a problem - getting an index out of
bound error, using < instead of <= etc. Or I would declare a variable before a
loop and use it initially, but forget to assign or reset it at the end of the
loop when it needed that. Sometimes I would declare a variable like k and then
re-use it in the same method. Also, if I ever have to switch to a web browser
to look up what call does a string reversal, I note that as well, and if it is
common enough, I memorize how it is done so I don't have to look it up again.

Memorizing the string manipulation, map etc. functions is already working for
me. I am getting better at some of the other problems, like not
assigning/resetting variables at the end of loops (I put a comment next to
them that they will need to be assigned/reset, and then do it later, and then
erase the comment). Some I still have to work on, like reasoning about exactly
where the array boundary is. These aren't things I mess up necessarily, but
things that slow me down, and cause bad compiles or runtime errors.

I can already see the improvement in the problems I am doing. I had been
letting myself naturally memorize some of these things, I guess it's not so
bad that I am memorizing more of them that I may need.

------
acconrad
For anyone interested, I took notes on _The Algorithm Design Manual_ for
JavaScript if you are studying chapters 3 through 5 like the blog post
suggested:

[https://userinterfacing.com/tag/algorithms](https://userinterfacing.com/tag/algorithms)

~~~
rhizome
Thank you!

------
dang
Big discussion at the time:
[https://news.ycombinator.com/item?id=11246917](https://news.ycombinator.com/item?id=11246917).

------
Adamantcheese
Is it just me, or does this read like a massive farce? That everything that
Triplebyte is trying to solve they just... can't?

------
mgkimsal
I just went through a small exercise with a company ... we did an hour
screensharing on coderpad.

basic exercise was in php (mix of systems, but there's existing php to touch).
financial service industry, and they'd mocked up a rough idea of a typical
problem. The example code _clearly_ wasn't production, and was generic, but
also illustrated the problem domain well enough for them to get an idea of how
well I could adapt.

I got through the 'nut' of the problem in about 10-15 minutes, talking through
some issues. One thing I'd ignored (and said I'd be ignoring) was date
handling - they wanted some date sorting thing, but since this was just 'raw'
code without any good helper libraries, I suggested we punt on that (and I
named the libraries I'd typically use for date handling).

There was one spot where the interviewer suggested the ?? 'newer' null
coalescing, where I'd been looking at doing some 'array_key_exists' checking.
he'd suggested that the ?? syntax was easier and more compact, and I'd
countered with I'd prefer to be more explicit about the specific keys I wanted
to check for, and that ideally I'd be using a class or some other more defined
structure to ensure some degree of valid data shape as a first level of sanity
checking. I'd felt I may have pushed back a bit hard on that point, but, we
moved on.

After the first 15 min or so, we'd spent another 15-20 talking about different
ways to do other types of error handling, some potential performance issues,
etc. High level stuff, mainly, which... there's only so much you can do with
coderpad (my jetbrains and vim muscle memory did me no good in the browser!)

All in all, though, I'd felt it was a decent exchange. They were able to show
a 'real' problem without relying on any proprietary stuff, it was difficult
enough that someone junior probably would have struggled a bit more, the guy
on the other end was pleasant, and engaged appropriately (responded to
questions and casual banter, and interjected now and then to ask questions and
give feedback in real time). It was probably one of the better 'tech
interviews' I've had (although I haven't had many in recent years, so, hard to
compare). It did seem better than many I read about, and certainly better than
some from 10-15 years ago.

~~~
akanet
I'm the CoderPad guy dropping in to mention you can switch to vi keybindings
in CoderPad settings!

~~~
mgkimsal
Thanks. I didn't see that up front, and was more concerned about the timed
aspect of our meeting/review, but I'll keep it in mind. Thanks for the tool!

------
magnetic
(I think I made a similar comment to a similar submission a while back)

I suggest this type of interview:

Both the interviewer and interviewee get a problem to solve and they work
_together_ to solve it. It should be new to both of them, so the interviewer
can better assess its level of difficulty without the bias of knowing the
solution beforehand. This will enable natural empathy for the candidate.

It also shows how interaction would look like in every day kind of work. You
can learn a lot about another person's skill by doing pair programming.

Logistically speaking, you can whiteboard the design/code, or sit around a big
screen for the coding part, with whatever tools/IDE the candidate likes to use
(s/he should be writing most of the code, even if the solution/design was a
common process).

------
randompi
It's a programming "test" right? Sometimes I wonder if it's better to solve
the problem in isolation, to show that I can sit on a problem and go at it, or
to solve it in a collaborative manner with the interviewer, to show I'd play
well in a team.

Sometimes when I read people saying the end goal is not to solve the problem
weird. Does that mean those who solved the problem alone by losing a few hairs
actually scored worse than an outspoken candidate who solved it with help from
the interviewer?

~~~
viraptor
You can ask them what they prefer. Also, communication is an important element
- in real work you may be spending time on something that's already obvious to
someone else, or getting stuck on an approach which is known to not work.

I think actually solving those problems or failing in the end is random
(unless you know the answer already). But if you get a good chat out of it, it
may be in your favour.

------
royosherove
I came up with my own set of questions that hopefully show how a person can
deal with human complexity at work (the bulk of our issues), rather than
memorizing algorithms. Some people don't like it - but it works for me:
[https://www.5whys.com/articles/a-realistic-hackerrank-
develo...](https://www.5whys.com/articles/a-realistic-hackerrank-developer-
interview-question-list.html)

------
wodenokoto
I recently came across some videos from Interview.io, which seems to be in the
same business as triplebyte, the company behind TFA.

I thought the interview seemed quite nice. Is this the type of coding
interviews, HN is always complaining about, or is it some rosy best-case
exhibition?

Example interview:
[https://youtu.be/tj_sBZw9nS0](https://youtu.be/tj_sBZw9nS0)

------
manish_gill
> Mentioning other offers in an interview heavily biases the interviewer in
> your favor.

Is this really true? Also, how do you just mention offers? And will the
programmer interviewing me really care? Should this only be done at the HR
stage?

Like, what's a good way to let the other person know that they're not the only
one.

------
akhilcacharya
Is there any evidence that coding interviews aren’t just tests for 1) general
fluid intelligence or 2) memorization?

------
crb002
Triplebyte/HackerRank etc is a great filter for companies that view their
developers so low they would subject them to such pre-employment screens that
no other employees in the organization must jump through.

~~~
iratewizard
I took their test once for fun once a few years ago. A few months ago they
suddenly added me to their "newsletter". Every week I would unsubscribe and
the next week I would receive their spam like clockwork. I complained that
they need to fix the unsubscribe link. Two months later some hapless customer
support person gave me a very informative email about clicking the unsubscribe
link at the bottom of their emails.

Not a company that has things together to say the least.

~~~
ttsda
Same experience here, did their challenge once, only feedback they will give
you about your performance is something like "exceptional" and then they keep
spamming you every day even if you said in the questionnaire you aren't
interested in a new job.

------
basementcat
<irrelevant comment deleted>

~~~
znpy
you probably wanted to comment on
[https://news.ycombinator.com/item?id=19344146](https://news.ycombinator.com/item?id=19344146)

------
expopinions
The key to success in any interview, but especially in a programming
interview, is practicing as much as possible. It's not enough to start just a
few days before the real thing. The best method of preparing is incorporating
your interview prep into your everyday coding practice, so that you'll never
fall behind, even if you aren't currently searching for a job. But the plan
"to practice" is too vague and leaves a lot of programmers unsure of how to
get started in the process, which can be overwhelming. If you're frustrated
and aren't sure how to get going on your coding interview practice, follow
these steps to get started.

1\. Review the basics. Even experienced programmers and engineers can get
tripped up when questions about algorithms and data structure come up. If you
haven't yet mastered the basics, focus on this for a few weeks or months to
get yourself ready to tackle the bigger problems. It's crucial, not only for a
coding interview, but for the entirety of your professional career, that you
understand the basics. They are your foundational skills upon which you will
build and master your expertise.

2\. Solve coding problems and work on projects. Online coding practice
problems are a great place to start. Apply your knowledge and work on projects
you enjoy. Write code. Build things. Put your skills to use. This should be
the fun part - if you aren't enjoying the journey and the process of building
your coding skills, you'll have a difficult career as a programmer. Sure,
there will be moments of frustration where you'll want to smash your computer
screen and throw your mouse at the wall. But forge on. Keep trying. Find those
bugs and destroy them. Build great things, and immerse yourself in online
forums and other communities where you can turn to for help when you really
get stuck.

3\. Use online coding interview platforms for practice. This is a great way to
get exposure to how the real coding interview will feel. Smash your nerves and
anxiety by conducting a full coding interview with a partner. On platforms
like Pramp and Leetcode, you'll get paired with another programmer of a
similar skill level, so it will scale to your ability. Together you'll
experience the coding interview from both perspectives. Performing the role of
the interviewer and the interviewee will teach you a lot. After the mock run,
you'll both leave each other feedback, and this is a great thing to have to
tailor your practice schedule and for identifying what you need to work on the
most.

