motiejus

16 KiB

Raw Blame History

title	date	slug	draft
In Defense Of Big Tech Hiring	2022-06-19T12:44:16+03:00	big-tech-hiring	true

There is quite a lot of negative sentiment about broken BigTech hiring processes. If you have not heard, these are good introductory posts:

I will be conducting an 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.

The standard interview process

This is how a standard¹ interview loop in the big techs I've worked so far at looked/looks like:

Recruiter: CV screen + chat over the phone: 30m-60m.
Engineer A: Phone screen: 1h.
"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² or Engineer E: Bar Raiser.
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 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. 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:

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.
The candidate is visibly nervous and is making silly mistakes they would never do in a non-stress situation.
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. 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:

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.
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³ (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.
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 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:

I will not know the exercise beforehand. We will all see it, including myself, at the same moment.
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.
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.

Many thanks to Abhinav Gupta and Tim Miller for reading drafts of this.

for 90%+ of the Software Engineering roles. The rest 10% are interns or "super-senior" level engineers, hiring whom is above my pay grade. ↩︎
Manager, Director, VP, et cetera. The point is, People manager. ↩︎
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. ↩︎

16 KiB Raw Blame History Unescape Escape