What is the engineering hiring bar?
blog.interviewing.io
blog.interviewing.io
> 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.
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 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.
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).
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.
Very bizarre experience.
Because they felt that it was a false help. If they take it they're disqualifying themselves because they didn't know something.
Your relationship when questioning is very conditional. Answer question right == get the job.
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?"
Note: the author of that page should add React.
Not saying this is or isn't true, but it seems insane.
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.
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.
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.
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 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.
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.
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?
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.
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).
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.
It’s called salary compression or even worse salary inversion.
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.
I've only ever worked as a programmer, so I'm genuinely curious - how does interviewing work for every other job that's out there?
Typically the interviews are more conversational, with an emphasis on behavioral questions, job history, and relevant skills. Academia and government have their own formats.
This could honestly be a single-line summary for every blog post I've read on interviewing.io.
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.
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.
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
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.
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.
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!
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.
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.
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.
And outside of SV, seen this in the Midwest at both tech and non-tech focused companies.
(It's a fine comment otherwise.)
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.
I wouldn't be so quick to presume that FAANG IQs aren't above average.
>the EQ (emotional intelligence) and CQ (cultural intelligence) factors which comprise the other 2 legs of the "good hire" stool
EQ may be difficult to measure but the spoken part of the interview should generally take care of 'CQ', if that's a thing.
IMO the only surefire way to hire is to bring people on temporarily and evaluate their performance in 1-3 months. I don't know why this isn't popular.
Also this would be especially good for graduates with little work experience.
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.
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.
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.
Google also offers associates or something similar to that. But it's for much longer, 6 months or a year.
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.
But that's just my anecdotal experience.
I am also single.
However I don’t think this company would generally tolerate brilliant assholes; who would almost certainly not be a good cultural fit.
It should be a job like any other.
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.
[1]: And, tons of professional work experience
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.
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.
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.
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.
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 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.
They were written about because they were so bad, everybody agreed they are horrible and they weren't that popular to begin with.
They do happen yes, I don't know if it's common or if I'm just not very lucky :)
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 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.
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.
How about other US states or other countries? I don't live in US, and where I live they pay about the average salary, maybe a tiny bit more.
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.
This is a pretty high bar IMO.
try again - there's randomness and variance to the interview process.
most FAANG engineers did not get in on their first tries and without even more prep a second time around most likely.
and even then you might just be unlucky and get a bad interviewer who won't hire you for any arbitrary reason.
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.
what are some of the tells ?
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.
Kind of like that math teacher accusing me of cheating because I did well on the exam.
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.
Debating if would be worth taking the hit of switching to python now.
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.
https://www.teamblind.com/post/Should-you-tell-your-intervie...
only ppl GP is catching is ppl who havent' practiced that skill. Leetcode junkies are simply outsmarting him.
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.
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.
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.
Nope; but it does sound like it selects for people who are obedient and willing to do a whole lot of extra work. Which might be the point?
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....
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.
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.
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.
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.
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.
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.
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.
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 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".
The skill level needed to not screw up large complex problems is exponentially higher than for simple small problems.
Companies and products vastly differ in this regard.
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?
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.
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.
Sorry, you lost me immediately. As a married person this is not a realistic typical schedule if you wish to stay married.
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.
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.
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.
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?
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.
Take it as what it is, downvote it all you want. A freedom of speech for everyone.
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.
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.
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.
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.
> 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.
1. https://blog.dropbox.com/topics/company/an-update-on-diversi...
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.
Yup, we marginalized groups get all the breaks. /s
your competition is not women or minorities. it's other majority groups, because more of them are interviewed and hired.
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.
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.
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.
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?
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.
Making this view more public would help.
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.
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
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.
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!)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
That's good, keep that! Don't get involved in this crap. I have to do it out of necessity.
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.
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.
If the answer is not, please do not call yourself engineer
Same with the firefighters, I don't want a firefighter to be considered as such only on some "contexts".
I am glad we don’t have to have “certifications” by some bureaucratic local agency to work.
Again, welcome.
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.
https://news.ycombinator.com/newsguidelines.html
Edit: please don't create accounts to break the site guidelines with.