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.
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.
> 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.
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
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.
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.
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).
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.
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".
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.
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.
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
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.
>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'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.
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)...
[+] [-] xyzelement|2 years ago|reply
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.
[+] [-] kodah|2 years ago|reply
[+] [-] codr7|2 years ago|reply
[+] [-] chris11|2 years ago|reply
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.
[+] [-] mgaunard|2 years ago|reply
What are you doing applying there with 15 years of experience? Are you looking to retire already?
[+] [-] HumblyTossed|2 years ago|reply
[+] [-] yodsanklai|2 years ago|reply
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.
[+] [-] hebleb|2 years ago|reply
[+] [-] leeny|2 years ago|reply
I'll be around to answer questions, and I'll tag in Kevin, the author, as well (I just edited it).
[+] [-] brian-armstrong|2 years ago|reply
[+] [-] fatnoah|2 years ago|reply
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.
[+] [-] shagie|2 years ago|reply
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.
[+] [-] snakewatching|2 years ago|reply
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)
[+] [-] dennis_jeeves1|2 years ago|reply
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
[+] [-] jasonpeacock|2 years ago|reply
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.
[+] [-] Sohcahtoa82|2 years ago|reply
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.
[+] [-] claudiulodro|2 years ago|reply
[+] [-] ldjkfkdsjnv|2 years ago|reply
[+] [-] VirusNewbie|2 years ago|reply
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.
[+] [-] xyzelement|2 years ago|reply
Being able to interview and get good offers helps your story. Even if your story ends up using those offers as leverage elsewhere.
[+] [-] actualwill|2 years ago|reply
[+] [-] weeznerps|2 years ago|reply
[+] [-] thomaslangston|2 years ago|reply
[+] [-] rel2thr|2 years ago|reply
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.
[+] [-] 0xbadcafebee|2 years ago|reply
I should feel bad for giving this advice, but fuck these bloated mega-rich companies if they refuse to get their shit together.
[+] [-] michaelt|2 years ago|reply
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.
[+] [-] Yujf|2 years ago|reply
[+] [-] zug_zug|2 years ago|reply
[+] [-] whoknew1122|2 years ago|reply
Companies operate on more than just code monkeys.
[+] [-] 120bits|2 years ago|reply
[+] [-] dudus|2 years ago|reply
[+] [-] codr7|2 years ago|reply
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.
[+] [-] onlyrealcuzzo|2 years ago|reply
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).
[+] [-] kerblang|2 years ago|reply
[+] [-] CamperBob2|2 years ago|reply
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.
[+] [-] superfrank|2 years ago|reply
> 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.
[+] [-] liuliu|2 years ago|reply
Most of the semi-successful companies don't need to be "the innovation machine".
[+] [-] em500|2 years ago|reply
[+] [-] kulikalov|2 years ago|reply
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.
[+] [-] TheBigSalad|2 years ago|reply
[+] [-] lionkor|2 years ago|reply
Im not victim blaming by saying you may just be applying to the wrong places, am I
[+] [-] ulfw|2 years ago|reply
[+] [-] nomel|2 years ago|reply
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.
[+] [-] dennis_jeeves1|2 years ago|reply
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.
[+] [-] jedberg|2 years ago|reply
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.
[+] [-] papito|2 years ago|reply
* 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.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] Nales|2 years ago|reply
[+] [-] zht|2 years ago|reply
is FANG still hiring? or are they generally in hiring freeze?
[+] [-] iLoveOncall|2 years ago|reply