diff --git a/content/log/2022/big-tech-hiring.md b/content/log/2022/big-tech-hiring.md new file mode 100644 index 0000000..737f8b7 --- /dev/null +++ b/content/log/2022/big-tech-hiring.md @@ -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.