I skimmed this briefly but I can't reiterate enough the importance of practice that the author mentions.
I am the same person when a FAANG hired me as I was 15 years prior when I first interviewed there (I also interviewed a bunch of times in between, for successively more senior roles and did better in the process each time.)
When I was young, I had some fixed mindset - I am either good enough or not. They will either see that I am good or they won't. Nowadays, it's obvious to me that it's my responsibility to make it easy for them to see that I am good. That's what practice is - it's you working on your ability to articulate your fit for the role. That could be your ability to solve problems at the whiteboard, honing your career story, etc - the point is that if you ultimately don't have something to offer, no amount of practice will help - but if you have the potential but don't know how to let it show, you won't get the job either.
It's worth saying I've been subjected to LeetCode interviews for SRE Systems Engineering positions. Though I write application code it doesn't even begin to reflect the problem domain I work in. It's simply a test that you must pass that someone arbitrarily believes does a good job of filtering. From my perspective as a senior engineer, and knowing that many of the people who can pass these tests suck when it comes to practical skills, the only thing it filters for is how bad you want the role.
+1 to this - I’ve had countless interviews for SRE positions that were pure leetcode. If I were applying for SRE roles today, I would take it as a signal and just stop the interview and leave. Leetcode interviews are a big part of the reason why I left my career in tech.
I’ve built infrastructures that handled 30,000 requests per second at dozens of datacenters - never once had to implement my own graph search.
And that hits the problem for me; the process often doesn't allow showing what you have to offer, it only allows you to show that you check all boxes in the process.
I don't think that's true -- and I say that as someone who's spent plenty of time on both sides of the proverbial interview desk.
Checking the boxes as you say sounds superficial, it's more like - there are some bars to the role you're interviewing for. A typical eng role probably has bars around programming ability, team work and communication ability, problem solving, etc. By "checking the boxes" you probably mean ability to demonstrate that you can do those things in the context of the interview - that takes practice.
Now it comes to the other stuff beyond the bar that you want to show. There are some attributes about myself that I want to come up in the interviews whether I am asked about them or not. Making sure they get mentioned takes practice too.
Either you say the specific words that are in their script, or highlight the stuff they're really into, or you fail.
Replying here because of wacky thread depth limitations in HN:
Often personal preferences. And there's no discussion, just failure because you didn't say the right thing. Especially if you have more experience than the interviewer. Arguing that someone shouldn't get hired because they didn't check whatever box is something you would never get fired for. My last example was using GET instead of POST for a login endpoint, which is a perfectly fine thing to do.
Sometimes teams are looking for specific knowledge or experience, then it really does matter. Other times, they are looking for a good developer who can pick up the necessary knowledge, and then it's much more open.
For example, I don't care what programming language you use in your interview. Senior engineer using Python? Sure! Want to implement in low-level C? Sure! I know any good engineer can easily be productive in a new language quickly.
But if I'm hiring someone to build/extend a real-time OS, then you need to check the "has experience working on real-time OS" box, because that's what I'm paying for when I hire you.
> Nowadays, it's obvious to me that it's my responsibility to make it easy for them to see that I am good. That's what practice is - it's you working on your ability to articulate your fit for the role
I second that. As an interviewer it's much easier to pass someone if they directly articulate how they meet the question rubrik. For coding interviews that can mean explicitly communicating a methodical approach and covering edge cases. For behavioral that can mean clearly communicating a situation and it's impact. This does take practice.
What excitement? You're joining to become one extra cog in a large machine that is past its prime.
You will have little agency and impact, and your only opportunity for a decent compensation will be based on internal politics rather than technical merit.
Meanwhile, you can join a human-sized company, and be a real enabler and transformer of that business.
Been at two FAANGs, a small startup and a mid sized company.
I cannot overstate how little I care about being an enabler and a transformer of the business, or even care about the business.
You see, as a business ( of one), I'm here to ensure my company (again me) is generating cash flow and profit for my stakeholders ( me + family + dog).
Unless I own the company or have equity >10%, it never made sense why anyone would.
That said, I enjoyed my time at the good large corps. Big and small, they all have their issues internally, but I'll take the boring and well compensated job over the interesting (almost never that interesting) and low pay one.
> Unless I own the company or have equity >10%, it never made sense why anyone would.
This is key. I worked for a small company for 8 years, and in the end I realized that the owners still wanted me to be just a cog, and I would never be anything except a cog in their (small) machine. That's when I quit and started my own company.
The gap between employees and owners is massive and almost always insuperable.
> Either you were not a key person or you badly picked the company you worked for.
This is a really uninformed and insulting reply. You speculate without having any knowledge or details about the situation.
First of all, I didn't join the company with the intention of staying 8 years or rising to management; I joined because they offered a big pay raise from my previous job. So no, I didn't badly pick the company I worked for.
Second, I personally wasn't looking for equity, I was looking for power, the ability to make independent decisions.
Third, a more general point: BigCo engineers get equity in the company, but they're still just cogs in the machine.
I don't know what constitutes as 'great' and 'dedicated' in your books, but I'm pretty happy with how my career and life so far ended up at.
I joined a FAANGM straight out of Uni, wrote code that currently runs even today on billions of devices worldwide, and services that processes requests also in billions.
Then ended up at another FAANG with similar outcomes.
Being at large corps in my early 20s was one of the best things that happened to me financially, setting me up for life by 30 to pursue anything I wanted - a lot of it was timing and luck, but some credit for my dedication wouldn't be asking too much.
The startup, on the other hand, was bought out and the service eventually scrapped. I'm pretty sure that code doesn't even exist anymore or an archive somewhere never to be touched. Ironically, this is the place I've had to work the hardest.
Today, I can at least get my foot in the door at most places purely based on past experiences. Whenever some company wants me to do a song and dance take-home interviews, I respectfully tell them to knock it off and they usually do.
I'm definitely focused on family now, and I'd argue it is the greatest thing I'll ever achieve.
I hope young, newly-minted engineers don't take your advice too seriously.
You can definitely forge your path in multiple ways in your life. Not drinking the kool-aid is paramount to maintaining perspective of what really matters in life.
Every decade or 5-year chunks of your life, has unique phases, choices/oppurtunities and experiences that are strictly for that part of your life. Your real job is to figure out which to pick and choose to minimize regrets.
Paraphrasing another HN comment -- In a decade, the only people who will remember you worked late to go above and beyond to deliver, is your kids. And if you choose not to have kids, well there's your answer.
You don't work hard for your code to be used, but for the opportunity to learn how to build things.
3 years of experience at a startup are worth a lot more than at a big corporation.
Personally I'd rather my kids are proud of having a father who believes in what he does, rather than one that just clocks in-and-out. I have a similar sentiment when looking for a partner too; I simply cannot date someone who's not driven by their job.
That being said, to each their own. I know a lot of people who prefer focusing on hobbies and family than on their career. I suppose that for those, FAANG isn't such a bad compromise.
1. First, there are plenty of roles in these companies. You could be working in a very small specialized team on open source software that is used beyond the company. It doesn't matter if the company is past its prime or not, and you're not more or less a cog that if you work for a startup.
2. I can only speak for my experience, but my compensation isn't based on politics at all. It's purely based on my contributions. Compensation is just like the interview process, highly standardized, no room for politics.
3. A lot of human-sized companies don't produce anything meaningful, with more politics, and you won't have any room for impact because you're blocked by a few stubborn people in power.
Again, just my experience but I found that in my FAANG, there's a critical mass of people with good common sense and less bullshit in general. In the couple of smaller companies where I worked, it wasn't the case. There were good engineers, but also enough annoying people with too much influence that make my day-to-day job less enjoyable.
1. In a start-up, you being good at what you do is what separates the company failing from it succeeding. In FAANG, none of what you do matters. There are thousands of initiatives and redundancies.
2. Highly standardized is exactly what leads to politics. Everyone's circumstances are different but somehow you need to fit everything to the same ill-fitted mold, so everyone is trying to exploit the game. The standardized interview is also the worse thing about Google/Facebook leading to dumbing things down, lack of purpose, and bad targeting of specialized skills. At least Google is backtracking from it.
3. A small company has vision and enables a few people to have genuine impact, this is what leads to doing something different and innovating. Those few people in power are stubborn, they need to. You don't innovate through design by committee. If you don't like the vision you shouldn't have joined that company.
Enabling FEELS great, but you are still just making (less) money - you are a work for hire no matter what. And it's a lot of work - making someone ELSE rich.
Now, if you are entrepreneurial and aiming to start something of your own, a smaller company will force you to wear many hats and become the jack of all trades, learning tons.
I say, do it when you are younger - you will have more time, more energy, and you will need to be learning a lot. And later on - be a mercenary for money.
>You're joining to become one extra cog in a large machine that is past its prime.
yada yada
>You will have little agency and impact, and your only opportunity for a decent compensation will be based on internal politics rather than technical merit.
Yes, you have little impact (unless you go up on the ladder), but you're working on products that serve the whole world.
That's quite a few order of magnitude more than working in yet another startup creating web-shop or niche app.
I'm not even at FAANG level of corpos and I really can say that I'm putting tiny bricks into really interesting products.
The work itself is pretty boring, but products as a whole are impressive as hell.
Don't get me wrong, I'm not saying that corpos are great and startups sucks,
but when you're talking about companies that hire 50k, 100k, 200k or more people and just call them places where you're just "cog" and there's nothing exciting about the job then I think you're just naive
There is always a lot of bitterness on the topic of FAANG interviews, and also a lot of bashing of engineers working there.
It's difficult to hire large number of people globally without some level of standardization. What I like with FAANG is that the interview process is fair. The rules are explicit and they give a chance to quite a lot of people (including people with slightly unconventional profile).
Another myth is that FAANG engineers are just leetcode grinders and are useless beyond that. What struck me is how diverse the people working there are. In term of educational background, origin, professional experience, age... I find it pretty remarkable. It's hard to make any general statement about this population considering how diverse it is.
Man, I've coded a fair amount in my free time, and have even created a couple of money making side-projects, but I just can't grind leetcode no matter how often I try. That plus the rejection after doing long on-sites drains me for days afterwards. I've come to the conclusion that even though I may be missing out on those top salaries, FAANG just probably isn't for me
I think recognizing that "something isn't for me" (vs is bad) is a great and mature point of view, I deeply respect that. Some thoughts beyond that:
By the time you frame something as "grinding" - it's going to suck. If I were you, I'd ask why does it feel that way? For example, is it because you don't have a good foundation in algorithms fundamentals -- if so, would it help your career to learn those, anyway? Is it because you don't enjoy problem solving or aren't a structured problem solver -- if so, is there something to learn there? Or is it because you framed something that could potentially be fun as an adversarial grind to begin? (BTW, I am not saying any of the above is true or likely - I am just suggesting one "next step" type thing since this question seems interesting to you)
Similarly, being deeply impacted by rejection -- is that a thing that would serve you to evolve over time? As you become more senior and ambitious, you are likely going after harder opportunities and your rejection / fail rate will go up and that's normal and good. Is there room for reframing how you deal with fails?
> Is there room for reframing how you deal with fails?
What would be your advice? How do you personally deal with fails? It feels shitty every time it happens, regardless of the amount of reframing or whatever else I put into my mind.
The unsatisfying answer is - that you have to figure out why it cuts you so deeply to begin with to really make sense and fix it. But I can provide some hopefully actionable things in the process:
- Recognize that interviews (and other things, like dating) is a high value endeavor but the failure raise of any given encounter is high. Go in wanting the job and doing your best, but recognize that the answer to any one of them is likely "no" for many reasons external to you as well as your actual match for the job. This is what they mean by "it's a numbers game."
- Especially if you already have a job and are just interviewing looking to grow, treat it like an experiment. "What can I learn by preparing for and doing the interview? How can I make it more enjoyable for myself? Is there a way to think of it as an interesting challenge/puzzle rather than adversarial?"
- Recognize that the feeling of failure is different than the reality of failure (eg: you are feeling like shit but in reality everything is fine, you're no worse off than if you hadn't tried, and in fact you're better off because you did try.) This is a thing in general - recognizing that our feelings are "louder" than reality allows us to tone down those feelings.
I have printed out the last substantive paragraph of your comment and taped it to my monitor.
I don’t know what, if anything you had to go through to learn this. And I figure that in my heart, I probably knew it already. But reading it once every few hours will probably do me some good. Thanks for that.
Thank you so much for making this comment. I would be beyond happy if this is helpful to you.
A few other thoughts on the subject of the paragraph that resonated with you.
A yoga teacher told me a long time ago to draw a distinction between how I feel and what I am. In English, we say "I am angry" or "I am sad" etc. - where our words literally describe us being that emotion. A more useful frame is "I have an anger", "I have a sadness" etc. It acknowledges that you may have a feeling but that feeling does not define you. Basically, the recognition that how you feel isn't reality.
Further reinforcing this point is the idea that we acknowledge that feelings can be inappropriate. EG: if someone loses their shit in anger over something trivial, we don't go "wow this is clearly a bigger issue that we thought", we just say this person is overreacting. Or if someone is anxious about something benign like flying or public speaking, we don't say "oh those must be really dangerous things", we say "it's unfortunate that this anxiety is limiting you and making you unhappy."
Likewise I think with failure. Failure in general is a bad thing - if you fuck up that can have real bad consequences for you and your community, so it makes sense for fucking up to feel bad. But reality is that most failure isn't material in this way (you and everyone are fine) but it can still feel as if it was. So recognizing that just like anger or fear can be obviously disproportionate to the stimulus, so can this feeling. Having that perspective is an important step towards keeping it in context and diminishing the sting.
Another thing is to realize that your failure is contextualized to a calculated risk you chose to take on. You decided that interviewing for ambitious jobs (in this example) should make your life better eventually. The fact that you decided to do that is a success. The fact that you then failed at a particular interview is totally within success criteria of the larger endeavor.
In general, there's something to be said for not taking ones' self too serious. The fact that you think or feel something is the beginning of the story, not the end. I find that a lot of religious growth comes from/entails recognizing that "just because you want/feel/fear/etc something - that's not the end-all-be-all"
This is probably now too much vs what you will find useful but I wanted to share!
When it comes to interviews, there are two types of fail:
1. The kind where I walk out saying to myself, "Yeah I couldn't answer those technical questions, so I probably don't deserve this job because I'm not ready yet".
2. The kind where I feel that I answered everything right. I realize that when it comes to those fails, there are so many factors out of my control that it's probably not my fault. Maybe one of the interviewers was having a bad day. Maybe they had one specific answer in mind and I didn't get, and I don't want to work with someone so inflexible anyway.
There are a thousand reasons that have little to do with you as to why you may not get a job. Just knowing that should make you feel better.
OP and founder of interviewing.io here. We spent hundreds of hours interviewing current & former FAANG interviewers to write this piece. We really wanted to peel back the curtain on what happens during these interviews, what actually matters to them, how these companies train their interviewers (if at all), make hiring decisions, and so on.
I'll be around to answer questions, and I'll tag in Kevin, the author, as well (I just edited it).
It is bewildering to me that there are companies where you don't interview with the team you will join. What if you don't click with them? These are the people you'll spend every day working with.
> It is bewildering to me that there are companies where you don't interview with the team you will join. What if you don't click with them? These are the people you'll spend every day working with.
There's a very important caveat here. At Facebook and Google (those are the ones I experienced) you have to pass a bar to get into the company. While those initial interviewers won't be the ones you work with you'll either (Google) go through team matching where you'll meet those team members or even better (Facebook) meet them AND work with them on a couple tasks to get to know them and their work BEFORE you join the team.
What if you were at a company that had 100 teams with open spots to fill. They all need the same basic skill set and with some onboarding it will fill in gaps in the domain knowledge.
Do you want to do 100 interviews? An interview with 100 people asking you questions? If you interview with the "wrong" team or someone else accepts a position with that team before you do, do you want to be dropped from consideration?
That structure for interviewing is set up to try to find as many people who are {this good} as possible to hire. Once you get hired, then they'll try to figure out where you fit in. Trying to fit each person to their exactly right and best fit spot as part of the interview process makes it even more time consuming.
So the main factor for succeeding those so-called interviews is doing more of them? ie, it has nothing to do with your actual performance on the job.
We should think hard as a society on what we want to spend our time on. At some point in my career I drank the koolaid that joining a FAANG was the most prestigious thing you could do. But now I start to see people working at FAANGs as bureaucratic rule-follower that put their 50 hours of leetcode-grinding (I suspect that they are implicitly filtering for those engineers that will follow tasks without asking too many questions)
>I suspect that they are implicitly filtering for those engineers that will follow tasks without asking too many questions
As a general rule most educational systems are that way, for example you need to be very conformist if you want to become an MD. Consequently you will not find many MDs who are no-conformist.
In fact I would go so far as to say that even elementary and high school filters for conformist people who are going to be willing cogs for their government and corporate overlords in the future
Interviewing is a skill that needs to be worked on.
Unfortunately, your "portfolio" is not portable between companies and so these tedious interviews are necessary. Similarly for other technical roles like welding - they expect you to do an example weld to show you can really do the work, though there are also certification standards that help which we don't have in the software industry.
I interviewed at AWS for an application security engineer position years ago, and I was surprised about the questions I was asked.
I did the recruiter call, then phone screen, then a series of 4 hour-long interviews. Since it was AppSec, not coding, I expected 3 interviews asking me technical questions about AppSec and a behavioral interview. Instead, all I got 3 hours of behavioral/leadership principles questions (With a lot of repeated questions between them), and 1 coding exercise.
I got rejected while feeling like I never actually got a chance to show my technical ability to do the job. I know how much they value leadership principles, so I probably wasn't going to get the job anyways, but it still made me feel a bit disgruntled.
Tangentially related, is it worth it to do the leetcode grind and all the FAANG-interview preparations if I'm always planning on working remote? Are there remote companies with FAANG-level compensation that would warrant this sort of interview prep?
Netflix still hires remote. I'm guessing for the right team and with the right resume you can get remote at Amazon, Google or Meta right now if you have enough seniority.
Finally, I think most companies are using some LC type questions. Asking if you should practice leetcode is like someone asking if they should get in shape. Vehemently the answer is 'yes to some degree', and the rest just depends on your goals.
100% yes. I did this 2.5 years ago, got a remote FAANG job, and more than 3x'd my comp. Remote FAANG-level comp is harder than to get than it was during COVID, but it is still possible.
My pro-tip if you want one of these jobs and are not great at leetcoding, try to get another role at the company and then transfer over.
Apply as a data analyst, theres no leetcoding, you just need to demonstrate sql knowledge and experience working with the business. And faang data analysts are paid as much as many non-faang engineers.
Once you are in, you will be working with engineers, just do a good job, and express interest in working on the software team. The bar will be much much lower than an external candidate.
I would say 20-25% of engineers at these companies come from a non-traditional route like this.
This is absolutely wrong, at least for the FAANG where I work (Amazon).
Not only are data analysis jobs given to business grads and are non-tech roles, they also do not work with software engineers at all and I guarantee you you will hate every second of your job in those positions because of how uninteresting it is.
After that, if you do want to switch roles, you will either have to go through a full interview loop and held to the same standard as an external candidate, or you will have to go through an even more grueling job title change process which will take months, with no guarantee of being approved (and to be fair, if you're a data analyst doing a data analyst's job, has no chance of being approved).
In my experience this is entirely incorrect. Being a strong outside candidate (assuming "strong"=="good at leetcode") is going to make you much more attractive then hoping you're noticed internally.
You're likely to get more bang for your buck by spending your time grinding Leetcode, than learning how to be a data analyst and networking your way into a SWE position.
Context: Was Sr+ at a FAANG, have had offers from 2 others.
If what you want is to be hired quickly and get a big paycheck, go with the higher chaos score. They may be easily impressed by simple interviewing tricks, and since the place is clearly disorganized, you can get away with not doing much work.
I should feel bad for giving this advice, but fuck these bloated mega-rich companies if they refuse to get their shit together.
Eh, to me the chaos score seemed pretty opinionated.
After all, if the interview process is highly standardised the jobs must be highly standardised. That's fine if everything is a java web service and you only want to hire java web service folks. But if I'm an expert in machine vision for robotic applications, how are you going to validate the specialist skills that make me so expensive?
And what do I care about the interviews being consistent? I only have to go through the process once. And it's not like I'm relying on getting hints or leaked questions to be able to pass.
I don't think this is necessarily true. Big chaos score means that the hiring manager is basically free to hire whoever they want with no verification, but that does not mean that they do not keep their engineers in check. Google has low chaos score, but you can essentially get hired without a job that you should do so that could also indicate you may get away with doing not a lot of work
Just a heads up to anybody super starry-eyed about fang, I worked 10+ years non-fang, and tried fang, and it was absolutely miserable, one of my least favorite jobs of my career. Yes I made a lot, but I also worked and stressed proportionally more. YMMV.
>> Just a heads up to anybody super starry-eyed about fang, I worked 10+ years non-fang, and tried fang, and it was absolutely miserable, one of my least favorite jobs of my career.
Most people I know say the same, but they stay. You can be at a non-FAANG and work for half the pay (and often be just as miserable) or you can work at FAANG, own a house, not worry about money, and often do not much work. Misery is part of the package.
But isn't that a bug? It's not that hard to find a non-FAANG job that pays well, lets you own a house, and not worry about money without having every working day be a misery.
While you absolutely take a huge pay cut to not work at a FAANG, it's not like making 200k+ is living in poverty.
Typically non-FAANG also has other perks: many more fully remote options, typically much more chill about working hours, working with niche tech stacks or on new problem spaces, etc.
You can enjoy work and still have a house and not have to worry about money at a non-FAANG, just not as aggressively much as you do at one.
Not that I know, but in my experience, the stress for me came from the increased level of expectations at faang vs non-faang. I recently moved to a faang-tier company and the most jarring thing to me was how much the expectations around the quality of what I produced grew. Not just in terms of code but like artifacts, documents, and discussions that needed to happen. Another aspect is how overwhelming a large organization can be for people. Going from a 10-50 person startup to an engineering org of 5k people is pretty different. The sheer scale can be stressful in and of itself as you try to figure out what's important to your section of the org.
Not saying non-faang can't have that stress, more just that sometimes the expectations are drastically different and that can feel like a sink or swim thing for people. I'd also say it depends on where you get placed in a faang company, some teams are more dynamic and free wheeling than others which I'm sure plays into it.
Yes, identical story here. I was over the moon when I got the job. Within 6 months was basically just waiting until I had been there long enough that leaving wouldn't look bad.
The FAANG, or MANGA, all vary a ton. It really doesn't make sense to compare them all as if they're remotely the same. They all have a similar hiring process and they're all big (which does wind up causing similar problems), and the similarities usually end there. Even between teams in these companies things can be totally different.
TL;DR don't throw out a basket of companies because you think they're the same
Speaking from experience working at both FAANG and non-FAANG, the worst part about FAANG is that compared to small-mid sized companies the work just isn't that interesting.
They buried the important info in the middle of the first page: "Moreover, this guide is written for experienced, back-end leaning engineers – interview processes are usually different for juniors, but we won’t be getting into those differences." There are multiple jobs out there are very technical positions pay 6 figures with no coding required. It's not interviewed for. It's not required at work. In fact, I can't give code to customers even if I wanted to.
My urge to work for FAANG company is faded away. Being in my late 30s I don;t want to grind leetcode anymore. I had interviews in Apple/Google/Facebook and I felt luck played a huge part of that. I got some live coding questions that prepared the day before and I aced them and in some cases I practiced so much and couldn;t even write more than 10 lines of code.
I don't know, I've walked into these interviews with zero preparation and succeeded.
And I've failed FAANG-ish interviews where no amount of leetcode grinding would have helped me.
In my opinion, it's getting rather silly. They're scaring off and filtering out excellent candidates with these excessive processes. None of them even cared about my Github repository that's full of code I write for fun.
Software developer hiring is definitely ripe for revolution/innovation.
It's luck of the draw. That's really how it's always been.
If you get bad interviewers, you're in for a bad time.
If you get asked questions you know, you're in for a good time.
It's possible your odds of getting bad interviewers has increased. But I doubt the increase is that substantial.
It's interesting to me how much stock these companies put into hiring, and then let countless terrible interviewers continue to interview.
You'd think they'd recognize high quality interviewers and get them doing more than 1 interview per week, and not let people interview until passing a pretty high bar in the quality of their interview.
Instead, they pretty much let anyone interview (as long as they've been at the company for N months and gone to some training).
They also don't give any feedback on your interviews other than an eventual "they were hired" or not. So if you are a mediocre interviewer you will never know.
> You'd think they'd recognize high quality interviewers and get them doing more than 1 interview per week, and not let people interview until passing a pretty high bar in the quality of their interview.
I think you substantially over-estimate the eagerness of software developers to take on unrewarding admin work.
It’s an important day for them, so you owe them your full attention. Can’t be browsing the web or replying to emails.
After a decade of interviewing, there is no excitement in watching the thousandth interviewee make the thousandth attempt to count the set bits in an integer.
Hiring is important, it's just very very very boring.
I tend to put it this way: If you are entrepreneurially/leadership- minded and can develop a talent for identifying talent, you can be 10x, even 100x more valuable than any engineer because you become a force multiplier who recognizes real talent and empowers it - and the best part is that everyone else is dragging their knuckles on the ground and obsessed with pretentious gate-keeping. The opportunity level is wide-open.
If you want to make money off of being better at hiring than Google et al you need two things:
1) the product idea for something to build that you can sell profitably
2) the hiring skill
Neither of those are trivial to develop.
I do tend the think the second isn't that hard to develop for specific situations (FAANG interviews are really aimed at hiring people who they could swap around to large different sorts of teams or roles and get along with, and be productive with, a huge swath of the company, though IME in practice that doesn't happen terribly often these days). But if you're doing it for someone else's company, your upside is capped by the upside of the company you're working for. And your reward is too - you're not going to command 10x the pay from a CEO you report to who doesn't themselves understand the difficulty of the hiring you're doing compared to "just copy Google" (or why they wouldn't have good results with the latter).
A talent for identifying talent needs to be supported with numbers and effect sizes.
The relative absence of numbers from the conversation is what allows many directors of football/soccer (those who recommend the purchase or sell of players) to boast about their stature as talent scouts.
Indeed, it is not surprising that directors of soccer focus on successes and tend to gloss over the many blunders made. Which makes it difficult, as in many other fields, to distinguish the role of luck and ability in successes and failures. Almost always, in my experience, those with the most money and at least an average "eye" succeed in doing the best that can be done: everything else is a game of chance.
A more sophisticated and technically oriented person would say that the most that can be done is to increase the odds of success, but then we are all left to the whims of fate: the young soccer player who many thought would be a sure bet will turn out to be one among many, and the average player at age 16 will have the growth spurt in the next two years that will make his body more conducive to stellar success (but was the growth spurt predictable?).
What I can say is that there have been several attempts to create a special agency for the identification and management of talent in the technology industry, but none has turned out to be more than a higher-level contracting firm.
What kills me is that the developers they are hiring based on their encyclopedic knowledge of language minutiae and mad leetcode skillz are exactly the ones who will be first in line for replacement with ML-based solutions.
The fitness function used by these companies is so broken it's not even funny. The ability to get things done and ship product doesn't even seem to be on their radar. They are optimizing for dead weight, which is how they end up with these periodic 1000+-person layoffs.
I agree that there's a lot that the current hiring process get wrong. I'm not really defending it, but want to clarify a few things.
> They're scaring off and filtering out excellent candidates with these excessive processes.
In my experience this is by design. The cost of a false positive (hiring someone they shouldn't) is far more expensive than a false negative (passing on a good candidate). Since FAANGs usually have a healthy pipeline of candidates and many who fail will eventually reapply they're okay with passing on possibly qualified candidates.
> None of them even cared about my Github repository that's full of code I write for fun.
As an EM at a mid to large tech company who has hired plenty of engineers I think ignoring people's Github is the right call and I don't even bother looking at candidate's Github unless it's for something like an intern role. Ignoring the fact that I don't know where the code on Github came from (did someone else write it? Is this just following a tutorial?), the code you write and the skills you use when you're writing code at home alone on a passion project is VERY different than the skills you need to be successful in a large, slow moving, bureaucratic corporation.
When you are hiring in volume, you are hiring for additive value, not for transformative value (nor multiplicative value). For additive value, conformance is essential.
Most of the semi-successful companies don't need to be "the innovation machine".
I will agree with this. Leetcode style interviews identify the "rule-followers", "not-going to rock the boat" type of engineers. That's what FAANGs need, not innovators and leaders.
FAANGs can get literally over a million job applications per year. Any procedure that filters that down to roughly the number of people that they plan to hire (a few 10k) is also going to filter out some excellent candidates, no way around it.
But it's still a very time consuming and expensive process. Typically 5h of interviews with 1/2 people from my experience. Spending that energy more wisely would result in more valuable feedback and better hires. But it takes actual effort to try and understand rather than simply checking boxes.
Not a recruiter, but I imagine there are at least 3 reasons for your repo to be ignored or deprioritized in favor of typical interview:
- not everyone contributes to OSS
- it’s easy to fake
- it’s hard to assess within a short period of time
This it seems to be hard to standardize and streamline candidates validation based on their oss repos.
Also, afaik the goal of interview is to assess candidates thinking patterns, it’s hard to do quickly based on an arbitrary piece of code.
"They're scaring off and filtering out excellent candidates with these excessive processes." I don't see myself ever applying to any of these whacky interview companies. I like money and all, but idk. It's such a turn off. Maybe if I truly felt they were actually measuring company value.
Where do you find other valuable companies to interview at? Genuine question, I've been entrenched in the Silicon Valley bubble for well over a decade that I don't even know how/where to find meaningful (remote) companies.
Mostly friends or targeting well known companies. I've used recruiters, all sorts of things. I can't speak to the current climate as I haven't looked in years.
All jobs I applied for that I interviewed for looked at my GitHub specifically, and my past projects, and that was their main topic of discussion in the interview, apart from usual coding questions and such.
Im not victim blaming by saying you may just be applying to the wrong places, am I
I would love to talk about my github projects with an interviewer - hell, I'd also love to talk more about my past systems than their hypothetical ones - but like the parent post, I've found it pretty rare. Past projects maybe 15% of the time at medium-to-large companies (500+ person), and so far am batting 0.000 for "asked about personal projects", including at FAANG interviews.
The logic is twisted and strange, the justification sums up to this: talking past projects like talking to a PhD student about his research paper, it is all they does and doesn't put them in enough "foreign situation" to see their novel problem-solving abilities.
OTOH, when you are hiring for leaders (directors and above), past experiences and behavior questions are all you talking about.
That makes a certain about of sense but I think you can usually get a feel for project-by-project dissimilarities in someone's background and figure out if they've been doing the "1 year of experience for 10 years" or the "continually tackling new challenges and learning from them" path.
Unfortunately this also means you have to be open to a potential 50% cut in TC as well.
Personally, I find enjoying the 8+ hours I spend at work each day more important than raw TC, so have made the tradeoff (and still have a reasonably high TC) which works for me.
That said, I would love a more laid back research programming job in academia, but that requires an additional 50% cut from where I am now.
It's still understandably frustrating that knowing how to write software seems largely irrelevant to getting a job at a FAANG.
The Product Manager interviews are even worse. Google was the shittiest experience I had, all the way to the silly hiring Committee. Three months of my life I'll never get back.
> None of them even cared about my Github repository that's full of code I write for fun.
Context: I've interviewed around 200 people for our current org, and have "settled" on an interview that's used for a certain position. I don't think I'm necessarily good at interviews, and I'm not sure I'm "doing it right". I give the number to show that my sample size is reasonable. We're solving practical problems, with code. Our interview sessions are 45 minutes for each person (which is the fundamental limitation).
I don't look at GitHub projects, or really ask about previous work.
I used to, but I very quickly found that the vast majority of people lie on their resumes. Generally, the more senior, the more lies. Most people put bullet points of "achieved x" which end up really being "kinda helped those people who were achieving x". For GitHub, in most cases, it was obvious the person was not the author of the Github repo they gave me. They could answer questions about the code, but couldn't go into any depth about it.
I found that going over previous work, or Github repos, ended up taking a huge chunk of the 45 minutes, that put each person on a different standard, somewhat of their own crafting, leaving no time to find out if they were actually able to write a for loop or not, which I've had Phd candidates, with "15 years of experience", fail to do. For feedback of the candidate, I need a tangible justification, and clear demonstration of why I say yes/maybe/no. There are no "gut feelings" allowed from the panel; you need reasons.
So, I give the candidate a simple, practical, work relevant, problem to solve during the interview. No compilation, no running code, no worries about perfect syntax, and no esoteric knowledge/libraries required. They're free to use whatever language they want. It's an interview where they have to demonstrate their thought process, how they question/navigate the requirements, and ability to see consequences (which I think is 90% of programming).
Maybe a few percent have finished within 10 minutes. For these people, we had fun talking about their other work, and they showed great knowledge, as expected. But, as desired, that wasn't required to do first. The interview itself proved that they would already.
I would love feedback about this approach, even though it seems to be working well for our orgs needs. Ideally, I would take the Jim Keller approach, and have a nerd out session, but, I have a feeling people are more properly filtered before they would get to him.
Personally I wouldn't terribly mind such an interview, but I do know plenty of people who absolutely fall to pieces when having to code while being watched, and it's definitely not particularly pleasant to me, either. I think the best interview I've experienced was one where the "2 hour interview" consisted of me receiving an email with a short, job-related task and then after an hour was up we spoke and discussed my solution. Respected my time, as it wasn't some open-ended take-home test that somebody with too much time on their hands could spend dozens of hours polishing to perfection, while still not being quite so "whiteboard-y".
With regards to Github projects and the like, I do ask about them in interviews, because I think there's a place for them as an early screening. Every engineer worth their salt has some war stories, and that's a good angle to approach their GitHub profile: if they have an interesting sounding project, asking them to talk about any interesting problems they ran into during its creation tends to make it immediately clear whether they're full of shit or not. It's not a great positive signal, but if they're not chomping at the bit to talk about engineering challenges, it's a strong negative signal.
> absolutely fall to pieces when having to code while being watched
Yeah, this is the biggest problem I have with it. I try to be conscious of this, and try to keep things pretty lighthearted. If I notice someone getting nervous, a "you're doing great for time" usually calms them. If not, I do follow up interview, if they did well seeking an understanding the problem, and could explain it verbally. I've had a few people pass with flying colors after a second round.
> and that's a good angle to approach their GitHub profile
I disagree here, with the (probably wrong) assumption that not having a GitHub profile adds a negative bias. Some people put their coding hours into work, with different lives outside of coding. All of the colleagues I've known with impressive GitHub profiles burnt out/left. Battle stories can be within corporate repos.
I recently had an interview where, for the first time, the coding round was Coderpad based, which allowed me to run my code and build my solution bit by bit with instantaneous feedback.
I know for sure that I wouldn't have been able to solve that recursion problem without that live terminal. I now am going to insist on this live terminal in all of my future interviews and refuse to do any that don't employ one.
I think this is fair. But, with how simple the problem is that I give, it's a real issue if they can't read/understand the code they've written. It's simple enough that anyone should be able to mentally run the program.
Regardless, I'm going to offer that as an option and see how things go. Maybe everyone will be in a better mindset, allowing me to add a bit more complexity/depth to the problem.
I realized I've left out some detail. I'm on a panel, and I'm not one of the hiring managers. Others might be looking at resumes and repos, ideally before they make it to us. The above was to show why I, personally, don't consider them.
Maybe my org is different, but I need to have confidence and justify/document my yes/maybe/no. It's very hard to prove that someone is lying, especially since you can't expect them to remember everything from some years ago. You could claim they should have tried to remember the details of their projects, but that's tricky since most people can't take code or notes with them. If I show that they have a Phd, with experience building whatever, but can't write a for loop, then I have my proof.
Terms like "good thought process", etc aren't allowed in our feedback, unless specific examples are given. Terms like "team fit" will get your feedback outright rejected. No mushiness allowed.
>Software developer hiring is definitely ripe for revolution/innovation.
That's like saying that janitor jobs ripe are for revolution/innovation. You would think I'm joking, but most companies really do not care, despite what they say.
I have a public disclaimer in my LinkedIn profile intro saying that I refuse to do any algorithmic live coding. They’re top employers and whatnot, but one doesn’t need to torture themselves with Leetcode to get a good job in this industry
There was a great story on HN a few days about the concept of "It wasn't for me"[1] - the distinction between something being "bad" vs "just not for me." Your comment made me think of that.
If you really perceive algorithmic live coding as torture, then it makes all the sense in the world to avoid it. "It's not for you."
But it's important to recognize two things: first that this is subjective. A different person may enjoy something you hate (I don't mind live coding for example) or at least won't consider is bad enough to be called "torture." So just because it's not "for you" doesn't mean it's bad.
The second thing is to recognize that there's a cost to being however we are. In this case, the cost of avoiding opportunities that require such interviews is that you may have fewer opportunities and they may be less lucrative on average. It's possible that (a) you are still able to find good-enough opportunities and (b) the downside is worth avoiding the torture. But you can also decide that this cost isn't worth it, and you have some room to shape what is and isn't for you, over time. For example, if the thing that makes this "torture" for you something like anxiety when being watched? If so, probably something like that shows up in other places in your life and maybe valuable to tackle anyway.
By no means am I suggesting that you need to do something different than what you're doing, just pointing out that these reactions are subjective, can have downsides, and are under our control to some extent.
> the distinction between something being "bad" vs "just not for me." Your comment made me think of that.
> If you really perceive algorithmic live coding as torture, then it makes all the sense in the world to avoid it. "It's not for you."
I wasn't aware of this concept, but I can assure you that I don't have such a mindset. I tend to enjoy finding difficult challenges and complex topics to dig into which are way outside of my comfort zone. Leetcode practice is different though, and yes, it does feel like torture to me and some other developers who tend to be rather quiet in general. While it's really tempting, I don't think I'm the right person to act as a community voice on this topic, although I do chime in sometimes.
When you're just starting this career path, it feels like homework. Heck, it's even exciting to solve problems which are a bit more complicated than whatever you're exposed to in school. However, try to spend several years in a row (8 in my case) trying and failing to pass such interviews (several in-person ones each year) and it will feel like torture. "If you'll spend a little bit more time on Leetcode, surely you'll pass next time..." No thanks! I'm done. The issue is not the lack of training, but the way in which these interviews are conducted by certain people which causes me distress and severe anxiety. I moaned about this before in various HN threads related to interviews and I might bother to blog about it some day.
> In this case, the cost of avoiding opportunities that require such interviews is that you may have fewer opportunities and they may be less lucrative on average.
Hasn't been my experience, but I'm not looking to maximise my income. I looked for advice on negotiation strategies and whatnot and felt happy with the offers I got. Others might have a different experience in this regard, but I think asking for less money in exchange for a psychologically-safe interview process is nonsense. At the end of the day, you get what you pay for and there are review sites anyway.
> For example, if the thing that makes this "torture" for you something like anxiety when being watched? If so, probably something like that shows up in other places in your life and maybe valuable to tackle anyway.
I think you're making certain assumptions here. I don't need to "tackle" my perception of what's safe and comfortable. We're all different and that's a good thing.
It felt quite empowering, actually. I ended up having to point it out to some recruiters who kept pestering me even though I already knew what their employer’s interview process is like. It also helped me avoid wasting time to hop on the first intro call with HR to get details about the next steps. Also, I got a few people reaching out specifically because they resonated with it, which was great!
Interesting. So if I asked you to open up coderpad.io and write a python function to reverse a string, you'd just absolutely refuse? What would you do otherwise to show me that you're a programmer?
> What would you do otherwise to show me that you're a programmer?
Pretty much every other job in every other industry seems to do OK with education, experience and references.
If I want to hire a guy to tile my bathroom I don't need him to slap some tiles onto a whiteboard to get the job - some photos of the last few jobs he's done would be just fine.
Is the programming profession really so full of inept frauds? Is our industry so unable to regulate university education that qualifications are so worthless?
The main reason I hire the way I do is I learned that there are people who have resumes that look like mine (with 30+ years of coding) but they don't actually know how to do any coding, even just "please write out a simple class in python that does nothing". I go out of my way to give every candidate a fair shake and I'm not looking for some fast, set-in-stone rules. Nor am I looking for you to solve any really hard problems. Still it's been depressing just how many coders I interview who can't even explain how a hash table works.
I’d refuse, but If the conversation goes in that direction, then I’d probably end the conversation right there, since it’s pretty clear that’s not the kind of role I want to interview for. I managed to accumulate a bit of online presence over the years and I expect my future employer to a) look me up prior to the interview and b) have a direct interest in my Open Source work.
Sure, I'd look you up and scan your github pages. I've dealt with people who set up fake githubs (copying from various places on the web to make it look like they did real work). Can't help you if you only want to interview people who are interested in your open source work... that sounds very limiting.
In my experience it’s super easy to see that the resume or github or a home project is fake. If not immediately then in like first 10 minutes of the interview. I don’t think that “people lie” is a valid reason to generalize. If anything, that’s the interviewers who are limiting themselves, not the other way around.
This guilty-until-proven-innocent attitude will drive people like myself away instantly and that's fine. So far, I had plenty of options to pick from and, for me at least, culture match is highly important.
Oh, I understand. However, the problem is that many companies are inundated with low-quality, puffed up resumes, and it's truly hard to find people that are actually qualified, especially if they're not doing any work to make themselves available.
I would add that I don't think you should think of it as "guilty-until-proven-innocent"; it's just the reality that you are competing with large numbers of amoral people who will lie to get a job. This is much less about culture match than you think.
I've dealt with people whos whole CV was fake. One of the points of the interview is to sniff this out.
Diving into a github and then asking questions about it, in the same way as you would ask about stuff on a CV seems like a massive win for the skilled interviewer.
Normally when I’m interviewing people I don’t go much further than asking about the topics they covered in their resume. If they lied in the resume, it’s an instant no-go. And if their resume is on your desk already, that means that their skill set covers most of the requirements for this position already. Simple enough.
Well, hold on. I see a resume that says "Worked on a complex ML problem, training a model that did blah-and-blah". Sounds great, right? Then when you poke further you find out the person just took an online class that involved git cloning a repo and running scikit-learn on some toy examples without even understanding any of it.
This might be too cynical ... but those that engage in resume inflation and all the other games get the interviews and get the jobs and become the interviewer. Thus git cloning a repo and running scikit-learn on some toy examples without even understanding any of it == Worked on a complex ML problem.
As for the CV that says took an online class that involved git cloning a repo and running scikit-learn on some toy examples is a CV you should discard as they probably just went for a cup of coffee and looked at the clouds for an hour.
Maybe by presenting your education and past experiences by discussing the design and interpersonal challenges you worked through?
IMO quizzing someone on whether they can solve an artificially tricky algorithm problem on the spot does not correlate very strongly the actual day-to-day work we do as software engineers. At best it's a measure of... whether someone can solve a tricky algorithm problem on the spot. It looks like engineering but it's not really what we do.
1. Many (most) engineers are not in positions to be able to meaningfully contribute to OSS (e.g. all the code I write for work is proprietary).
2. It can easily be faked.
3. Personal projects can sometimes be interesting, but often don't showcase usefulness (unless front-end).
4. Many high quality engineers don't like to spend their free time doing more of their job.
Some repos, of course, are more impactful though. And I would probably say that if you are someone who loves to write code 16 hours a day, more power to you, you deserve to be hired! But many quality engineers would get missed if that is the desired bar (which is fine - other companies will just scoop them up).
(edit: OSS engineers extra upset by what I'm saying, but there is a lot more to this world than just what shows up in your GitHub feed)
I've been an interviewer at Netflix and Amazon and both of these feel pretty spot on in the guide.
Not sure if it's still this way, but at Netflix the hiring manager was the only decision-maker. They took in all the feedback from the other interviewers and usually went with the majority, but they had the ultimate choice. You could say they had the Freedom to hire anyone they want and the Responsibility to deal with the consequences of that.
And yes, at Netflix we pretty much all just made up our interviews as we wanted to, although after I while I zeroed in on questions that would give me the best go/no go data and would repeat them often.
And at Amazon, what they say here is very accurate -- the bar raiser is the key person to impress. They and the HM have ultimate say on the results.
Not quite true. The Bar Raiser's job is to ensure the hiring decision is data-driven, bias-free, and is a good hire for Amazon - not just the team (this does create some tension between hiring manager and bar raiser).
I've been on plenty of loops where the bar raiser had a bad experience with the candidate, but the rest of the loop had good data and the candidate was hired.
I've succeeded with interviews looking for three things:
* Find a candidate who takes apart with ease a couple of rather rudimentary programming problems. NOTHING crazy. Something practical and easy to understand the purpose of.
* Look for passion in technology and coding. Ask them what they would learn or do if they didn't have to work for a year.
* Look for rapid upward trajectory (potential). Someone doing the same thing for 5 years, meh. Someone going from data entry to automating a gnarly task with Go in a year - give me a ticket on that rocket ship.
I'm not sure what to think of the whole guide when there is blatantly wrong information about the basics of the interview process for some companies (for example, Amazon does NOT have a team-dependent hiring process)...
Definitely agree with unethical, although net negative seems a lot harder to quantify. Amazon has a lot of bad practices I disagree with, but are they net negative? I find it difficult to assess. And even if they aren't net negative now, is the 10 year trajectory clearly downward?
Soloing out Netflix, is there anything particularly wrong with them? I have significant gripes with all the others but no specifics about Netflix.
Grinding leetcode for a month or two to get a 400k+ TC is definitely worth the effort up front. It's probably the easiest way to earn that much money short of going to medical school or getting your JD.
>> All of the FAANGs are various levels of unethical, or a net negative for society in my estimation. No more interviewing there for me.
Feel the same way, until you realize you've cut out half the jobs in the process. Also, wait till you see how much it sucks when loser startups offer you 90kbase + XYZ illiquid options.
You and tens of thousands of other smart people who could be doing something other than maximizing attention and shilling trash products. Good luck undoing 3.5MM of damage with social work.
I mean stick with math for everything. Value of a human life is ~10M [1] so it's pretty easy to undo 3.5M of damage if you spend decades helping people.
Doesn't the depend on where you live and how old you are?
In my part of the US, you can live like a king on $200k/yr and such jobs aren't rare. You can live better than 90% of the people here on $100k, and putting 100k/yr away for retirement is genuinely more than enough unless you're in your 40s or so.
But I know there are other parts of the US where what you say is 100% true.
In the Bay/Seattle/NYC, 200k is new grad range for most FAANGs. If the parent commenter does well, they can easily hit the 350k within a few years of work.
If they job hop and optimize, 500k+ is attainable at Senior(L5/L6 at AMZN). That will cut down your retirement estimates heavily especially if you're willing to relocate to LCOL down the line.
Is the company you are working for using any of the cloud providers? Are you using computers built by low wage workers? Do you use Amazon? Google? Microsoft?
Or does it make you feel better that you aren’t working for them directly?
Yeah, of course I use them. It’s practically impossible to use the internet without them. No ethical consumption and all.
It makes me feel better that I am not directly working for them in the same way that putting plastic in my recycling bin makes me feel better about having no choice but to have plastic waste follow me around everywhere.
edit) have you tried eating food without having plastic involved?
I find it difficult to take people seriously who continuously clutch their pearls about the evil of BigTech yet and still benefit from it.
I bet you dollars to donuts that you’re making a higher than median wage working in tech instead of being a teacher, working at a non profit etc.
The tech industry is a net negative on society. Yet it’s a net positive for you. It’s the other people that it hurts.
> in the same way that putting plastic in my recycling bin makes me feel better about having no choice but to have plastic waste follow me around everywhere.
I bet most Mormons use very little plastic when they eat - they have the courage of their convictions.
I hate to break it to you. But most things you separate for recycling isn’t actually recycled.
I am the same person when a FAANG hired me as I was 15 years prior when I first interviewed there (I also interviewed a bunch of times in between, for successively more senior roles and did better in the process each time.)
When I was young, I had some fixed mindset - I am either good enough or not. They will either see that I am good or they won't. Nowadays, it's obvious to me that it's my responsibility to make it easy for them to see that I am good. That's what practice is - it's you working on your ability to articulate your fit for the role. That could be your ability to solve problems at the whiteboard, honing your career story, etc - the point is that if you ultimately don't have something to offer, no amount of practice will help - but if you have the potential but don't know how to let it show, you won't get the job either.