![](https://csdnimg.cn/release/download_crawler_static/10690081/bg11.jpg)
Cracking the Coding Interview
17
*OUFSWJFX8BS4UPSJFT | You Can (Maybe) Count On Me
:PV$BO$PVOUPO.F+VTU/PU6OUJM&BSMZ"GUFSOPPO
Ahhh, 1999. The crest of the dot-com bubble, and the tightest labor market in history. Our
company was racing to expand its development team, and we would have hired a German
Shepherd if it knew HTML. Instead, we wound up hiring Ian. We should’ve hired the dog.
Ian was a cheerful, friendly guy who had a gift of natural charisma. He got along fantasti-
cally with all of the interviewers, and seemed very intelligent. Skill-wise, he was adequate. He
hadn’t written a single line of computer code outside of his college courses, and didn’t even
have his own e-mail address. When we gave Ian the chance to ask us questions at the end of
the interview, he asked about exible work hours, and how soon he could take vacation time.
Instead of showing an interest in the career opportunities, or in company’s growth prospects,
he asked whether he could take the all-you-could-drink break room soda home with him.
The questions grew more bizarre from there.
Ian was very interested in our Legal Assistance benet. He wanted to know if it covered the
cost of ling lawsuits, if it covered him if he got sued himself, if it applied to any lawsuits he
currently was involved in, and if he could “theoretically” use it to sue the company itself. He
also asked us if he could use it to help him “x” some unpaid speeding tickets.
In any other year, that should have been it for Ian right there. But, in 1999, we were hiring
anybody who was even remotely competent. Ian collected paychecks from us for eighteen
months, and he was about as productive as a trac cone. He usually sauntered into the oce
around ten-thirty with some sort of lame excuse (by my count, he had to wait for the cable
guy sixteen times in a six-month period). He usually killed the morning by answering e-mail
and playing ping-pong, before breaking for a two-hour lunch. After lunch, it was more ping-
pong, and maybe an hour of writing bad code, before bolting the oce sometime around
three. He was the dictionary denition of unreliable.
Remember, your potential future team members need to know that they can rely on you.
And they need to know that you won’t need constant supervision and hand-holding. They
need to know that you’re able to gure things out on your own. One of the most important
messages that you, as a candidate, can convey in your interview is hiring me will make your
lives easier. In fact, this is a large part of the reason for the famously dicult interview ques-
tions at places like Amazon and Google; if you can handle that kind of unpredictable pres-
sure in an interview, then you stand a good chance of being useful to them on real projects.
To cite a more subtle example, once I was on a four person team that was desperately try-
ing to recruit new members to help work on an old pile of software. It was a real mess; we'd
inherited a nasty ball of spaghetti, and we needed people who could jump in, gure things
out, and be part of the solution.
There was one very smart fellow, Terry, who would have been a great asset for our team –
but we didn’t hire him, despite his excellent technical and personal skills. It was because he