
How to Pass a Programming Interview - runesoerensen
http://blog.triplebyte.com/how-to-pass-a-programming-interview
======
quanticle

        Being a good programmer has a surprisingly small role in passing programming 
        interviews.
    

And that just says it all, doesn't it? I agree that interviews should test
candidates on certain basic skills, including (time/space) complexity
analysis. But do you really learn anything by asking the candidate if they can
recite the time complexity of a moving window average algorithm (as I was
asked to do by an interviewer yesterday)? What does the candidate's ability to
code a palindrome checker that can handle punctuation and spaces tell you
about their ability to deliver robust, maintainable code?

I don't have the answer, but I just don't see how the questions typically
asked in programming interviews give you a good picture of the candidate's
actual programming ability. I much prefer "homework" projects, even if they
involve me working "for free", because I feel like they ask for actual
programming skills rather than the "guess the algorithm" lottery of phone
screens and whiteboard coding.

~~~
digler999
> including (time/space) complexity analysis.

I think this is one of the most inane things to be asked during an interview.
personally, I've never found myself in a situation where I truly _needed_ to
choose between a vector/map/list/hashmap. Or had to find the O(x^n) and
replace it with O(x^2)

Obviously it depends on the application, but many jobs are simply maintenance
coding: find bug, fix bug, test fix. Often times it makes absolutely no
difference whether you use a list or a vector, or else you'll get the
paradoxical "vector-is-always-faster" because of locality of reference.

In my (admittedly limited ) experience, most of the effort is spent simply
making it _work_ , not being bogged down because you used a map instead of a
hashmap, or didn't know about some esoteric, bleeding-edge probabilistic data
structure.

~~~
jerf
"Or had to find the O(x^n) and replace it with O(x^2)"

The other thing that really seals the deal for me as an inferior interview
question is that you don't need to have a clue what O(x^n) is to wrap some
code in a simple time call, see that the code you think ought to run in
microseconds is running in seconds, by visual inspection notice stupid nested
loops, and fix it. Self-taught programmers may not be able to say "O of exx to
the enn" but that doesn't stop them from fixing it.

So... seriously, what good is the question anyhow?

~~~
JupiterMoon
I would recommend going through some undergrad CS datastructures and
algorithms lectures to any self taught programmer. My process of reading code
improved dramatically. And the big O concept is, once you wrap your head
around it, an intuitive way to think about speed. Also once you've timed your
code and found the slow bits you need to know how to speed it up, not all
speed ups are as simple as unnesting loops.

~~~
vpeters25
Same here. last week I was sent a Codility test, tried the demo and failed
miserably.

Then I noticed the test was expressing constraints using time/space
complexity, concepts I was completely unaware about for my previous 15+ years
in the profession.

So now I am reading about algorithm theory face-palming at the realization I
have reinvented the wheel many times during my career instead of just re-using
a PhD. researched algorithm.

------
staunch
> _candidates who have worked at a top company or studied at a top school go
> on to pass interviews at a 30% higher rate than programmers who don’t have
> these credentials (for a given level of performance on our credential-blind
> screen)._

Welcome to Silicon Valley meritocracy.

And it's much worse for founders seeking investment, where there are no hard
skills to test at all. It's almost purely about being the same class as the
investor.

Which is why you get only upper class people funding upper class people, which
then hire upper class people. The 99% only makes it in because there aren't
actually very many qualified people among the "elite".

From
[http://paulgraham.com/colleges.html](http://paulgraham.com/colleges.html)

> _We 'd interview people from MIT or Harvard or Stanford and sometimes find
> ourselves thinking: they must be smarter than they seem._

~~~
akhilcacharya
Gotta say, this is incredibly discouraging for someone like me.

~~~
staunch
On the positive side, no one can stop you from making lots of money using the
internet. And if you have something that really takes off, those same
investors will line up at your door.

~~~
akhilcacharya
Right, but it's still discouraging to be forever branded a "2nd tier
engineer/human/etc" because of where I went to school (unless I get into a
good grad school).

~~~
gaius
5 years into your career no-one normal cares where you went to school.

------
bshlgrs
Another tip which I give: Interviewers vary widely in how much they care about
whether your syntax is accurate, whether you handle invalid inputs, and
whether you write unit tests. It's really useful to ask the interviewer
whether they want you to worry about those things.

If you handle invalid inputs for an interviewer who doesn't care about that,
they're going to be a little annoyed by you going more slowly than needed. If
you don't handle invalid inputs for an interviewer who _does_ care, then
they'll think you're careless.

~~~
alistairSH
Is there any reason an interviewer _should_ care about syntax, etc?

When I interview, I ask for psuedocode - I don't really care what language the
interviewee uses, I do care that they can get their point across.

~~~
ionforce
I've had people interview claiming to know X and then not code in X correctly.
So... that's a red flag.

We allow interviewees to pick their strongest language. But if you end up
picking something that doesn't exist, well, you aren't earning yourself any
points.

~~~
nilkn
> But if you end up picking something that doesn't exist, well, you aren't
> earning yourself any points.

I don't know about your personal interviews, but I'd find this reasoning
slightly strange if I were being asked to write computer code on a whiteboard.
I'd find it much less strange if I were actually handed a laptop to write a
functioning program on.

Expecting perfectly correct code on a whiteboard seems to me to be a slight
abuse of the medium. Whiteboards and chalkboards specifically exist to sketch
things out in an adhoc fashion, often in a collaborative and easy-to-edit way.

~~~
flurgl123
I don't think he meant perfect code. But I've had candidates claim their main
language is Java, but were unable to write a proper for loop or know basic
data types like arrays or ArrayLists. I've met such people with PhDs and
impressive CVs.

Interview enough people and you'll encounter some that are very convincing
until you dig down into details. So you have to dig into details.

------
methodover
Interesting article.

For a while, we had a non-typical interview strategy: A take-home project. We
would give the candidate a week or so to work on a smallish project, the
requirements of which we would specify. After they completed the project, we
would do a group walkthrough with them.

We've hired five engineers over the last three years. For the first two, we
did the take-home project. But, then I started to wonder a bit about if it was
reasonable to ask programmers to work a weekend on a project. There were a
bunch of persuasive comments in HN threads on the subject saying it was unfair
-- a job seeker would have to spend an incredible amount of time on each
application. And one candidate that I really liked aborted the interview
process once I told him about the take-home test.

So I changed the process to something much more typical, with live, in-person
coding exercises. We hired three more engineers under this system.

So, how did they compare? Well, the engineers hired when we were doing take
home projects have worked out INCREDIBLY well. They are independent and very
resourceful. They are excellent.

The engineers hired under the more typical system have not done well at all.
We had to let go of two of them, after months of coaching, and the third isn't
doing that well.

Random chance plays a huge role here, I'm sure. Maybe we just got lucky with
the take-home project engineers. But personally, I think it makes a lot more
sense to have the interview process match the work. /shrug

~~~
dclowd9901
Right there with you; we do take home tests. It's all about the expectation.
We outline out front what we're looking for (logical code separation, FP-
inspired, sound code), and what would be nice to see (testing etc.)

Mostly, we want to see how well the developer can explain their decisions
throughout the process. Maybe they made a shitty decision. If they know it,
and explain why it was shitty, that's a pass.

When I joined the company, the exercise took me about 3-4 hours. I don't think
that's a ton to ask, especially if you make the onsite interview less
intensive (which we do).

------
osagatisop
I really wish that at some point during my CS education I would have realized
how typical programming interviews worked and just how impossible they are for
me. None of my internships had this sort of stuff and after a long string of
failures interviewing after graduating, I can openly admit that being able to
solve algorithm stuff just isn't in my blood.

It doesn't matter how many books I read or questions I practice, I just can't
work these kinds of problems. If I had an inkling of what it was like
beforehand, I would have switched majors or dropped out. Half a decade of hard
work, tens of thousands for tuition and a useless degree at the end.

I don't know whether to laugh, cry or jump off a cliff. Maybe all three.

~~~
hire_charts
One thing that helped me was to actually implement things that made use of the
"algorithm stuff." Not just practicing in front of a whiteboard, but real
executable code!

In particular, anything involving a Tree was never very intuitive until I
tried implementing a script to search for files by name. Suddenly both the
recursive and the iterative approaches made sense. I understood the trade-offs
because they applied directly to my work. That opened the door for more
complex algorithms, like a Huffman Coder (which I wrote in C, as part of a CS
class).

The other thing that helps me in interviews is to just talk through everything
I am thinking. It feels like I'm stating the obvious over and over, but a good
interviewer will be able to follow your thought patterns and help you along
when you get stuck. Also it just helps to hear yourself say things outloud
sometimes. If you just stand there silently decoding a problem in your head,
the interviewer can't help you and has no idea how you'd approach a real
problem on the job.

~~~
Smudge
> actually implement things that made use of the "algorithm stuff."

Part of the problem is that the overlap between "concepts used in technical
interviews" and "practical things I would actually implement" is very small.
So to take your approach, I'd have to go out of my way to implement something
that, in the end, would have no utility to me.

Granted, there are developers out there who do take on really technical
projects for fun. It seems like every language has at least one implementation
of the GNU `coreutils`, which I'm sure requires at least some algorithm
expertise. And there are, of course, jobs where the technical is really
important (systems-level, research divisions, etc).

But for the most part, the types of interview questions they ask in no way
correspond to the actual on-the-job requirements. I find it strange how common
it is to interview web developers (or, engineers whose job will effectively be
web development) as if they are C programmers.

------
BinaryIdiot
> This situation is not ideal. Preparing for interviews is work, and forcing
> programmers to learn skills other than building great software wastes
> everyone’s time. Companies should improve their interview processes to be
> less biased by academic CS, memorized facts, and rehearsed interview
> processes. This is what we’re doing at Triplebyte.

Thank you! This is a good write up and just like it concludes it's far from
ideal.

I'd love to see more interviews based on real-world type things like maybe
code a project, come in and explain the architecture, reasons for your data
structures, performance questions, etc. Shows how you code and communicate and
even better: work with others and maybe walk someone through extending your
project or something similar.

Honestly though my biggest issue with interviews is the lack of response with
a negative result. For instance one of my last interviews I spent literally
months with the company interviewing on and off on the phone and in person. I
never heard a SINGLE negative thing from anyone, always answered every
question correctly, shot the shit with many of them and everything seemed
perfect. Even the team lead asked me not to go after something else because he
wanted me. Then I was ultimately declined with the only reason given was "lack
of experience". But I had over 12 years of experience, all of the interviewers
told me I went above and beyond, said they agreed and liked the solutions I
came up with, that I talked through them well, etc etc. I was never able to
get anything else out of that.

If something is wrong with a candidate and they don't fit that's perfectly
fine. But please give them accurate and detailed feedback where possible. This
leaves me absolutely nothing helpful and instead of possibly improving on
something I'm left thinking they made a mistake or everyone just simply lied
to me during the entire process. I was even exchanging some texts and emails
with the lead up until I was given the negative result and then nothing.

~~~
cema

      Honestly though my biggest issue with interviews is
      the lack of response with a negative result.
    

Exactly mine too. However:

    
    
      If something is wrong with a candidate and they don't fit that's perfectly fine.
      But please give them accurate and detailed feedback where possible.
    

Detailed feedback is hardly ever possible. Not only because of a fear of
litigation (which is a big factor too) but also because the hiring decision is
a matter of balancing so many different points.

~~~
BinaryIdiot
> Detailed feedback is hardly ever possible. Not only because of a fear of
> litigation (which is a big factor too) but also because the hiring decision
> is a matter of balancing so many different points.

You're right but if a candidate is going to spend hours or days working with
your company I think it's the least they deserve. If there is a legitimate
reason for not hiring them I'd like to think litigation would be rare.

I mean when you work with a sales guy to buy something and ultimately don't
buy you usually tell them why especially if you've been working with them for
days. The inverse is true as well if you decide not to sell a product to
someone. It just seems weird to me that a person can spend so much time with a
company and possibly not even get a good learning experience out of it (when
you're left with the impression that everything went as smooth as
statistically possible and then you're declined without any useful data how do
you know how to improve if at all? Hell maybe someone was just better than you
or they decided they needed something else for the job; telling the person
could save them so much trouble).

If you want someone to spend hours or days trying to join your company I feel
like you should be able to give them feedback. I don't like the trend of big
companies not giving anything. Interviewing is a two way street but there is
just a weird stigma or legal worry preventing feedback.

~~~
redblacktree
There is also a power imbalance that is exploited. You need a job a lot more
than the hiring company needs a new recruit.

~~~
BinaryIdiot
Maybe? I like to consider myself pretty valuable (ego++) :D

But you're right. I wonder what the statistics are for interviewing; are more
people interviewing while they don't have a job or do have a job and are
looking. I feel like it has to be the former like what you were suggesting but
I haven't seen data either way (not even sure on the logistics on collecting
that in a good, representative way).

------
BoysenberryPi
I've interviewed for a lot of YC companies and companies that frequently post
in the "who's hiring" thread and the programming interviews they give are
absolutely horrendous. I've had programming test where companies look at my
resume and go "so you are very experienced in Ruby? Great, solve these
algorithms in C++ for us. I've actually had someone give me a ACM-ICPC world
finals question.

I don't have a problem with pushing someones limits and see where they stumble
but a lot of these interviews seem intentionally trying to screw you over with
the abstract way these questions are asked and the brain teasers they give
you.

~~~
ktRolster
_I 've actually had someone give me a ACM-ICPC world finals question._

What company, do you mind if I ask?

~~~
BoysenberryPi
Would rather not disparage the company. They do good work they just have
terrible interview practices.

~~~
ktRolster
I don't think it's disparaging, I want to work there lol

------
gurgus
Late to the party but I'll just add in my $0.02

I remember the best interview I had was at a company offering open source
software. For the coding components of the interview they give applicants a
task (they cherry pick one of the easier ones) from their JIRA backlog and
told applicants they've got two weeks to come up with a patch. It didn't
matter if the applicant could fully solve the bug/feature, since it's not
particularly fair to expect the applicant to be familiar with the ins and outs
and gotchas of the system they are working with, but what did matter is that
they A) submitted _something_ , and B) could talk their way through their
thought process and how they arrived at their current solution.

This sort of process really clicked with me. Obviously it's not as
straightforward for some organisations that may offer proprietary software,
but the process could certainly be adapted for a lot of organisations, in my
opinion.

~~~
tedmiston
This is interesting because without knowing how their system is architected or
designed, it allows you to state assumptions and you can use that time to
assert knowledge of best practices of a given framework. Sort of an implicit
test for depth though.

Edit: I missed where you said _open source_ company. Though I still think this
thought for a closed source company that uses open source pieces (like a web
framework) could be useful.

------
kelvin0
What if designers had to go through a similar interview process? Here are some
colors, please arrange them in palette groups that are color coordinated for a
given visual effect? Why is red font on blue background bad, please justify?
That would simply be hilarious.

~~~
illicium
> Here are some colors, please arrange them in palette groups that are color
> coordinated for a given visual effect?

"Please arrange these colors in complementary, analogous, and triadic color
schemes". This is color theory 101 -- something every visual designer should
now.

> Why is red font on blue background bad, please justify?

Again, a valid question. It all depends on the brightness/saturation of the
colors, and how much contrast is between them.

Edit: Obviously these are ridiculous and unnecessary interview questions
because frequently a designer provides a portfolio of work that demonstrates
their skill. This may not be possible in a programming interview if the
candidate has been not been working on open source code or side projects.

~~~
bayonetz
Many (most?) times you provide samples for a software engineer job, they don't
get looked at or serve to provide much help to your cause. That you have
samples seems to help get an interview but after that it's at if the samples
were never even provided. I link to many samples right from my resume so
interviewers don't have to depend on HR or whoever passing on extra files.
I've often asked the interviewers, "just curious, what did you think of my
samples?" Almost without exception they say sheepishly say something like
"sorry, didn't have time..." Which is probably true but geez you'd think a
portfolio would matter more and merit a required look.

On a related note, I love the story about the Homebrew guy getting rejected by
Apple because he couldn't invert a tree or some such thing. Even if it was
sensationalized (or plain false for that matter), we aren't even surprised by
headlines like that anymore given the current interview climate.

~~~
illicium
When interviewing, I'm interested in seeing the process a candidate takes to
get a result, not just the result. I like looking at code samples to get a
feel for code quality and software engineering practices (everything from
variable naming and program structure to Git commit messages)

Real-time coding during the interview shows me how good a candidate is at
collaborating when solving a problem. One good indicator is asking follow-up
questions to make sure requirements are clear. Other things to look for are,
e.g. TDD, which can help solve a problem with predictable correctness and
pace. I have interviewed quite a few candidates who throw a bunch of code into
the editor and start pseudo-randomly tweaking the code to try to make it work
-- this is not a recipe for successful problem solving. Some aspects of code
quality can be evaluated during the interview as well, which probably explains
why many interviewers don't bother looking at code samples.

It's important to ask for a solution that can be easily deduced -- trick
questions are bad for both parties, because the candidate is often stumped,
and the interviewer thinks they are bad because knowing the trick makes the
question simple. Many classical algorithmic questions are "tricky" in this
way.

The questions also have to be "real world". Like you mentioned, you can be a
successful engineer and not know the specifics of inverting a tree. If you can
correctly recognize the need for the algorithm and implement it from
pseudocode, you have solved your problem, which is what engineers are paid to
do.

------
vkjv
> "That’s exactly the point. These are concepts that are far more common in
> interviews than they are in production web programming."

The list includes things like Big-O analysis. While, formal analysis is
certainly not a day to day occurrence of most programming, knowing what the
runtime complexity of the code you are writing is almost always important.

While, I generally don't care for most algorithmic problems, I am honestly
concerned when someone can't tell me that something runs in O(n^2) and good
probably be optimized.

EDIT: I should note, I'm not necessarily looking for them to use precise term
here, but they should be able to clearly articulate it.

~~~
ammon
So, I see where you are coming from (I actually love academic CS). But the
VAST majority of the programming work out there does not require any Big-O
analysis. It just does not. It's used as a tool in interviews to (essentially)
look for rigor. The problem is that this harms people who are rigorous as hell
in low-level details of JS and V8 (something I'd posit is actually more useful
to many more companies), but never studied academic CS. There's nothing wrong
with valuing the skill of complexity analysis. But there's a mismatch in how
common it is to look for this.

~~~
quanticle

        But the VAST majority of the programming work out there does not require any 
        Big-O analysis.
    

Your point is simultaneously valid and irrelevant. The vast majority of
programming doesn't involve any Big-O analysis. But if you can't do Big-O
analysis, there are problems where you will be stuck. Your code will be
running slowly and you won't know why, and all the micro-optimizations in the
world can't make a O(n^2) algorithm run faster than an O(n) algorithm on even
a moderately large data set.

To make an analogy with driving: the vast majority of driving doesn't involve
parallel parking. But you still need to know parallel parking to pass a
driving test.

~~~
whatshisface
You don't need to know how to prove a big-O to optimize an algorithm. Anyone
who can think about what their code is doing will have at least some sense of
_how much_ it is doing.

Honestly, I don't think calculating the O(f(n)) is ever worth it outside of
academia. Intuition is only slightly worse, and it is just so much time-
cheaper.

~~~
quanticle

        Honestly, I don't think calculating the O(f(n)) is ever worth it outside of 
        academia. Intuition is only slightly worse, and it is just so much 
        time-cheaper.
    

Sure. I've never been asked for a formal mathematical proof of the Big-O
complexity of my algorithms in an interview. And, as an interviewer, I've
never asked. Intuition is exactly what interviews are looking for. If an
algorithm has a nested for loop, and the inner loop is traversing the full
data set, you should be able to say, "Oh, yeah, that looks like O(n^2) time
complexity." If an algorithm is storing every element of a data-set in memory,
you should be able to say, "That's O(n) space complexity."

Big-O notation, in practice, is a handy shorthand for talking about various
classes of algorithms, and ranking them in order of how much time/space they
take.

------
entitycontext
It seems like there is a large middle area of concepts in between low-level
algorithms/data structures and high-level system architecture that are left
out of many of these interview prep guides:

* Principles and patterns of object-oriented (or functional) design

* Relational (or NoSQL or analytics) database design

* Unit, integration and system testing

* Logging, profiling and debugging

* Source control (e.g. branch/PR/merge flows)

* Deployment and devops

Do these subjects really not come up in some programming interviews?

~~~
cableshaft
From my experience, if they do come up, it's only because I was asking them
what they used. I don't think I've ever been asked about any of these topics,
with the exception of database design.

~~~
entitycontext
It's a shame, since these topics could make for a rich conversational
interview that probably has more to do with the actual job than whiteboarding
an algorithm. Just taking source control as an example, a hypothetical
interview question could be something like:

"You've been assigned to implement feature X in our product. Assume that the
specs are clear and you have a pretty good idea what code you are going to
write. Also, assume that your teammates Joe and Jane have been assigned
features Y and Z respectively with roughly the same due date as your feature.
Ideally, describe how you would make your changes, test them and coordinate
with your teammates to get all three features merged into the master source
code."

Obviously a lot of details are missing, but they can be fleshed out in
conversation (during which the interviewer should also describe the current
process used on the team the candidate is being hired for). This would give
both parties some insight into experience and expectations.

------
dbcurtis
When the the job interview become a quiz show? I've spent plenty of time on
both sides of the interview table. Sure, I've asked problem-solving questions.
It was _never_ to pay stump-the-candidate or to see if they could come up with
some CS proof on the fly. It was to examine their approach to problem solving,
and the way they interacted (back-and-forth questions). The right answer never
entered into it, and if the interview question _has_ a "right answer" then it
is probably a lousy interview question.

I knew a college recruiter at Large Semiconductor Maker. She had been around
the company many years, starting out as a mask designer. She knew nothing
about engineering, but had worked with engineers on a daily basis for 10
years. She was great as a recruiter for new-grad engineers. One of her
favorite questions was: "My back yard is 60 feet wide, and I want a brick
fence across it. How many bricks do I need?" You would be surprised how many
people never said another word, worked out a numerical answer, and told her
the number. _boggle_. The point of the question is to find out how good the
candidate is at uncovering and understanding the customer's wishes and what
the customer's vision is of the desired end result.

Somewhere along the line there has evolved a group of people who never learned
how to interview job candidates for problem-solving oriented jobs. A quiz-show
lottery is a lousy way of finding out if someone can flesh out under-defined
problem statements, replace a stupid problem statement with a better one, and
creatively explore the dark corners of a solution space.

Let's stamp out the quiz show now.

------
Udo
> _If you’re interested in what we’re doing, we’d love you to check out our
> process._

Well, I say this as someone who was apparently blacklisted on TripleByte
despite ostensibly getting a perfect result on the programming taks, _getting_
an interview would have been a start. Or at least getting told what and why it
happened, instead of trying to request a pre-screen phone interview without
result over and over until I "got the message".

I understand the TripleByte team is perceiving problems that exist in the
programmer hiring process, including the fact that interviews are not
necessarily designed to gauge a candidate's qualities as a programmer. I also
understand that you probably can't change the status quo in that space without
first establishing yourself firmly in the existing field. But my own
experiences make me skeptical about how transparent TB really wants to be.

------
Aleman360
How I did it for a Microsoft interview: cram for a weekend with a good
algorithms text book. I do UI development where 99% of the work is figuring
out the UI framework but the study session definitely got me into the right
mindset for interviews.

~~~
atom-morgan
It really makes the whole thing feel like school right? Every time I'm on the
job hunt I have to study all the stuff I never actually use while I'm working.

~~~
mech4bg
I still think you can learn valuable things and become a better coder this
way. Preparing for a Google interview was eye-opening for me, I learnt a ton
of things that I immediately started applying day-to-day.

------
lackbeard
>Similarly, most programmers just want a good job with a good paycheck. But
stating this in an interview is a mistake.

Just like everyone only hires the best, they only hire people who are
"passionate" about <blub>.

~~~
ph0rque
[http://www.smbc-comics.com/comics/20140817.png](http://www.smbc-
comics.com/comics/20140817.png)

~~~
johan_larson
Wow! I regret I have but one up-vote to give for this comic.

------
nice_byte
> Use a dynamic language, but mention C

I take issue with that recommendation. You should use whatever language you
feel most comfortable with. If it's C, use C. If it's Java, use Java. You
don't have the luxury of an IDE or anything like that, so you need to have
enough of the language in your head to write a program without looking
something up.

~~~
jcadam
I haven't used C professionally in a long, long time, but I naturally
gravitate to it when doing technical interviews.

One of the reasons, I think, is that the language itself is "small" enough you
can actually hold most of it in your head.

That, and for certain problems it gives you the opportunity to demonstrate
understanding of things like pointer arithmetic that you wouldn't have if you
used Java. I remember an interviewer at a Java shop being impressed a few
years ago when I used C and pointers to reverse a string in place (I wasn't
very comfortable with Java back then).

All that said, I'm getting old and cranky and whiteboard interviews are
starting to get _really_ annoying.

------
pyb
Another great post from Triplebyte, but I am confused about their model. Why
would candidates want to apply to Triplebyte, if they still have to go through
the companies' full interview process on top of the Triplebyte process ?

~~~
Harj
If you apply to Triplebyte you don't go through the full interview process at
the companies we introduce you to. You skip the technical phone screens (most
companies do 1 or 2 hour long phone screens before bringing candidates onsite)
and go straight to on-sites.

Where we can really save time is focusing on the matching process of
candidates to companies. Interviewing is tiring and we find candidates often
stop talking to companies they were initially excited about because they're
exhausted from interviewing (usually after 4 on sites) and just want to accept
an offer

We wrote before about how much hiring preferences vary across YC companies
([http://blog.triplebyte.com/who-y-combinator-companies-
want](http://blog.triplebyte.com/who-y-combinator-companies-want)). By using
data we get from the Triplebyte interview, we can send you to the companies
where you've the strongest likelihood of passing the technical onsite. The
result is getting the best set of offers to choose from, rather than picking
from what's available before interview burnout sets in.

~~~
tomjen3
I don't really see how you are relevant if I still have to go through a
technical interview - it still means the interview process takes way too much
time and I am better of finding a way around it.

~~~
Harj
Usually the only way to circumvent the technical phone screens at a company
are if you're coming in through a strong referral. That's great if you already
have a strong network, not so much if you either don't have personal
connections or a resume with the credentials recruiters are trained to look
for.

Just focusing on interviewing time, if you're talking to 3 or more companies
that's approximately 3 hours of technical phone screens (usually repeating
similar problems). With Triplebyte, you interview for 2.5 hours and save 3 (or
more as you talk with more companies).

------
DeadeyeRolf
As a junior in university looking for internships this summer, I can attest
that going through the programming interview process is a pretty foreign
process compared to traditional interviews. I just stumbled through my first
programming interview last week.

I believe in the future point 3 will be especially helpful. The hardest parts
for me were trying to figure out how appropriate it was for me to be rambling
as I coded (something I'm not used to doing at all), and trying to understand
what was and wasn't appropriate to ask the interviewers about my code.

Time to brush up on breadth-first search and hash tables!

~~~
jonesb6
It gets better! After a few interviews you start to get the hang of things and
can begin to read the situation and understand what's in your best interest to
do. Some interviewers like to test your knowledge of C.S. curriculum like you
just mentioned, others prefer a friendly person who isn't afraid to ask
questions and be honest about what you can and cannot do, others prefer both.

It gets better.

~~~
DeadeyeRolf
I definitely will be far more prepared for my next programming interview from
the experience I gained going through the process once already. It's just sad
that my first interview process had to be with a higher-profile company that
would have been a ticket into silicon valley. Those interviews don't come easy
in the first place. Haven't heard back from anyone else yet, but I trust
they'll come along.

~~~
jonesb6
You'll look back at it in a year or so and laugh. Personally my resume and
interviews were absolutely atrocious (I thought an online resume builder was a
good idea..).

------
hoodoof
I've built alot of stuff and apart from hash tables, never really needed to
understand:

    
    
      Hash tables
      Linked lists
      Breadth-first search, depth-first search
      Quicksort, merge sort
      Binary search
      2D arrays
      Dynamic arrays
      Binary search trees
      Dynamic programming
      Big-O analysis
    

I guess it depends if you are going for a job that REQUIRES these techniques
then yes it is important, but for web application development - even
sophisticated web application development - not needed.

~~~
cgh
You should know a number of things on this list if you do back-end webapp
development, particularly for large/hairy enterprise stuff. So maybe you are
referring to front-end only.

~~~
krzyk
Almost all of those are handled by a standard library, so why bother. When
issue arises then you look for a book/website and fix the problem. Source:
Doing backend (and some frontend) web stuff for the last 10 years.

------
m4tthumphrey
When I interview candidates I sit with them for half an hour or so to get to
know them. Then I give them purposely broken, poorly written piece of code
which I tell them to pull apart. This proves incredibly effective as even if
they miss some of the more obvious errors I can at least point them in that
area and then see if they can see the problem on their own. There are about
100 different things to talk about so it really gives me an idea of the level
they are at, and also the type of programmer they are; passionate, lazy,
smart, meticulous, inexperienced, confident etc.

Then if I feel they are worth a second interview, I get them back to sit with
me and my team for the day to see how they fit in with the team. Then all
being well I offer the job.

~~~
Jemmeh
Love this idea, doesn't take a lot of time and I think it's a pretty good
measure. Anyone have anything against this?

------
jameshart
Programming interviews aren't pass/fail, they're match/no match. Imagine how
it would read if this said "how to pass a first date".

~~~
kafkaesq
But they're _conducted_ as if they're pass/fail -- quite often before any real
(two-way) discussion can take place.

Imagine if prospective dates gave you a 4-hour take-home test before making
eye contact. That's actually the way many employers like to start of the
conversation process with candidates, these days.

~~~
shawn-butler
That is sort of the premise behind a whole slew of very successful dating apps
isnt it?

Spend several hours perfecting a profile to increase your odds?

------
noonespecial
Interviewing should now be part of most CS educations, if not its own three
class/semester course. Its that weird, and that important.

~~~
dang
But the people who'd need that the most are the ones furthest out of school.

I shudder at the thought of ever having to do another programming interview.
Well, alternately shudder and laugh. What a joke!

~~~
waterlesscloud
It's my belief that the best experienced programmers don't have to go through
programming interviews. Even if you don't actively make an effort to network,
you have a network of people who know you're good enough to outright hire
without the whole rigmarole.

Companies who aren't finding people like this are missing out on many of the
best.

~~~
vonmoltke
> Even if you don't actively make an effort to network, you have a network of
> people who know you're good enough to outright hire without the whole
> rigmarole.

Not sure why you think this is the case. It is really easy to end up with a
worthless network (I managed), and many larger companies insist on forcing
every applicant through the HR hiring funnel for compliance reasons.

~~~
waterlesscloud
It's been my whole career. Yeah, I've had to go in and do the grip'n'grin
interview and talk to people for a couple hours to make sure I'm not a martian
or something. But every job has always come about because someone at the
company either knew I was competent (from working with me in the past) or
asked someone I knew who told them I was.

I've never had a job that involved whiteboarding or any sort of coding test.

~~~
vonmoltke
Yes, but why do you think your experience generalizes to anyone else?

------
bogomipz
I'm sorry but could someone explain who tripplebyte is and why they are so
"precious"? This blog post in my opinion is symptomatic of of this bizarre
silicon valley interview culture. This whole "how to ace the programming
interview" bullshit is really disturbing. Are you looking for people who are
good at test taking or people that can produce good product? Yes CS
fundamentals are important - data structure/algorithms, but I'm much more
interested in whether a candidate understands the problem space and can reason
about it. I want to know about systems they've designed in the recent past why
they made the choices they made. Being able to code up Kruskal's spanning tree
perfectly on a white board while being timed is a neat parlor trick but if you
don't understand the bigger holistic picture of systems I don't think it means
that much.

As far as these take home assignments go, I find this a disturbing trend as
well. Especially egregious is telling someone there is a time limit on your
working for free. If you're going to pay me for my time awesome lets talk,
otherwise lets maybe look at some code I've already written.

This industry seems to get more up its own ass every day.

~~~
bliti
From their website:

 _We help programmers find great jobs at Y Combinator startups. No resumes,
just show us you can code._

* Our Company

We believe hiring should be about what you can do, not what you say you can
do. Our mission is to build the world's best technical hiring process.

We don't care where you went to school or which companies you've worked at. We
only care if you can code. If you can, we'll do everything we can to find you
the best startup to work at. *

That mission statement plus the blog post means that they are recruiters for
financially unstable companies (aka startups). Makes the blog post that much
harder to believe since startups are beggars not choosers when it comes to
hiring.

------
Omnipresent
The practice section doesn't mention anything other than the book. Are there
any other resources that people use to prep for an interview? Looking for
something that tests algorithms and data structures more than solving tricky
problems.

~~~
rifung
I think Cracking the Coding Interview is very popular if you're specifically
targeting interview questions. There's also the accompanying website
www.careercup.com

I personally also like to do problems on hackerrank, SPOJ, or Code Jam, but
are probably overkill (especially Code Jam) as they're much harder than what
you probably should expect in an interview. Still, I find that it helps my
nerves when I solved harder questions because then the interview questions
seem much simpler so it might help you too.

------
aprdm
I've been interviewing in the past month as I need to find a new role and it
is just crazy.

It is SO random, a lot of useless questions, small startups having a long
hiring process harder than the big 4.

Just one example: I've received an offer from one of the big 4 after going
through their process. I was lucky in the questions - things I had studied.

I also applied for around 40 start ups / small companies. I made through the
final on-site interview in only 5 of them. Lots of white boarding, silly
technical questions that don't proxy to day-to-day work and etc.

I really think that passing in a process in a company like Facebook and not
passing in other companies working in a much less complex environment says a
lot.

Another thing that annoyed me a lot was that in some companies, when I froze
upon a problem and was in a dead end, instead of them trying to help me or
give constructive advice they would just keep adding pressure. It's craaazy.
You're in a white board in a position of someone judging you in a on-the-fly-
absurd-problem and the guys is trying to talk you down instead of help.

Crazy stuff.

~~~
sarchila
Perhaps the smaller/scrappier startups are trying to have more rigorous
processes because small startups don't have as much resources to train new
hires when compared to 'big 4' companies, so they really need engineers that
can do it all themselves, quickly and under-pressure. They also may be more
risk-averse when it comes to false-positives, because if your entire
engineering team is 5-10 people, you're much less likely to be able to afford
to get it wrong and hire someone that won't end up working out.

------
eiopa
It's always been strange to me that tech interviews tend to check for basic
CS, rather than deep engineering.

When was the last time you had to implement _bsearch()_ in a real project?

~~~
oriolid
It is widely believed that if you are able to do deep engineering you should
also be able to get the basics right. It takes a lot of time evaluate a real
world project and most of applicants would not agree to do one anyway, so
basic CS is the easy approximation.

~~~
eiopa
What makes implementing qsort/bsearch/etc "the basics"? It seems rather
arbitrary, and it mostly measures how well you are able to recite from CS
books.

~~~
mattkrause
The weird thing is that some of the "basics" aren't even particularly basic.
Finding cycles in a linked list was an open research problem for a while. One
can argue that interviewees need to know about the Tortise and Hare algorithm,
but it's crazy to think that someone who hasn't should be able to come up with
it on the spot.

------
ammon
A large number of bad things influence interview decisions (credentials,
targeted practice, how well you know the specific algorithms that come up
again and again in interviews). I hope that more programmers getting better at
interviewing skills will help move companies toward measuring actual
programming skill.

~~~
superuser2
My credential represents hundreds of hours of programming projects over
several years. For that reason alone it is a much better signal than an
interview will ever be.

It also establishes depth and breadth of familiarity with a variety of
fundamental topics demonstrated through exams and large programming projects:
program design, networking, operating systems, security/cryptography, team
software engineering practices, algorithmic techniques and analysis, etc.

You fundamentally cannot assess this as well as my alma mater can because my
alma mater has 4 years of me working under realistic conditions (laptop,
internet, colleagues, deadlines on the order of weeks) and you have, what, 5
hours of me standing at a whiteboard?

Credentials are seriously underrated.

CS programs are not created equal. If you find that candidates from a
particular school aren't necessarily competent, then you should value
candidates from better, harder schools. If you find that candidates from well-
respected schools aren't necessarily competent, then you should respect them
less (US News isn't always right) and respect other schools more.

~~~
ammon
You're not being compared to people who lack hundreds of hours of programming
projects. You're being compared to people who have that same experience,
either at a worse school, or on their own. Credentials correlate with being
good, absolutely. But many, many more people lack credentials than have them.
This means that there is a large number of great programmers who don't have
them (I think a larger number than who do). There are also bad people with
good credentials. Strong filtering on credentials harms companies who miss
good programmers, and harms programmers who can't get jobs. Using credentials
as one factor among many in a screening step, however, makes good sense
(although we don't do this at Triplebyte because we want to force ourselves to
get as good at possible at directly measuring skill).

~~~
superuser2
>You're not being compared to people who lack hundreds of hours of programming
projects.

I don't think that is quite right. Interviewers claim coding interviews are
necessary to weed out the large fraction of our industry that cannot write
code at all. If they cannot code, then they did not successfully complete a
good undergraduate program's worth of coding projects (they cheated, rode on
the coattails of group members, were graded way too easily, or something).
Otherwise they can code.

>Strong filtering on credentials harms companies who miss good programmers,
and harms programmers who can't get jobs.

On the other hand, strong filtering on whiteboarding unnecessarily filters out
people who don't do well under that kind of pressure but may be great
programmers given a computer and a more realistic deadline. They also
privilege people who have optimized well for whiteboard interviews but may be
destructive in the longer term.

Which is why the optimal solution seriously considers both factors. (I'm
arguing with you because you called credentials influencing hiring a "bad"
thing).

------
graycat
A candidate has an impressive STEM field educational background, say,
Bachelor's, Master's, or Ph.D. degrees, has peer-reviewed publications of
original research in the STEM fields including in computer science, has taught
computer science in world famous US research universities, has created
original, fast algorithms in computer science, has written successful software
for a wide variety of applications in a wide variety of programming languages,
and, then, somehow needs to learn some additional, special lessons on "how to
pass a programming interview"? Such an interview is by the Queen in _Alice in
Wonderland_ or from someone well qualified in computing?

Why the heck the needs for special lessons to do what the candidate has been
doing successfully for years?

~~~
the_af
Because passing a programming interview is _not_ what the candidate has been
doing for years.

Interviews are artificial, stressful situations which in many cases do not
resemble what you will actually be doing at your job.

Like well-known blogger Steve Yegge once commented about Google's interview
process, sometimes it gets so bizarre that two interviewers in your queue
_wouldn 't have hired each other_! Focusing on the details one interviewer
likes will make you lose points with the other. He calls this phenomenon "the
interview anti-loop".

I guess being well-drilled about common questions and tricks helps
counterbalance some of the pitfalls of the interview process.

~~~
graycat
So, right, _programming interviews_ are from _Alice in Wonderland_ and not
about programming.

Gee, I'm glad I'm programming, for my own startup. Wait while I ask my
founder, CEO if my programming is good -- got an answer back right away, my
programming is fine!

~~~
the_af
> _So, right, programming interviews are from Alice in Wonderland and not
> about programming._

I don't understand your irony. No-one is saying that. We're saying that
programming interviews are often not ONLY about programming, and unfortunately
the parts NOT about programming tend to overshadow the parts that are.
Therefore, interviewing requires preparation.

Are you bitter that programming interviews are like this? If so, fine. So am
I.

Are you saying that programming interviews are NOT like this and do not
require training for? You are mistaken. It's a fact of the world, whether we
like it or not.

Or are you saying you lucked out and didn't have to go through this hell? If
so, congrats! It's known to happen. But still, it pays to be prepared for the
average case of difficult, stressful interviews.

~~~
graycat
I'm saying that programming interviews have descended into tea leaf reading.

People with obviously high qualifications are being rejected for no good
reasons.

The situation was not always so.

Apparently the people doing the interviews are more interested in being nasty
than hiring people to get more work done. For this situation to hold, there
has to be not much demand and a big supply. So, the process is free to descend
into totally silly games. It's the Queen in _Alice in Wonderland_ and "Off
with their heads".

------
balls187
> The good news is that interviewing is a skill that can be learned.

When I hear folks complain about programming interviews, I point to that.

The month I spend gearing up for coding interviews usually guarantees me a
job, that offers at minimum a $10k raise. I consider that a very good use of
my time.

~~~
julie1
There is a problem. (job interview are selecting incompetent people)

Ho, but there is a solution to walk around the problem of job interviews being
unable to select good developers: so let's avoid investing in being a good
developer and fix the problem at hand and just be good at interviews.

Problem solved.

Brilliant!

Are not interviews kind of de facto selecting scammers by giving them an
unfair advantage, then?

Is it not causing a problem of credibility of the profession, hence the of the
value of our earnings?

Growth is shrinking, recession is coming. Will they keep people whose values
are uncertain when time will come to get rid of the fat?

~~~
balls187
> There is a problem. (job interview are selecting incompetent people)

Of the developers you hired, how many nailed the interview process, then went
on to being classified as a bad developer?

From my experience hiring candidates, the typical software interviews that I
have been a part of, tends to produce very few false positives, and instead do
produce false negatives.

------
jroseattle
"They eat large sprawling problems for breakfast, but they balk at 45-min
algorithm challenges."

Care to guess what we're looking for in screens and interviews?

Some of our best performers were poor interviewers. Likewise, we've had
interview aces not pan out. Rather than expecting the world to become
interview clones (and make our hiring decisions even more difficult), we're
learning how to be better interpreters of people to get to the answer of our
real question -- is this person an engineer we'd like to have on our team?

It's still a work-in-progress and we're nowhere near perfect, but we're simply
not going to outsource our decision-making to the status quo of technical
interviewing in 2016.

------
rurban
Given that none of the most popular dynamic languages know how a good hash
table should be implemented with dozens of half-way experienced programmers
over many years, and most of them would not be able to write a proper binary
search, these questions are certainly too hard for a jobseeker. Those
languages still survived with improper implementations for decades. So will
TripleByte.

A good programmer must be able to survive mediocre colleagues and terrible
managers. How to check for that in an interview?

------
ascetonic
While there are several resources to practice the use of algorithms and data
structures, I find there aren't as many good resources to prep for the 'system
design' interview.

If one wants to switch from a completely different domain - like working in
investment bank tech or embedded development, there is no way one can have
prior knowledge to tackle the design of a Google Docs style system.

It seems like something that can only be gained through on-the-job experience.
Is there no hope for newbies?

------
progproprog
If you can't talk about design implications quantitatively, nor have a
rigorous understanding of how to build data structures - not memorize anything
- you can't get mad that I make $100,000 more than you do and work half as
much.

If you're a career programmer, and you've never bothered to hone these skills,
don't be surprised when you can't easily find work in 10 years. The cheaper
guy or girl who comes with less risk will beat you.

------
blisterpeanuts
My solution has always been pretty simple -- I do poorly in exam interviews,
and usually I don't get the job. Regurgitating Algorithms 301 -- nope, not for
me. They'll end up with someone who's great at regurgitating. They're happy
and I'm happy.

I can explain very clearly _how_ I would go about solving a problem, maybe
whiteboard it, flesh out a design, ask them some key questions to show I'm a
thinker and not just a follower. That kind of interview usually goes well for
me.

As a result, I usually end up with jobs where I have a lot of creative
latitude, where I can think up new product ideas and prototype them out, where
I can solve problems my own way.

I wish I could pass those Google tests, though. It would be nice to have it
all. But some of us just have limitations, I guess. Luckily, it hasn't held me
back from having an enjoyable and relatively well compensated career.

Probably today the thing is to have a couple of apps on the Android or Apple
appstore, a Github page with some interesting toys and experiments, some open
source contributions, and of course the old-fashioned networking that is how
many of us still get our best jobs and most successful business relationships.

------
gtolle
At my startup, I've had some success hiring mobile devs through "audition
programming" on Google Hangout.

I create a "real-world-lite" task like "connect to this simple JSON API I
built and implement a recursive product category browser on top of it". I've
done this task myself already with a timer and am confident that it will take
about an hour to implement. Then I ask the candidate to share their screen and
implement it in Xcode while I watch. As they develop, I can get a sense for
how they attack problems (quick and dirty, slow and methodical, stack overflow
copying, etc), and afterwards I can ask questions about their thought process.

If they did well in the first one, we block out a second one for another hour,
and a third for another hour after that, each one testing different skills.

This avoids the time imbalance inherent in take-home projects, because I'm
spending just as much time as they are. And it avoids the painful "implement a
red-black tree" whiteboard questions by focusing on real-world work in their
own dev environment. It also means I have a decent sense of their skills
before I ever invite them to an on-site interview.

------
boopuyy
Edge cases, running time, and correctness. If you're not hitting at least 2 of
these perfectly, then you're not writing good code.

------
valine
It very much depends on the gig, but I would add another item to the list:
Show a basic understanding of UX design. Companies need people who can mediate
between designers and programmers. While demonstrating an understanding of
Photoshop and Illustrator says nothing about your skills as a programmer, it
could be the thing that makes you stand out from the crowd.

~~~
jameshart
But "an understanding of Photoshop and Illustrator" is to "a basic
understanding of UX design" as "an understanding of vi or emacs" is to "a
basic understanding of distributed application architecture"

~~~
valine
The only reason I mentioned Photoshop and Illustater is because they're easy
things to put on a resume. "Knowledge of design principles" is a little more
amorphous.

------
joe_the_user
To past a sane interview with sane people, focus your mind on the "how to be a
good programmer" question - programming as a cooperative human endeavor.

Of course, it may that a bit of craziness may be involved and they'll ask
ridiculous little or big problems but someone with a reasonable amount of can
answer those.

Or it may be that a lot of craziness is involved, things veer into bit-
twiddling assembly, top management steps in unannounced to shoot random
questions, suddenly syntax or whether you are "server side oriented" or
whatever matters a lot - "we want the absolute best programmers on the market
and we cement their loyalty by paying well under market rates..." etc.

Now, the more craziness appears, the less you'll actually want the job. But
markets being what they are, you may need the job. By the end, there are no
easy answers. Keeping is probably the main advice.

------
innertracks
While not strictly programming I just finished interview number four/five with
a company about an hour ago. SQL and data modeling. First, one non-technical
phone interview, one technical phone interview, one online take home test.
Today, two different sessions, second one primarily technical, and lunch.

White boarding a simple data model of a real world scenario was surprisingly
difficult even though the interviewers were very cordial. The exercise was
used to gauge my question asking skills (interviewer was acting as subject
matter expert) as much as data modeling and SQL. It was kind of fun as I used
it as an opportunity to expand my ability to problem solve in stressful
environments.

------
ancymon
The company says: "We help programmers find great jobs at Y Combinator
startups."

What's so great in Y Combinator startups? I mean why do they narrow only to
such startups? Wouldn't it be better to just say they help with finding jobs
in startups?

------
felhr
I had an interview some years ago which demanded a difficult CS problem to be
solved and besides coding the offer stated that you should happily accept
being helpful with the IT needs of the marketing guys installing their
Antivirus, email...

------
gerbilly
I was saying to someone the other day that timed programming tests (codility
seems popular) are really just youth tests.

They are meant to weed out older programmers, in favour of younger cannon
fodder...I mean candidates.

------
k__
I had a bunch of interviews in my life and everyone had its own "special
sauce"...

My first one was with a Java company and the hiring manager wanted me to draw
UML diagrams, which was the only thing that I learned in the software
engineering course in university.

Another one was about programming a game. Nothing much, but it needed a few 2D
transformation I knew nothing about, so I failed miserably.

Most jobs I got were just "talks" about what I can do.

"You know web development? HTML? Nodejs?" \- "Yes" \- "You're hired!"

------
mooreds
What's the least stressful way to pass a programming interview?

Not to have one at all!

This obviously doesn't apply to people just starting out, but I've found the
easiest way to get a job is to have worked with someone at the company in a
similar role. Many of the issues that interviews are designed to highlight
(attitude, flexibility, stick-to-it-ivness, culture fit) simply are non issues
if you have someone on the inside who has experience with you.

------
eranation
If you have an unbounded abundance of good candidates, it is a different story
then when you are a new startup fighting for talent.

At highly targeted companies such as Google, Facebook et al, I'm sure that if
they have a dryspell of good candidates in a given month (can't think of a
reason why), then they revert to things like: "We don't care if you don't get
the 'trick' immediately, we'll give you hints" and "we just want to see how
you think and how you code" and "just talk through the problem" and "you
should not learn specific problems and if you see one you know just tel your
interviewer" or "cracking the code interview type of questions are banned".

But the reality is that people who apply to Google (or Apple or Amazon or
Facebook or Microsoft...), are very smart, and want to work there very much,
so while they can probably do well without preparation, due to the fact they
will have competition with all this year's new Stanford / MIT / CMU graduates
on a limited amount of positions, they take no chances. I have a friend who
has a masters degree from a target school and it took him 4 attempts to get
into Google. He is smart, he probably did well in the interviews, but you are
being compared to others, so until he went and worked on those pretty useless
skills of: practicing writing fast on a whiteboard, getting interview books
and practicing tricky problems, doing a lot of online judge problems, he
didn't get in. Why? because if you have two candidates, both smart, one has
practiced whiteboard coding for all of the problem sets on geeksforgeeks /
careercup / glassdoor, and one haven't, then even if both are presented with a
new problem, most chances it might be a variant of one of those other "usual
suspects". e.g. after I solved the famous water trapping problem (tough one if
you don't get hints), the idea for the largest water container problem just
pops to mind, and if you know that you can find the only non duplicate number
in a list in O(1), then the problem of finding if an unsorted list of numbers
is an arithmetic series with just O(1) memory is practically the same trick.

So think of two developers, both are awesome, both know CS and both are fast
coders.

One practiced whiteboard coding and knows the XOR trick for duplicate numbers,
his code for such a question will be written in 1 minute

    
    
        public int findDupe(int[] nums){
            int dup = 0;
            for (int num : nums){
                dup ^= num;
            }
            return dup;
        }
    

The other guy, who didn't see these kinds of problems will probably use a
hashmap and x2 more lines for the same problem.

Both are O(N) time an O(1) complexity, but the hashmap guy might accidentally
say it's O(N) memory (common mistake for frequency maps)

Bottom line, both are good candidates, and the only reason the first one
thought of the XOR solution in 1 minute without a hint is that they either saw
it before (it's not that rare) or a real genius (statistically less likely,
but still possible)

If you don't have enough good candidates, you might have the time and energy
to really see which one of these will perform better at work using work
related questions other than tricks like this.

But if you have unlimited good candidates coming in, the one that will solve
it in 2 minutes will be the one that will stand out from the crowd, there is
simply no other good way to filter out so many people. I'm sure they have tons
of false negatives. (and probably also a few false positives, but I doubt it's
too many)

So the system is broken, but also SATs and GREs are broken. Popular schools,
popular jobs, will have to put filtering systems that are not only directly
related to the ability to do the job. Someone at Google is simply writing CRUD
apps for a living all day, I'm sure. But I'm sure his interview tested him on
a much harder set of problems.

~~~
ape4
In Java this prints -4

    
    
        int [] nums = { 2, -2, 0, 0 };
        int dup = findDupe(nums);
        System.out.println("dup="+dup);

~~~
ammon
This only works if the numbers are in a known range (say sequential from 1 to
100), and you XOR in the index (plus 1) as well. Then each number is XOR'd two
times, except the duplicate, which is XOR'd 3 times (and thus remains at the
end). The fact that the code is wrong shows why this question is a very bad
interview question.

EDIT

The given code works to find the only non-duplicate item in a list (perhaps
that was what was intended)

~~~
eranation
yes,that was the intention, I can't edit by now. I had to leave fast and then
got "noprocast" on and couldn't reply / correct

but it is nice that people got what I said through the lines!

it should have been called findNonDupe and the var should have been called
nonDup.

Hope I'll do better in a real interview ;)

------
vadym909
Recruiting is F*&^%$ No matter what you do to the interview process Hiring
managers are looking for @#$#% and they may be #%@%@ and their company maybe
$@%@ and their team dynamics are ##%# Candidates are looking for $@#!@ and
they may be $@@$ and their personal situation is $$@@ and their salary
expectation is ##%@@

------
piokuc
This is a very good piece of advise, matches my past job seeker's experience
really well. I think I got most of my jobs largely thanks to enthusiasm I had
for the stuff the companies were doing. It was genuine but I'm sure it could
be pretended as well. Everything else spot on, very honest stuff.

------
smaili
I think it's also important to mention that you should come in with some good
questions of your own that you've prepared for them. A lot of times the
interviewer uses this to see how much homework you've done on both the company
and the job you're applying for.

------
andrewstuart
Recruit people who are smart, work hard, solve problems, enjoy learning and
get stuff done. Joel knows.

------
jconley
I'm pretty sure I could never get an engineering job at companies that
interview like this. I've shipped tons of real world products over the last 20
years, founded companies, and just reading about what it is like to interview
scares the shit out of me. I'm a firm believer in proving real world skills,
not silly/irrelevant high pressure short time domain stuff.

Safe to say, we don't interview with whiteboard hazing. We do a phone screen
mainly for personality and to see if the candidate deeply knows about a
project they recently worked on. We dig in a bit there and look for the spark
of passion. Then, if we are moving forward, we give a take-home project in a
private git repo that is relevant to the role and tell them to spend 4-8 hours
on it depending on their availability and ask them to time it and be honest.
They choose the scope of work they want to accomplish. If the code looks
reasonable we have a video conference where we do a code review and dive deep
and ask "why" a lot.

We have been really surprised at the difference in quality of these take home
projects. Some people can barely get started and struggle to produce anything.
Others build full on, useful, applications.

Obviously we are screening for people that are self-starters, so being able to
choose scope and regulate and make larger decisions is important to us.

An example project for a full stack c# developer:

Feel free to search around and work on the challenges as if you were on the
job. Let me know when you think you can have this stuff done by. Please do
this on your own time, with your own equipment and tools, and not your
employer's. We don't want any lawsuits or IP ownership questions. Also, for
the code, you can retain copyright if it's something you'd like to publish on
GitHub, etc.

Clever Code Can you send me a code snippet in the language of your choice of
something you have done that solves a hard problem in an elegant way?

For instance, here's one of my snippets from a few years back. It solves the
complex problem of transactional optimistic concurrency control using ~30
lines of code. The usage of lambda expressions in C# and generics makes it
succinct and expressive.

[http://blog.jdconley.com/2009/01/functional-optimistic-
concu...](http://blog.jdconley.com/2009/01/functional-optimistic-concurrency-
in-c.html)

Production Backend Question Let's say I have a very popular consumer facing
service with 10 load balanced front end web servers running the latest asp.net
mvc and averaging 100 simultaneous requests each, appropriately sized ms-sql
servers, and a heavily used memcached cluster of 4. Everything is running
great until we do some capacity planning and double the number of web servers
to 20 and experience a 25% increase in simultaneous requests. Suddenly load
shoots up on the ms-sql tier with far more transactions per web request than
typical, overwhelming a ms-sql cluster that should have handled twice as much
web traffic. Web server requests start timing out and throwing 500 errors to
the clients, and the system practically comes to a halt. There were no code
changes. Describe how you would troubleshoot this and what you think might be
a few likely causes.

Failure Tell me about a project you have worked on that failed. What was your
role? Why did it fail?

The Challenge This is meant to be a practical exercise, and is representative
of the types of challenges we face. We want to see if you can make reasonable
product choices under time pressure as well as write code. You get a lot of
ownership here. Please use any frameworks/services/etc you want. We suggest
using something you know very well. Feel free to search Google, go to the
library, call a friend, or whatever you need for research. Please write all
the code/copy/etc yourself. The output can run on whatever OS or PaaS/SaaS
provider(s) you want, but it should be something we can also easily run.
Please try to limit this to 4-8 hours of your time.

If you want to keep the repo private, please share it with me:
[https://github.com/jdconley](https://github.com/jdconley)

Create a web site with the following characteristics: Make the
hackathon/minimal/proof-of-concept version of some popular consumer web app
that you think could use some love. Craigslist, eBay, reddit, whatever...?
Site must be responsive, gracefully scaling down to smartphone resolutions and
up to full screen desktop displays. It does not need to be beautiful. Supports
all the way down to IE8, with appropriate feature degradation as needed. Lean
toward implementing things in-browser rather than in back end code. Bonus
points if you do a Show HN and your implementation makes it to page 1 on
hacker news.

------
yueq
tl;dr -- current programming interview format should be drastically changed.

I have interviewed 100+ candidates so far. I'm doing interview less and less
recently simply because I found those coding/design questions less meaningful
to judge how good a candidate is.

With websites like leetcode.com/lintcode.com that collect interview questions
and provide online judge, all you need is to put enough time practicing.
10-years ago we use "reverse a linked-list" and nowadays we maybe use
questions like "topo-sorting". The latter is significantly harder than the
previous one -- but if candidate saw solution beforehand, it's actually easier
to implement.

------
swillis16
I look forward to seeing more articles that find ways to game the interviewing
process. Perhaps showing interviewers how easily their hiring process could be
gamed will 'inspire' improvements in interviewing.

~~~
emodendroket
Countless books have been written on this topic, so my money is on no.

------
fibo
Good article. Anyway, I am also disappointed with many interview processes.
Sometimes I think there are courses or books about how to hire that spread a
particular concept or practice that is common in some period.

------
erbo
"Line up offers" only works if you already _have_ a job, I suppose. If you're
unemployed, you generally _have_ to take the first offer you get, or you lose
your unemployment benefits.

------
geebee
"You need to be able to write a BFS cold, and you need to understand how a
hash table is implemented."

Great advice! The list provided in this blog post is an excellent description
of what you should know, cold, before you go into an interview. The reason you
need to know them "cold" is that you (probably) won't be simply asked to code
up mergesort. Instead, you'll be presented with a problem that can be reduced
to mergesort. You need to know it cold so that you can reason more abstractly
with it.

While this is great advice, it also demonstrates why people eventually develop
interview fatigue over a career. I'm not talking about fatigue from your third
interview this week, I mean, I mean fatigue that sets in over decades.

See, a year ago, just before I interviewed at google, I could have done all
this "cold". I could code up a BFS, mergesort, find the shortest path between
two nodes, print all permutations of a set, and so forth. Cold. And you know,
I think in many knowledge-intensive fields, most practitioners are required to
do stuff like this cold. But I probably wouldn't be able to do it all cold
now. I could figure it out, but not in 45 minutes at a whiteboard, and
certainly not in time to reason abstractly. I wouldn't be able to do this with
partial differential equations or shakespeare's plays, two other subjects I
was highly prepared for exams in a couple of decades ago.

See, people in other professions have to do this, but they do it once.
Actuaries need to know vector calc and linear algebra, cold, to take their
exams. But they don't have to remember how to integrate by parts when they are
interviewing for a Sr Actuary position 15 year later. Physicians need to know
Organic Chemistry, cold, at some point in their lives. But an experienced
anesthesiologist isn't expected to answer whiteboard questions about
undergraduate oChem.

I don't have an easy solution, since I actually do completely understand why
tech employers rely on these exams. But I do think they take a serious toll on
the field, and are a major contributing factor to attrition (as well as
aversion among people who never go into the field at all). We, as developers,
really do have to re-load complicated undergraduate coursework into exam ready
memory over, and over, and over.

I'll finish the way I always do: if you interview like this, that is your
choice, and you should feel free do do so - I really mean this. But why then
do these employers act mystified that there is a "shortage" of developers? It
seems to me that aversion and/or attrition is a very natural outcome for the
way we do things in software. "No thanks, I'll do something else" seems like a
very reasonable response to an industry that hires like this.

------
soham
At the risk of repeating myself what I've said elsewhere on the page:

This method of interviewing has been around ever since, and is going to be
around for the foreseeable future. Nobody loves it, including the
interviewers, but there just isn't a better way to do it at any sort of scale.
Especially when there are much bigger problems to solve when you're running a
business. And a lot of other reasons.

It's best to take the bull by the horns. I run
[http://InterviewKickstart.com](http://InterviewKickstart.com), which is a
bootcamp for preparing for such technical interviews. We do almost exactly
what is in the blog post. It works. Spectacularly well.

~~~
nathanaldensr
You've copy-pasted the exact same text several times in this thread already.
Your worry about repeating yourself is justified. This seems like blatant
advertising to me.

------
sbierwagen

      This is a different skill [1].
    

The [1] is inside an <a> tag, but the tag doesn't contain an href attribute,
so it doesn't link to anything.

~~~
ammon
Thanks. Fixing!

------
progproprog
If you're given a take home project and you take a lot of time on it, it's
usually a signal that we shouldn't hire you. We're not using you for free
work, and if you think your take home project is assigned in that vain, then
you're probably not qualified for the job. It's great personal work ethic when
you tell us you worked super hard and spent a week on it, but we give you the
expected time so you can filter yourself out. Also, shame on you because it
makes us feel shitty to have to reject you after that.

------
hooliganpete
How about technical interviews for non-technical roles. Any advice?

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

I certainly hope they aren't interviewing anybody under duress.

------
qaq
align your interview requirements with your actual desirability as employer
and with realities of job at hand.

------
zyngaro
Recruitment in this industry is FUBAR.

------
deedubaya
> I fundamentally do not believe that good programmers should have to learn
> special interviewing skills to do well on interviews

> 2\. Study common interview concepts

lol

~~~
vonmoltke
You can simultaneously believe a process is bad and advise people to learn it
in order to get ahead if you do not have control over said process.

------
patmcguire
Being evaluated is a skill.

------
boubiyeah
The article starts pretty fine but then just explain how to be good at
bullshit interviews?

------
known
interview != quiz

------
jorgecurio
Well, technical interview questions are why I've given up on pursuing a
programming career path and I was shocked that employers were still giving out
technical interview questions for a product manager role, it didn't matter if
I was a software dev years ago. Rote method still trumps real world experience
building real commercial software that people will pay you for according to a
lot of interviewers....and I've heard about few managers hiring neophiles
based on their 'algorithmic' performance on a whiteboard build shit on
Node.js, panic when it's far more work necessary and pull the plug on their
CMS (reinventing wheels) because PHP is 'slow'...what in the fuck did I just
hear you want to rebuild a static CMS website in Node.js because you think
it's going to give you wings?

well at least that has been my experience so far trying to get a job and I'm
coming up dry every time. I technically have no work experience because I've
been holed up writing a big data mining SaaS tool for a few years and since I
was self employed it seems to mean jack all for credentials.

I don't know I'm in a bit of a jam. Starting a complex SaaS product from
scratch that thousands of people have used is simply useless against a fucking
sorting algorithm that will be used heavily on the actual product.

Like I feel like I'm living in a bizarro world sometimes...I have all this
experience and knowledge in this one area, building shit and getting people to
pay for it, and it's going to waste as I'm half heartedly applying for jobs I
know I will not be able to pass the second round of interviews when the
technical algorithm questions begin....I'm sure if I wanted to learn more
about the different variety of sorting algorithm I would've fucking consulted
stackoverflow already....come on man I just wanna solve _real world_ problems
with _real world_ product experience not write fucking code on a whiteboard.
I'd be happy to architect out an entire stack powering your product in to the
future on a white board but fuck man if you want help on your sorting
algorithm just google stackoverflow.

my 2 cents.

~~~
anotherproger
You come off as a technophobe. As an employer, how am I supposed to quickly
judge your independent work if you hate algorithms and new tech? I'm not going
to pour through a repo; I don't get paid for that or care, to be honest.

If you're talking about PHP being better than JavaScript in a startup
interview, you're not going to be hired most likely. Startups typically use
new technology, and you clearly don't.

------
yarou
Is it weird that I find this entire blogpost eerily similar to PUA strategies?

I think it ultimately boils down to confidence. To use the dating analogy,
nothing drops the proverbial panties (or boxers, if you're into that sort of
thing) faster than having confidence. Being physically attractive (i.e. fit
and in shape) doesn't hurt either.

Take my analysis with a grain of salt, though. I happen to be hilariously bad
at interviewing, and don't get me started on dating.

~~~
emodendroket
I can't tell you how much dating advice I've read that advises you to be sure
you remember breadth- and depth-first search algorithms.

------
vegabook
Ummm, this should be titled 'how to pass an interview', period. Most of this
advice applies well outside of programming and reads like any of 1000 self-
help books of the past many decades. Sure there are a few specifics to coding
but all the themes are as old as the hills.

------
gaius
It you "mention C" in an effort to game the system, any competent interviewer
will eat you alive.

I remember when "having a Github" was a signal, as soon as word got out
everyone had one, but most were zero or near-zero original content.

------
gedy
"Whiteboard hazing" is the most apt description I've heard it called. Pass the
wringer, you can join the club.

~~~
digler999
Its good to see how people handle stress. You can weed out a lot of crybabies
by analyzing their performance under pressure, regardless of whether they
produce the "right answer".

~~~
ArtDev
This is not how to find people you actually want to work with.

~~~
rqebmm
On the bright side, it's how you find people you want to work for.

------
jlarocco
The point of most job interviews is to weed out people who need to read
articles like this one.

~~~
emodendroket
No it isn't. It's to weed out people who wouldn't think to or know where to
find it.

~~~
jlarocco
Rote memorization of a guide or following a "script" is not the same as
qualifying for a position.

A sufficiently experienced and knowledgeable person will be doing things
similar to what's in the guide because they've learned to do so through
experience, not because they read it in a silly guide.

People seeking out the guides are typically the same ones who _don 't_ have
the experience to back up what the guide tells them to do.

~~~
emodendroket
I'd guess very few people use every one of these things on a day-to-day basis
and in my experience the bigger companies actually encourage you to brush up
on algorithms before interviews with links to resources you can use. If you're
really hopeless it's not like two weeks of study are going to teach you
everything you need to know.

------
pklausler
I hated this article. A good technical interview reveals an aptitude for
programming or a lack of same, and can distinguish a true aptitude from an
ability to fake it. I've been interviewing programmers for a very long time
and I'm pretty good at avoiding "false positive" results with a few
straightforward questions.

If you have aptitude and talent, brush up on your algorithms and try to have
fun with the interview. If you don't, then I'm sorry, but maybe you'd be
happier doing something else.

~~~
onlyrealcuzzo
Care to mention these questions? Most companies are suffering HARD from false
positives. I'm sure a lot of people would love to know what's working for you.

Thanks!

~~~
pklausler
Well, I'm not going to spill my current repertoire, but in short it's all
about "programming in the small". Can you construct a precise Boolean
predicate to test for a well-defined condition? Do you "get" pointers and
recursion? Find sample problems in your own work.

~~~
vonmoltke
If it is something that loses value if "spilled" it probably is not as
valuable as you think.

