wip big-tech-hiring
This commit is contained in:
parent
83facd78ec
commit
ea7311c116
310
content/log/2022/big-tech-hiring.md
Normal file
310
content/log/2022/big-tech-hiring.md
Normal file
@ -0,0 +1,310 @@
|
||||
---
|
||||
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 myself why I am doing an interview at all, and why I am OK with the
|
||||
format we are heading to. 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 all the time.
|
||||
- Understand/recap the interview process of megacorps ([I've worked at two]({{<
|
||||
ref "resume" >}} "Resume"), the process is very similar; will shamelessly
|
||||
extrapolate for "most others").
|
||||
- Talk about the consequences of the process and some mitigations.
|
||||
- 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. Judging from
|
||||
the resumes in the later Phone Screen stage, to praise the recruiters, it seems
|
||||
to pass through quite a diverse folk, sometimes 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 may often circumvent the CV screen if you know someone in 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], I will do the recruiter's job of
|
||||
"bringing you to the loop" by submitting the resume for further interview
|
||||
stages. Which means I can use my own criteria for evaluating your background
|
||||
and experience. I don't care about your title or $DAYJOB, but 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 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. A nice touch from a company though.
|
||||
|
||||
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[^3], 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 do 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 interviewer 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.
|
||||
|
||||
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
|
||||
interviewee. 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. Of course, depending on the outcome of the other
|
||||
interviews. 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:
|
||||
|
||||
- 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. People often think programming
|
||||
puzzles are limited to time and space complexity, 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 memory pressure from the
|
||||
negative dentry cache even if you started with a seemingly simple coding
|
||||
exercise).
|
||||
- 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.
|
||||
|
||||
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?
|
||||
- Do they understand limitations of the system they have built "on the
|
||||
whiteboard"?
|
||||
|
||||
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: this is not a hiring prerequisite.
|
||||
Bullshitting through will deny you for the behavior, but being honest about not
|
||||
knowing the answer is a perfectly valid response, and definitely not a
|
||||
prerequisite to join the teams that I've worked at. Assuming your other skills
|
||||
are valuable, you will learn Design and Architecture on the job.
|
||||
|
||||
Unfortunately, I have seen candidates trying to "bullshit through" this
|
||||
interview. Drilling into the details helps. The bullshitters usually break down
|
||||
at the question: "how exactly would you observe this behavior?", with varying
|
||||
degrees of "exactly".
|
||||
|
||||
### 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 does not.
|
||||
For obvious reasons, we cannot live-stream a candidate, so 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 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 time.
|
||||
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.
|
||||
|
||||
Hopefully we will be able to publish the talk recording, but that's not a
|
||||
given. I encourage you to attend it live.
|
||||
|
||||
P.S. The candidates can use any programming language during the interview. Make
|
||||
a wild guess which I will pick.
|
||||
|
||||
[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 below my pay grade.
|
||||
[^2]: Manager, Director, VP, et cetera. The point is, People manager.
|
||||
[^3]: I am one of those people. If you want to work in Uber Vilnius, 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.
|
||||
Loading…
Reference in New Issue
Block a user