
Interviewing in Silicon Valley - reikonomusha
http://symbo1ics.com/blog/?p=1709
======
balloot
I despise interviewing for software positions. Engineers love to treat
interviews like some kind of hazing. They're gonna make you quiver and sweat
and if you can still solve their stupid brainteaser maybe they'll give you the
honor of working with them. Problem being, this has basically nothing to do
with how good you'll be at the job. I spend 0% of a normal day with someone I
don't know staring me down and judging every line of code I write in realtime.

I much prefer medium sized offline coding challenges, both for myself and for
hiring my team. You give a good engineer a small project to work on, an he
should crush it. Because that actually has something to do with what engineers
do on a day to day basis. Personally, I get the job pretty much every time if
I am told to build a small project, and I crash and burn almost every time if
I get the SWAT team of surly technical interviewers.

It's worked fine for me because the small companies I like to work for are
more apt to give out the projects, but still I could do without some of the
awkward interviews I've gone through with companies who use the Google-like
process.

~~~
brightsize
I'm a software developer. By far the _best_ interview I've had in the past few
years was with a very small startup in NYC with some cool tech. We had a
fairly extensive and relatively detailed tech interview over the phone that
included mostly general questions like explaining how DNS lookups work. They
then gave me a fun, throw-away programming project to do offline in a day or
so that utilized their preferred stack, and they PAID ME with for it with a
$150 Amazon gift card. I can't tell you how many bonus points they earned with
me, both for the enjoyable, puzzle-free interview and for signalling that they
understood that my time had value. I was ultimately told that they had
"changed direction" and weren't going to hire at all, and I have no reason not
to believe them. I don't feel like my investment in time with them was wasted
or that I was insulted/abused in any way, quite the opposite and that was
refreshing.

~~~
throwaway1979
This sounds like an awesome idea on the part of the startup. Kudos to them!

------
mc-lovin
I think there is a lot of negative bias here, because people who do badly in
algorithms and data structure questions, or dislike them for some other
reason, are more likely to speak on the issue.

I think that these questions are good because they are difficult, and a
smarter more capable person is much more likely to get them right. Notice that
big tech companies have stopped with the "brainteaser" style questions like
how many potholes in Manhatten, but there is no move away from algorithms and
data structures questions. And I don't consider the format to be high
pressure. Apart from the pressure inherent in having to answer the question on
the spot, I never felt any pressure from the interviewer, they tended to be
very polite and mild mannered. At worst they didn't understand or agree with
my solution.

Telling people that these interview questions suck and they should look for
jobs where they don't have to answer them, is really bad advice. Some of the
best jobs (for most people) require them. If you face such an interview, the
very best thing you can do is study. I probably did 100 interview questions in
preparation for my job interviews.

~~~
dirktheman
Interesting point of view, which I don't share by the way. I think the right
person for the job is not per definition the smartest or the best at solving
equations during an interview.

Finding the right person for the job is more about getting a good fit with the
rest of the team. Being the smartest guy/girl on earth doesn't help you when
you have a shitty personality or can't work together with the rest of the
team. If I were to recruit a programmer, I'd look for past work (Github repos,
online projects), accomplishments and personality, rather than test results
that don't reflect the reality of the job in any way.

~~~
mc-lovin
Well it's hard to quantify the relative importance of personality and cultural
fit vs intelligence and programming ability. You can turn what you said
around, and say that you can be the nicest, coolest person in the world, but
if you are a fucking moron who can't code, you won't be very useful.

But the big tech companies seem to have settled on the current process, and
are therefore probably fairly happy with the people their interview process is
giving them. As to looking at previous projects, that makes sense but it might
be more time consuming to properly evaluate someone like that.

~~~
randomdata
The big tech companies haven't been happy with the people the interview
process have been giving them – all we heard about for a long time is about
how they couldn't find anyone to hire. Perhaps this settling you speak to
marks the end of developer shortages in the industry?

~~~
mc-lovin
Not really. These are two separate issues. If I am a gold panner, I might be
very satisfied with my gold panning technique, and yet complain that there is
a shortage of gold in the river.

------
dirktheman
Well written piece that shows what to me is the SV recruiting paradox: there
is a massive demand for programmers, yet companies make it really, really hard
to get a job. It's easier to start your own company without the interview
hassle and condescending attitude of some HR managers.

I might be out on a limb here, but it seems it's almost easier to raise money
for your startup than to get a job. Of course it gets a lot easier once you
have established a network of people so you can bypass the whole recruitment
process.

~~~
stevewilhelm
>> yet companies make it really, really hard to get a job.

It is much better to filter out some perfectly good candidates than
accidentally hire the wrong candidate.

The wrong hire can be very disruptive, and in some cases fatal for a company.
Firing the wrong hire is very, very hard.

>> but it seems it's almost easier to raise money for your startup than to get
a job

Raising money is like interviewing for three jobs at once: CEO, CFO, and CTO.

[EDIT] removed some platitudes and fixed fatal.

~~~
dirktheman
Hiring the wrong person is potentially dangerous for your business, there's no
denying that. However, the tendency today is the demand for hiring 'rockstar'
programmers for essentially pretty mundane jobs. This poses two problems: an
artificial shortage of qualified programmers, and if you manage to find one,
you hire an overqualified programmer who is likely to get bored and
unmotivated within a couple of weeks.

~~~
bane
> you manage to find one, you hire an overqualified programmer who is likely
> to get bored and unmotivated within a couple of weeks.

Or, to keep themselves interested, end up over-engineering even simple bits,
making their work a nightmare to maintain.

------
ultimoo
I am in grad school and live with roommates in the SV. Amongst the six of us,
we have interviewed at a cumulative of 20 big SV names in the last month and
of course we discuss the interviews frequently with one another.

Companies like Broadcom, Cisco, Juniper, Anritsu, Apple etc. solely rely on
the programming problems the OP talked about.

HP focuses on riddles and puzzles to a point where it is ridiculous and mind-
numbing (1 hours interview, two interviewers, about 15 riddles :-/)

There is however a marked difference in the way companies in SoMA, SF
interview you -- conceptual discussions, chatting about previous projects,
finding out about your open source contributions, asking you about what you
like about a certain language, talk about editors a little, etc. And I'm also
including companies like SCEA, who although a part of larger companies, behave
in this way.

Unfortunately none of us interviewed at Google or Facebook, so I have no
comments there.

P.S. Most of us have accepted offers at smaller companies in SoMA, SF.

~~~
wowoc
What's SoMA?

~~~
theunixbeard
An area of San Francisco:
<http://en.wikipedia.org/wiki/South_of_Market,_San_Francisco>

------
jmaskell
The urgency to interview, followed by the abrupt halt in communication isn't
something that is unique to Silicon Valley or engineering positions. I had it
a lot in London a couple of months ago for mostly product jobs.

It's incredibly unprofessional / downright rude - especially when so much
pressure is put on to get you through the interview process quickly. It also
means that I now have a negative opinion of a number of companies - and advise
friends against applying or interviewing there if approached.

I've been in a position of hiring before, and while it's not nice to tell
someone that they haven't got the job, it's the polite thing to do. Most
people are reasonable, and it increases the chances of them recommending your
company to others.

~~~
yitchelle
I have had similar experiences as well with the slow feedback on the
interview. Although I cannot confirm this, but I have heard that the lack of
communications is their way of avoiding any litigation action from the
candidate. They fear that any rejection can be mis-interpreted by the
candidate in such a way that litigation is possible. So no communications
equates to no chance of litigation.

------
nilkn
I personally would quite like an interview where I work _with_ the interviewer
to solve a problem or puzzle that he himself has not solved--as opposed to the
traditional setup where the interviewer acts as the all-knowing oracle who
happens to withhold the solution to this one problem. This could be difficult
to set up on a regular basis, though.

I actually had an interview somewhat like that recently. The team was about to
start working on a new feature for their software. We had a sort of round
table discussion of the feature and how to go about it. They actually didn't
have me write any code at all. We just discussed approaches to the problem,
algorithms, architecture design, potential problems, etc.

Another place had a pretty cool interview process. They were going to give me
a take-home project with a week to work on it and pay me market rate for it
(in the form of an Amazon gift card for a few hundred bucks). I didn't end up
doing it, though, as I took another offer right before they gave me the
project, so I voluntarily withdrew. Still, I think it was an interesting and
worthwhile idea.

~~~
ecspike
I think all take-home projects should pay market rate.

~~~
recursive
I suppose that cuts you out of the applicant pool for those positions then.

------
bengillies
This echoes my experiences about a year ago almost exactly (although I was
looking in London). The obscure programming problems are largely a waste of
time, but fairly non-threatening and generally ok (there were a few companies
that did group problem solving exercises instead which really impressed me).

The biggest issue that I found by far was communication. Especially in the
Silicon Valley based companies that were looking to hire in London at the
time. Communication times of a few weeks seemed fairly commonplace (with
contact still extremely positive after such a long wait). One company (I
suspect the same as the non-profit mentioned in TFA) took more than a month to
get to my second interview, during which time one interview was cancelled
about an hour before it was due, and one interviewer simply failed to turn up
with no explanation.

My limited experience is obviously no indicator of any wider issue, but if
that's generally how companies interview, then I'm really not surprised at all
that they find it difficult to hire talent.

------
woodchuck64
> [ Lots of coding puzzles and vague about that "very difficult problem"
> they're working on that requires expertise in 20 different technologies ]

I get it now. Silicon Valley job interviewing is white-collar gang initiation:
you have to show you can bear the pain and humiliation of getting
metaphorically beaten up and humiliated. It's not about getting the questions
right anymore than taking a fist in the face qualifies you to be an expert
Crip, it's about impressing someone of rank by the way you bleed.

~~~
ttrreeww
It's been like that for awhile now...

------
estebank

      > I emailed them back asking if they had any feedback from
      > my interviews, but I’ve failed to receive a response.
    

I've been bothered by this as well, because we want to improve ourselves, and
the best way to do so is through feedback. At the same time, you have to
understand that not everybody is like us, and enough people that _where_ given
that feedback in the past have used that opportunity to "argue" that they
really should have been hired or argue that the feedback was wrong. Between
helping a stranger improve and avoiding a potential headache for themselves,
as much as I would like to have had feedback on some interviews, I can't blame
anyone for avoiding the issue altogether.

    
    
      > Almost all interview questions I take a long time with. I 
      > probably have a 85–95% rate of solving puzzles—using almost 
      > all of the allotted time—on my own, and the rest I’ve needed 
      > a very small hint to get me in the right direction to begin 
      > with. I can’t think of an instance where I’ve been given the 
      > answer because of being unable to solve the problem.
    

Well, that's one problem right there. The kind of companies that ask you the
kind of questions that you say are beyond Fizz-Buzz, are usually just
starters, to get the ball rolling, give you confidence and keep iterating
after the first solution is reached if it isn't perfect, or by adding new
constraints to make it so you have to keep thinking.

The interviewer most likely has allotted time for 2-5 of these questions in
his interview, if you are taking all this time on the first one, then most
likely you are not going to be highly regarded, as the interviewer hasn't got
enough information to say wether the one question you answered is
representative of your skills.

    
    
      > Is a total of eight cumulative hours of interviewing with 
      > around seven different people not enough to get a good 
      > signal? What does this say about the interviewing process?
    

It says that they want to make sure they hire somebody who's "a good fit" and
the hiring pool is high enough that they can get away with false negatives.

    
    
      > Don’t sell me your product, sell me your challenges
    

The fact that they talk about the business instead of the tech, at least gives
you some confidence the company will not go belly up because they are selling
cuecats. Of course it's not the best way to entice a developer, but it's not
as much of a red flag to me as you make it out to be.

~~~
reikonomusha

        > Well, that's one problem right there. [...]
    

Of course it depends. Getting the ball rolling is probably not best done by
giving an NP-complete problem (subset sum) as a first exercise.

When presented with an interview question, I usually say "well, it can be
solved by doing $NAIVE_SOLUTION, just to get that out there, and I know you're
looking for a better one." By doing this, I've established that there is a
naive solution and that I'm going to spend time thinking of a better way.
Unfortunately, with these kinds of algorithmic puzzle problems, it's usually a
waste of time to give the naive solution in full detail, because no
incremental development will ever make it monumentally better unless some
cheap trick, like memoization, can be done.

    
    
        > The interviewer most likely has allotted time for 2-5 of these questions in
        > his interview
    

This is usually the case when the problems are easier. For example, "compute
the square root of a number" where the solution is, for the most part, cut-
and-dry. (Though I would never blame someone for taking longer if they have to
re-do the calculus by hand to rediscover the solution.) FizzBuzz is another.
Simple binary tree exercises are another.

As said, it entirely depends on the questions. To some interviewers, asking
"how do you traverse a binary tree" on-site probably would be a waste of time;
that is expected by a first-year CS student.

    
    
        > It says that they want to make sure they hire somebody who's "a good fit" and
        > the hiring pool is high enough that they can get away with false negatives.
    

This is the easy way to explain it, but I don't think it's a very good answer.
I don't think someone is a good fit if 7 people across 8 hours couldn't come
to a consensus. If there's that much controversy, what is another coding
question going to tell?

    
    
        > The fact that they talk about the business [...]
    

This isn't an issue. In fact, it's good to talk about the business and
mechanics thereof. But spending half an hour preaching to an interviewee about
why the product is so good from a consumer standpoint isn't the best way to
capitalize on either person's time. I think, aside from a brief introduction,
that propaganda should be disseminated when the interviewee asks questions
about the product.

In addition to the above, I think it's a problem when the scales tip way in
favor of talking about the product instead of the engineering. If the product
gets a 30 minute talk and engineering gets a 5-10 minute talk, I think it's
indicative about the priorities of the company toward its employees.

~~~
ecdavis
> "well, it can be solved by doing $NAIVE_SOLUTION, just to get that out
> there, and I know you're looking for a better one."

I'm at the very beginning of my career, having just accepted a new grad
position, but I thought I'd offer my opinion on this: just implement the naive
solution. If you're really unsure, ask them if they're OK with you doing that.
In my very first interview I took the approach you just described and the
interviewer actually stopped me as I was brainstorming other ideas and said,
"Just work on the basic solution and we can talk about ways of improving it
later." In subsequent interviews I've implemented the basic solution first
then talked about the drawbacks of that approach with the interviewer,
possible improvements that could be made, etc.

Now, most of the problems I was given were far simpler than what was described
in the OP. I do think I was very fortunate to get interviewers who weren't
just looking for an outside-the-box solution to some brainteaser they'd
concocted. Nonetheless, I think it might be worth considering just taking the
naive approach (and telling them what you're doing any why) rather than
spending a lot of time trying to come up with a perfect solution.

~~~
reikonomusha
If they request I spell out the naive solution, I certainly oblige. But if
it's clear to both the interviewer and me that they are looking for that
particular solution, then I won't spend time writing it out. So far, this
approach of assuming they want the best solution—while acknowledging the
simple solution exists along with a brief sketch of it—seems to be agreeable.

~~~
eclipxe
Your posts leads us to believe that this is in fact, not agreeable.

~~~
reikonomusha
Why's that? I've used that technique in places from which I've received offers
(from small non-profits to large multi-billion corps). I think it's a
realistic thing to do. If they want me to code the naive way, they can just
say so. If they want a better solution, and I sketch out verbally the naive
solution and they're happy, why magnify into it?

The non-agreeable part is the difficulty with finding a better solution, and
spending inordinate amounts of time searching for one.

------
Schwolop
The whole interviewing process is ass-backwards for smart people.

I have little interest in working for a company where I'm going to struggle to
do the job. I'm not going to apply for a job where I'd be out of my depth for
any more than a month or so, because that sort of "if I don't get better at
this soon I'm going to be fired" sort of stress is horrible. I want to find a
job where I can succeed right off the bat, learn new things and get better
over time, and where I can see myself staying for several years at least. No
one wants to be a job hopper; it's a symptom of poor interviewing on the
interviewee's part.

From my point of view then, I know before I even get to the interview that I'm
perfectly well suited for the company and can do the job - if I wasn't, I
wouldn't have applied. So I approach interviews in reverse: I'm going to grill
_you_ , your team, the baristas in the nearest coffee shop, and anyone I can
find on LinkedIn who's recently left. If you ask me stupid puzzle questions
that have little to do with what I've come to understand the job entails, I'm
going to take that as a sign that your company is less than functional in the
interviewing arena, and I know from experience that that extends to the actual
engineering too.

Interviewers seem to treat these types of questions as shit filters. I do
exactly the same. If you ask them, that's a smell.

~~~
lutorm
_I know before I even get to the interview that I'm perfectly well suited for
the company and can do the job - if I wasn't, I wouldn't have applied._

You do realize that just because you think you are perfectly well suited for
the job, that doesn't mean that the prospective employer has any way of
knowing that or that it's even true, right?

Sure, the company needs to show that they are a place you want to work at, but
you should realize that you also need to show the company that you are someone
they want to work with.

~~~
Schwolop
Oh absolutely - but _both_ parties need to work this out. They need to work
out that I'm suitable, and I (already knowing this, or at least thinking it)
need to work out whether they're suitable for me.

The best interviews are two-way streets.

------
orangethirty
I personally have had a better experience working with companies outside of
SV. Better pay, hours, and less stress. Plus gasp!, actual profits (which are
important for long term contracts and or employment).

------
steven2012
I've been interviewing a lot of candidates over the last couple of months and
I also despise trivia question interviews. The approach I've been taking is
using a FizzBuzz type of question, but a bit more complex. I couldn't believe
the number of candidates that have trouble with things like manipulating two
arrays, which I feel is a basic level of expectation for a programmer. If I
spend all hour on this relatively simple question, they are a "no" from me.
About 10% of the interviewers pass this problem quickly enough to warrant the
second question I ask. Frankly, I'm shocked at how under-prepared people are
for whiteboard questions, regardless of how stupid it is. You would expect
that by now, people would know to expect them.

The second question is something that is hard, but I tell them upfront that I
don't know the answer to the question, to put them at ease, and that I want to
work with them together on the question. I also ask for pseudo-code, I don't
care about syntax. I think this usually gives me a lot of insight into how
good the candidate is. I had one recent candidate that wasn't a spectacular
coder (he had bugs in his code and he couldn't see them until I almost had to
point it out to him), but he had this intuitive ability to zero-in on the most
efficient algorithm for both questions that I asked. I felt he was good enough
to be hired.

However, some other members of the team, while agreeing with my technical
assessment, rejected him because of culture fit. He was a bit aloof and kind
of weird. Some of the team felt like he might not be pleasant to work with, so
they thought it was better to be safe than sorry. So sure, technical chops
matter, but so does personality.

~~~
nfoz
I code all day. I don't have a whiteboard, I don't use a whiteboard. I can
expect whiteboard-questions but that doesn't help anything. Am I supposed to
practice them? Why can't you be happy just giving me a laptop, or a pad and
paper, or something I'm used to?

~~~
eikaterine
I can code on a whiteboard, but it's certainly not something I enjoy. So when
interviewing, I often ask for pen and paper. Just like a whiteboard, I have to
write code without a computer and IDE, but unlike a whiteboard, I don't have
to stand and write code in a position I'm not used to, with a tool I'm not
used to (and let's be honest, whiteboard markers are kind of a pain to write
with).

If I'm going to be disqualified based on my choice of writing medium, well, I
probably wouldn't be that keen on working there anyway.

------
dclowd9901
Let me posit a couple things to my fellow interviewing engineers here:

1) I like to ask questions during interviews. I hate the whole "I'm a
brilliant guy charade." I'm not. You're not. Einstein was. Deal with it.

2) And I especially don't have a care for rote memorization bullshit for
things I can look up in less time than it would take me to remember. I'm a
thinker, not a fucking textbook.

So, if you said to me "do whatever using x algorithm", and I said to you, "I
don't know x algorithm by heart; could you tell me what it is, and I'll
implement it in one of the languages I'm proficient in?" would that just
completely turn you off to me as a candidate?

~~~
jerrya
I tend to say, and this has not worked well for me, "Uh, I would google it,
and see what other people have done, and learn from their experiences, and
either use their license appropriate code, and or their knowledge and
experience and consider that and how it would fit into our architecture and
start from there".

Because that's how I engineer. I try to stand on the shoulders of others. And
Google provides such an excellent step-stool.

But as I've said, that doesn't seem to go over well.

Implement _your favorite_ sort algorithm? I don't know that algorithm, I tend
to use the sort algorithm that comes along with the libraries of the language
I am using on the assumption that a) it's good enough until proven otherwise,
b) it's well implemented and mostly bug free by the language designers, and c)
schedule is paramount, the most bummed out, tweaked out, sort is not.

~~~
dclowd9901
Yeah, but this differs in what I'm talking about, in that I am going to prove
to you that I'm good at doing the most important part of the task:
implementing an idea into code.

I think, regardless of memorizing a specific algorithm, if I can prove that I
can understand something after only knowing about it for a few seconds, and
then actually create a mechanism that works with that understanding, that's
really what an interviewer would want to see.

~~~
jerrya
I thought that by telling them I would use google to learn what other people
have already learned about the task, I WAS proving to them I know how to
implement their ideas into code.

I am more worried about the folks that just jump into a complex project
without seeing if someone has already done this beforehand.

------
bane
Followup: (I can't edit my old post anymore), it's informative to actually
read lots and lots of after-interview writeups where the candidate had an
overall negative experience. Consistent problems emerge:

Glassdoor is _awesome_ for this:

Some SV-companies with higher than average negative experience ratings:

[http://www.glassdoor.com/Interview/Zynga-Interview-
Questions...](http://www.glassdoor.com/Interview/Zynga-Interview-
Questions-E243552.htm)

Lots of "after the interview I appeared to have been dropped into a black hole
since nobody's told me if I've moved on or not".

[http://www.glassdoor.com/Interview/Palantir-Technologies-
Int...](http://www.glassdoor.com/Interview/Palantir-Technologies-Interview-
Questions-E236375.htm)

Unbelievably disorganized hiring process by the sounds of it. Numerous,
detailed reviews of interviewers simply not showing up, poor communication
with the recruiting staff, etc. Weird cult-like experiences. It sounds like a
cattle call. I actually couldn't find a company with a higher negative
experience score.

[http://www.glassdoor.com/Interview/eBay-Interview-
Questions-...](http://www.glassdoor.com/Interview/eBay-Interview-
Questions-E7853.htm)

Unbelievably poor communication. Amateurish interviews. No follow up from the
recruiters, candidates are simply left in limbo.

There's a fair number of obviously bad candidates who were miffed. But there's
tons and tons of people who were probably good candidates, but were simply
jerked around for weeks on end. In some cases, the company's own internal
processes are so broken they couldn't even conduct the interviews correctly.

Some with more positive ratings:

[http://www.glassdoor.com/Interview/Facebook-Interview-
Questi...](http://www.glassdoor.com/Interview/Facebook-Interview-
Questions-E40772.htm)

[http://www.glassdoor.com/Interview/Google-Interview-
Question...](http://www.glassdoor.com/Interview/Google-Interview-
Questions-E9079.htm)

[http://www.glassdoor.com/Interview/Amazon-com-Interview-
Ques...](http://www.glassdoor.com/Interview/Amazon-com-Interview-
Questions-E6036.htm)

[http://www.glassdoor.com/Interview/Microsoft-Interview-
Quest...](http://www.glassdoor.com/Interview/Microsoft-Interview-
Questions-E1651.htm)

See the difference in the candidate responses? You're doing something right if
people get rejected but say they had a positive interview experience.

------
maaaats
> I am especially bewildered by the fact hard CS questions are given to
> prospective interviewers who will only be doing boilerplate PHP development
> for the actual job.

I agree. I think it's fun to solve these puzzles, but often they're of no
relevance to the actual job. Better if they asked me questions from their
domain or about the technology they're using.

------
robmil
I've long since abandoned trying to do programming tests when interviewing
coders. Instead, I work through a problem with them in a sort of socratic
method; I play devil's advocate to them while they flesh out how they'd
approach the problem.

It's far more illuminating, and a far better reflection of their worth as a
candidate, than their ability to go off into a room somewhere and work through
a problem alone. I'm much more interested in someone who thinks well than who
codes well (since the latter can easily be trained).

~~~
leklund
This is the same approach we've taken with candidates. We start with a phone
screen and then a simple coding problem submitted via email. When we bring
them in for an interview they spend time with with a few developers working
collaboratively on a problem. If possible, it's a bit of work from the current
iteration. Working together on real-world code has been surprisingly
effective. I was skeptical at first, but it has been very helpful in weeding
out candidates who had good cv's and probably could have coded a really great
algorithm to traverse a binary tree but weren't great with solving real world
problems.

------
dsowers
Here's the lesson: Don't play the game.

Don't spend all of your time studying coding puzzles to answer questions
correctly to people who are unlikely to hire you anyway. It's just a
ridiculous waste of an intelligent mind. Spend your time building something
interesting that actually helps the world. Build fun and interesting projects
with this time. These projects might give you a career or a job that is smart
enough to realize that you don't need to be given the fizzbuzz test.

~~~
reikonomusha
It might not be advantageous to spend all of one's personal time figuring out
coding puzzles, but I wouldn't be ignorant of the fact they will be brought
up. Unless you develop an open source project which gets love from thousands
of people and becomes very popular, few companies are going to use just that
as a basis for hiring you.

Unfortunately, this also conflicts with the fact most people do need to make a
living in order to survive. Unless it's possible for one to live without
income from a job, then relying on "being noticed" will probably not be a
fruitful avenue.

~~~
danielweber
Yeah, the "be an open source coder to get a job" really doesn't scale. It
already feels like I'm in a maze when I look for a tool to solve a certain
problem, and have to wade through a bunch of projects that it takes a while to
evaluate. The search costs are huge.

You probably aren't making the world any better by adding yet another open
source project to it. If we want people to do this to get jobs, we are
encouraging them to help drown us.

------
krat0sprakhar
> In most interviews I’ve had, engineers and recruiters I speak to spend a
> great deal of time gloating about their product, almost as if they are
> trying to sell me their product. The fact of the matter is, I am not
> interested in being spoken to as if I would be a potential consumer of your
> product. I want to be spoken to as if I would be a potential employee
> working on your product.

Spot on!

~~~
rdl
Actually, as soon as you've decided not to hire someone, it actually makes
sense to shift the whole conversation to "selling the product" and otherwise
making it likely the person, who takes a job elsewhere, will either refer
other (hopefully better) candidates, or use your product.

~~~
reikonomusha
It's often the first thing (selling the product) companies talk about, not the
last, however.

------
bokglobule
From reading the post, my takeaway is a guy who's probably going to struggle
for awhile to find a position. When an engineer says that they only care about
the technology and not the product, that would set off my red flags
immediately. Frankly, in 99% of the cases, it's the product that pays the
bills including the salaries of the team. If I had interviewed him, I probably
would have suggested he look for a position in a R&D group in a large company
with the funds to do that sort of software engineering.

I find many of the interview puzzles that people have posted on the Web that
they've encountered at the Big Name companies as often a bit silly. Having
said that, asking software developers to implement a solution to a common
programming problem - "navigating a tree using recursion", etc. is perfectly
reasonable. I've found more than a few software devs who have great looking
resumes but who have no idea what recursion is, what a tree is used for as a
data structure, etc. And I consider this the basic, easy, 1st year undergrad
type stuff.

If there's an undercurrent to all of the comments here, it's that we still
don't really have a good way to sift through the good from the really-not-so-
good developers _quickly_. The programming tests and puzzles are a proxy for
this and they only work so far - some people like to think through issues more
before coding, or tend to freeze under this on-the-spot pressure. Doesn't mean
that they aren't a good, competent developer you'd want on your team; my
experience is that the guys who blurt out very quick answers can sometimes
write the worst code.

------
bluepanda_
I've seen so many posts about interview rants, including one I wrote myself,
that I feel like the problem lies in the higher demand than supply of
positions, and that interviews, not matter what bad feedback they seem to
give, aren't that poorly designed.

~~~
throwaway1979
You raise a valid point. Back in the old dotcom days, a body that could this
thing called HTML got a job. While it seems we are in a tech boom (based on
stories of 150K salaries in SF, oodles of stock options at established social
media companies, etc.), perhaps we aren't. In the NYC area, my jaw has dropped
when I see the large number of smallish startups working from co-working
spaces. Are these people who shunned lucrative jobs or just couldn't get one?

------
bane
I agree with this article that communication with companies is getting
absurdly poor. With all these communications channels available, why is it so
hard to send a quick email? Don't have time because of too many candidates?
Maybe you shouldn't have more candidates than you have time to handle.

I've reached a point in my career where I'm not interested in engineering
positions anymore (a great motivator has been to avoid the absurd SV-style
interview). SV-style companies don't know what to do in these situations, they
have an open position, I have the experience and skill set, let's have a
conversation about the work I've done and what your needs are.

Problem is, nobody in the company knows how to hire for these positions and
they seem to be done based on word of mouth or through the networks of the
investors or other seniors in the company. In a couple of interviews at these
companies, they plan for the usual all-day interview, and then I sit there in
front of an interviewer who is simply at a loss for what to ask me.

On occasion they haul out a brain teaser, but I usually stop that with a "you
do realize the position that you are hiring for is not one where solving brain
teasers will be a reflection of the kind of work I'll be doing". This rings
some alarm bells as some of the larger SV companies have found themselves on
the business end of a law suit for this. Asking prospective project managers
nonsense questions during an interview offers no information to the hiring
committee about the suitability of a candidate. This can create a legal
liability for the company if the unhired candidates feel they've been
discriminated against -- especially if the company just hires somebody they
know anyway -- proving that the position wasn't filled on a level playing
field for all the candidates.

One other problem I've faced, I simply make too much money these days. In an
interview with a now very large company that exactly matches the format in
this article, I made it through the interview gauntlets and finally got to the
compensation round:

"So what kind of compensation are you looking for?"

"Well, I made this much last year, I'd like to make at least that much this
year and going forward."

 _blank stare of shock_ "y-y-you made how much?"

"Well, it was a mix of sources, my base was this, I made this much in bonuses
and additional grants, and I was helpful in a few sales and earned this much
commission. I don't expect that this job is commissionable, but I'm open to
alternate mixes of compensation so long as my base stays about the same."

"y-y-you realize not even the CEO is pulling down that much base?"

"I'm afraid I'm not privy to your company's compensation packages, but I know
that the CEO reported a few tens of millions in stock grants last year, I'm
not expecting _that_ much, but if you feel the need to offer a lower base, I'd
like to expedite the vesting schedule by a year then"

"I-I-I.....I'll see what I can do."

And that ended that job right there. I received a very nice call with a
rejection a week later.

Another anecdote, a friend of mine interviewed for a VP position with another
major SV company, he got through the initial rounds based on his education
(Ivy-League) and other credentials. During the interview they decided to do
the equivalent of an engineering-style interview...the recruiting team had
clearly dug deep into the bowels of some undergrad finance textbooks, and
asked him to derive a number of finance formulae he hadn't seen or cared about
in 20 years. It was utterly random and doomed to failure. He went on to other
companies where we was quite successful, while that position remained open for
the better part of two years before finally being filled with a friend of one
of the investors.

The best places I've worked (as an engineer and otherwise) have been the ones
that don't engage in this nonsense. I can see a simple fizzbuzz test being a
prescreen as being useful, but just sitting down with a candidate and having a
conversation about their resume seems to work best. Bonus, it's respectful of
the candidate. Unlike a great many companies, you've actually taken the time
to look at their resume. If you recognize something on the resume, ask them
some penetrating questions and dig into what they know. If you don't recognize
something, engage them to teach you about it. Competent people are competent
at talking about their job. Ask them things like "can you give me examples of
where you applied algorithm design or at least some complexity theory in a
job?" If they give an example, probe deeper, have them talk in depth about the
algorithm, see what they remember from their undergrad about big-O. Or "what
was the most difficult integration you've ever faced?" followed with a "why?".
Dig in, make it a conversation. Let them become a teacher during the
interview, where they teach you about what they know and about their life. Ask
questions like a student would. It's respectful, humble and draws unbelievable
amounts of information from a candidate.

You'll quickly learn what kinds of things they know, what they don't know and
what they're weak at. You'll also learn about their soft skills, like
communication. Instead of playing an insipid game of cat and mouse, you'll
learn about the _person_ you're hiring. Ain't that what YC looks for?

~~~
tptacek
This is a good comment. Some nits I'd like to pick:

* Companies aren't required to provide a level playing field to applicants. I think you've alluded here to discrimination against protected classes; that is, you're suggesting that someone could get an unnecessarily hard interview and use it as evidence that they were constructively rejected for their race or gender. That could happen, but most companies probably use the same terrible interview for everyone but their friends, which, while unethical, is lawful.

* In our experience, the resume conversation is the second-worst hiring signal, after the trivia interview we're discussing here. The ability to sound smart while talking about your experience involves a set of skills usually disjoint from those of the job. Every hiring mistake I've made in my career has involved someone who could "talk the talk"; in fact, many times, those people can also, if forced at gunpoint, "walk the walk", which makes their unsuitability all the harder to spot.

I'm an advocate for work-sample tests: have a standard set of (reasonably
small) problems that are representative of the work you do and give them to
all candidates so you can grade them. After we started doing this, it quickly
became apparent that I didn't even need to have much insight into what
reasonable or "good" solutions to our challenges were, because I could just
look how good hires/candidates had solved those problems in the past.

~~~
dionidium
_That could happen, but most companies probably use the same terrible
interview for everyone but their friends, which, while unethical, is lawful._

Wait, why is it unethical? It's frustrating and inconvenient and sucks for
everyone but their friends. But, unethical? On what grounds? I don't have an
obligation to give strangers the same favors I give my friends, do I?

~~~
bane
You have an obligation not to waste people's time, especially if you are
putting up the facade that they might actually be in the running. The modern
interview process can take weeks or even months to get through. If you're just
going to hire your friends, can you give the other candidates those weeks or
months of their lives back?

~~~
dionidium
Your reply and the one below assume that the choices are mutually exclusive.
That was not implied and is an unnecessary assumption.

------
throwaway1979
I wonder what would happen if perspective job seekers just say that they won't
do coding questions in interviews? Moreover, if they insist that interviews
can't be longer than 1 hour total, with a maximum of 1 phone screen. Oh .. to
top that off, candidates insist they get told their fate within a week or less
by email. If only ...

~~~
danielweber
Then they'll find someone who will.

As a candidate, I like coding questions. There are certain jobs where coding
questions are usually not worth it ("we need someone to code up this website
in PHP"), but I'm not looking for those jobs.

------
rahilsondhi
"Don’t sell me your product, sell me your challenges"

I actually care about the product equally if not more than the engineering
challenges. I write code to build products and businesses, not for the sake of
engineering. I'm a bit different though :)

------
jcarpio
>>Almost always, communication is done over email with a recruiter, and the
average response time is several hours to a day.

How about trying a different method? Instead of emailing a recruiter (or the
company), try calling. This is signaling that you're more serious than someone
who's just following up with an email (think of the volume of the candidate
pool you're in) and distinguishes yourself. Even better, at the end of the
interview you could plant the seed for a follow up, like "It's been great
meeting you, blah, blah, blah…I'd like to check in with with you next Tuesday
(or whatever) at 10am with a brief phone call, as I've got other positions to
consider and I know you've got other candidates…"

>>They then emailed me asking if I’d like to stop by their office for a few
hours for an on-site interview. I responded after a couple days…

then later the OP says

>>larger companies, such as Facebook, Amazon, or Apple, are very expedient
with scheduling and setting things up, and keeping the loop. This is extremely
to their advantage.

Time is of the essence, but I understand you might have been busy. Probably
not too busy for a quick follow up email to set up the interview. And, if you
don't hear back anyway, be tenacious and call them.

>>A friend told me that I should take the strategy of sending email after
email until they give me some sort of response. (“Stop sending us damn emails.
We don’t want you.”) I’ve not really done this, but I’ve done more than what I
think I am responsible for doing…

Responsible for doing? A different way of thinking about it would be to think
about being responsible to yourself, not them. You want the job; are you doing
everything you can to get this job? See stuff by Ramit Sethi for interview
tips.

------
codecool
I have also encountered this while interviewing for the couple of jobs. I
thought I did not study well and that's why could not solve the problems in
front of the interviewer! In fact, when I am able to solve bigger problems
while developing live projects. Nice post and it echoes something which has
happened to all of us at some point in time.

------
rdl
Normally you know someone in the company and ask that person for information
on how your interviews went, how your application is being handled, etc.

I don't think I'd want to work anywhere where I didn't have at least some
loose connection to an investor or employee.

------
imsofuture
If you think "Explain design decisions and trade-offs of different
techniques." is a 'puzzle'... Perhaps that explains a lot.

------
ttrreeww
And then they claim they can't find anyone and push for H-1B visa...

