motiejus/jakstys.lt
1
Fork 0
Code Releases Activity

abg and timm

Browse Source
This commit is contained in:
Motiejus Jakštys 2022-06-21 22:55:48 +03:00
parent ea7311c116
commit 6c94f1e7e6
1 changed files with 82 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

147
content/log/2022/big-tech-hiring.md
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
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.