abg and timm

This commit is contained in:
Motiejus Jakštys 2022-06-21 22:55:48 +03:00
parent ea7311c116
commit 6c94f1e7e6

View File

@ -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 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 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 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 explain to 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: 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, - 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 and why we reasonably expect them to work, despite of all the negatives we
keep reading all the time. keep reading about all the time.
- Understand/recap the interview process of megacorps ([I've worked at two]({{< - Understand/recap the interview process of Big Techs. [I've worked at two]({{<
ref "resume" >}} "Resume"), the process is very similar; will shamelessly ref "resume" >}} "Resume"), the process is very similar; will shamelessly
extrapolate for "most others"). extrapolate for "most others".
- Talk about the consequences of the process and some mitigations. - 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 - Hopefully refute some of the popular beliefs that hiring process in big tech
companies "is incredibly stupid". Yes, I have heard this multiple times. 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 ### Recruiter: CV screen
CV screen is conducted by a recruiter in the HR department: I do not take part 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 in this, therefore I have no visibility into rejected candidates. To the
the resumes in the later Phone Screen stage, to praise the recruiters, it seems recruiters credit, juding from the resumes Ive seen during phone screens, we
to pass through quite a diverse folk, sometimes with a minimal "match". For interview folks with diverse backgrounds, even with a minimal "match." For
example, a physicist major with data analysis background in Python is unusual, 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. 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. 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? Or all of the above. What then?
You may often circumvent the CV screen if you know someone in the company and 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 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 Vilnius, [ping me directly][ping-me]. We are able to submit referrals, which
"bringing you to the loop" by submitting the resume for further interview skips the standard CV screening, because, ahem, I am doing the screening. I can
stages. Which means I can use my own criteria for evaluating your background use my own criteria for evaluating your background and experience. I will note
and experience. I don't care about your title or $DAYJOB, but I will note your your open-source contributions, especially pull requests, pull request reviews,
open-source contributions, especially pull requests, pull request reviews,
communication issues and, of course, code you've authored. Bonus points for communication issues and, of course, code you've authored. Bonus points for
maintaining a project: changelogs, mailing list submissions, etc. 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: because:
- My referral is a pretty weak signal to the hiring committee, so I take - 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 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. 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 - 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 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, - 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 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 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 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 ### 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. - ~30-40 minutes: a "simple" coding challenge.
- ~20 minutes: interviewer selling the company and the position. We spend quite - ~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 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 cares about. Work-life balance, how we do planning, how frequently we have to
to work during non-working hours (e.g. due to meetings with the US), what is work during non-working hours (e.g. due to meetings with the US), what is the
the office like, equipment, etc. office like, equipment, etc.
- ~10 minutes, optional: very brief inquiry about concrete past experiences to - ~10 minutes, optional: very brief inquiry about concrete past experiences to
determine candidate's "level" and "experience". Some interviewers do it. I determine candidate's "level" and "experience". Some interviewers do it. I
don't do this part, as I prefer more coding time. don't do this part, as I prefer more coding time.
There are a couple of aspects worth highlighting: There are a couple of aspects worth highlighting:
- The interviewer (Engineer A) *alone* decides on go/no-go. - 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 later stages require them to explain their decision, whatever that is, in the
debrief. debrief.
- The interviewer decides on the interview problem and the interview format, - 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. 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 2. The candidate is visibly nervous and is making silly mistakes they would
never do in a non-stress situation. 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 How can bright candidates mitigate this? Practice. To bring up to speed with
the primitives, a couple dozen coding challenges in your favorite "coding the primitives, a couple dozen coding challenges in your favorite "coding
challenge site" will help. How can they mitigate the "stress" part? Also challenge site" will help. How can they mitigate the "stress" part? Also
practice, but with a friend. Once you have practiced the "coding challenge practice, but with a friend. Once you have practiced the "coding challenge
site" alone enough, take a friend/spouse/anyone to pretend being the 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. but certainly help.
Is it ridiculous? Yes and no. Yes, because, to be accepted at a BigTech, you Is it ridiculous? Yes and no. Yes, because, to be accepted at a BigTech, you
@ -157,15 +165,14 @@ 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 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 "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 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 decent chance to be hired. Besides the safety net for the candidate, the rest
interviews. Besides the safety net for the candidate, the rest of the of the experience is similar to the Phone Screen: I truly believe that passing
experience is similar to the Phone Screen: I truly believe that passing this this stage is a matter of practice.
stage is a matter of practice.
You may ask me: why bother with a puzzle at all, since it is not representative 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: 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 1. We need a proof you are able to do things that are required for an engineer
anyway: anyway:
- Understand the task. - Understand the task.
- Come up with a solution: on your own or with guidance. - Come up with a solution: on your own or with guidance.
@ -174,16 +181,17 @@ of what we do at work anyway? Because of two reasons:
- Write tests for simple cases. - Write tests for simple cases.
- Write tests for edge cases. - Write tests for edge cases.
- Debug issues and find bugs. - Debug issues and find bugs.
- Reason about the solution's efficiency. People often think programming - Reason about the solution's efficiency.
puzzles are limited to time and space complexity, but it can be much more 2. We need a somewhat consistent way to calibrate across candidates. E.g. I
than that: venues for memory leaks or garbage collection (depending on the know that, if a candidate reaches point X of my exercise, they pass my phase of
language), non-memory-non-cpu resources to achieve the task (e.g. network, the interview.
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 On reasoning about the solution's efficiency, people often think efficiency
exercise). boils down to `O(<...>)`, but it can be much more than that: venues for memory
- We need a somewhat consistent way to calibrate across candidates. E.g. I know leaks or garbage collection (depending on the language), non-memory-non-cpu
that, if a candidate reaches point X of my exercise, they pass my phase of resources to achieve the task (e.g. network, file descriptors; you can go far
the interview. 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. 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 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? - Has built something themselves? Did/do they maintain it?
- Offering the trendy or a reasonable thing (these are often very different)? - Offering the trendy or a reasonable thing (these are often very different)?
If they choose the trendy, why? Do they understand the drawbacks? If they choose the trendy, why? Do they understand the drawbacks?
- Do they understand limitations of the system they have built "on the - Understands limitations of the system they have built "on the whiteboard"?
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 Unlike the coding challenges, everything we test in Design & Architecture
interview is critical at work: we need to understand many systems, both ours 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 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 reading the documentation and surveying owners for knowledge gaps. Once the
limitations of your dependencies are understood, write code having them in 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 mind.
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 If you have never worked at a place to muscle your Design and Architecture
interview. Drilling into the details helps. The bullshitters usually break down skills, do not worry: when you let us know this isn't a thing you've had a
at the question: "how exactly would you observe this behavior?", with varying chance to learn, we'll still try to work with you towards a solution based on
degrees of "exactly". what you do know and well 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 ### 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 P.S. The candidates can use any programming language during the interview. Make
a wild guess which I will pick. 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-talent]: https://danluu.com/talent/
[danluu-hiring-lemons]: https://danluu.com/hiring-lemons/ [danluu-hiring-lemons]: https://danluu.com/hiring-lemons/
[danluu-trendiest]: https://danluu.com/programmer-moneyball/ [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/ [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 [^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. [^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 [^3]: If you want to work where I work (company + location), feel free to ask
to ask me for a referral. Keep in mind, though, that I will spend some time me for a referral. Keep in mind, though, that I will spend some time to
to understand whether I believe you are a good fit. See the post for my understand whether I believe you are a good fit. See the post for my
criteria. criteria.