(Unofficial) Insider guide to tech interviews(bartwronski.com)
bartwronski.com
(Unofficial) Insider guide to tech interviews
https://bartwronski.com/2022/01/04/insider-guide-to-tech-interviews/
20 comments
I think it might be the classic distinction between "simple" and "easy".
I do believe that most of those problems are "simple" - typically when you read solutions, it's under 20 Python lines of code; and not really complex or difficult to understand code.
At the same time, I agree it's not very "easy" to do them well (come up with a solution, code it up, test it, and explain everything along the way considering trade-offs and pros and cons) under the interview stress and time pressure. Even the most brilliant and well prepared people do fail them for a reason.
Its hard to grok you calling them "simple", then saying brilliant people fail them. One could define hard as "a thing that even brilliant people fail at".
For me, easy is something that a person of average skill in that domain can do and that the top 20ish% person in that domain can do with their eyes closed.
I have a masters in CS, I know all of the words and stuff in your essay. I have been programming python for a while. I would most definitely need to study up on graph algos, implementing sorting algos, dynamic programming, etc. Then refresh my big-O notation as well. Unless you are doing it everyday, this stuff ain't simple or easy to master to the level of being able to code it up during a 45 min online session.
I can easily see 2-3 weeks of full time studying for myself to even be minimally ready to code up a BFS search in python, as part of a larger problem, in python, in 45 minutes, while writing an example down, while writing a test case, while talking out loud.
For me, easy is something that a person of average skill in that domain can do and that the top 20ish% person in that domain can do with their eyes closed.
I have a masters in CS, I know all of the words and stuff in your essay. I have been programming python for a while. I would most definitely need to study up on graph algos, implementing sorting algos, dynamic programming, etc. Then refresh my big-O notation as well. Unless you are doing it everyday, this stuff ain't simple or easy to master to the level of being able to code it up during a 45 min online session.
I can easily see 2-3 weeks of full time studying for myself to even be minimally ready to code up a BFS search in python, as part of a larger problem, in python, in 45 minutes, while writing an example down, while writing a test case, while talking out loud.
What an incredible post.
Whether you agree or disagree with the guidance here, you have to respect the effort that has gone in to put this together. Especially good in understanding the role of the corporate recruiter - not a friend, not an enemy - though I would add nuance such that they are not a friend but become a friend once you secure the endorsement of A N other assessor.
Whether you agree or disagree with the guidance here, you have to respect the effort that has gone in to put this together. Especially good in understanding the role of the corporate recruiter - not a friend, not an enemy - though I would add nuance such that they are not a friend but become a friend once you secure the endorsement of A N other assessor.
I agree that this is a pretty well-written post. A couple key points that could be further emphasized are that:
1) Recruiters often have quotas too - In many cases, their own performance is measured by hitting hiring targets, so they're incentivized to get you in the door, even if not on best terms for you.
2) In the age of initial RSU stock grants, underleveling can be VERY, VERY costly. The difference between L and L - 1 could be > $100k/year, so the penalty may be far more severe than just time, especially if annual stock refresh is based on level as well.
3) Coding interviews aren't supposed to test knowledge of specific algorithms, but I've been part of a hiring committee at a FAANG and had to request another round of interviewing a few times because the original interviewer failed the candidate based on a chosen coding question that had to do more with knowledge of matrix math, graph theory, etc. than the ability to take a problem, break it down, consider edge cases, and produce code.
4) The process is indeed very arbitrary. My favorite story is about a time I submitted my resume and got a call from a recruiter two weeks later who loved my background. I interviewed and got an offer that I eventually declined. I learned during the process that my application was rejected by the company's resume scanning software. It was purely a coincidence that a recruiter happened upon my LinkedIn profile (which mirrored my resume) at nearly the same time.
1) Recruiters often have quotas too - In many cases, their own performance is measured by hitting hiring targets, so they're incentivized to get you in the door, even if not on best terms for you.
2) In the age of initial RSU stock grants, underleveling can be VERY, VERY costly. The difference between L and L - 1 could be > $100k/year, so the penalty may be far more severe than just time, especially if annual stock refresh is based on level as well.
3) Coding interviews aren't supposed to test knowledge of specific algorithms, but I've been part of a hiring committee at a FAANG and had to request another round of interviewing a few times because the original interviewer failed the candidate based on a chosen coding question that had to do more with knowledge of matrix math, graph theory, etc. than the ability to take a problem, break it down, consider edge cases, and produce code.
4) The process is indeed very arbitrary. My favorite story is about a time I submitted my resume and got a call from a recruiter two weeks later who loved my background. I interviewed and got an offer that I eventually declined. I learned during the process that my application was rejected by the company's resume scanning software. It was purely a coincidence that a recruiter happened upon my LinkedIn profile (which mirrored my resume) at nearly the same time.
> 4) The process is indeed very arbitrary. My favorite story is about a time I submitted my resume and got a call from a recruiter two weeks later who loved my background. I interviewed and got an offer that I eventually declined. I learned during the process that my application was rejected by the company's resume scanning software. It was purely a coincidence that a recruiter happened upon my LinkedIn profile (which mirrored my resume) at nearly the same time.
I had something similar happen to me. I submitted my resume on the company's career page after seeing a role that matched me perfectly. I got an automated email telling me I wasn't the right fit. Dejected, I posted my resume on a job portal only to have a recruiter reach out to me for the exact same position. I interviewed and got an offer.
I had something similar happen to me. I submitted my resume on the company's career page after seeing a role that matched me perfectly. I got an automated email telling me I wasn't the right fit. Dejected, I posted my resume on a job portal only to have a recruiter reach out to me for the exact same position. I interviewed and got an offer.
I'm always curious in these cases: do people point that kind of thing out? If you get such feedback from a candidate, is there something you can realistically do about it in your company?
I did bring it up with the hiring manager. I turned down the offer so, I don't know if they did anything about it.
Thank you! :) Yes, I spent quite some time preparing for that post.
If you disagree with some of the guidance, I'm happy to discuss (and/or revisit some of the advice)!
Such a well written post. OP has saved me the effort of writing post on this topic. I'll just refer to this link. One thing I would like to add is that, usually offers from BigTech companies last much longer than candidates think. Companies dont want to miss out on good candidates and it takes awful lot of time to hire one.
Also, if you interview candidates regularly, please abstain from asking Dynamic Programming problems unless the job really needs it. It doesnt give any signal about candidates coding skills or ability to write good code. Most of them are just memorized solutions.
Also, if you interview candidates regularly, please abstain from asking Dynamic Programming problems unless the job really needs it. It doesnt give any signal about candidates coding skills or ability to write good code. Most of them are just memorized solutions.
This is very high quality advice and worth a read if you are interested in working for a FAANG.
What I don't get is a lot of big companies only do team matching after you have already passed the interview
In that case how could they do domain-knowledge interviews if they don't even know what you will be working on?
In that case how could they do domain-knowledge interviews if they don't even know what you will be working on?
Typically it's based on self reported domain expertise and general hiring interests that you express to the recruiter - to check your competence in what you claim your competence is.
But overall the hiring process is slowly changing and now you're more likely to be targeting more specific area of the company, and then your interviewers have a high chance to later be ones during team matching calls.
When I started interviewing, I went for a year of ~2 interviews a week and never saw anyone I'd know on the list of other interviewers. Now it's getting more and more likely (other interviewers for example also work at Research and we are interviewing candidates targeting Research).
In many cases they don't. I'm a PM at FAANG but the process is roughly similar in that you do a generalist interview loop. Most PMs work on consumer products so the questions are commonly stuff like [highly simplified for example purposes] "how would you grow the userbase of a new photo sharing app" or "Which is more important, growth or retention and why?"
I have some colleagues who are career enterprise and infrastructure PMs and they tell me it's very frustrating to have tons of very valuable expertise and then get asked a question about Tik Tok in an interview. I've also heard from SWE friends that they self-identify as a backend/infra engineer to the recruiter, only to show up to the interview and be asked to create a webpage from a mock and some specs. tl;dr FAANG has not figured this out yet.
I have some colleagues who are career enterprise and infrastructure PMs and they tell me it's very frustrating to have tons of very valuable expertise and then get asked a question about Tik Tok in an interview. I've also heard from SWE friends that they self-identify as a backend/infra engineer to the recruiter, only to show up to the interview and be asked to create a webpage from a mock and some specs. tl;dr FAANG has not figured this out yet.
Is it better to be overleveled or underleveled? Presumably, overleveling would increase your compensation at the risk of not being able to deliver and being washed out early.
100% overleveled, imo. Being underleveled literally erases years from your career.
It will take a little while for you to "wash out" as you put it, and in that period you can just look for another job with a better anchor point. In the mean time you'll be getting paid significantly more.
I also think that the levels are noisy. A good enough L4 can manage a "good enough" rating at L5 almost always. The hard part is actually getting promoted.
It will take a little while for you to "wash out" as you put it, and in that period you can just look for another job with a better anchor point. In the mean time you'll be getting paid significantly more.
I also think that the levels are noisy. A good enough L4 can manage a "good enough" rating at L5 almost always. The hard part is actually getting promoted.
I don't know if this translates to other FAANG companies as well, but "washed out too early" doesn't happen at Google. It's very very hard to get fired. You know all the stories of people just "resting and vesting"? It's definitely a thing.
On the other hand, you might be getting "average" ratings (where average translates in practice to poor - a paradox culture of everyone always expecting you to exceed the expectations ;) ), and after 4 years when the initial equity grant runs out, refreshed will be lower and you will start having significantly less stock (which is definitely more than half of the total compensation on higher levels).
(Also IMO it's rather impossible to get overleveled.)
On the other hand, you might be getting "average" ratings (where average translates in practice to poor - a paradox culture of everyone always expecting you to exceed the expectations ;) ), and after 4 years when the initial equity grant runs out, refreshed will be lower and you will start having significantly less stock (which is definitely more than half of the total compensation on higher levels).
(Also IMO it's rather impossible to get overleveled.)
> At Google it took me roughly ~5 months from my first chat with a recruiter and agreeing for interviews to signing my offer.
Forget leetcode, this would burn me out much more.
Forget leetcode, this would burn me out much more.
This is gold! Thank you for writing this up.
Great post, thanks for sharing.
I think this essay understates how difficult the coding test screenings can be. I do agree that it is not necessary to memorize obscure algorithms - second year data structures and algorithms will do. But (based on my experience) the progress you need to make in workable code in 45 minutes at s whiteboard id too great to refer to any of this as a “simple coding test”. I know some might view this as a quibble around semantics, and “simple” is subjective. But words have meaning and we have to draw the line somewhere. I maintain that this is not simple for a reasonable definition if simple.
This is easily remedied since I can be exact: designated “hard” questions from Cracking the coding interview are fair game, and you are expected to make substantial coding progress at the white board in 45 min.
I’d like to wrap up by coming back to my first point - excellent essay, worth bookmarking and reading in full.