A Senior Engineer’s Guide to FAANG Interviews
interviewing.io
interviewing.io
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.
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.
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.
What are you doing applying there with 15 years of experience? Are you looking to retire already?
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.
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.
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.
Feeling insulted by logic really takes the cake for a computer scientist.
Settling for a cushy job where you don't have to care and can focus on your family, yes, that's what FAANG is for. That's what I meant by retirement.
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.
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.
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.
> At least Google is backtracking from it.
Interesting, I didn't know that. How do they hire people nowadays?
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
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.
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.
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.
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?
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.
- 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.
Does that help?
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.
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.
I'll be around to answer questions, and I'll tag in Kevin, the author, as well (I just edited it).
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.
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.
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)
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.
With leetcode interviews there seem to be very little correlation.
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
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.
Being able to interview and get good offers helps your story. Even if your story ends up using those offers as leverage elsewhere.
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.
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.
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).
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.
I should feel bad for giving this advice, but fuck these bloated mega-rich companies if they refuse to get their shit together.
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.
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.
I've had Canadian coworkers at multiple companies where Senior Engineers made 200k+
TL;DR don't throw out a basket of companies because you think they're the same
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.
Companies operate on more than just code monkeys.
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.
Most of the semi-successful companies don't need to be "the innovation machine".
Im not victim blaming by saying you may just be applying to the wrong places, am I
OTOH, when you are hiring for leaders (directors and above), past experiences and behavior questions are all you talking about.
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 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.
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).
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.
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).
I think you substantially over-estimate the eagerness of software developers to take on unrewarding admin work.
Why do you assume it can only be un-rewarding?
If hiring is so important, maybe it's worth paying the best people extra to get it done correctly.
If it's not that important, it'd be nice if they'd stop pretending like it is.
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.
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.
Resume inflation is a big thing.
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.
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.
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.
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.
We're talking fizzbuzz-level verification, I'd say about 50% of applicants that I interview can't do fizzbuzz.
Do you want me to make it easier? how about reverse a string?
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.
> 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.
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.
But it would also provide more valuable feedback.
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)
Like I said, it would take more effort from the interviewers to dig into.
But it would also provide more valuable feedback and result in better hires.
> 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.
The cost of a false positive is 0 - they always hire the non optimum candidate there is a massive margin of error.
We all like to pretend that without our unique special skills the entire company would dissapear overnight, but it is a fantasy.
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.
If the candidate is lying, just move on to the next.
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.
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.
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 it helps my anxiety immensely.
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.
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.
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.
* 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.
is FANG still hiring? or are they generally in hiring freeze?
Soloing out Netflix, is there anything particularly wrong with them? I have significant gripes with all the others but no specifics about Netflix.
I think so, yes. It's been that way for a good while.
[1]: https://www.npr.org/2020/04/23/843310123/how-government-agen...
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.
I just mean that you need far higher incomes than 350K for 10 years (gross) to be able to stop working entirely
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.
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.
Or does it make you feel better that you aren’t working for them directly?
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 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.