motiejus/jakstys.lt
1
Fork 0
Code Releases Activity

wip big-tech-hiring

Browse Source
This commit is contained in:
Motiejus Jakštys 2022-06-21 09:40:34 +03:00
parent 83facd78ec
commit ea7311c116
1 changed files with 310 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

310
content/log/2022/big-tech-hiring.md Normal file
View 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.