The article could be a_lot_ more concise. Here’s what I got out of it as the takeaway:
> And that helps us understand why Recursive Cactus spends so much time practicing. He’s training himself partially because his current company isn’t developing his skills.
Exactly. Recursive Calculus wants a better job, (a lot) higher pay, a better environment. So he spends time prepping for this.
And companies who can offer all of this, and get a lot of interest already, they are selective, minimising false positives in the hiring process. They expect working code in the coding challenge, a good attitude and some other skills like demonstrating decent systems design. Recursive Calculus also preps so much as his interview process to his current place was different and he _really_ wants to nail these interviews, get a bunch of offers and get into a bidding war before saying bye to his current workplace he’d love to leave for something better.
There wasn’t really any actionable thing in this article that I found, or applicable advice. The end.
The actionable thing is the graph about two thirds of the way down - passthrough rate vs performance.
That's the whole point of the article. Two possible conclusions:
One is that companies are cargo-culting hiring, and have absolutely no idea what they're doing. Clearly whatever the process is supposed to do, it's not hiring the "best people" by any realistic metric.
The other is that the process is working as intended, but the actual goals are not stated. This might be true if the aim is to hiring difficult and stressful for candidates to discourage job hopping. (Other interpretations are also possible. [1])
If a company wants the "best people" it needs to follow up hiring with performance tracking, and identify and reward the people and hiring practices which increase performance. [2]
If companies want hiring to continue as a social/political game which stresses and discourages developers, the system is working for them, and they don't need to change it.
Startups need to decide what kind of company they want to be. [3]
[1] IMO there may be a strong element of corporate narcissism in the process. It's not about hiring good people, it's about allowing the CEO and senior management to feel that their company is better than those other companies which hire these people. In reality "these people" may be a bit more than averagely competent, but with a few standouts most won't be insanely great or A players or 10X or whatever the goal is supposed to be.
[2] Which assumes it's possible to measure performance, which is a whole other issue.
[3] I'd bet almost anything that in reality there's a lot of "Oh, you were working with X at Y? Awesome!" affecting hiring choices in SV.
> If a company wants the "best people" it needs to follow up hiring with performance tracking, and identify and reward the people and hiring practices which increase performance. [2]
And that's glossing over a ton of massive difficulty, which is one of the biggest reasons things move slowly and are more based on opinion than data.
It seems like a lot of these discussions end up being something along the lines of "the standards are bad because they exclude me, therefore there shouldn't be any standards at all" (just with a lot more words).
The standards (e.g. algorithmic questions) are bad because
A) they're only tangentially related to the work, meaning they include bad hires and exclude good hires
B) they put a huge workload on employees who must practice tens or hundreds of hours of underwater basket weaving, time which would be better spent doing almost anything else
C) they systemically exclude anyone who can't play the dumb game due to a lack of time, including but not limited to older people and poorer people
> A) they're only tangentially related to the work, meaning they include bad hires and exclude good hires
And that's the reason many companies have to set the standards so high in the first place: excluding false positives (bad hires) is so important in practice that this distorts the whole hiring process. Fine as far as that goes of course, but it does mean that people who practice their leetcode questions are basically stuck with very expensive (per B and C) lottery tickets.
I think everyone knows at this point that algorithmic puzzles are not desirable; the real question is whether one can do better, even at FAANG scale.
Puzzles no, but it really matters how candidates are evaluated on coding.
For coding, if a coding question boils down to implementing KMP string matching or something that's only realistically solvable by memorizing the entire algorithm and writing it out on a whiteboard, then it's not any different than any of the puzzle type questions like "why are manholes round?"
The proper way to evaluate coding questions, and what is mentioned in the article, is that one is evaluating general intelligence in the context of software programming. Is the candidate coming up with a reasonable solution? Are they asking questions to understand the problem better? If they get stumped by something, do they stay stuck on it, ask for help, or think through it? Can they find the issues with their code and improve on it?
I haven't heard of a better way to interview engineers, but if there is I'm definitely all ears.
I agree the standards are bad, for senior devs in particular.
In addition to your points:
Technical understanding of systems in general (networking, CAP, testing, writing maintainable code) are all overlooked in the interview process, though these are what actually make a developer productive.
The older you get the more specialized and optimized you are to learning what matters, which is why most of the older guys suck at these types of interviews.
Imagine interviewing Brendan Gregg by giving him some leetcode problems!
That's a very good summary. Discerning what truly matters is really the mark of experience. And you're right, algorithm memorization doesn't fit in the top-50 of what matters for a software engineer.
I went to CMU, enjoyed algorithms classes a lot. In the nearly 30-year career since, I've used that knowledge... never. Not once.
It's not about the interview bar being too high. It should be high, mine is. But interviews based on algorithm memorization have the bar in the wrong place, measuring something that has no real-world relevance.
I think of "the bar" as being basically our industry's equivalent to a law degree: it's just a way to show that you have some foundational knowledge in the subject, even if it bears little resemblance to day-to-day work. All of the flaws you enumerated could also apply to law school, but at least "the bar" is reasonably accessible and doesn't cost hundreds of thousands of dollars.
The annoying thing is that with the bar exam, there is a clearly defined test with criteria. Whereas what you have in the software industry is a vaguely-defined set of expectations that vary widely. There's no standard.
Definitely agree with you there. I wonder how far we are from some kind of standardization. Lots of startups are already in this space, but if a few FAANG companies adopted a common standard it wouldn't be long before a large share of the industry followed suit.
Yes well except you forgot that lawyers pass the bar once and don’t have to redo randomized exams over and over in under 45 minutes. My lawyer friends are making 160$/h and their interview efforts were an hour discussion with a few lunch meetings.
Most of the criticism probably should be articulated again to probe whether these standards are realistically something one can work towards.
If we’re out of the running no matter how much you practice, no matter how much job experience, and if there really is this mysterious value G, with the right combination of Ivy League CS program, then I can see how these discussions mirror the notion of ‘the bar’ - that is, a forgone conclusion.
You could start a company and hire people on other standards, and I suspect it would work, as long as the "other standards" are painful in the same way as the current ones. For example, you could require candidates to learn ten pages of Chinese poetry by heart, or anything else that tests their ability to keep their mind on-task for long stretches of time. In my experience, people with that ability can become good programmers if they're inclined to.
What won't work though is hiring based on only past experience. The bullshitters will eat you alive. You really do need some kind of "underwater basket weaving" as a test.
>And that helps us understand why Recursive Cactus spends so much time practicing. He’s training himself partially because his current company isn’t developing his skills.
I develop software full time and have some 10 years of experience depending on how you count it, and I'm absolutely terrible at leetcode style problems and find whiteboard questions difficult for non programming reasons.
I know it wasn't the point of the article, but there's a deeper problem here that most FAANG programming questions aren't actually testing work related code skills.
At my company we give two very basic tests, takehome. Both can be completed in 15 minutes if you're rushing. Far more useful of a tool than any of leetcode style questions.
I remember one time I was hiring for a JavaScript developer. The most important technical competency was a brief working knowledge of the DOM. The actual position required modifications to pages for A/B tests and jQuery was either too slow or broke in production when other developers used it for their test code.
Of everybody that passed through HR to me I sent out a notice that there would be a minor code assessment and they could not use jQuery. 6 or 7 people instantly dropped out. There were 22 people left that I actually talked to which only three could pass the code assessment.
The assessment was never designed to be challenging. Candidates were using their home computers had access to any reference material. There was no hurry. They could look things up. I also told them if they got stuck just ask me and I would point them in the right direction without any penalty, but only 2 candidates tried that.
The assessment was an hour long phone call. At the start of the call I would send out a static HTML page for the candidates to open in their browser and for them to write an answer in whatever tool they wanted but it had to execute in the console of a browser on that page. Tasks were things like take this item out of the page and reinsert at some other location or change the color of a particular paragraph to red. Stupid simple stuff that you would expect any UI developer to do easily. After all these were beginner skills and this was a senior level position.
I did ask to see the code they wrote only to make sure they completed the tasks. I would drop their code in my browser console and run. I never looked at code style or sloppiness. It’s a job interview where people are rushed and nervous. Their code is allowed to be sloppy.
Only 3 candidates were able to pass this code filter. The people that did pass either did well enough to pass or extremely excellent. The people that failed, maybe 19 of 22 people, all failed epically.
That experience really shocked me. I did everything I could think of to make this relaxing and take the edge off because there is always pressure during a job interview. No matter how much of a lifeline I threw out almost nobody would bite. They would sit there silent on the call or they would attempt to stall like that would somehow make code magically appear. Sometimes I would remind candidates they could ask me questions because I cannot evaluate a blank answer. Other times I would try nudge them to get started or guide them into progress, which only seemed to hurt more than help.
> No matter how much of a lifeline I threw out almost nobody would bite. They would sit there silent on the call or they would attempt to stall like that would somehow make code magically appear. Sometimes I would remind candidates they could ask me questions because I cannot evaluate a blank answer. Other times I would try nudge them to get started or guide them into progress, which only seemed to hurt more than help.
Because they felt that it was a false help. If they take it they're disqualifying themselves because they didn't know something.
I suppose they could have assumed I lied about the assistance, but surely they could have reasoned that would be less disqualifying than delivering nothing.
I've had very similar experiences with Delphi, Jade and embedded C developer interviews. It makes me wonder why other companies don't actually care whether I can write new code, only whether I can replay algorithms.
When interviewing I build a set of simple examples like yours and run people through them, normally in person. How they talk to me is also important.
Albeit here in Australia FAANG interviews are mostly regarded as yet another US foible like driving on the wrong side of the road. I've had exactly one attempt in ~10 job changes but they failed (I walked out as soon as they made it obvious that they were serious... but were not offering FAANG money).
I've written a fair amount of vanilla JS over the past 20 years and know what you're talking about.
But in the circle of people that I've talked to, everybody else uses frameworks, and I doubt they could make surgical changes in the browser console.
So you're excluding most of today's working front-end developers, and appealing to "edge cases." I guess you could pre-screen candidates by asking, "Are you familiar with vanilla JS?"
Doesn't something seeming insane automatically make you question and check your own assumptions and information first? Isn't the most likely explanation for your premise either that it's not true, or that your expecations don't match reality?
Is it true that most front-end devs don't know how to manipulate a DOM with JS? I don't know, but it's not exactly true; Jquery is still javascript. Do you do front end dev professionally, and use strictly the pure javascript DOM API with no frameworks? There's a reason most people who do front end dev for a living don't do that: because it's time-consuming and there are easier options. Also because there better options than fiddling with the DOM at all, like React.
Is it insane that most programmers wouldn't be able to code something up in X86 assembly during an interview? (Not to mention that most wouldn't be interested.) To me that seems like a similarly unrealistic expectation.
I'd assume that a developer should at least have a mental model of what DOM is and what it consists of, and that it can be queried and transformed by calling functions on JS objects that represent DOM nodes.
If the dev doesn't remember the names of actual functions (which is no fault, since that comes only with using them regularly), this would at least allow them to figure out what to search for on the Internet and how to use the results.
Is that a far fetched assumption? It's not really comparable to wanting a webdev to write some assembly code.
Well, the original problem seemed to be that interviewees were not able to even find the API. If they had a mental model od DOM, this shouldn't be a problem.
They'd knew that there are nodes, can be queried from the document via JS and moved in relation to other nodes, so they could just google: "move dom node", or "query dom node" and put the pieces together via JS.
Look, yes this very well might be a case of lots of inexperienced people shooting ambitiously high (you don’t win unless you try, right?). And it might be true that most people interviewing for front end jobs don’t know squat. The story above just doesn’t actually demonstrate that.
My point here is that there are other explanations, we can’t jump to the conclusion that the cause is because most people lack a mental model of the DOM, that’s overlooking many possible reasons. Nothing about the state of developers is proven by this anecdote.
The interview specifically asked about an API that most people simply do not use. It’s not a surprise that a bunch of candidates backed out when they learned this, and it’s not a surprise that it was accidentally more challenging than the interviewer thought for those who stayed.
It doesn’t really matter that Google was allowed, it’s an assumption to think that it’s easy to come up with keywords and search terms for a API you haven’t used, during a job interview. I’ve interviewed a lot of people and watched a lot of people freeze during interviews, people that I know would figure it out quickly if I wasn’t interviewing them and they were relaxed. A job interview is a test, and the test administrator isn’t in a position to claim that it should have been relaxing or easy for the test-takers.
I generally don't do front end development professionally.
I do know how to manipulate the DOM without frameworks. Learned it over a weekend.
If I were interviewing for front end, I wouldn't recall the syntax immediately, but I would know what to google or be able to have enough of a conversation with the interviewer to show them I have the basic understanding of what is happening.
I do backend. A similar situation might be something like using curl to make individual http requests.
Yeah, we don't do that in real life and I forget some of the parameters and flags available, but if I acted like I had no idea how to use curl, I hope an interviewer would be very disappointed with that.
The issue here is precisely is about recalling the syntax of a low-level approach, not whether you understand it conceptually. It’s the difference between being asked to make a request using curl, and constructing an HTTP request buffer manually without the help of a wrapper to tool to do it for you. It’d be the same as going to an interview, and having the interviewer ask you to complete an HTTP request on the spot using telnet and a keyboard. Sure, you can look it up, but when you do that you’re showing the interviewer you don’t already know.
Many devs know very well how to manipulate the DOM using JQuery, or construct the page they want using React. Most people do not use the low-level pure JS API. Conceptually I totally know how to make things happen in the DOM. Using the JavaScript built-in API, not really. Yeah it’s easy to learn in a weekend, that doesn’t change the fact that the API is tedious, hardly used in practice by most people, and rarely if ever necessary to use for performance reasons.
You say "The issue here is precisely is about recalling the syntax of a low-level approach, not whether you understand it conceptually" and in a scenario where an interviewer blindsided a candidate with such expectations I would agree, but that's not how we got to this topic.
The parent says, "Candidates were using their home computers had access to any reference material. There was no hurry. They could look things up," which is the opposite of that.
It even says they let candidates know ahead of time that's what the interview was.
I mean come on, people are on here and Reddit all the time acting like it's reasonable to grind leetcode for months to get a job, but a Saturday afternoon of studying the basics for an open book quiz on Monday is too much?
I should have said it’s about “using” the low-level syntax, and not “recalling”. You’re right that the story superficially claimed the interview was open-book and didn’t require memorizing the low level API, but it did say specifically that JQuery was not allowed. It was definitely not about conceptually understanding DOM manipulation.
As an experienced front-end developer, I can see from the story I might have personally bowed out of the interview too, not because I can’t use JavaScript to manipulate the DOM, but because I don’t want to. If the job involves doing that, I might think twice about that job.
You might be over-estimating how easy an open-book quiz is. I don’t think I’d pass an interview that asked me to write only x86 assembly, or write HTTP requests manually, or use pure JS to do what I know how to do in JQuery or React, even if it’s an open book quiz.
The big companies don't care if some great candidates can't do these kinds of problems, there are many others who can. They care about not hiring bad candidates, period.
Anyway, I've done both types and for me the false positive rate for take-home assignments is far greater. I've seen people ace home assignments and later turn out to be mediocre engineers. Maybe they were cheating. Maybe not.
But I've never seen anyone really ace an on-site coding question and not being great (I'm sure there are some, this is just my own experience).
We can't reasonably priced which is superior for selection, but in our opinion the process is much saner and less resource intensive on our part.
I wonder if the modern interview process at large orgs is built on a false sense of security. They are possibly overly selecting and perhaps successfully choosing above average candidates but missing exceptional cases who fail to conform to their rigid criteria.
Perhaps there wasn't any actionable advice, but it's a sad indictment of the current state of tech hiring. Based on the article you can assume that Recursive Cactus is already in Big-Tech ("well known tech company") so "(a lot) higher pay" is a moot point and quite frankly it's unlikely that the daily tasks involved in the next job will bear a strong resemblance to the kind of synthetic tasks or problems you are asked about in an interview setting.
The article did raise more questions than answers, but that was by design. A lot of the assumptions that go into most tech interview processes don't withstand scrutiny. Interviewing is a hard problem to solve, but we shouldn't be satisfied with the status quo.
no its not. I know ppl who quit MS and reapply later to get placed into a higher tier after they interviewed there again. Jumping jobs into a higher tier is easier way to get a raise than grinding at the same job.
Just adding I had to do this at a large non-faang corp. Just curious how common this is, it seems like the only work around to strict HR caps on raises.
Extremely common. Interviewing is a tiring and arduous process and companies have all the power. They make the bet that the majority of people are not willing to leave (esp. once they have families).
Varies by industry and sector, but there's typically no "technical". It goes:
1) Resume + cover letter + cumbersome online job app,
2) phone screen,
3) On-site, and
4) Reference check.
Typically the interviews are more conversational, with an emphasis on behavioral questions, job history, and relevant skills. Academia and government have their own formats.
> and quite frankly it's unlikely that the daily tasks involved in the next job will bear a strong resemblance to the kind of synthetic tasks or problems you are asked about in an interview setting.
The blog post mentions in passing that their interview.io site gives users a choice between practicing traditional "synthetic"/algorithmic questions and a different approach focused on "systems design". I'm not entirely sure what the latter involves, but it seems like it could strike quite a bit closer to the generalist knowledge that would be required in "day to day work", while preserving a desirable problem-solving component.
One might even imagine using both approaches in combination, e.g. using algorithmic puzzles as a sort of tie-breaker to choose among candidates who seem about equally strong in the 'systems design' domain.
Algorithmic coding tasks and system design questions are the two types of things you get asked in SWE interviews. They just have practice interviews for both. It's not novel.
None of my jobs have done much to exercise the skills I’d need to get exactly the same job in every way at a place that does whiteboard quizzes, language trivia questions, and/or leetcode stuff. It’s not even about moving “up”, necessarily.
I had a conversation with a fellow engineer and we pretty much concluded that our current company would not hire us with our current resumes if we had to go through the interviewing process. And we are generally viewed as some of the higher performers. I bet the same is true for a lot of other companies.
I too would most likely not get hired at my current company with the current interviewing process (which I am asked to do technical portions of!). Company growth really changes things.
I suck at writing resumes, to the point that recruiters and even hiring managers at companies that I applied to give me a pity and even talk on how to improve my resume DURING INITIAL PHONE CALL lmao.
(Your comment was probably downvoted because it broke this site guideline: Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized.)
I have a similar perspective in that I think most engineers probably could get hired, but there's enough randomness in the interview process that we probably wouldn't. Not just in who gets advanced to the phone screen, but also variability in test performance. Most of the interviews were open-ended and had multiple correct answers - but it still really only answers, "did the candidate think of the right answer in X minutes". One of our questions pretty much explicitly required knowledge of how to implement a rolling hash to pass, and that's not something I knew when I worked at the company.
I'm of the mind that most interview questions can only reliably identify people who are not capable of coding, and roughly gauge the algorithms knowledge. I had floated the idea of making interview experiences that more closely resemble work, like having the candidates make PRs in a mock repository. Better yet we could see not just how they make a PR but also review PRs and make comments. But often the primary concern is logistical. It's easy to train people up on 1-hour problems with a grading rubric, than a longer more open ended interview.
For sure -- I've seen this at multiple companies. I'm not sure what causes this. I suspect there's a certain element of "pulling up the drawbridge" going on here.
This is so silly. Here's teh secret: your programming ability is set genetically by how much Yeti blood you have in your ancestry. Yeti half-breeds recognize each other (often unconsciously) by smell. That's why some people can get programming jobs hella easily while others just can't even after strenuous training. Check your feet. If your second toe isn't longer than your big toe you're screwed. Give it up. You might as well go get an MBA or something.
The section in that article about 'Defining “Intelligence”' is similar to a previous discussion on HN about whether a FAANG interview is just "an IQ test which is disguised as a relevant skills test for legal reasons". [1] This article does a good job of supporting that claim. Theoretically, both IQ tests & FAANG interviews test for whatever "innate intelligence", but in practice, both of them can be gamed by grinding brainteasers & leetcode respectively.
The tech interview process is just so badly messed up. Even if the process were a reasonable proxy for IQ (it's not), or correlated somewhat with use of actual required technical skills (it doesn't), it still almost entirely ignores the EQ (emotional intelligence) and CQ (cultural intelligence) factors which comprise the other 2 legs of the "good hire" stool.
IMO the grueling FAANG interviews actually optimize for how much people want to work at the company. If you're sitting through 10 interviews and grinding on LeetCode problems every night then really all you are proving is how badly you want the job. It's effectively a hazing ritual.
That seems to be it. But I don't get why. It's like wanting to join a gang or mafia: you have to prove how dedicated you are to join a particular organization.
If you make it as far as internship to hire, the company is signaling more of a commitment than just temp work. It's basically like a probationary period.
Also this would be especially good for graduates with little work experience.
Sure, that’s exactly what an internship is and it’s why these companies offer it. If you gave a similar opportunity to people who are already in the industry, you would have a major adverse selection problem where the better candidates would never pick a “probationary” job with second-class status over a normal job.
>Sure, that’s exactly what an internship is and it’s why these companies
I don't think so, to me an internship is temporary by nature and does not have a "guaranteed" job at the end based on good performance.
>you would have a major adverse selection problem where the better candidates would never pick a “probationary” job with second-class status over a normal job
The selection process is so competitive right now that I think plenty of people would be happy for such a change if it meant a more reasonable interview process. Plenty of strong candidates are being thrown away over arbitrary metrics right now anyway.
Personally I'd take a non-leetcode non-white board interview with a probationary period over the typical grueling 2-5 round FAANG process, and I'm sure I'm not the only competent developer who expects to have trouble with the typical FAANG process.
>I don't think so, to me an internship is temporary by nature and does not have a "guaranteed" job at the end based on good performance.
If you do a great job in a FAANG internship then you will get a full time offer at the end. Does the probationary period you propose have a lower performance bar than is applied post-internship? If so then it seems it wouldn’t achieve FAANG’s standards.
> The selection process is so competitive right now that I think plenty of people would be happy for such a change if it meant a more reasonable interview process. Plenty of strong candidates are being thrown away over arbitrary metrics right now anyway.
FAANG doesn’t need to attract more weaker candidates who can’t pass the interview, they are more concerned about getting strong candidates who have multiple offers to pick them. For less competitive candidates there are contract positions.
This only works for new grads. Why would I ever want to quit my job to get hired as an intern? In our industry, quality people overwhelmingly already have jobs, so this way you’re restricting yourself to pool of lower quality candidates on average.
The last time I was applying, I was finally at a place in my career where I felt I could choose an interesting company to work for. I applied for places like Tesla and SpaceX and Boston Dynamics and such. I ended up in a fantastic role through the typical process, but if someone had offered me internship to hire at a desirable company I gladly would have taken it and used it as an opportunity to demonstrate my value.
Maybe this is something only companies with reputations can do.
Hiring a candidate based on a 1 hour interview and a minimal coding exercise is a pretty substantial risk. I'm surprised more companies don't do this as a sort of hedge. I doubt it'd be that discouraging - do you know how many candidates apply for the average role right now? And if they're willing to jump through all the ridiculous leetcode hoops now, I imagine they'd be willing to take the internship too. Especially if that means we can return to saner interviews.
> the only surefire way to hire is to bring people on temporarily and evaluate their performance in 1-3 months
In countries that have decent leave policies this might be possible for people who have jobs, but it would be expensive then and even more expensive for others. I can see myself taking a month off to go and work at Elite Company X, then going back, working out my notice, then starting the new job. But that stretchs the hiring period and makes them vulnerable to counteroffers (I can give notice to Elite Company X too).
But where I am now, no way. I can't take a month off on less than about six months notice, and right now I wouldn't get it because of the pandemic. So in the event that someone wanted to hire me, or someone senior in the US (etc), they'd have to front enough money to make it worth while quitting my current job on the off chance I might make it past the trial period.
Albeit when I was younger and jobs were much easier to get, I used to habitually negotiate salary at new jobs by saying "pay me what you want, then in three months you either start paying me what I'm asking or dump me". It is effective, sounds a bit arrogant (and not everyone likes that), and only once did someone try to negotiate after the trial period. That was a very short negotiation and they decided they'd rather keep me.
This sort of already exists. Many companies take on university students to intern for 3 months over the summer, and offer full-time return offers to seniors. At least in the US Bay Area, this is substantially more common than offering internships to full-time employees. Mainly for the reason people mention: 1-3 months is a huge time investment for what amounts to an extended (albeit paid) interview, when they can interview somewhere else and get a full-time offer with no uncertainty.
Google also offers associates or something similar to that. But it's for much longer, 6 months or a year.
In my experience interviewing candidates for a FAANG, people say that they weight "CQ" heavily behind closed doors, but it is mostly used as a way to enforce various -isms under the guise of "probably would[n't] be a good cultural fit". It's how they screen out people who might have or develop a family life, among other things.
> it still almost entirely ignores the EQ (emotional intelligence) and CQ (cultural intelligence) factors which comprise the other 2 legs of the "good hire" stool.
all of them have "behavioral round" which is similarly hacked as white board rounds. Check leetcode discuss.
Describe the time you had a conflict with your team == Invert a binary tree.
I applied to a new grad production engineering job at Facebook recently.
I probably did about 80 leetcode puzzles, let's just assume that is 1 hour per puzzle. So 80 hours of leetcode puzzles.
In addition, 10 hours were spent reviewing my networking trivia (focused on layer 2/3/4 and HTTP).
The PE recruiter at the company also provided a study guide packet. I elected to sink about 10-20 hours into studying the Linux troubleshooting and finding some common questions off of Glassdoor to understand the type of things they will be asking.
Finally I tried to review some system design stuff (but as a juniour in this industry didn't really know how) Just followed some study guides from the system-design-primer on Github. Probably 5 hours dedicated to this.
Let's just round it to about 100 hours of prep in about a month and a half. While juggling a full time job as a devops engineer.
Afterwards I was rejected :)
Ultimately I wasn't surprised I was rejected. I was under the impression that I needed to pass all 7 of the interviews in order to get an offer (2 phone screens, 5 on site.) I know for sure I failed the system design interview question HARD. Like irredeemably hard. Regardless of my performances in my other interviews, I know I definitely did a good job in my network and OS interviews but it doesn't matter.
I do wish that companies would provide a feedback system. I would love to know where they thought I was weak so that I can improve upon that later. But there is nothing beyond "we decided to pursue other candidates."
Here's the crazy thing, though. It isn't even a question in my mind that I should try again if another FAANG recruiter reaches out to me. I will sink another 200 hours if necessary to pass their interviews because of what it represents to achieve getting hired at such a firm. There's prestige, salary, and quality of life that just can't be matched by any other tech companies.
> There's prestige, salary, and quality of life that just can't be matched by any other tech companies.
Not sure about prestige and quality of life. Salary, yes!. I happily quit my Microsoft for a slightly lower pay and way better quality of life.
Right now AAMFGN are hiring tons of engineers. So their quality really varies and different teams have different bars. You can't say they worked at Google so they must be good. We are humans and we have our biases. Like it or not, hiring is biased (mostly towards white/asian males from prestigious universities). To counteract, there's also diversity hires (with various degrees of definition what it exactly is).
For some people, money is much higher priority, for others it's not. Just be sure what you really want from life. Remember, it's not a race.
For many Google does carry that weight. And unlike Msft, the hiring bar is common across the company and is not decided by teams. Something that I feel, always results in more consistent hires.
>There's prestige, salary, and quality of life that just can't be matched by any other tech companies.
To asses the quality of life you have to take into account : payment, time spent on the job and for the job, the amount of work, the prices in the area you live and work, the stress level, the interactions in the company and probably more.
I've done these calculations and for myself, job hunting for FAANG isn't worth. I would however not refuse to work for FAANG if that would match my personal goals, however working for FAANG would not be a goal in itself.
At 45, I’m still an active developer and these days just your regular old “Enterprise Architect”. Married, dual income living in the too big house in the burbs of a major metropolitan city. We make “enough” that making more wouldn’t change our lifestyle.
Grinding algorithms to work for a FAANG doesn’t interest me. I’m actively disinterested.
Even though I started as a hobby developer in the 80s doing assembly and spent the first decade of my career writing assembly, now I’m much more interested in solving business and process problems than I am in the computer science side of software development.
So, next move will probably be more in the Solutions Architect/Professional Services/Enterprise Architect/Consulting route for a few years. I’ll have to do a little “grinding architecture”, and I may end up at one of the major cloud providers but that isn’t a goal in and of itself.
I like to calculate dollars per hour worked when comparing roles, and I use a fairly generous overtime multiplier (ie, 35 hours a week base, then time and a half for the next 10 hours, then double time the next 15 then you can take your job and shove it)
All too often the big, hard, prestigious companies turn out to pay the same hourly rate as the second-tier places if not slightly less. But the same quality of life at 45 hours a week costs a lot more than at 35 hours a week. So you have to look at the prestige benefits and hope they pay off.
this is fine, so long as you're looking to get hired by a megacorp (fine,faang.) but for most people theres a point of diminishing returns. Do you want to spend six months to a year out of your life drilling for a $10k raise working for a company that works you like a rented mule anyhow, or do you settle with your present quality of life and conclude 70k is enough to do whatever you wanted to reasonably do anyway.
Then theres the variable of google et. al. and their random eleven-round interviews. Are you patient enough to sit through questions like "how many kegs of beer on a schoolbus" and "how to build a datacenter on the moon" from some grinning techbro only to be told youre re-invited to another round of interviews?
Finally, age. You can cram and cram but if youre over 50 your chances of building that moon datacenter are better than getting hired.
I agree with a few things you said but you're also wrong about a few things.
FAANG compensation is much higher than you think. $200k/year (including stock) in the Bay Area for new grads is common. Yes, the prep for these interviews is insane but what has effectively happened (and this is supported by the article) is that companies have offloaded the selection work to the interviewee: they will only be able to pass if they are willing to do the ridiculous prep work. And yes, the interview questions have nothing to do with the job; that's not the point. Sadly, the process is often selecting for intelligent, compliant worker bees and not, what I would prefer, more creatively-inclined people. I agree with you: depending on what team you end up on, you could be asked to clock-in, crank out code, and clock-out without much creativity or input into anything.
BTW, Google doesn't use brain teasers since 15+ years ago. But, there is the occasional interviewer who asks questions about trivia that only they know about. This is supposed to be banned but there's no consequences for interviewers who do this. Hiring committees (who make the decision) usually throw out these questions when they see them in the list of interview feedback that they are using to make a decision.
Re: age. I worked on a team at FAANG that has tried very hard to hire folks with industry experience and we haven't found any resistance from interviewers to that. However, when talking to potential interviewees, we have found that very few are willing to subject themselves to the interviewing process for the reasons that you've outlined above. I don't blame them.
I decided that I wanted a job at Google, so I did the only reasonable and started grinding Leetcodes, probably at the same level as Recursive Cactus. I even took two days a week off for a couple of months to just do leetcodes. ~10 hours every weekend was Leetcodes. I read the whole CLRS (and made sure that I understood 80% at least). I wrote a thesis. I studied maths. I dug deep into databases and distributed systems.
All this at the same time as I was working a full-time job as a softare engineer at a world-famous tech company and as a head of engineering at a startup.
I've been programming my whole life, and I've got a lot of experience with Java, C++ and Ruby, and now 10 years professionally. I've written operating systems, game engines, networking protocols and many products from the ground up. I get great feedback wherever I go and I learn systems very quickly, and I'm soon the "go to"-guy at a new place. I tend to out-experience the "old guys" that everyone look up to.
But Google? I was invited for a video interview. I think I might've miscommunicated my understanding of database transactions (though I got great feedback on my coding tests), but alas, from that point, the recruiter lost any interest they might've had. For some position, I had to ask multiple times to learn that it was internally filled.
Thanks for the kind words. Unfortunately I'm not sure the stress is worth it.
Also, it's not like I'm getting bombarded by FAANG recruiters anymore (where did they all go?), and I'm not going to submit my CV to a "black hole"...
> "how many kegs of beer on a schoolbus" and "how to build a datacenter on the moon"
I interviewed at Google and Facebook in 2015 and never got any questions like that. I don't think they've had those type of brainteasers for over a decade.
> Are you patient enough to sit through questions like "how many kegs of beer on a schoolbus" and "how to build a datacenter on the moon" from some grinning techbro only to be told youre re-invited to another round of interviews?
I systematically end all interviews when they've reached this point. As soon as the smart-ass finishes their stupid question I just say "I think we're done here". I can stomach take homes, even whiteboarding, but don't ask me how many tennis balls would fit in the Empire State Building.
The last time I really looked for a job was maybe 4 or 5 years ago. I interviewed at ~5 or 6 companies and I got a variation of this 2 or 3 times. So let's say 1/3rd of the interviews.
They do happen yes, I don't know if it's common or if I'm just not very lucky :)
Usually they don't really understand what I mean, and I just elaborate by explaining that I have no interest in working for a company that uses this type of brainteaser to decide who to hire.
One time the guy got half angry, started defending his process and just walked me out. Another time they tried to move on to the next interviewer and I just said I wasn't interested anymore, it would be a waste of time.
Obviously I never got a positive response after saying that. I still dream of the day when the interviewer will shout "that's right! That was the test! You passed!" :)
I can usually spot the candidates who are leetcode junkies. This is why I direct our interviews to be as pragmatic as possible. Most of our question bank comes from actual code one of our devs had to implement.
I'm fairly confident that if you've studied hard enough to solve these problems easier the studying just paid off by making you a better developer.
Ironically, I think I develop this ability as well through solving hundreds of Leetcode questions myself. At some point I actually have to step back and think, act not to solve it too quickly otherwise the interviewer will spot me as Leetcode junkies.
People will just game this as well. If you already know the answer to a question coming in because you leetcode all day you could easily ask a lot of clarifying questions, identify edge cases, and give brunt force/alternative approaches before solving the question. A smart person will use that opportunity to highlight their communication skills and get an even higher grade on the interview
Our questions aren't on leetcode and we aggressively monitor for leaks (including on Blind). You're also missing the point: we're intentionally avoiding the questions which boil down to a binary question of "do you know this algorithm or not?". Most of our questions are open-form, asking the candidate to implement a widget or interface with an API. They usually don't involve big-O or any data structure tricks. Unless you've seen the exact problem before leetcode won't help aside from general programming practice.
Also I will say that the few candidates who've tried lying about seeing a question before are not as good at acting as they think they are. Not only do you have to pretend that you've never seen the question before but if you don't stumble, second-guess yourself, refactor parts of it, etc. it's usually pretty obvious.
Now, if someone's a great actor and they've seen all four problems before and manage to impress the hiring manager -- well, what can you do. But I don't think there are very many of those.
I can tell you how I spot:
1. Doing it in Python. "Can I do this with Python instead of X? because Python is really fast to write and I don't need to worry about small helper functions"
2. Know various approaches more than ordinary people. "Ah we can solve this in various approaches. We can sort this one, and the problem will be log N, or we can use Heap and make it log K. We can use stack but does it get counted as space in the space complexity? Oh I can use deque here but let me just use Python list because Python list is very versatile, it can be anything, it can be array, can be queue, can be stack"
3. Know the solution right away even the non obvious ones. One example is the problem of next permutation. Given a number 1, 3, 2, 4, 5. Find the next permutation in O(n) time and O(1) space. This solution is easy but if you have never done it before there is no way you can come up with a solution complete with code. Another problem, given preorder and inorder list, construct the binary tree. There are many non obvious problems like this.
I'm not penalizing them. I don't think it is bad if someone is a Leetcode junkies. Definitely not downing points if they use Python.
But to actually answer your question. Say the role is in JavaScript, say a Frontend role and the candidates want to answer it in Python instead of JavaScript. Then it is possible that the candidate is a Leetcode junkies.
Why I know? Because I do this myself. And definitely no points subtracted from knowing and using Python.
I think it is worth it. I did Leetcode in JS, then in Go, then in Python.
In Python you just need to focus on the actual algorithms than the actual minuteae details such as "let me create a function to copy this array". As long as you are aware of limitations such as Python int has no restriction like Java (int32, int64) etc, because some problems require you to look into that restrictions. Python string concatenation is also O(n^2) because there is no stringbuilder in Python. Just be aware of those and it should be fine.
also in Python you can literally not use a computer and just write down your algorithm in a piece of paper. makes it more fun to kill time during queueing in line, commuting etc lol.
It's usually forgiven if you mention that you know that specific language idiosyncrasy and they'll handwave it for the purposes of the interview. If they don't, then that's what knowing alternatives is for.
I feel like giving people a decent coding project is, at the moment anyway, the best approach. If I'm interviewing someone I really just want to see these things: what their code is like, what their final result looks like (if there's room for creativity -and there should be), how they got there (revision history). And then in the interview portion I just want to get a sense of their personality and their decision making process on the project. It's not perfect but it gives a sense of if they can finish a likely task, and if they would be easy or hard to work with.
Btw, none of that involves puzzles or trying to guess their IQ. If your company is like google in 1998 maybe you care about that, but chances are you need someone to build something relatively straightforward, not invent PageRank. Honestly having a super genius on board might be bad if you're not solving a truly hard problem - they might get bored and check out.
It's a valid complaint that these projects can take time, but job searching is pretty time consuming anyway, and joining the wrong company or hiring the wrong person is way more so.
So I got contacted by Facebook London about 2 weeks ago. The job description sounded quite interesting, but when the recruiter described the interview process and actually sent me a deck with resources for preparation for coding interview he lost me.
The reason is that I am absolutely satisfied with my current job and decided that I don't want to bother at this time with preparation for an interview. Maybe I would pass it without prep, but I would not feel comfortable showing up without putting any time in.
I get a feeling that process as this somehow does not select for top performers that are already working on exciting stuff.
Over the past 27 years, I've worked for 8 different organizations, including two FAANGs, and I've never technically prepared for any interview. This is not some kind of indirect boasting about how smart I am. Far from it. I feel positively dumb compared to my peers.
I rarely fully nail the most difficult algorithmic interviews, and I don't think that's the point. I think I get most of my 'points' by taking a very direct, easy going and open approach to things. The phrases "I don't know" and "I'm not sure" will get practically worn out at the end of my interviews.
I don't think it's what one knows as much as it is about how one approaches and thinks about problems.
Second item: do the interviews anyway, even if you don't necessarily intend on leaving.
I'll tell recruiters that I'm pretty happy where I'm at, and that it would take some kind of enormous comp package to entice me to move. But we'll still do the whole process, and I'll often end up turning down a pretty solid offer.
For many/most companies, turning down an offer 'locks' you out for a year or so; no big deal.
I really enjoy interviewing at the top tier companies, because, in the end, I always learn a great deal.
Like most things, interviewing is something you can get good at with practice. What's nice is that you have the opportunity to get several hours of face to face time with really smart people at no out of pocket cost, except for a day of PTO from your current job if you live local.
On the flip side, as an interviewer, this all incredibly true.
In particular, I frequently end up asking algorithmic questions during interviews. For all the hate that they seem to get, I find them to actually be quite predictive; in my experience, the people who are extended offers despite just barely getting by in that portion of the interview are also the ones that struggle when those types of issues come up during actual development- and yes, despite claims to the contrary, basic fundamental algorithmic knowledge really does turn out to be useful in a surprising number of circumstances.
However, I will say that the utility is entirely based on how the interviewer handles things. I've passed many candidates who have failed to complete the problem at hand because throughout their attempt they demonstrated an ability to communicate, an ability to reason about a problem, and an ability to respond to feedback during the course of trying to arrive at a solution. In particular, one of my favorite questions has a tendency to make candidates try an approach that ultimately ends up being a dead-end as their first attempt. That's fine! It's completely natural! The really interesting bit is how they they respond when I produce counterexamples that start showing the limitations of that approach (and, ultimately, its infeasibility.) Do they keep digging the whole? Do they rethink their approach? Do they say "Yep, that makes sense, but let's see if we can get this done for the easy case and then we can approach the more general problem?" Those sorts of questions are the ones that ultimately end up being the most valuable.
>I get a feeling that process as this somehow does not select for top performers that are already working on exciting stuff.
There are senior engineers who essentially work as tech leads making $500K+ at these companies. It's a tradeoff to prepare but if you can essentially double/triple your salary to do comparable work while also getting whatever benefit from brand awareness in your social circles....
All whiteboard problems should be fairly novel and 'not possible to practice' or else you are testing their preparation, not their ability.
(Admittedly, preparation is a measure of something, and 'conquering all algorithms' is a measure of something.)
But neither are the measure you're looking for.
And 'General IQ' is not only it either.
The ability to decipher problems, understand requirements, grasp tradeoffs, translate that into reasonably clean code, keep possibly complex systems in your head, work with others and maintain a positive disposition.
Finally, the elephant in the room is 'perceived confidence'. It took me 30 years at least to be able to understand how well a problem was communicated, and how good the solution actually is.
Someone who is confident, who 'looks the part', who can communicate the issue clearly ... may still have a mediocre problem.
The weird, lacking in self-awareness, a shy-but-blunt nerd who may be totally unsure of themselves, sweaty palms ... may possibly have just as great as a solution.
We are hard-wired to see 'patterns' and our intuition misguides is significantly on this issue.
It's a lot of hard work to try to ignore 'the bad parts' of one's own intuition while keeping the 'good parts'.
One of the solutions to this literally is data. Instead of 'feeling' how they did, a checklist of things might help us structure in our minds how truly well something was accomplished.
And of course, we can't ignore the fact that communicating matters, it just matters differently in different contexts.
The spread is insane. I have interviewed at one FAANG three times within the same year (this one does not have cooldowns). On-site DS&A question difficulty capped at two-sum with no twist for the most recent one (extremely easy if you have seen it before, still doable for most people if they haven't), binary tree LCA (impossible within 30 minutes if you haven't studied binary trees, moderate if you have but have never attempted/seen LCA, easy if you have) for the first one, and a keypad DP problem (hard for anyone who hasn't practiced DP imo) for the middle one.
There are people who are extremely good at DS&A interviews and can reliably pass almost any loop at any FAANG company that sticks to conventions. But I think most people don't fall into that group, and it generally comes down to luck and not getting a single question that stumps you.
I think most people should dis-regard what FAANG do. The hiring bar there is so astronomically high that they're only hiring people at the very top of their field. I wouldn't try to take any lessons from FAANG and apply them to the rest of the industry.
> "The hiring bar there is so astronomically high that they're only hiring people at the very top of their field"
The average engineer at FAANG is less than stellar, let alone at the top of their respective fields. People who are actually at the top of their fields can often skip leetcode interviews and only get domain specific questions related to their field of expertise.
My hiring bar (for coding) has gotten easier the more I interview (as the interviewer). I don't ask any kind of super tricky algo questions, because the signal you get from those tends to be closer to "is the candidate familiar with this specific area of algorithms" than anything else. I don't ask any questions that take a really good candidate more than 20-30 minutes to solve, because then I can't scale the question down. You can always scale a question up.
I used to ask questions that were fairly close to what you find on leetcode now, but the signal isn't great anymore. It used to be good at identifying candidates who can quickly figure out the right tools to solve a given problem, but now it ends up identifying candidates who spent a lot of time on leetcode.
Now I mostly ask questions that involve
* transforming some data using a less than stellar API (using a REALLY simple transformation)
* holding a bit of state to accomplish the above transformation
* throwing a few edge case wrenches at the candidate
And the last part is technically baked into the question - a candidate who can fully grok the state could determine all of the edge cases on their own. But even if they don't I'll explain them and see how the candidate handles. 'cus in the real world we have unit tests, and I don't expect TC to really figure out all the edge cases in 30 minutes. A couple of them, sure. And they better be able to handle them once pointed out.
Candidate forgets that a java collection can have null because you can't have a List of primitives? That literally doesn't go into my feedback at all (and depending on how recently I've written java, I might have forgotten myself). Candidate writes a function that doesn't compile because there's no return statement? I'll point it out, maybe make a note, but don't really hold it against them because we write code in IDEs. Candidate spends 10 minutes trying to figure out how to force a single variable to do the job of three different variables, despite increasingly desperate hints to just store more local data? Yea that might go poorly in feedback.
But yes, I expect a candidate to be able to write 10 lines of code to answer a data transformation in 30-45 minutes. And yes, when either they figure out or I point out a couple of edge cases, I expect that 10 lines to not morph into a congealed mass of horror that cause their original solution to break.
I don't get it why people try very hard to get a job at FAANGs. Could it be because they would feel like they would become part of an elite, could it be because that once they have a FAANG company in their resume, they won't have to pass lengthy and stressful interviewing processes anymore and won't have to job hunt.
But there are many other software engineering jobs with at least as interesting problems to solve, at least as good payment, at least as good job security while being less stressful.
For me, hunting specifically a job at FAANG doesn't pay off.
I'd accept any job that meets my criteria of what I have to do, payment and stress level.
I see this said sometimes, and frankly I doubt it. A mediocre performer at Google or Facebook with 3 years of experience is pulling in 250K+. At Amazon and Microsoft, that's a bit lower but still over 200K. And there's upside for a higher performer.
The only places that match that kind of progression are bay area startups/public unicorns and quant finance and hedge funds. And for a competent person, that growth doesn't stop for another few years.
I don't have a study to back it up, just my empirical observations over the past 12 years, but I'm kind of convinced that hiring engineers almost randomly (let's say they can speak clearly and write a fizzbuzz) would have almost the same outcome as designing and implementing these complicated and convoluted hiring processes.
I have yet to work with the mythical "really really bad engineer that completely screw up your project and does it in such a stealthy way that you don't even fire them before it's too late".
I've definitely worked with engineers that are 10x slower or have extremely poor engineering practices: copy-pasting chunks of code, 8+ nested ifs, all code in one giant function, use of global variables throughout, clueless how memory management works/tons of cyclic retains, etc.
I've seen plenty of purported "senior" engineers with 7+ yoe that code worse than new grads.
Now that I'm in FAANG with a high hiring bar, these type of engineers are completely absent. I'm sure that's not a coincidence.
I agree, this was the biggest striking difference I saw between the engineering workforces at FAANG companies vs "everywhere else". You'll encounter a similar percentage of geniuses and top performers at both types of companies. You'll see plenty of regular 1X to 2X engineers, too. But somehow the FAANGs have, for the most part, figured out how to filter out the programmers who literally cannot program, whereas many other companies have not. You'll never see The Brilliant Paula Bean [1] at FAANG, but you will encounter them once in a while pretty much everywhere else.
I think there are actually a lot of Paula Beans in FANGs, they just perform at an entirely different level. In short, in order to be called out an incompetent liar, someone needs to make an assessment, but if the domain is too complex, if the knowledge is spread across 100 people, nobody will ever be able to assess or even notice the incompetent do-nothing types. Senior management don't understand the technicalities, middle managers see only their own area, very technical architects are very technical only in their domain and so on.
that seems ... impossible. almost every single project I have worked on always ended up not really what we had hoped for.
maybe you've generally worked at larger places and I've generally worked at smaller?
3 reasons I can think of why projects fall short -
hubris: you were never really going to be able to do that in the time and resource limits anyways
bad actor: maybe we should really fire Joey, but hiring is hard, and stuff is kinda getting done..if we can just keep it together another quarter
general structural dysfunction: we have a bad culture. no one can really depend on any one else, and its kind of not clear what we're doing anyways.
(1) is a given, but usually isn't the whole story. (3) almost mandates the appearance of (2). but (2) kind of depends on having at least some kind of twisted competence, otherwise they wouldn't be able to do that much damage. so are you in a (3) dominant situation...or do you live in the place beyond the mists where we get what we need to done and have a great time doing it?
I think you may have both misunderstood my comment and made my point.
1) if that's the case, how could spending time and resources in complicated interviewing processes help with that?
2) if you don't f*ck with candidates and have them jump through stupid rounds of interview, hiring may not be that hard.
3) Bad culture comes from the top, not from the code monkey.
Sure projects fail, sure they end up being not very satisfactory, but it's not because your complicated interviewing process didn't prevent you from hiring bad people.
Recently I had two different online testes where a good chunk of the questions were about Javascript generators - a feature that is very hard to see in the wild.
Thankfully I'm already employed, but this was not the case I would lose a good amount of time studying this subject in depth (only to not use it later)
After 9 years at the same company, I left my job at the beginning of January 2020 to dedicate myself to leetcoding and interview practicing in the hope of getting hired at a FAANG, more specifically Google.
I really started dedicating all my time to interviewing January 1st.
It is now March 31st and I am now abandoning the idea of getting hired at a FAANG, or any larger-sized startup and will target early startups with lower entry bar.
Yesterday I had my “virtual on-site” interview with Google and it went poorly.
The 1st interview was behavioral and I think it went fine, but I’m not sure the interviewer was thrilled.
The 2nd interview was horrible. First, the interviewer had a bad internet connection which made it hard to understand her (I asked her to turn off her video to help, which she did), 2nd she jumped immediately to the problem without introducing herself or anything which made it feel like she was in a rush, 3rd she simply started reciting her problem statement, which was hard to make sense of because of her bad internet connection. I asked her if we could write it down in the shared google doc, so she proceeded to copy/paste a blob of text that seemed to be taken from the _middle of a problem statement_. It had no context and no actual instruction like “write a function that will calculate x and y”. My NDA unfortunately prevents me from sharing the actual thing. Because of this, I did not know what I was supposed to do. I asked her multiple times “so, should I write a function to do this and this?” and she kept reciting the ambiguous problem statement over and over in an impatient and dismissive manner. I felt completely out of place. Then when I finally started making a little bit of progress on guessing what she actually wanted me to do, I started hearing background noise of someone chopping vegetables, and moving things around: extremely distracting. I would ask her specific questions and from her lag in answering and her short 2 words answers I just know she wasn’t paying attention. It took all the strength in me to not tell her how disrespectful it felt to be interviewing with someone that clearly did not want to be here and wasn’t paying attention. At the end of the interview I thanked her a lot, smiled big and swallowed my pride.
I left for our 1 hour break and took a walk to reset my emotions and tell myself that the interview could still go well and that I still had my chances.
The 3rd interview went well. The interviewer had a good connection, a good mic, was understandable, introduced himself and even said “before we start, I want to remind you that if one of your interviews went bad, don’t sweat it, it’s all fine. We’re here to have a conversation. I’m not looking for a right or wrong answer, I just want to see your thought process”. It took him literally 2 minutes to set me up for success. He then proceeded to give me a problem statement, with some context around it, and we started proceeding to _have a real conversation_. I wrote code that, according to my interviewer, compiled correctly and was close to the actual code it was based off of. I left this interview feeling good
4th interview went bad. Interviewer was 10 minutes late and had a bad connection, but aside from that introduced himself correctly, gave me a clear problem statement and although did not talked much at all during the interview, he did give me a few hints here and there. The reason I failed is that I couldn’t solve a simple algorithm and started panicking internally. All on me. I left the interview hoping the next one would go better.
5th (and last) interview went meh. It was a system design interview. I was hoping to be having a conversation with the interviewer but he just was speaking much at all.
I hung up and cried a little. It’s really hard emotionally to accept this.
Before my Google interviewed I got rejected by AirBnB, Twitter told me they don’t think a senior role is adequate and will see if they have “mid-level” roles (which is totally fine, but I’m left wondering if that’s not just a way of rejecting my candidacy), and I cancelled Facebook because what Airbnb taught me is that I’m just not ready. That’s not a lot of interviews you’ll tell me, but I spent _months_ preparing.
Because I know my algorithm and problem solving skills are lesser, I spent hours studying on leetcode, reading an operating systems book, reviewed “cracking the coding interview”, reviewed “introduction to algorithms”, re-read some chapters of “TCP/IP illustrated”, spent hours watching system design videos, hours watching algorithm videos. I spent $5000 on an interviewing/algorithm bootcamp.
I know that I am not a bad engineer. I started programming at 10 years old (I’m 33), taught myself VB, C and C++ (though I haven’t coded in these for many years now). Computers have been my life’s passion. I designed my former’s company infrastructure and made it scalable and resilient. I was a major influencer in my team and my coworkers trusted me. I know I’m a good system administrator; I might be less good a developer but I know how to code well; I know how to influence my coworker into following best practices, reading/writing documentation, being security conscious; I stay informed on the latest trends, I try new technologies, learn new languages, not even out of necessity but because that’s what I love.
But none of this seems to be enough.
And maybe it really isn’t for a company like Google. And maybe I wouldn’t be successful at Google if they hired me.
What I know is that these past 3 months have left me with little confidence about my skills and just wondering if I’m cut out for this. I’m trying hard to not feel defeated, but damn, that hiring bar in FAANG interviews can really make you feel like crap.
You are a fine engineer and there are many people that are working at FANG that are worse than you. Just keep grinding and don't give up. You have built a solid foundation the past few months. All of these companies let you interview again. Just keep practicing, albeit at a slower pace, and try again next year. You will eventually break through. I succumbed to depression after getting rejected after a lot of work my last cycle. I wish I wouldn't have and just kept grinding. There is a lot of luck involved in this game between getting questions you know or are good at or getting a good interviewer.
Definitely hang in there and keep practicing. I've worked at two FAANG companies, and for both of them I was rejected many times before finally passing. There seems to be quite a bit of random chance at play. They all allow re-applying, and some recruiters will tell you the minimum interval between applications, so just set your calendar and re-apply again and again.
There is a good chance that you're more qualified than all your interviewers except the 3rd one, who looks like a tenured "staff" engineer or manager. This is the reason you don't leave your job before you've landed a better one.
> This is the reason you don't leave your job before you've landed a better one.
I don't agree with this. I actually don't regret any second having left my job before having a new one and would do it again in a heartbeat.
After so many years at the same company I needed a radical change to change careers and had been meaning to find another job for a while but just never had the energy to do so and was just becoming complacent.
I can't really comment on your interview experiences except to say: that sucks. I know firsthand (unemployed for a long time and had a really long personal struggle similar to yours) how shitty it can be. The unfortunate reality is that, no matter how much these companies say otherwise, a huge part of hiring comes down to luck. Luck of who you interview with, luck of what mood they are in before beginning the interview, luck of having technical problems, luck of a lot of things. To a certain point, you are in control of how you respond to unlucky, non-ideal situations, but you may still not come out ahead versus someone who didn't get so unlucky. Luck sucks. But one day, you might get lucky too, so keep your head up.
The main thing I want to say to you as this: I work for a FAANG, I know many people that work for FAANGs, and I know many people that have left FAANGs. It is not all it is cracked up to be. I would even venture to say that, in most cases, it isn't worth the hassle. You should not in any way feel like you are setting your sights "lower" by targeting non-FAANG companies, because you absolutely are not.
The FAANG hiring process measures whether or not you pass the FAANG hiring process. That sounds tautological, I know, but it's a not-very-well-kept-secret within my FAANG that the hiring process does not at all measure proficiency for the job, but it's something we keep doing because at this point the process itself is ingrained in the culture. It is not a measurement of how smart you are, how good at programming you are, or even how likable you are. The "hiring bar" is entirely built around whether or not you will be a good worker for that specific team's needs, which are not necessarily the characteristics of "smart, good at programming, likable". Sometimes it could be a specific niche skillset, or how well you will adapt to a weird or chaotic internal culture, or how well you will kiss ass. Sometimes people dumber than you will be hired because it just so happens that they applied at the right time when the company was in dire need of bodies.
I too know how much it sucks when your personal confidence starts to take a hit. It makes it so hard to apply to jobs when you already feel like you will fail before you even hit submit on the applications. But keep in mind all of the things that make you smart and all of the things that got you those FAANG interviews in the first place. If you failed out of FAANG hiring, it just means you aren't good at FAANG hiring. That's it. Period. It does not mean you are not good at your job, or that you are not smart, or that you can't pass hiring at another company. It doesn't even mean that you wouldn't succeed working at FAANG! It only means you didn't succeed at FAANG hiring.
If you really want a FAANG job, then keep at it. You are smart enough to get it, you just have to use those smarts to mold yourself to the very specific way that the FAANG hiring process looks for. If molding yourself in that way isn't something you want to do, that isn't a bad thing, and there are definitely other, just-as-good-if-not-better, companies that will value you.
Actual professional engineers don't have strange, gamified interviews to guess someone's skill level.
Is all of this modelling the problem of the hiring bar or training to beat it really solving the right problem?
Do any of the solutions to this constructed problem actually work reliably or are they just elevator close buttons, frobs that may not really function but provide a sense of control?
I work in tech in a non-coding discipline. I was reading this article thinking, "Are there really that many people out there that you need to separate the good hires from the average hires?" Every time I've interviewed it is hard enough finding a single competent hire at all, never mind trying to grade hires to separate multiple seemingly good candidates.
The best kind of practice is the kind you get paid for. Freelance work (if your current contract permits it) always has opportunities to stretch your legs. Also, I think most companies would prefer breadth of skills over someone who knows the answer to a gee whiz algorithm. Put a different way, companies prefer someone who is valuable over someone who is "smart".
Holy cow, is Recursive Cactus me? Lol I can totally relate. And I believe a lot of people on cscareerquestions subreddit and people at Leetcode forum can relate. 100%? Accurate.
Also, just to give a context of the hiring bar these days. The FAANG companies coding question is no longer on Easy even on phone interview. Expect at minimum 2 Medium difficulty questions in a phone interview that need to be able to be solved in optimal space time complexity in under 45 mins (or more precisely, under 20 mins each because if the first question is not solvable under 20 mins then they will skip that and you already failed).
So for those FAANG engineers that were able to get in early, whether by acquihire, by diversity hire, by luck, by normal hire. Stay there as long as you can especially in today’s times. Because once you quit you’ll experience a rude awakening for getting right back in, unless those companies waive you in because you’ve been in before.
And yea, I’m talking for both fresh graduates as well. There are instances where a fresh graduate get 4 out of 5 hard leetcode questions in an onsite. Yea, its that crazy.
I'm strictly speaking from personal experience and by reading subreddit cscareerquestions and Leetcode forum on people's experiences.
So at this point, a lot of people (including me) already solved hundreds of Leetcode questions, and still got rejected. So this is now a luck of the draw game, apply to those companies every year (because once you get rejected then you are not allowed to apply within a year), one day you will get your lucky strike.
One way to maximize your luck if you really want to get in, assuming that you are not lucky, not part of diversity hire, not part of acquihire:
- internship
- contract work
Damn I have to EDIT so many times lol. But due to this Leetcode style training that a lot of us are going through, we literally have less time to learn anything else, for example, learning new libraries, new frameworks. I personally think learning new frameworks or libraries are kinda dumb because it is easy to pick up on the job anyway, but nevertheless when you want to look for a job you need these on your resume. Say you only know REST but now companies want gRPC and Protobuf then you gotta learn those on the side. Assuming that you are a normal working person with hobbies, families, responsibilities, activities on the side you need to pick your choices carefully.
So this has an interesting result. The more you prepare for FAANG and doing Leetcode style questions, the less time you prepare for mid-tier companies and the lesser the chance you will get a better offer from them. So you have to go ALL IN one way, can't go half ass one way or the other.
> Expect at minimum 2 Medium difficulty questions in a phone interview that need to be able to be solved in optimal space time complexity in under 45 mins
I see this being repeated on Leetcode and Blind, but it is not my experience at all.
In 2019, I got Senior level (L5/E5) offers from everywhere I applied, including Facebook and Google. I never solved more than a single medium problem in 45m-1h. I was asked a hard problem maybe twice, and not at FB & G.
I also interviewed 100+ candidates at Microsoft and Google. I have seen hundreds of interview questions and feedback reports and I simply can't corroborate that statement.
Oh nice, I've been waiting for someone like you to reply. Thanks for replying, I need a perspective from you as well.
Why do you think it happens this way? I have some other anecdatas that I gathered from the forums but I am not gonna spew it here because it could be offensive/racist or whatever.
But what I think the more reasonable answer is, because interviewers are humans, and a lot of it are based on luck. Maybe the interviewer has a bad day? Maybe the interviewer has a favorite question that is super tricky and he/she really want to test this to the candidates.
I also think that due to your seniority, it seems that the FAANG companies already know that you know your stuffs. Since L5/E5 definitely not an easy task. Therefore you don't get a really hard question, because they don't need to determine whether you are a risk or not. They already know that you will perform great in the company.
Btw if you are doing your interview like this, I commend you. Thank you for not making life hard on people. I myself has gone through hundreds of Leetcode but still failed, due to the harsh questions that I've seen these days. Yet due to Leetcode I postpone learning other things that can serve me better in my career. It is stupid, but it is what it is. I know a lot of people can relate with me.
Anyway, please continue to do a great work of interviewing people! Maybe one day I will get my chance.
I've never once adjusted my question based on where the candidate was coming from. The idea that people would ease up if they saw FAANG on a resume or a 10+ year career is just not a thing I've ever seen.
There are a few truths in modern tech interviewing:
1. There is a large amount of randomness. Between the question that an interviewer chooses to ask and whether the interviewer is having a really bad day, you might just get screwed.
2. A lot of people are genuinely working really hard to do a good job interviewing. I've seen careful and detailed interview feedback and talked with a huge number of people who really care about interviewing well.
3. Interviewing has less oversight than ordinary work, so some people are bad at it and don't get feedback. Some people get back luck and are assigned one of these interviewers.
4. Interviewees suck at evaluating their experience. This means that when somebody says "I did everything well except I missed some impossible optimal algorithm and they rejected me so that's bullshit" you should become skeptical.
5. Angry people get signal boosted. Online discourse around interviewing is dominated by people with bad experiences.
You answered some of my questions in some other HN posts. I remember you.
Thanks for the replies.
Btw I am curious of this one thing. Say a FAANG has X years of experience in a FAANG company and then quit. When he/she reapplies to the company, is there any sort of stuff that makes he/she preferred over other candidates? Why I'm asking this question is this. I imagine that a FAANG engineer who has more than X years of experience, say x = 10, he/she must have better things to do rather than just memorizing 1000 Leetcode problems. Therefore if being judged strictly by using Leetcode style questions, I imagine he/she would not do well.
If you leave and then re-apply, hiring managers will look at your past performance reviews when considering you as a candidate. If your past performance reviews were excellent, it'll be a lot easier to come back. If you left another FAANG company... it doesn't matter beyond maybe making it easier to get a phone screen.
I expect that everybody has better things to do than memorizing Leetcode problems. That's because I don't expect people to memorize problems at all. I strongly believe that candidates should be able to succeed at the question I ask despite never having seen it before in their lives.
What is considered a medium problem? Is this in terms of equivalence of problem levels found on leetcode and such? I have yet to do the grind. My current job is great and pays FAANG level- I hope to not have to engage in this crap.
Medium is defined as Leetcode's problem tagged in Medium category. It is quite blurry to be honest because some questions should be on Easy category and some Easy questions should be Medium and some Medium should be Hard and some Hard should be Medium.
That's good, keep that! Don't get involved in this crap. I have to do it out of necessity.
On leetcode they are literally marked "Medium". Mostly questions that involve some sort of BFS or DFS on graphs, figuring out the next available time slot in a meeting calendar, figuring out the best time to buy and sell a stock given the daily price, stuff like that.
Aren't sites like leetcode partially to blame for this?
Years ago asking a candidate to push all zeros to the end of an array , in place, probably eliminated 75% of the pool. Now anyone who adequately prepares can probably solve that optimally in 10 minutes. I remember when asking for optimal solution to isPalindrome was a "bar raiser".
I was recently told that I am expected to solve 2 medium-hard questions with clean code and good variable names and test cases in 30 minutes for phone screen. The recruiter emphasized that speed was a factor. The bar will keep increasing as people optimize for the test.
I think sites like Leetcode is not to blame, because they merely filling the gap. Btw Leetcode is really good for this sort of things because they actually put questions tagged for the companies based on people who have interviewed. The community there anonymously (obviously) always post and tag questions.
Back to your question. I think personally one (at least me) can blame:
1. The insane salary that these companies give
2. The not so amazing salary that the mid size and startups give, and these days, startups are imploding left and right, low hanging fruits are gone, IPOs are longer, VCs are more greedy, etc.
The money is to blame here, and this is a direct result of tech giants growth being unchecked. If somehow we can level the playing field more, then this DS&A problem will go away.
But if we don't solve the money problem, then no matter how many experiences and senior architect titles you have in your career, if the money doesn't beat FAANG money, then a lot of people will constantly chase FAANG money as the end goal. As a result, a lot of companies that knows this know that it is hard to contest FAANG in terms of compensation, therefore these mid-tier companies and startups are okay living with the reality that one day their employees will jump ship anyway, so we don't need to raise their salary as much and just get a fresh body to replace him/her when that happens.
Maybe expectations are different for senior engineers, but from my experience in applying/getting into FAANG last year, I was only asked easy/medium algorithm questions.
I felt the algorithm questions were more of a technical bar/weeder, far more emphasis was placed on the behavioral, practical, and architecture questions.
I did around a month of casual prep for the algorithm questions, about an hour after work.
I was agreeing with you until you used the phrase "diversity hire" in your comment. I think that you could have made the same point without inferring that the hiring bar has been lowered for employees in underrepresented groups. That's a pretty terrible thing to say to anyone who is in one of those groups.
I won't dispute whether you think it's a terrible thing to say, but preferential treatment towards demographics categorized as "diverse" is something I've both witnessed and taken part in during my time so far in tech. At least in the San Francisco Bay Area, many tech companies are setting targets of >30% women in engineering roles despite the fact that they make up 20-25% of the tech workforce. Achieving these numbers necessitates discrimination.
Note that you're putting words in the other poster's mouth when you write that "the hiring bar has been lowered". Not all forms of discrimination involve lowering the hiring bar. From my experience, the bulk of discrimination occurs before hiring event starts - recruiters extend phone interviews to diverse candidates at higher rates. The hiring bar is the same for diverse and non-diverse, it's just that diverse candidates are more likely to get a chance to attempt to pass that hiring bar.
>From my experience, the bulk of discrimination occurs before hiring event starts - recruiters extend phone interviews to diverse candidates at higher rates.
How is this different from any other targeted recruiting?
FAANG recruits students from CMU while not even visiting my alma mater. Recruiters extend phone interviews to referrals at 100% rate no matter how bad they suck, etc. Diversity recruiting != diversity hiring, and the numbers bare that out. Unless you argue that recruiters should have zero targeted pipelines I'm not sure how it's unique for diversity initiatives
You're right, it isn't. But are people offended when people say that FAANG gives more opportunity to CMU grads than community college grads? Not in my experience. Speaking as a grad from one of the universities mentioned, I can say with certainty that and education from those institutions opens up a lot of doors and that pointing that fact out is fair.
The major difference is that both CMU and your alma is seen to welcome both women and men (and people of different colors, cultural backgrounds, religion, social economical status and so on).
Targeted recruiting from single sex schools or religious universities would be different, but there aren't many such universities in the first place.
However, targeted recruiting for high prestige university tend to create discrimination for social economical status, which discriminate against people who were not lucky enough to be born by rich parents.
"I've seen it myself" - So you've sat on FAANG hiring panels that made decisions specifically based on candidates' underrepresented demographics? Or you're just inferring based on people you met while employed at a FAANG? Or...?
I've sat at company hiring panels, and have taken part in discriminatory policies first hand. At career fairs, Dropbox recruiters had us mark candidate resumes with a star for diverse candidates, two starts for "double diverse" candidates (female + URM), and "ND" for Asian male candidates. It turns out "ND" stands for "negative diversity". Literally the first thing we did was bucket candidates by the desirability of their demographics. Recruiters also got higher bonuses for recruiting diverse candidates, along with bonuses for more experienced candidates. The diverse bonus was equal to the difference between hiring an entry level IC1 and an IC6 (senior staff engineer).
Usually discrimination doesn't take place in the hiring panels. Rather it's done by the people given incentives to discriminate, usually recruiters. Recruiters can infer candidates' race and gender with census data on names, and advance diverse candidates to phone screens more often than non-diverse candidates.
I can also detail the company's "opportunistic hiring" plans if you want to hear more.
I would like to hear more, but maybe HN doesn't want to. If you don't care about the risk of downvoting and this being on HN, please write so. But if not, it is ok.
This is the part of the document that described the motivation:
> The Problem Statement
> Based on 177 like tech companies in Silicon Valley (market research and EOO-1 Diversity Statistics data), the percentage of diverse engineering talent is sparse. In short, 4.7% are latino, 2.1% are African American, and 19.2% are female. These candidates are being targeted with all of our top competitors with white gloves tactics, strategic outreach, and engagement strategies, while Dropbox has yet to systematically establish any of these practices to compete for this top talent and showcase our uniquely inclusive, dynamic, and thoughtful culture.
> Opportunity to market DBX [Dropbox] more broadly:
> Moreover, diverse engineers are the most sought after group of individuals on the market today. While the average response rate to engage is high (37%) the rate at which they are interested in moving forwards is quite low (11%). We interpret this in two ways:
> First, due to the small pool and scarcity of diverse talent, companies are motivated to keep their diverse talent happy, well-compensated, and engaged; prospects are rarely on the market, and when they are, it is a highly calculated and careful search based on existing relationships.
> Second, traditional sourcing engagement methods (email, LinkedIn) do not adequately showcase what makes Dropbox special, and because these candidates are so highly sought-after, it would serve us to highlight our culture early on, and to take a more long term approach to courting them.
And here's the proposed solution
> Opportunistic Hiring
> As the business needs shift and open roles become more narrow, it will become difficult to find a home for diverse candidates that we're able to engage and who pass our bar. Wee feel like it would be a disservice to use in the long-term if we miss out on hiring critical talent for Dropbox because of current headcount constraints. To this end, we propose that Eng VP's withhold 20 heads to hire opportunistically.
> When a diverse/URM candidate is interested in interviewing, regardless of headcount, we will put them through the process. If they pass the TPS [technical phone screen] we will bring them onsite and evaluate based on their skillset.
* If the candidate goes to HC [hiring committee], we will proactively find a sponsor/team home for the candidate, and that team would receive a preciously withheld headcount for that hire.
This was announced April of 2019. I've transcribed parts of the document that announced this policy above. I can't speak as to whether or not this is still in place as I have since left Dropbox.
Interestingly, Dropbox already 23% women in tech roles[1] at the time that this was announced - larger than the figure of 19% shown above.
I used to think naively that checking these boxes does nothing:
- "I prefer not to disclose my sexual preference"
- "I prefer not to disclose my race/ethnicity"
- "I prefer not to disclose whether I'm a veteran or not"
Anyway, it is a sad read for people like me who don't get preferential treatment. It seems like I'm being salty, but it is just the reality. People like me studied hours and hours doing Leetcode and sacrificing other things, even sacrificing things that should have helped our career better, such as learning relevant skills like techniques, libraries, etc. It is what it is. Naively think about meritocracies.
If I can just write a huge *sigh here, it is what I'm currently doing right now.
I don't care about downvotes. I just need to rant.
Anyway thank you for the replies! I really appreciate it.
Well that's generalizing isn't it? Not every Asian male sounding name person actually have a good track record in their family, free of abuse, loving both dad and mom, good education, know how to do math to the point of memorizing the entire Pi numbers.
There are people who are outside of the normal as well. Why not give them privilege by hearing their stories as well?
Or better, why not discard the preferential treatment and do it based on meritocracy? I know this can't be done in today's world, just hoping.
Not every white person comes from a rich, educated family either. I'm very familiar with this being a white, uneducated, disabled female from the Midwest US with an uneducated, abusive, lower-middle class family.
Meritocracy does literally nothing to aid less privileged people to get ahead. It primarily helps those who started with privilege in the first place which is mostly limited to select groups.
I'm not sure why pointing out the fact that this forces members of the same race or gender to compete against each other for a limited number of spots is justification. The fact that we're allocating some hiring slots for certain races and genders, while others have to compete for a more limited number of slots is the problem.
Furthermore, this policy announced when the company's tech workforce was already higher than the industry's representation in the metro area. So they were using discrimination to increase an already existing overrepresentation.
Were you required to remove stars already on the resume? If not, then I know just what to do.
Where on my resume should I put the two stars? Are those the traditional hand-written style, with the lines crossing to make a pentagon in the middle? What sort of pen or pencil should I use?
We wrote the stars ourselves - normal 5 point star style. If you wrote the stars yourself recruiters would probably cross them out and write in the stars that correctly reflect your diversity status.
So basically I know a few people who can't even solve an Easy Leetcode questions. They got in as SWE L3/L4, E3/E4 and I also know one L5.
Can you help me in explaining why? I don't have the intention of looking down on people. I'm just gathering data. If I can find a reasonable explanation then I want to take a look at it, and learn from it, and see where did I do wrong, so I can improve and pass the interviews next time.
I knew a lot of people at FAANG that were L4/L5 that couldn't solve Leetcode easies. Leetcode isn't part of the job, just the interviews.
Getting an offer is not just a matter of solving a programming problem. It's about how you communicate. And, of course, if you're a brilliant jerk ability doesn't matter: you're not getting hired.
If you're not getting past the interviews despite being a strong programmer, you may want to really think deeply about how you're communicating with your interviewer. Remember, the vast majority of people who are getting offers aren't women or minorities so that's probably not what's blocking you.
Your experience matches my anecdote. Hence you can imagine my total confusion once I got the interview myself (Google, 2 times, phone to onsite, Amazon one time to onsite, Facebook, one phone). In my latest FB phone for example. I was asked a Medium question that I've never seen before, and nevertheless I solved it. How do I know? Because apparently that was taken straight from Leetcode, and the interviewer didn't even bother to change the question. I copy pasted my solution to Leetcode, run it, pass 100% test cases.
I got rejected....
I asked for feedback from the recruiter. Apparently I needed to do 2 Medium questions in the allocated time. I solve the first Medium question in about 30 mins, and there was only 10 mins left for the 2nd one so the interviewer didn't bother to ask me the 2nd one.
The scenario that I just told you above is not unique. Venture enough to cscareerquestions and Leetcode forum you'll be surprised to see many many worse experience than this.
Keep trying. I hate to say it, but luck is a factor. The process is by no means objective. Sometimes it's just a matter of getting the right interviewer.
Thank you. I am currently pivoting to learning other things that are more practical in the job. I did enough Leetcode that I started to like it (Stockholm's syndrome).
You just said that a diversity hire is anyone who is female or an under-represented minority. I think this comment is what you meant to say. Explicitly, if a candidate is a female or an under-represented minority, AND they do not stack up to standards.
But it undeniably has, and I've had multiple older women in management express to me that they felt their position was less respected because of the company's overt push to hire women.
Sure, in theory we're correcting the injustices brought about by inequality, but what we're really doing is presuming that minorities need extra help and white men do not, without considering that all people have struggles and, frankly, it's racist/sexist to judge people by skin color and/or gender.
You can easily invent a dozen ways to claim someone's life is underprivileged, but we only have a handful that are allowed in hiring considerations, and they all happen to be "not white or male."
It's terrifying to see how casually acceptable this has become.
The presumption here is that white and Asian men get extra help by default, and the rest are penalised. This has enough evidence in favour that I would call it a theory and not a hypothesis.
Worked at FAANG. There are diversity programs because most engineers are white and Asian men with professional networks composed almost entirely of white and Asian men. Referrals are a big source of talent, so you can imagine what that does to our hiring pipeline. But there are no diversity hires. Everyone who's hired has to pass the bar.
Candidates from well represented backgrounds are also given two attempts. It depends. In general, most candidates aren't given two attempts irrespective of background.
>So for those FAANG engineers that were able to get in early, whether by acquihire, by diversity hire, by luck, by normal hire
Can we please stop assuming that being a minority or woman is some kind of hiring free pass? It's often quite the opposite.
But more to your point, I've been cynically wondering if the untenably high bar set for technical interviews serves as an industry-wide means of lowering turnover.
Also very confused about what constitutes a pass or failure, with the opaquely-defined expectations. I'd love to be able to prepare for my technicals, but usually end up wildly misleading information from recruiters about what the technical entails. (Why are you testing me on Java!? I never claimed to have any experience with Java. I was told this would be a behavioral interview!)
At every company I have worked at, policies were in place to extend greater opportunity to URM and women candidates. Most large companies are setting diversity targets well in excess of the share of women and URM workers in software development other engineering roles at the company. This necessitates discrimination to achieve this over representation. For example, Dropbox announced a goal of 33% women in engineering roles when I was there in 2019. My currently employer has a goal of 30% women in engineering.
This typically doesn't result in easier interviews. Rather it was implemented by giving recruiters incentives (larger bonuses, or penalties for failure to meet a certain %) to hire diverse candidates. At my current company, over 50% of engineering candidates phone screened last year were women (and were given phone screens at a rate twice as high as men). In other words, framing diversity hiring as "giving a free pass" isn't quite accurate. Rather the companies increase their diversity by adjusting the rate at which diverse and non-diverse candidates are let into the interview process.
If we could quantify the net effects of sexism and racism in hiring and attrition, we could compare whether the incentives mentioned offset the sexism and racism equivalently. But, since we don't have a means of doing so, it's a futile discussion on this site. Also worth pointing out that just hiring a diverse candidate is pretty meaningless if they get bullied or harassed to the point of being forced out in a short order.
But that's beside the point (or, beside the tangent to the point). The context of "diversity hire" above parallels being diverse and getting hired to an acquihire or getting lucky. That's very different than what you outlined above.
Whether one thinks that discrimination in hiring is justified to offset suspected discrimination in other areas is besides the point. The point is, there exists discrimination in hiring that results in women and URM candidates getting offers that would not have been obtained were it not for diversity status. The opportunities of people categorized as diverse in tech company interviewing is substantially different from those not categorized as diverse. Maybe I'm biased towards the SF bay area, but there's a palpable mismatch between how common and prevalent these practices are and the offense people take when they're acknowledged.
I'm not sure why you think what I'm saying is different. At my company, white and asian male new grads are only given a chance to interview if they're CS (or math, EE, or other tech majors) grads from top universities like Stanford, MIT, Carnegie Mellon, etc. Candidates from boot camps, less well known universities, or non-tech majors are only extended the chance to interview if they're diverse. Does that mean that a diverse candidate from a boot camp who gets hired is unskilled? No, probably not. Does it mean that a diverse candidate from a boot camp would not have been hired if they weren't diverse? Yes, because non-diverse candidates from boot camps don't get interviewed at all.
Maybe I'm biased toward the SF Bay Area, but the mismatch between the prevalence of these policies and the discomfort with acknowledgement of their existence is concerning.
No, it's not an SF Bay Area thing. I've moved to SF from the Midwest a year ago, and have been called racial slurs more times during my year here than in my entire adult life living in a medium-sized Midwestern town. Shall we assume that because you haven't had a similar experience or personally faced discrimination on the job that no one else has?
Exaggerating the status of "diversity hires" just ignores the harsh reality of rampant discrimination in the tech industry. And not just on the basis of sex and race, but age and disability too. There wouldn't need to be such a hard push for underrepresented candidates if it were a more welcoming, diverse workforce in the first place.
Who is getting the short or long end of the stick is not something I aim to answer, or even purport to be able to answer. This is a matter of perspective. I'm a Hispanic person that attended an elite university and have household names on my resume. I'd have a good chance of getting interviews regardless of my gender or ethnicity - and when you do take ethnicity into account it probably helps me even more. I'm largely indifferent towards this kind of discrimination in hiring. But is the perspective of a white or asian man pursuing a coding boot-camp to try and break into tech going to have the same opinion on policies that greatly reduce or eliminate his chances of getting an interview as compared to if he was a woman or URM? Many see getting called slurs as a small price to pay to get a chance to break into tech.
The only thing that bothers me is attempting to equate acknowledgement of these practices as offensive or taboo. The reality is that this is what many companies are doing. Thus, the only way one can avoid offense in that scenario is to deny reality.
Yes, they really do. I've explained the details my employers' hiring processes to white and asian men trying to get into tech, and the majority feel like it is an overall benefit to diverse candidates - other discrimination in tech notwithstanding. Really, how can you write this? Do your claim to know the opinions of every white and asian man in this country?
My point is, that the fact that diverse tech workers may face discrimination in other ways (e.g. slurs as you pointed out) doesn't necessarily "even out" discrimination in hiring that favors diverse candidates. Someone who can't land an interview may feel that the opportunity to get a job, even if it comes at the expense of other forms of hostility, is a net positive.
> What a horrifying thing to say. Normalizing racial and sexual harassment is a large part of the problem. Are you going to claim you don't understand how the tech industry is so homogenous while simultaneously claiming that racial slurs are just some inconsequential price of admission in tech?
The idea that discrimination in hiring is justified because of other forms of discrimination (such as slurs) is something you originally claimed:
> Exaggerating the status of "diversity hires" just ignores the harsh reality of rampant discrimination in the tech industry. And not just on the basis of sex and race, but age and disability too. There wouldn't need to be such a hard push for underrepresented candidates if it were a more welcoming, diverse workforce in the first place.
Your message here is that discrimination in hiring is necessary and justified because of other forms of discrimination. This seems like the "price of admission" mentality you refer to above. Whether or not this is "Horrifying" is up to you, but lets be clear: the idea that one form of discrimination justifies another form of discrimination is an idea that you originally brought up.
For what it's worth, I'm of the mind that two wrongs don't make a right. If people are being treated with contempt on the basis of race, then the appropriate response is to curb that behavior - not discriminate in favor of the targeted demographic in hiring. Claiming that one slurs are okay because candidates are beneficiaries of discrimination is wrong. So is claiming that discrimination is okay because these people are subject to slurs, or other forms of hostility.
> Also, the notion that racial slurs are "the price of admission" is something you seem to have brought up - not me
> Many see getting called slurs as a small price to pay to get a chance to break into tech.
I'm still having trouble believing anyone who isn't a frothing racist can pass off "many" getting called racial slurs on the job as just business as usual. Or, "a small price to pay."
Whereas what I was saying is that the policies which you cited incentivisng more diverse applicants to apply doesn't even begin to counter the ubiquitous prejudice in hiring and on the job. If it did, minorities and women would be over-represented in tech rather than under-represented.
The whole "minority free pass" idea is what grates on me. Plenty of hiring managers have unconscious biases against women, minorities, older candidates, people with disabilities, etc. So, it's throwing more diverse candidates into a situation where diverse candidates are going to be disproportionately rejected.
But the employers who actually incentivize diverse candidates are also frequently over-emphasized despite it being an uncommon practice. The boilerplate EEOC "we encourage diverse candidates to apply" statement is usually just that: an empty boilerplate put there for legal purposes, backed with zero action behind it. More often than not, it's nothing close to what you've described above
> I'm still having trouble believing anyone who isn't a frothing racist can pass off "many" getting called racial slurs on the job as just business as usual.
I don't think it's business as usual, and looking back on my comments I never wrote this. Again, the first one of us bring this up was you when you justified discrimination in hiring as a means to offset discrimination elsewhere. What I wrote was,
> But is the perspective of a white or asian man pursuing a coding boot-camp to try and break into tech going to have the same opinion on policies that greatly reduce or eliminate his chances of getting an interview as compared to if he was a woman or URM? Many see getting called slurs as a small price to pay to get a chance to break into tech.
that many white or Asian people struggling to get into tech see the employment opportunities conferred by diversity status as outweighing the other forms of discrimination that diverse workers may face - not that the latter is justified as "the price of admission".
> The whole "minority free pass" idea is what grates on me. Plenty of hiring managers have unconscious biases against women, minorities, older candidates, people with disabilities, etc. So, it's throwing more diverse candidates into a situation where diverse candidates are going to be disproportionately rejected. But the employers who actually incentivize diverse candidates are also frequently over-emphasized despite it being an uncommon practice. The boilerplate EEOC "we encourage diverse candidates to apply" statement is usually just that: an empty boilerplate put there for legal purposes, backed with zero action behind it. It's just usually nothing close to what you described above
First of all, it is a common practice at least as far as what I've experienced. Some companies, like Intel, went so far as withholding unless diversity quotas are met.
And second, if the hiring managers have biases then eliminate those biases. If a company suspects that biases are causing women, minorities, etc. to not get offers then excluding white and Asian men to pad the former's representation doesn't create an equal hiring process. It just creates a hiring process that discriminates against both women, URM and White and Asian candidates. Furthermore, while it's common to see people cite unconscious biases against women and URM candidates in tech hiring studies trying to actually measure this often don't find this suspected bias. In fact, they often find bias in favor of diverse candidates. Interviewing.io experimented with blind hiring and actually found a slight preference in favor of women [1]. Studies in university STEM faculty recruiting found a 2:1 bias in favor of women [2].
> Because that's a breath-takingly racist assertion. And I did not say that. I suggest re-reading your post so that you understand that you wrote those words.
Let's reread the sentence in context:
> But is the perspective of a white or asian man pursuing a coding boot-camp to try and break into tech going to have the same opinion on policies that greatly reduce or eliminate his chances of getting an interview as compared to if he was a woman or URM? Many see getting called slurs as a small price to pay to get a chance to break into tech.
Say you have two people in a coding boot camp. One is a woman, the other a white or asian man. They get the same scores and are just as capable. At my current and previous employers, only the former would get a chance to interview.
If the latter looked at this situation, and concluded that they would have better career opportunities if they were a woman - even if it meant additional discrimination in other forms, like being subject to slurs - then they're "breath-takingly racist"?
I'm also confused as to why you're calling me racist for pointing out the fact that many white and asian men feel like the tech industry's treatment towards them on the basis of race and gender is a net negative. Again, these are the opinions of people other than myself. The fact that you're exclusively quoted this sentence without the preceding one suggests that you either forgot this fact, or are deliberately attempting to conceal it.
> I'm referring to tech hiring in the private sector.
Good thing I cited a source studying hiring the private sector as well.
And I've heard hiring managers say racist and sexist comments on prospective employees all throughout my career. And neglect to mentor or promote them. And freeze them out of the team. I suppose the strawman you've set up outweighs the actual racist and sexist discrimination in hiring, which only seems to exist to you as some abstraction, rather than real people losing their livelihoods because of sexual harassment and racist bullying.
> Good thing I cited a source studying hiring the private sector as well.
Ah yes, the highly regarded International Journal of blog.interview.io. How did I miss this groundbreaking research?
What you call a strawman is exactly the kind of discrimination that exists at my current employer and at my previous employer. This is reality. And the discrimination isn't small or subtle. We're talking about aggregate 2-3x times less likely to get a phone interview as a diverse candidate. Is harassment or bullying equal to or greater than the impact of this preference in hiring? There's no right answer to this question, this is a subjective question for which people can and do give different answers. Someone whose diverse in tech might feel like a reduction in harassment or bullying would be worth a significant reduction in career opportunities. Someone who is struggling to get into tech, and doesn't have diversity status to stand out from the rest of the pack could also arrive at the answer that they'd be better off as diverse even if it did mean that they might be subject to additional harassment or bullying.
Calling the latter "frothing", "breath-takingly racist" is an incredibly hostile thing to say, and it makes me question whether people actually want to discuss the impact of discrimination in hiring or want to shut down discussion by making it taboo.
Also interviewing.io actually conducts interviews on a large scale, and is probably one of the best positioned organization to conduct this sort of experiment. Can you elaborate on why their study should not be accepted?
And you do realize that you're equating diverse hiring efforts with getting called racial slurs on the job, yes? Those are two very different definitions of "actual" racism. And rather supports the breathtakingly racist claim above.
> Can you elaborate on why their study should not be accepted?
Forgive me, I didn't realize they were the leading authority on the nuanced sociological facets of unconscious prejudice during hiring. And here I thought a publication by psychology researchers or African American Studies professors would be the subject matter experts to seek out, not a blog post.
> And you do realize that you're equating diverse hiring efforts with getting called racial slurs on the job, yes? Those are two very different definitions of "actual" racism.
Right, they are different. The latter makes people uncomfortable or alienated at their job. The former keeps people from getting jobs in the first place on the basis of race and gender.
Which one is more serious? Someone who gets bullied for their race at their workplace probably has a very different opinion on this than someone who can't get an interview because they aren't diverse. The proverbial grass is usually greener on the other side. Someone who's non-diverse and can't get a job in tech might look at a diverse worker talking about bullying at their job and think to them selves, "well, at least that have a job.". That doesn't mean they are racist. That means they have a perspective different than your own.
> Forgive me, I didn't realize they were subject matter experts on the nuanced sociological facets of unconscious prejudice during hiring. And here I thought psychology researchers or African American Studies professors would be the subject matter experts, not a blog.
This reads like a total non-sequitur. Interviewing.io compared non-anonymous interview performance of women to anonymous interview performance, and found that there was little discrepancy (in fact it found a slight positive bias in favor of women). Why are you referring to sociology and psychology in a study focused on anonymous vs. non-anonymous interview performance? Also, why would African American Studies relate to studying potential gender bias in hiring? It seems like you just assumed that this study was focused on black candidates, when in reality it was studying potential bias with respect to gender.
> So, you're saying racial slurs are better than diverse hiring?
I answered this question:
> Which one is more serious? Someone who gets bullied for their race at their workplace probably has a very different opinion on this than someone who can't get an interview because they aren't diverse. The proverbial grass is usually greener on the other side. Someone who's non-diverse and can't get a job in tech might look at a diverse worker talking about bullying at their job and think to them selves, "well, at least that have a job.". That doesn't mean they are racist. That means they have a perspective different than your own.
> Thanks for definitively putting the "Are you a racist?" question to rest. I think we're about done here.
This kind of rejection of different worldviews is the antithesis of inclusion. You're branding people as racist for looking at the world from a different perspective.
If you met an Asian man who graduated from a boot camp and failed to get phone interviews while his diverse peers got interviews and jobs, would you tell him to his face that he's racist if he thinks he's getting a short end of the stick? If he felt that having a job, even if it meant additional bullying or harassment, was better than not having a job at all would you genuinely tell him that being unemployed and Asian is better than being employed and black, female, or Latino?
Let me turn this question back to you:
> So, you're saying racial slurs are preferable to diverse hiring?
Between getting a tech job but being subject to racial slurs vs. not having a tech job at all, yes many people conclude that the former is the better outcome. I think the former is more disadvantageous. But I'm speaking from the privileged position of already having a tech job. People who don't have the security of already having a tech job often think differently. And it's not right for me to dismiss their views as racist for being different from mine.
Not to mention, non-diverse people are subject to slurs too. I've witnesses more hostility towards Asians than any other race, yet diversity hiring penalizes them hardest.
> This kind of rejection of different worldviews is the antithesis of inclusion.
Ah yes, the old "You're intolerant of our intolerance" chestnut. Every post of yours is just doubling down on insistently denying the realities of racial biases in hiring, and portraying any attempt to hire diverse candidates as the real racism. Oh, and look: more strawmen.
> Every post of yours is just doubling down on insistently glossing over the realities of racial biases in hiring by painting any attempt to hire diverse candidates as the real racism.
If this is your takeaway, then I don't think you've been getting the message that I've been trying to convey this whole time.
There are benefits and drawbacks of being diverse in tech. You correctly highlight that diverse workers are often subject to more bullying and harassment. On the other hand, many tech companies do discriminate in hiring and that results in greater opportunities being extended to diverse candidates as compared to non-diverse candidates. Both of these are "real racism" (and sexism). Which one is more impactful than the other? That's a subjective question, and people with different experience are going to have different responses.
Someone who is diverse and subject to bullying or harassment might think, if I weren't diverse I might have diminished career opportunities but it'd be worth it to avoid this harassment. By comparison, a non-diverse aspiring tech working might think, If I were diverse I might be subject to more harassment or bullying but the career opportunities would be worth it. Which one is right? They both are, because these are their opinions. Trying to say one is right is like trying to identify the correct flavor of ice cream.
And the "strawmen" are real diversity hiring polices I've encountered. If you're a boot camp grad and you applied to Dropbox between 2014 and 2019 you only got an interview if you were diverse. Dismissing the things I've personally witnessed as strawmen makes me think your opinion comes from a perspective that is not aware of the extent of diversity hiring. Perhaps you'd think differently if you worked at my current and past employers and witnesses our hiring policies.
Referral candidates definitely get plenty of offers that they "would not have obtained" were it not for their referral status. I think it's more than a bit silly to worry about diversity focus introducing unwanted "biases" in hiring, when it's never really possible for something as random as hiring to be "fair" in any real sense.
There's also the issue of laws that mandate offering equal opportunity on the basis of race and gender. By comparison, I'm not aware of any legislation mandating equal opportunity between candidates with and without referrals.
Furthermore, I'm hesitant to write off discrimination as a non-issue. I don't feel personally impacted by it - but I'm also incredibly fortunate to have graduated from one of the most prestigious universities for computer science, and to have household names on my resume. The fact that my employers don't interview White and Asian men from boot camps doesn't impact me. But what would a white or Asian man think about this situation? The nature of this discrimination is that we don't get to hear the opinions of the people who are impacted by it. We get to talk to the diverse people who were included because of discrimination, but the people who were excluded because of it are absent from our workplaces.
Ultimately, I have no good answer here. Tech companies are stuck between a rock and a hard place. Companies are getting criticized for having "only" 20-25% of women in tech roles, when most estimates put the share of women in tech roles industry-wide at 18-20%. So companies have to choose between either enduring criticism and being portrayed as sexist, or discriminating in their hiring policies to increase their diversity numbers. With the techlash in full swing, public perception is important and I don't fault companies for doing the latter.
I'm not assuming. I'm just describing my experiences and what I've seen with my own eyes, a few times. Take it as what it is. Btw I don't assume that women are strictly diversity hires. Nowhere I said that in my statement. There are many many amazing smart women everywhere, even CS professors that I respected during my education are women. I'm just saying that diversity hire exists, that's all.
That is definitely one possibility. If you have studied a lot to get into an X companies and now you also need a lot of luck to get in, then it will deter you from quitting.
So basically, for example, two questions, Leetcode Medium difficulty, there are a few solutions. One can be done in O(n^2) the other one can be done in O(n) (non trivial algorithm). You need to code the O(n) algorithm to pass. You also need to be able to do it in under 20 mins each (total 40 mins, 5 mins for questions to the interviewer and introduction).
Sometimes the non trivial algorithm is an algorithm that you don't know, which in fact, was founded by some famous CS scientist. So in order to do that, you need to have studied that algorithm yourself and apply it during the interview. For example, Robin Karp algorithm, Knuth Morris Pratt algorithm, Djikstra algorithm.
I have always thought maybe there should be a path for people who are terrible at coding interviews but are confident in their abilities? Perhaps maybe a pass on the interview but then you work provisionally for little to no pay at first until after a discretionary period where they can decide whether they want to keep you or not.
Do people really eat dinner at this time on the weekend?
What about on weekdays; you have 30 mins to 'hang out with wife' then it's meditation and algorithm practice till bed time? A little depressing.
Apologies in advance for being harsh, but are you a member in order of your state association of engineers, did you pass the FE exam?, was your school accredited to grant engineering diplomas?
If the answer is not, please do not call yourself engineer
Firstly software engineer is not a protected title in most of the world.
Secondly the major way to properly learn proper software engineering is to join a top company and learn on the job. I don't see software engineering degrees containing anything useful at all compared to computer science degrees, they just contain some ancient practices which most of the industry moved past ages ago. So I don't really see how someone who studied software engineering at school is more of a software engineer than a person who designs and builds distributed systems at Google.
Welcome to Hacker News. I think you might be lost. Friendly advice: Try spending some time reading posts and comments for a while to become familiar with the site before jumping in.
The "Fundamentals of Engineering - Electrical and Computer" exam requires topics from differential equations to impedance in AC circuits to op-amps to frequency modulation. I would never gong a candidate for not knowing any of those things, because we write computer software; we don't make our own servers out of magnetite and sand.
"Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents."
If you follow that logic then a lot of people on this site are just pretenders. I don’t think it’s helpful to discuss the meaning of “engineer” in this context.
> And that helps us understand why Recursive Cactus spends so much time practicing. He’s training himself partially because his current company isn’t developing his skills.
Exactly. Recursive Calculus wants a better job, (a lot) higher pay, a better environment. So he spends time prepping for this.
And companies who can offer all of this, and get a lot of interest already, they are selective, minimising false positives in the hiring process. They expect working code in the coding challenge, a good attitude and some other skills like demonstrating decent systems design. Recursive Calculus also preps so much as his interview process to his current place was different and he _really_ wants to nail these interviews, get a bunch of offers and get into a bidding war before saying bye to his current workplace he’d love to leave for something better.
There wasn’t really any actionable thing in this article that I found, or applicable advice. The end.