
Ask HN: Why are Silicon Valley interviews such a drag now? - algoal
2 people I know and I are in the process of looking for new jobs.<p>My first friend is almost 20 years my junior, but a fantastic coder.  He is someone that every company would want.  He&#x27;s smart, curious, has initiative, and has a lot of wisdom behind the way he codes despite his youth.  He&#x27;s fluent in Java, Scala, Python and has built everything from simple web services to entire parsing engines and he does it because he&#x27;s genuinely interested in the work he does.<p>My other friend is 10 years my junior, but also great.  He&#x27;s an official Apache committer, and has worked on some really great projects for some well-known companies.  He also has worked on a lot of side projects that got picked up by his employers in various forms and he works his butt off every day.<p>My two friends are people that any company would be lucky to have.  But all three of us are very reluctant to start interviewing because we all know how much interviewing really really SUCKS.  Basically we are forced to write whiteboard code for 4-5 hours on topics that we may or may not know.  If we don&#x27;t know it, we&#x27;re fucked and we might as well give up because everyone appears to want perfection.  But the range of questions we can be asked on an interview is so wide, you can&#x27;t expect someone to know EVERYTHING.<p>It seems to me that interviewing in Silicon Valley is really broken if my friends are reluctant to start interviewing, despite how great they are and how much of an asset they would be to ANY company.<p>Is there a site besides glassdoor that details or rates a company&#x27;s interview process?  It would be sad if we all end up choosing companies based on their interview process, but it&#x27;s a lot better than wasting our time and PTO days going for interviews and then getting blown out of the water because one interviewer wants us to code a particular dynamic programming question the way they are picturing in their head.
======
luke_s
If you are looking for a job, I cannot recommend giving technical
presentations at user groups highly enough...

As you have pointed out the dynamic of interviews sucks. A potential employer
will be seeing dozens of people for a position and comparing you to all of
them. You will be talking on a topic decided by the employer which you may or
may not know anything about.

Giving technical presentations inverts this dynamic beautifully. Instead of
one position and many candidates, there is one of you and potentially dozens
of people in the room looking to hire. Instead of doing white board problems
in a domain you may not know about, you will be talking on a topic that you
KNOW MORE ABOUT than anybody else in the room! Instead of speaking off the
cuff in an interview, you can polish your presentation for weeks in advance.

I am a freelancer. Every time I have done a technical presentation at a users
group I have picked up at least one job out of it. Many of the people at the
users group are looking for employees. They are always disappointed to find
out I'm not looking for a full time position.

~~~
sbfeibish
Writing a book is another way to raise your profile. Just don't expect to make
a fortune from publishing the book. Making YouTube videos is along those same
lines. See Derek Banas or SlideNerd on YouTube.

~~~
sbfeibish
Just wanted to add. With the videos. Don't give it all away. "Make them pay
for what they can't get for free."

------
azakai
> But all three of us are very reluctant to start interviewing because we all
> know how much interviewing really really SUCKS.

Have you interviewed much recently, or are you going on what you hear about
bad things in the interview process? (The bad stuff tends to get more
mentions.)

It might not be as bad as you think. Yes, some amount of whiteboard work is
common. But it shouldn't be about "topics you may or may not know" \- that
sounds bizarre to me. You should be tested on a language you know, and on a
problem that a reasonable person would be able to solve. Also, the focus is
often on how you approach the problem, not if you write up a perfect solution
or not.

Overall, what you describe sounds like a horror story ("one interviewer wants
us to code a particular dynamic programming question the way they are
picturing in their head"). I don't think that's as common as you appear to
think.

It sounds like you are reluctant to even start interviewing. Why not try, and
see how it goes?

~~~
zerr
> Also, the focus is often on how you approach the problem, not if you write
> up a perfect solution or not.

This is a common misconception. Unfortunately, most (read 99%) interviewers
expect you to come up with _exactly_ the same solution they have in mind (or
in paper/screen in front of them). Even if your solution is _correct_ but
different, as soon as you start to diverge from their solution, you're red-
flagged.

~~~
azakai
I'm not sure how you can be so certain? (99% of interviewers..?)

I interviewed a bunch, but not for a few years. More recently, I've been on
the other side of things. In all my experience: yes, some people expect a very
specific answer from you, but not most.

Most people look at how you approach the problem, how you solve it, and what
questions you ask about it if you need any clarifications. You can often tell
someone is a good programmer even if they don't fully solve a problem, or if
they happen to pick an approach that doesn't work out.

Again, that's my personal experience and knowledge, so I can't be sure how
common it is.

~~~
zerr
99% is exaggeration (or "hyperbolation" ), but I wanted to highlight the
issue. From my personal experience, and from what I hear from others. In fact,
I've never experienced "wants to know how you approach the problem" moment
ever.

------
santoriv
I periodically see posts about how hard it is to get a job as a computer
programmer on this forum. I think I have a different point of view on this
one.

I previously worked as a classical orchestral musician.

In the entire United States, there are a maybe about 10 full time jobs open
per year for any given instrument (excepting strings). For most instruments,
there are thousands of music performance majors who graduate from colleges
around the US each year.

When there is an audition, people fly to the audition at their own expense
from all over the world. If you are even permitted to audition for the
orchestra, you will face between 100 and 300 competitors. Almost everyone at
these auditions has at least 15 years of playing experience and advanced
(expensive) degrees. In the initial round, players have between 3 and 5
minutes to advance. Often the audition will consist of many rounds that will
span 4 or 5 days (depending on the number of candidates).

Even if you win the audition, you don't necessarily have the gig. You are
often on a six month to one year trial. It is very common for musicians to win
an audition, play with an orchestra for a year, and then lose the job, never
to win an audition ever again. It is also common for a musician to win a job,
only to find that the orchestra is insolvent a few years later.

Often people will spend a decade going to auditions around the US before they
win a position or just give up.

The last audition I attended was with the San Antonio Symphony. There were
over 100 players at the audition from all around the US. The base salary for
the San Antonio Symphony is $26K per year.

By contrast, the last time I was in San Francisco (2.5 years ago), I applied
to about 80 web development jobs in 1 week. At the end of the week I had
landed a job that paid $120K per year, great health care, free massages once a
week, and all the food I can eat. I had 1.5 years of professional development
experience and no CS degree.

~~~
anthony_barker
Ironically one of my best hires was just finishing his degree in particle
theoretical physics at a top school. No puzzles at all - all questions were
focused on would we want to work with this person.

I figured his physics background pretty much proved he can figure puzzles out.
I did call his thesis advisor as a reference.

Your comparison with music kind of reminds be of people applying for unique
faculty positions in Universities. It sounds like is that there are lots of
qualified applicants and not many decent jobs.

------
aorloff
There are 2 problems these days :

1\. Companies think they are hot shit.

2\. The interviewers are all pretty junior and actually have no idea what they
are looking for, so instead they try to grill everyone in some perceived
gauntlet.

The reality is that companies need experienced people (of all ages). And that
the gauntlet exercise is supposed to do 2 things - first of all, demonstrate
that people know a bit about some kind of software development / CS
experience. Second of all, and this one is missed a lot, its a chance to see
what someone's personality is like trying to solve a problem.

Experienced interviewers know that its not about trying to throw problems at
people until you exhaust them, its about determining if you want to be on the
team with someone when a difficult problem arises (and uses as a proxy for
this, how do they react to solving a problem right now in front of you).

Companies are about culture - there are still companies out there that do have
cool engineering cultures (and some of them are hot shit).

~~~
__Joker
Personal experience/ Ancedote about (2). Sometimes interviewers (may be new or
inexperiences) just try to prove that they are hot shit. And feels like they
forget that the objective of interview is not to establish who is superior
rather if the candidate has the skills what they are looking for. This
happened couple of times to me.

------
skynetv2
I interviewed for Google two times, FB one time and Amazon once. I hated every
single one of those interviews. I got another call from Google and I told the
guy if he is expecting me to go on a 2-3 month interview loop with one day of
hoping to give the answer the interviewer wants (on those situational
questions) than what makes sense in the context with limited info, deal with
guys who think they are the gods of the universe ... i am not interested.

~~~
droidist2
Good for you. Google can get away with this garbage because so many people
would sell their girlfriend to work there. It's good to hear about people not
taking their crap. There are plenty of great places to work.

~~~
mentat
"would sell their girlfriend"

Really not appropriate here.

~~~
senorito
"Really not appropriate here."

Really not appropriate here.

~~~
mentat
Karma 6, probably all for this. This community is going to crap.

~~~
mentat
Please burn more karma for me, loving this.

~~~
senorito
see reply - are you happy now?

~~~
mentat
Yes, yes I am. You're showing me good.

------
brendangregg
Yes, SV interviews can be pretty bad, and I've been through the whiteboard
coding style ones myself, and in one case probably faired badly. As I was
trying damn hard to remember stuff from 2nd year software engineering class, I
was also wondering why the interview was focusing on a skill I hadn't used
since University, and not, instead, questioning any of the skills I've been
using for the past 10 years -- and which were relevant to the actual job. My
regret is not walking out half way through that interview.

Not all companies interview poorly. My Netflix interviews were great, and
focused on what value I can bring to the company, down to discussing specific
projects and tasks I could begin work on. Note that this wasn't strictly a
programming role, but then, nor was the other company who did have me do
whiteboard coding.

As for more programming roles: can we come up with a better interview
technique? How about this:

    
    
      - Ask the candidate for several URLs to code they have written (eg, github).
      - Select some code beforehand and print it out.
      - During the interview, ask the interviewee to explain their own code.
      Explain choices, rationale, how they tested it, how they developed it, etc.
    

edit: formatting

~~~
logn
That's how I got my first job out of college. Actually when I walked into the
interview room, they had my program on a projector, the code loaded into an
IDE, and asked me to explain everything. Then they loaded their apps on to the
projectors and basically did the inverse for me. A very nice interview. The
final portion was their most junior developer who told me just to ask whatever
questions I wanted that would help me decide whether I wanted to work there.

------
downandout
The funny part about this is that the founders of these startups, who in many
cases wrote the code that got the funding to start hiring programmers,
couldn't come close to passing these interviews themselves. They also in many
cases aren't very good programmers, and are looking to hire people better than
they are for rewards that won't come close to what the founders receive.

Case in point: I recently emailed a simple question to the Magic
(getmagic.com) folks. I asked why they didn't make the short code on their
home page (which used to be a 10 digit phone number) a clickable SMS link. It
seems obvious right? They are asking people to send them an SMS. Why make
people either memorize/type or copy/paste? But not only did they not think of
it, they didn't respond to my email and haven't implemented it. These guys
basically got a check for $12M at a $40M valuation after 1 weekend of buzz and
couldn't figure this out on their own - and either could the VC's that wrote
them the check apparently (and they're in charge of billions of dollars).

So walking into these interviews (especially at recent startups), understand
that if you have a bad interview experience, then the people that are already
there probably aren't very good at what they do. Bad interviews tend to be
conducted by bad managers/coders that are suffering from extreme bouts of
justifiable impostor syndrome. If you are not hired after a bad interview
experience, it's probably a good thing, because you wouldn't want to work
everyday with the people that designed that experience in the first place.

~~~
Cymen
I agree -- the interview process is a direct reflection of the organization
you are interviewing for and you should judge your potential employer on how
they interview you.

------
andrew-d
If you or your friends are interested, you should check out Matasano
(disclaimer: I work there). Our hiring process is much more focused on work-
samples, and the in-person interviewing is pretty laid-back. We're also very
up-front with candidates about what to expect and where they are in the
process. Check out our careers page:

[http://matasano.com/careers/](http://matasano.com/careers/)

Feel free to drop me a line if you (or anyone else) has questions - I'm andrew
AT matasano.com

~~~
fsk
Great, spend a lot of time studying your niche (security), all just for one
interview. Yeah, your process isn't broken.

~~~
andrew-d
For what it's worth, that's a fair concern. I offer two things that make it
not quite as bad as you may think, though :-)

1\. We don't expect applicants to be amazing at this already. Having a
background in security is good, of course, but not necessary. As a data point:
in the office I work out of, we have someone who used to work in a bakery,
someone who worked for an insurance company, and several people who had never
done security before applying to Matasano. It's my opinion that you generally
learn more "on the job", as it were, than you would preparing for an interview
anyway. @tptacek's post at [0] is a good example of the type of people we have
working for us.

2\. We generally send candidates resources to help them prepare - I believe a
couple recent applicants got free copies of "The Web Application Hacker's
Handbook" [1].

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

[1]: [http://www.amazon.com/The-Web-Application-Hackers-
Handbook/d...](http://www.amazon.com/The-Web-Application-Hackers-
Handbook/dp/1118026470)

~~~
fsk
Any interview process that requires a substantial time investment by the
candidate pre-interview is broken.

Why would I spend some time learning the security niche just for one
interview? I could instead work on Android development, Python, Scala, or a
whole bunch of other things. Those would be useful for many jobs, and not just
1-3 employers.

Why is putting in a lot of time researching security for your interview a
better use of my time than learning more widely applicable skills?

What if I put in all the time, pass the pre-screening, and then when I meet
you, it turns out you aren't the type of people I'd want to work with?

~~~
infinite8s
It's pretty simple, then - don't apply there.

------
northisup
This is not what an interview at Disqus is like. We interview you like we
work. This means you are going to code and you are going to lead a design
discussion.

Coding is done on a computer you bring with your tools in a language you know.
You get to use the Internet to looks stuff up, you know, just like you can
when you are really doing your job. And the questions we ask are problems we
have had to solve at work.

The design discussion is collaborative, the interviewer is an active part of
the discussion playing a sort of devil's advocate.

If this seems like a process you would like, we have a bunch of python
positions open right now, check them out here:
[http://grnh.se/vj71bo](http://grnh.se/vj71bo)

------
JesseAldridge
FWIW, I just accepted an offer from Instacart (my first day is Monday). Phase
1 of the interview process was a 10 minute coding problem on Hacker Rank.
Phase 2 was building a small web app in half a day on my own time from my own
apartment. Phase 3 was a 10 minute face to face coding problem that I solved
using my normal programming environment on my own laptop. There were also
conversational interviews with several people. No whiteboards were involved at
any point.

They (er, we) are still hiring:
[https://www.instacart.com/jobs/engineering](https://www.instacart.com/jobs/engineering)

~~~
johnsberd
That sounds absolutely awful.

------
solomatov
Basically, interview questions at such companies test your knowledge of basic
algorithms and data structures. If you have problem with answering such
questions, I recommend you taking a couple of courses in these fields on
Coursera or read basic algorithm books (and of course solve exercises).

I interview people a lot, and I always ask such questions. I just don't want
to have people who don't know how data structures they work with every day
work and which time complexity they have. You would be surprised, to see how
many people don't know the basics.

Often companies, like google, and facebook ask brain teaser, i.e. tricky
questions with tricky answers. I agree with you that such questions are mostly
useless and make people feel stupid, especially if they didn't have experience
with them.

P.S. It would be nice if you provide examples of tasks which you against, so
that everybody who reads this is on the same page.

------
lfowles
> But all three of us are very reluctant to start interviewing because we all
> know how much interviewing really really SUCKS. Basically we are forced to
> write whiteboard code for 4-5 hours on topics that we may or may not know.

"reluctant to start interviewing" based off of stereotypes? Am I not
understanding this?

~~~
jeremymcanally
Yeah, I'm not entirely sure where they've interviewed or read about
interviewing. I guess Google and Microsoft might run interviews like that, but
I've never had that experience. And I've interviewed in a lot of places (both
in Silicon Valley and out of it!).

It seems like maybe they've spent too much time on HN and Reddit reading about
interviewing without doing it. ;)

~~~
Blackthorn
I've proctored a number of interviews for $BIG_COMPANY and they wanted
whiteboard coding (yuck), so I made sure that my questions involved the
whiteboard but zero coding. Without revealing my own secret interviewing
sauce, I take people through an area that most software engineers use but are
highly unfamiliar with: the linking and loading process. It works because it's
such a black box with most people. I have them figure out how they would write
a linker and loader. The people who score well with me never really thought
about it before, but with a bit of guidance come up with a pretty reasonable
facsimile of what such a system looks like for real.

Then I interviewed at a bunch of places. Most of them were fairly small and
they _universally_ used whiteboard coding, except when I interviewed for a
specific team at $OTHER_BIG_COMPANY and didn't touch a whiteboard at all. I
expect that if I wasn't interviewing for a specific team, I'd have had to use
the whiteboard.

So yeah, sadly IME whiteboard coding is alive and well.

~~~
danellis
> Without revealing my own secret interviewing sauce

Why is it a secret?

~~~
zzalpha
To be fair, an interview process that's novel and successful is certainly a
competitive advantage, at least in companies where they understand their
engineers are key to their success and not simply cogs in a machine.

~~~
danellis
> an interview process that's novel and successful is certainly a competitive
> advantage

That's true, but... it's pretty sad that it's true. There's so much to be
learned from good interviewing practices.

------
throwaway879032
If you think interviewing is bad now, wait until you're world-class.

Then either the interviewers "know" the wrong answers, or feel so threatened
that you're "not a culture fit."

~~~
danellis
Maybe they're just put off by people arrogant enough to call themselves world
class.

~~~
brendangregg
Total guess, but picking a "throwaway" account might suggest the writer is
uncomfortable saying that, and may never have said that in an interview. But
that's a guess. If they did call themselves world-class, then that's sure to
come across as arrogant, even if they are.

~~~
danellis
Sure, but it's something other people say of you. To say it of yourself, even
outside of an interview, is rather gauche, and perhaps reveals a sentiment
that does manifest in interviews.

------
drawkbox
When you are an interviewer, remember you are given power to determine whether
people get the job and are their gatekeeper. You are determining career paths
and opportunity. Don't make the interviewee do things they wouldn't do on the
job but find out who they are. Even when you hire you really learn who you
hired in action, even if you have a circus hoop based interview process, the
real test is the first 2-12 weeks.

It is sad some pedantic people can determine your success on a one off trick
question and whiteboard exercise interview judgement like a rogue war tribunal
rather than your work.

------
ejcx
I don't think all companies interview like that. In my honest opinion, the
interviewing game is changing if you don't interview at any of the giants.

You can also ask about what the on-site interviews are like before you commit
to them. If they mention white-board programming, just pass on them. I am
super against horrible interview practices (I'm all for phone screens being
you and the interviewer SSH'd and in the same screen session together), but
you can find companies that have good ones, and part of that task lies on your
shoulders.

------
nojvek
Interviewing is a hard problem. I've done many interviews at small startups
and big tech firms. Its a bit of a hit and miss to be honest.

You have a long flight and ended up burning midnight oil last night. They
might think you're not passionate enough.

You're quite excited about certain things, they think you're trying too hard.

you absolutely suck at writing recursive code on a whiteboard, they think you
can't code for shit.

Some dude on the other side is trying to prove his seniority and intimidating,
they think you don't fit in culture.

Lesson learnt the hard way: Just gotta keep on trying

------
algo123
I get many emails from recruiters but ignore them because I simply don't know
what to expect from interviews - not really interested in being asked to solve
someones' pet algorithm on a white board. I wish there was a list of companies
who do project based interviews where they ask you to work on a small but
challenging project related to the actual work you'll be doing, and then bring
you to an interview to present it and defend it in front of your potential
future colleagues.

~~~
hurin
I'm genuinely curious why engineers would prefer to work on a project for an
interview? To be tasked by multiple companies (presumably by as many as you
are applying to) to spend 4-8 hours doing _unpaid_ work on a project which is
probably inane and most off all - completely useless for everyone involved.

If I've got 8 hours to spend I'd much rather contribute it to something that
someone else will actually benefit from.

~~~
sirwolfgang
Because as much as spending 4 hours doing unpaid work may seem to suck. (Which
let's face it, I do at least 8 hours of unpaid development a week on side
projects.) It's a better and more accurate test of your abilities than doing
what can only be compared to that of a trivia based game show.

Option A) Spend anywhere from 2 to 12 hours interviewing for a position with
little to no break. While being asked to solve problems, that may very well
actually be unsolvable, under the pressure of rotating team of people. And for
bonus if you suffer from any sort of test taking anxiety in school you'll get
to feel the blood drain from your prefrontal cortex, as your fight or flight
instincts kick just enough to make sure that doing high cognitive work like
programming is next to impossible.

Option B) Spend a few hours solving a hopefully interesting programming
challenge at home where you're probably not wearing pants.

------
jlees
I think you'll find startups to be more flexible on this, with the downside
that they are often still figuring out their own processes. At Nylas we ask a
range of questions from high to low level but all related to the kinds of
problems engineers would be working on - for example, if you'd be working on
the platform team, we ask you about things like concurrency and locks because
we actually use those, not because we read some CS 101 textbook and thought
they'd be cool.

Sometimes, the goal of an interview is to get you to think about something you
don't know. If you knew every answer to every interview question perfectly,
what does the interviewer learn? It's quite enlightening to get out of that
comfort zone and see whether someone pulls an answer out of their backside,
honestly says that they don't know, or somewhere in between. I'm not saying
all interviews should be like this for everyone, and I think interviewers
should be very much aware if that's what they're doing -- which I think is
less the case ("oh, the candidate didn't use a linked list but solved the
problem some other way? 0 points!").

------
ARenhard
I'm working semi hard at solving this problem right now, but up in Seattle.

Here's what I can tell you and your friends to help until I am running the
awesome company that will solve some of these issues:

Interviewing is hard. For both the candidate and the interviewer. With
engineers, it's even more difficult. They have to assess a culture fit, a
character match, a specific set of already acquired skills, the ability to
learn new skills, the ability to solve problems not yet known to anyone...and
all in some consistent fashion. It's very difficult to extract hard data out
of an interview that isn't a question and an exact answer. So, think from your
interviewer's perspective. The best thing you can do is help them get the data
they need to extract from you. If the question they ask is too specific, help
them see what you do know, how you would find answers to what you don't, what
you think the answer would be, how you would reason about it, etc.

I would highly not recommend selecting a company based on their interview
process...you might not like the narrow pool you're left with.

------
chipotle_coyote
As others have said, you're making a fair amount of assumptions about the way
the "median" interview in Silicon Valley goes. Interviewers tend to be less
concerned about whether your code matches the picture in their head as much as
whether your code works and isn't doing anything unduly stupid. (Being aware
of performance concerns and how to optimize for best O(n) values is a huge,
huge deal.)

The biggest challenges I've personally noted are these:

(1) Despite all the (probably sincere) claims many startups make about not
looking for computer science degrees, coding questions are absolutely,
positively optimized for computer science majors. I have lost more than one
job because I'm "not strong enough with algorithms." For certain kinds of
positions that's assuredly correct -- the engineers where I work now, who are
building a high-performance realtime database, for instance -- but the number
of times I've needed a routine to return a list of strongly connected
components in a network graph as part of my 15-year web development career is
exactly zero. (I have, however, needed it for a coding interview; as it turned
out, writing that _and_ a shortest path method _and_ a simple parser just got
me to the final face-to-face interview, where I was asked three or four more
algorithmic questions. I did not get that job.)

(2) I increasingly see jobs requiring experience that I literally cannot get
without already having one of those jobs, i.e., "must have _already_ worked
with high-performance clusters and web sites serving millions of hits a day."
It seems like the only way to get that experience is to either start a startup
that gets to that point, or get an internship at a company that already has it
(which is not an option once you're out of college).

~~~
ZanyProgrammer
Your second point is analogous to companies asking for X years of experience
in a language that has only been out for y years, where y < X

------
onoyoudont
The whole hiring process is broken. The recent trend is to put a firebreak of
"recruiters" between the company and the jobseekers. These folks know
shockingly little. But, descended as they are from bridge-trolls and meter-
maids, they are happy to get in the way and throw their puny weight around.

No one is served by this approach but the recruiter fraternity.

------
innocentoldguy
I want a site like this too! I've become so frustrated with stupid interviews,
I've just started walking out. I feel that if a company can't be bothered to
learn how to conduct a meaningful interview, I don't want to work there
anyway.

Nowadays, I tell recruiters right up front that I won't do whiteboard
questions. I'm more than happy to bring code I'm currently working on to the
interview and talk about it with the interviewer, but I will not subject
myself to pointless puzzles and demeaning whiteboard tests.

Another thing I've seen companies do in interviews is ask candidates to code
something on their own time as part of the interview process. I have then seen
that code go live on their site. I won't write production-ready code for
companies as part of the interview process anymore because of that clever bit
of dishonesty.

~~~
seige
How many companies are left after you declare you wont participate in
whiteboard questions?

~~~
innocentoldguy
I've never been unemployed during my 25-year career, so apparently enough.

------
smil
The more you try to emulate reality, the farther from reality you get. That's
why interviewing practices are so absurd today -- cognitive tests, personality
tests, whatever work test that tries to assign a quantifiable score to an
applicant.

------
ryanSrich
Stop looking for jobs in Silicon Valley.

------
Cymen
Hired.com. If you don't want to deal with a lot of BS and are able to make
decisive choices, you can't go wrong.

Otherwise, you end up interviewing at places were recruiters are just trying
to get another body in the door and half of them are not prepared.

I was very skeptical but it got the job done.

[http://join.hired.com/x/XfELvW](http://join.hired.com/x/XfELvW) if you want
to toss me a referral but honestly, it doesn't matter to me either way. The
quick decisive moment is the hard part but Hired.com really does take care of
the rest.

Also Mattermark is hiring and I would encourage anyone interested in full
stack or dev ops to apply:
[http://mattermark.com/jobs/](http://mattermark.com/jobs/) (other business
roles are on there too)

Why Hired.com is good: if you are a bad negotiator, you'll learn very quickly
that you need to filter out jobs early on based on salary expectation. Nobody
talks to engineers/geeks about that. But once you go through the hired.com
process, you realize that hey, it's an open field -- you can establish up
front what your criteria are in terms of compensation and discuss that early
in the potential interview process. Because time is money, hiring is
complicated and compensation is all over the place. You are the best judge of
your value. It's complicated. But you are also the best judge of what you'll
accept in terms of tradeoffs (cash vs equity).

Everyone single person who contacted me via my Hired.com profile was a founder
(or a recruiter pretending to be the founder). Either way, I got a great
summary of what they were looking for along with up front knowledge of the
compensation (so I knew we were on the same page). I got 11 or 12 offers and I
did 4 on-site interviews. I ended up at a company that I am very happy with.

So I recommend it to those that don't have a perfect network. With a great or
perfect network, you can likely do better. But like online dating, Hired.com
exposes you in a way that optimizes presenting your value to potential
employers. I think that most of us engineers do not have a perfect network
and/or do not know how to leverage that network so it is a huge win.

~~~
sagivo
i don't think you understand the question. the problem presented is about the
interview itself and not about how to find a place to interview.

~~~
Cymen
I do understand. Going through Hired is a dramatically accelerated process of
the regular interview cycle. So while you might get those annoying interviews,
you won't have time to dwell on them because you'll also get some great
interviews and it is all packed into a week or two instead of dragging on for
months on end.

Perhaps in other words, you are guaranteed a few bad interviews. Interviewing
is very random. I have sat on both sides of the table. I have sighed when
other interviewers have bought up minor quibbles about otherwise excellent
candidates. There are a lot of really bad interviewers. Getting interviews at
a bunch of places that really desire to hire you somewhat lowers the crappy
interview percentage.

Yet another way to put it is you are practically guaranteed a bad interview.
It is best to accept that and move on. I had what started out as a really
great interview process go bad when I went on-site. It happens. The randomness
of the interview process and the fact we're all human/fallible practically
guarantees at least one bad experience. My bad experience really bruised my
ego but ultimately, I realized it was a good experience too when I framed it
in the context of the overall experience.

------
biot
Why not actually start interviewing. It may be that your fears don't match up
with reality, and you'll do awesome and each get a handful of great offers.

------
CyberDildonics
It's a good point that asking so much of someone's time right off is
unreasonable. Really there should probably be a quick discussion about what
the job is, can the person do the job, what the company is about etc, and then
some loose terms, and then a big interview if that is even necessary. Either
that or pay people for their time if you are going to require a 5 hour
interview.

------
bayonetz
My interviews are not like that. They focus on your work samples, talking
through system design thought experiments, and some light on-the-spot coding
just to make sure you are not BSing your work samples (FizzBuzzy type stuff).
I posted a job in recent Who's Hiring you can find in my submissions if
interested.

------
tobinfricke
Maybe I am in the minority here, but I thought the interview process was super
fun! I enjoyed solving puzzles on the whiteboard and the courting process.
"Forced to write whiteboard code" ... is that really how you feel about it? In
some ways solving well-specified problems (often a few carefully-crafted gems)
with a captive audience is a special treat. And then you typically have the
opportunity to turn the tables and ask questions about their business and
engineering challenges. Maybe just relax a little and try to have fun with it?
(I know, easier said than done when your career is on the line.)

------
siscia
If you want, I use to run this service...

[http://siscia.github.io/open-hire/](http://siscia.github.io/open-hire/)

Help 3 fellows would be a pleasure...

------
rokahnhn
We desperately need a couple of additional coders to work with our tech leads.
However, (perhaps surprisingly) having no additional coders is better than
someone who's a bad fit (sorta like it's better to be single than married to
someone you cannot stand).

It might be that you're hearing about job openings at companies which are
large enough to have a marketing budget or happen to make a narrow range of
products which you may use. Candidate and company both prefer candidates who
are "walked in the door" by a trusted intermediary. However, for a company
such as ours, we're small, our folks are heads-down on their work so don't
spend much time at conferences, we sell to enterprises so you wouldn't hear of
our product, and we don't use recruiters. There's probably new hiring
forums/recruiters/technology stacks which would help this process, but I get a
few such offers each week and how would I determine what works?

We've gone through a number of approaches to interviewing and haven't yet
found an interview "formula" which reproducibly gets to firm assessments. An
interview (typically filled with talking) usually distinguishes between a
"probably no" and a "probably yes". In contrast, a day or two of the typical
back-and-forth while coding on real problems produces a highly accurate
assessment...and enough insight to pay a premium for someone who could really
help us get where we're going. However, interviews rarely include such real
programming. As some other posts have mentioned, recruiting (and particularly
the interviewing aspect of recruiting) is tough.

While it's bad news for a company to hire the wrong person, it's also bad news
for the candidate. Assuming you're not looking to hop from company to company,
a good job is IMHO for 5+ years--a substantial portion of your productive
years. Once you get a good sense a company is attractive to you (and vice
versa), why not offer to spend a couple of days (e.g. a weekend) working with
someone with whom you'd actually be working if you were hired...before you or
the company commits? For our company, maybe we could pay you as a consultant
so you could work on real code/real problems. No, don't ask for big dollar
consulting fees--the benefit to the company is probably negative given your
limited context and the oversight you'll require--this is just to reduce the
likelihood of companies engaging in this practice without being actually
interested in hiring you. It's a big investment from both sides, so this would
be after achieving the "probably yes" outcome.

For both the initial, superficial programming tests and optional 2-day
programming projects, how about proposing to the hiring company how you'd like
to be assessed? For example, our company develops single-page, collaborative
editing and annotation applications for patent offices. If a candidate liked
our company's people during the normal interview, tried our software, and
proposed to add a feature to an open source project we use, the results would
be a pretty clear indicator. You'd also be doing something you find
interesting, since you suggested it.

Our jobs are at [https://angel.co/edyt](https://angel.co/edyt)

------
MichaelCrawford
I don't have the answer to your question, but I agree that interviewing has
gotten really bad. It's not always whiteboard problems:

A few days before I moved to Portland, I applied for some iOS coding jobs from
San Jose. I scored two interviews, on the day after I arrived, the other a few
days later.

"iOS" coding, mind you.

At that second company, I interviewed for four hours with six people. There
were no whiteboard questions, it was all talk. My last interviewer was the
president of the company. He asked me what an "activity" was.

I had no clue. Quite unwisely, I pulled my answer right out of my ass.

I looked it up later: iOS Apps don't have activities, that's an Android
concept.

I am dead certain that I didn't get that job, because I didn't know about an
API that's only used for a platform that I would not be working with.

~~~
Estragon
Maybe you didn't get it because you lied? What if you'd said you didn't know?

~~~
MichaelCrawford
In what way was I lying?

~~~
myko
Not lying per se, but if someone pulls something out of there ass in an
interview I'm giving that's a red flag for me.

If I am interviewing I don't do that without explaining that I don't know
exactly what they mean, and if I have some idea of what they might mean I say
that. Otherwise I say I'm sorry I don't know, and list it as something to ask
about at the end of the interview (typically when you're given a chance to ask
the interviewer some questions).

------
hyperliner
I find that companies don't know how to interview, and therefore the
individuals doing the interviews have no clue what they are supposed to be
interviewing a candidate for.

If teams would prepare ahead of time, they would create a schedule for the
process with specific steps for specific areas of interest: personality and
fit, general algorithms, design approach experience, domain expertise If core
to the role, ability to work well with others, general approach to the craft,
approach to quality, money expectations, check for previous projects,
references, etc. I have been in interviews where 8 people try to compete to
see who asks the most bad axx question with no flow whatsoever. Or other times
is the "big shot" with experience on the latest framework of the day who has
no experience in other things at all. What a waste of time.

My approach sometimes, particularly with the younger interviewers, is to pause
the interview, ask them what they are interested in knowing, and then give
them some hints, through comments, about the questions they should be asking
me.

For "how many balloons fit in this building" question, I ask what is the
purpose of the question. Sometimes they don't know! Then I say "let's figure
this out together." And then have a little fun together while showing
estimation skillS or asking clarifying questions: is it regular children
balloons or hot air ones?

For coding questions: pull out the laptop and show them.

People: prepare your interviews.

Candidates: take control of the interview if the company didn't. You already
invested the time so might as well help turn it around.

~~~
ARenhard
This is excellent, and a great reflection for what you'd be like to work with.

------
MichaelCrawford
Cisco gave me a written test. I was left alone in a room with the test, some
paper and a ball-point pen.

One question asked me to debug some C++ code - without a computer mind you.
Another asked me to reverse engineer a hex dump of a network packet. I don't
recall what the third problem was.

It was only after I completed the written test, and my interviewer looked over
my answers, that we had an actual face-to-face interview.

It is quite puzzling to me that that's not commonly done.

------
formulaT
This is my defense of whiteboard interviews.

\- They are aimed at identifying smart people who know the basics of coding
and algorithms. They are intentionally not domain specific. In my experience,
smart people can pick up all the other details over time. I've worked with
many people who switched languages and within a few months were (for the
purposes of their job) as good as someone with years of experience. Similarly,
version control, testing etc. are things you can learn on the job.

\- They have _worked_ for major companies. Look at the share price of Google
and Facebook over time, or the general feeling that they are successful in
their goal of hiring the best people.

\- They are fast and scalable. They only take as long as the interview, and
they scale well because it's easy to compare the notes of different
interviewers. The process takes about 5 hours for the interviewee, and about
10 hours combined for the interviewers.

~~~
anthony_barker
My question is if the candidate did a degree at a good school doesn't that
prove anything? If they did a similar job for a competitor that doesn't count
or has a giant set of github repos does that not count? My feeling is that
pressured puzzles are a cop out unless you are trying to filter out low level
employees.

Also your comparison with share price is not necessarily accurate - #1 company
in the past 100 years is Exxon (profit per 100 years). I would argue that they
manage their existing employees better than their competitors and fire the
weak ones. In 50 years I'll bet no one knows facebook or google - just like no
one knows DEC or any other tech company from the 70s except IBM and Oracle.
Currently they just have the Zeitgeist going for them.

