326 lines
16 KiB
Markdown
326 lines
16 KiB
Markdown
---
|
||
title: "In Defense Of Big Tech Hiring"
|
||
date: 2022-06-19T12:44:16+03:00
|
||
slug: big-tech-hiring
|
||
draft: true
|
||
---
|
||
|
||
There is quite a lot of negative sentiment about broken BigTech hiring
|
||
processes. If you have not heard, these are good introductory posts:
|
||
- [Dan Luu — Misidentifying Talent (2022)][danluu-talent].
|
||
- [Dan Luu — Hiring Lemons (2016)][danluu-hiring-lemons].
|
||
- [Dan Luu — We only hire the trendiest (2016)][danluu-trendiest].
|
||
- [Thomas Ptacek — The Hiring Post (2015)][tptacek-hiring-post].
|
||
|
||
I will be conducting an [Uber Mock Interview][uber-mock-interview] later this
|
||
month. I meant to write about seemingly broken BigTech interviews for a while
|
||
now, but this event offered me a concrete deadline. I feel like I have to
|
||
explain to myself why I am doing an interview at all, and why I am OK with the
|
||
format we are planning to use. In this post I will:
|
||
- Explain some reasons why *I think* the interviews are done the way they are,
|
||
and why we reasonably expect them to work, despite of all the negatives we
|
||
keep reading about all the time.
|
||
- Understand/recap the interview process of Big Techs. [I've worked at two]({{<
|
||
ref "resume" >}} "Resume"), the process is very similar; will shamelessly
|
||
extrapolate for "most others".
|
||
- Talk about the limitations/caveats of the process, along with mitigations how
|
||
to work around them.
|
||
- Hopefully refute some of the popular beliefs that hiring process in big tech
|
||
companies "is incredibly stupid". Yes, I have heard this multiple times.
|
||
|
||
Usual disclaimer: this is my personal opinion and this blog is not affiliated
|
||
with my employer in any way.
|
||
|
||
Jump to the bottom for the [TLDR](#tldr-is-this-stupid-or-not).
|
||
|
||
## The standard interview process
|
||
|
||
This is how a standard[^1] interview loop in the big techs I've worked so far
|
||
at looked/looks like:
|
||
|
||
1. Recruiter: CV screen + chat over the phone: 30m-60m.
|
||
2. Engineer A: Phone screen: 1h.
|
||
3. "Business loop": 5 interviews in a single day, 1h each:
|
||
- Engineer B: Coding 1.
|
||
- Engineer C: Coding 2.
|
||
- Engineer D: Design & Architecture.
|
||
- Manager: Hiring Manager.
|
||
- Manager[^2] or Engineer E: Bar Raiser.
|
||
4. All participants above: Debrief, where hire/no-hire decision is made:
|
||
30-60m++.
|
||
|
||
I will be focusing on the parts of the process where qualified, bright, but not
|
||
"interview primed" candidates may be rejected. Thomas Ptacek
|
||
[states][tptacek-hiring-post] writes:
|
||
|
||
> The majority of people who can code can’t do it well in an interview.
|
||
|
||
Well, let's see how the his words hold. But first let's drill into the process.
|
||
|
||
### Recruiter: CV screen
|
||
|
||
CV screen is conducted by a recruiter in the HR department: I do not take part
|
||
in this, therefore I have no visibility into rejected candidates. To the
|
||
recruiters’ credit, juding from the resumes I’ve seen during phone screens, we
|
||
interview folks with diverse backgrounds, even with a minimal "match." For
|
||
example, a physicist major with data analysis background in Python is unusual,
|
||
but not very surprising: they do get a fair chance at the phone screen.
|
||
|
||
Some are truly unlucky: perhaps your experience does not match the recruiter's
|
||
understanding of what is necessary for the role. Or perhaps you want to change
|
||
direction and have spent a long time preparing for it, which does not show in a
|
||
resume. Or maybe you are like me and just don't know how to make a good resume.
|
||
Or all of the above. What then?
|
||
|
||
You can often circumvent the CV screen if you know someone at the company and
|
||
ask for a referral — which I openly encourage: if you want to work at Uber in
|
||
Vilnius, [ping me directly][ping-me]. We are able to submit referrals, which
|
||
skips the standard CV screening, because, ahem, I am doing the screening. I can
|
||
use my own criteria for evaluating your background and experience. I will note
|
||
your open-source contributions, especially pull requests, pull request reviews,
|
||
communication issues and, of course, code you've authored. Bonus points for
|
||
maintaining a project: changelogs, mailing list submissions, etc.
|
||
|
||
I have all the incentives to refer my friends and people I don't know (yet),
|
||
because:
|
||
- My referral is a pretty weak signal to the hiring committee, so I take
|
||
minimal risk. I can take bets, I do, and some of them work out. Some of my
|
||
referrals are rejections at the first technical interview, and that's OK.
|
||
- Some of my referrals turned out to be *excellent* people that I did not even
|
||
appreciate beforehand, because I did not know them enough. (E.g. because we
|
||
did not see each other since high school, not to mention any professional
|
||
interactions. Hello, Ignai.)
|
||
- We get a monetary benefit: a referral bonus. The amount is relatively small,
|
||
thus not worth the time investment alone. It is, however, comfortably enough
|
||
to pledge: If you want to talk about possible transfer to my team/company,
|
||
let's meet. I will buy you a coffee from the referral money. No strings
|
||
attached.
|
||
|
||
To sum up: if you can't get past the CV screen phase, look for friends, ping
|
||
engineers. If you don't know anyone working in the target company, you may find
|
||
them online. If you show reasonable politeness and promise, we will be happy to
|
||
refer you, increasing your chances of success.
|
||
|
||
### Engineer A: phone screen
|
||
|
||
The first phone screen is usually the first candidate's interaction with an
|
||
engineer. The phone screen (these days via a video link) usually consists of:
|
||
- ~30-40 minutes: a "simple" coding challenge.
|
||
- ~20 minutes: interviewer selling the company and the position. We spend quite
|
||
a bit of time explaining what we do and answering questions that candidate
|
||
cares about. Work-life balance, how we do planning, how frequently we have to
|
||
work during non-working hours (e.g. due to meetings with the US), what is the
|
||
office like, equipment, etc.
|
||
- ~10 minutes, optional: very brief inquiry about concrete past experiences to
|
||
determine candidate's "level" and "experience". Some interviewers do it. I
|
||
don't do this part, as I prefer more coding time.
|
||
|
||
There are a couple of aspects worth highlighting:
|
||
- The interviewer (Engineer A) *alone* decides on go/no-go.
|
||
- The interview also has very little accountability to reject the candidate;
|
||
later stages require them to explain their decision, whatever that is, in the
|
||
debrief.
|
||
- The interviewer decides on the interview problem and the interview format,
|
||
which leads to highly inconsistent phone screens across interviewers.
|
||
|
||
Therefore, I think this part is the *most subjective and punishing* in the
|
||
whole loop.
|
||
|
||
Unfortunately, many people fail at this stage. An engineer is put into a
|
||
position to understand, solve, code and debug a simple, but non-trivial problem
|
||
in 30-40 minutes. Such high-stress high-stakes situation barely happens in life
|
||
*except* at the interviews. I believe this phase is most susceptible to the
|
||
Thomas Ptacek's quote before. How can we help ourselves? Well, first let's
|
||
understand what the most frequent causes for failure are:
|
||
1. The candidate is not up to speed with their programming language's
|
||
primitives that are often necessary during coding challenges. E.g. they may
|
||
struggle an unreasonably long time to read file to an array, just because
|
||
it's been years since they needed to simply open a file in their dayjob.
|
||
2. The candidate is visibly nervous and is making silly mistakes they would
|
||
never do in a non-stress situation.
|
||
3. For some reason the candidate feels obliged to a language that Uber uses
|
||
(e.g. Go) even if they are not comfortable in it. I always ask candidates to
|
||
pick literally any language that they're very comfortable with. One of my
|
||
colleagues did the Uber interview in Haskell, and Uber's Haskell footprint,
|
||
being honest, is very very minimal (but nonzero).
|
||
|
||
How can bright candidates mitigate this? Practice. To bring up to speed with
|
||
the primitives, a couple dozen coding challenges in your favorite "coding
|
||
challenge site" will help. How can they mitigate the "stress" part? Also
|
||
practice, but with a friend. Once you have practiced the "coding challenge
|
||
site" alone enough, take a friend/spouse/anyone to pretend being the
|
||
interviewer. Do the same again. Drills with friends do not remove the stress,
|
||
but certainly help.
|
||
|
||
Is it ridiculous? Yes and no. Yes, because, to be accepted at a BigTech, you
|
||
need to practice for things you will not do at job. No, because, like Patrick
|
||
McKenzie points out, it's worth to spend a few weeks [learning something you
|
||
will never need at your job][salary-negotiation]. It makes sense to be good in
|
||
programming puzzles for exactly the same reasons it makes sense to learn how to
|
||
negotiate.
|
||
|
||
### Engineers B and C: Coding
|
||
|
||
The "business interview" usually starts with 2 coding interviews. Conceptually
|
||
they are similar to the phone screen, with less focus on "selling" and more on
|
||
"coding". However, these are safer to the candidate, because, if the candidate
|
||
excels the interview B, and fails the interview C, they still still have a
|
||
decent chance to be hired. Besides the safety net for the candidate, the rest
|
||
of the experience is similar to the Phone Screen: I truly believe that passing
|
||
this stage is a matter of practice.
|
||
|
||
You may ask me: why bother with a puzzle at all, since it is not representative
|
||
of what we do at work anyway? Because of two reasons:
|
||
|
||
1. We need a proof you are able to do things that are required for an engineer
|
||
anyway:
|
||
- Understand the task.
|
||
- Come up with a solution: on your own or with guidance.
|
||
- Explain the algorithm.
|
||
- Code it.
|
||
- Write tests for simple cases.
|
||
- Write tests for edge cases.
|
||
- Debug issues and find bugs.
|
||
- Reason about the solution's efficiency.
|
||
2. We need a somewhat consistent way to calibrate across candidates. E.g. I
|
||
know that, if a candidate reaches point X of my exercise, they pass my phase of
|
||
the interview.
|
||
|
||
On reasoning about the solution's efficiency, people often think efficiency
|
||
boils down to `O(<...>)`, but it can be much more than that: venues for memory
|
||
leaks or garbage collection (depending on the language), non-memory-non-cpu
|
||
resources to achieve the task (e.g. network, file descriptors; you can go far
|
||
into the effects of memory pressure from the negative dentry cache even if you
|
||
started with a seemingly simple coding exercise).
|
||
|
||
I simply do not know of a better way to achieve the above in 3 hours or less.
|
||
We know coding puzzles are not perfect, because it requires candidates to
|
||
prepare for things they would not do otherwise. But motivated candidates do
|
||
prepare. And we have a way to calibrate them.
|
||
|
||
### Engineer D: Design & Architecture
|
||
|
||
An engineer will ask you to come up with a solution to a problem they may be
|
||
more familiar with than you. This hour is a proxy to understand if the
|
||
candidate:
|
||
|
||
- Is aware of software architecture as a concept: what is it and what is it
|
||
for?
|
||
- Has built something themselves? Did/do they maintain it?
|
||
- Offering the trendy or a reasonable thing (these are often very different)?
|
||
If they choose the trendy, why? Do they understand the drawbacks?
|
||
- Understands limitations of the system they have built "on the whiteboard"?
|
||
- Understands the trade-offs? What alternatives have they considered, ruled
|
||
out, and why. This tells a lot about candidate's experience in a domain and
|
||
their decision making process: such talk is less sensitive to "mood of the
|
||
day" that can ruin the coding exercise, and provides a lot of signal.
|
||
|
||
Unlike the coding challenges, everything we test in Design & Architecture
|
||
interview is critical at work: we need to understand many systems, both ours
|
||
and of others', in a similar way you would do in the interview usually by
|
||
reading the documentation and surveying owners for knowledge gaps. Once the
|
||
limitations of your dependencies are understood, write code having them in
|
||
mind.
|
||
|
||
If you have never worked at a place to muscle your Design and Architecture
|
||
skills, do not worry: when you let us know this isn't a thing you've had a
|
||
chance to learn, we'll still try to work with you towards a solution based on
|
||
what you do know and we’ll use that to assess your ability to pick this up on
|
||
the job.
|
||
|
||
Unfortunately, I have seen candidates trying to dishonestly cheat (a.k.a.
|
||
"bullshit through"). It is easier to spot such cases than you may think. "How
|
||
exactly would you observe this behavior?", with varying degrees of "exactly",
|
||
is a good start to catch cheaters. Such behavior will definitely void your
|
||
application. Don't do it, be honest.
|
||
|
||
### Manager: Hiring Manager
|
||
|
||
I have never been in a hiring manager or a bar raiser interview (except as a
|
||
candidate a long time ago), so can only point out what I generally hear in the
|
||
debrief. If I am wrong, I apologize: please let me know.
|
||
|
||
Hiring Manager interview usually entails:
|
||
- Determine if the candidate has relevant skills for a particular role.
|
||
- Sell the position to the candidate.
|
||
|
||
Hiring Manager also assesses people and team skills together with the Bar
|
||
Raiser: see below.
|
||
|
||
### Manager or Engineer E: Bar Raiser
|
||
|
||
Bar Raiser will ask about your past experiences and determine your ability to
|
||
work in the team. "Tell me about a time" is a popular question prefix.
|
||
Bullshitting through this one is as hard as in the Design & Architecture
|
||
interview: you are dealing with a manager who is good at people-skills
|
||
(otherwise they wouldn't be a manager) and often had managed a team or teams
|
||
for a decade or more.
|
||
|
||
People are really good at spotting dishonesty. Your chances are much higher if
|
||
you are honest: admitting your weaknesses is better than trying to hide them.
|
||
|
||
If you are not a good team player, that will likely be determined during this
|
||
or the Hiring Manager's interview. That may be OK depending on the position;
|
||
but more often than not, this is a red flag.
|
||
|
||
## TLDR: is this stupid or not?
|
||
|
||
I do not think the BigTech hiring process is stupid. I can see legitimate
|
||
reasons behind every part of the interview. When the candidate knows what to
|
||
look for, they can prepare for it; which I think is totally fair.
|
||
|
||
To sum up:
|
||
- If you know someone at the company you want to apply to, ask for a referral.
|
||
You can always ask me[^3] (contact details are prominent in this blog).
|
||
- Do some puzzles before the interviews. This is an investment that will pay
|
||
off; just like spending some time to [learn to
|
||
negotiate][salary-negotiation].
|
||
- If you fail, the recruiter usually tells why. Prepare for that and do not
|
||
hesitate to re-apply in 6-12 months.
|
||
|
||
# Addendum: a mock interview
|
||
|
||
Now let's talk business. I will be running an [Uber Mock
|
||
Interview][uber-mock-interview] on 2022 June 29th. The mock interview
|
||
familiarizes potential candidates with the interview process, hopefully
|
||
reducing uncertainty, and thus stress. Listening for a presentation about
|
||
Uber's interview process sounds boring; looking at a live interview — much less
|
||
so. For obvious reasons, we cannot live-stream a candidate, we will do the next
|
||
best thing: conduct an interview which is for all intents and purposes real,
|
||
except I will not get or lose a job if I make or fail it.
|
||
|
||
So we will be conducting a mock interview. Because it should be educational
|
||
*and* fun, this is what we will do:
|
||
1. I will not know the exercise beforehand. We will all see it, including
|
||
myself, at the same moment.
|
||
2. I have not done a technical interview for >6 years now, so I did *a bit* of
|
||
preparation. Not too much though, like most of us when applying for a job.
|
||
3. I may fail the interview, therefore I know I will be stressed more than at
|
||
my work desk during regular coding. :) Stress is a very real interview
|
||
experiences for everyone. So you get to see the "mock interview" on
|
||
steroids.
|
||
|
||
We will not be able to publish the recording for legal reasons, so, if you are
|
||
curious, you have one shot to attend live.
|
||
|
||
P.S. The candidates can use any programming language during the interview. Make
|
||
a wild guess which I will pick.
|
||
|
||
Many thanks to Abhinav Gupta and Tim Miller for reading drafts of this.
|
||
|
||
[danluu-talent]: https://danluu.com/talent/
|
||
[danluu-hiring-lemons]: https://danluu.com/hiring-lemons/
|
||
[danluu-trendiest]: https://danluu.com/programmer-moneyball/
|
||
[tptacek-hiring-post]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
|
||
[ping-me]: https://news.ycombinator.com/item?id=31304657
|
||
[salary-negotiation]: https://www.kalzumeus.com/2012/01/23/salary-negotiation/
|
||
[uber-mock-interview]: https://www.meetup.com/uber-engineering-events-vilnius/events/286542203/
|
||
|
||
[^1]: for 90%+ of the Software Engineering roles. The rest 10% are interns or
|
||
"super-senior" level engineers, hiring whom is above my pay grade.
|
||
[^2]: Manager, Director, VP, et cetera. The point is, People manager.
|
||
[^3]: If you want to work where I work (company + location), feel free to ask
|
||
me for a referral. Keep in mind, though, that I will spend some time to
|
||
understand whether I believe you are a good fit. See the post for my
|
||
criteria.
|