abg and timm

content/log/2022/big-tech-hiring.md

@@ -15,15 +15,16 @@ processes. If you have not heard, these are good introductory posts:
 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 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 all the time.
-- Understand/recap the interview process of megacorps ([I've worked at two]({{<
+  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 consequences of the process and some mitigations.
+  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.
 
@@ -59,9 +60,9 @@ 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
+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.
 
@@ -71,32 +72,34 @@ 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,
+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][ping-me]. 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 refer my friends and people I don't know (yet),
+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
+  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.).
+  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.
+  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[^3], increasing your chances of success.
+refer you, increasing your chances of success.
 
 ### Engineer A: phone screen
 
@@ -105,16 +108,16 @@ 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.
+  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 interviewer also has very little accountability to reject the candidate;
+- 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,
@@ -135,13 +138,18 @@ understand what the most frequent causes for failure are:
    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.
+3. 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
-interviewee. Do the same again. Drills with friends do not remove the stress,
+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
@@ -157,33 +165,33 @@ 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.
+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. 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.
+1. 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.
+2. 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
@@ -201,25 +209,30 @@ candidate:
 - 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"?
+- 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: 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.
+mind.
 
-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".
+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
 
@@ -293,6 +306,8 @@ 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.
+
 [danluu-talent]: https://danluu.com/talent/
 [danluu-hiring-lemons]: https://danluu.com/hiring-lemons/
 [danluu-trendiest]: https://danluu.com/programmer-moneyball/
@@ -302,9 +317,11 @@ a wild guess which I will pick.
 [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.
+  "super-senior" level engineers, hiring whom is above 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
+[^3]: 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.
+
+