wip big-tech-hiring

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.