Facebook senior software engineer interview | Hacker News Reader

Facebook senior software engineer interview

daqo.medium.com

432 pointshpux504 comments

There are two interesting things in this post.

The first is that a senior developer at Facebook believes every single senior developer looking for a role at Facebook can revise the same things. Clearly the author believes that Facebook are looking for programmers who fit a very specific mould, to the point that they're willing to go out in public and state exactly that. I'd argue that points to a massive monoculture problem at Facebook, but I'm massively anti-Facebook so I'm biased.

Secondly, the author believes that senior developers, who likely have 10+ years under their belt if they're senior, need to spend a solid month revising in order to be successful landing a role there. Maybe that's worthwhile as FB pay well, but that's a hell of a time investment if you're not planning to stay at FB for a long time. That would certainly make me think twice if I was going to apply.

On your second point, that's the reality for many established tech companies. I know many solid senior engineers that can't pass the entrance bar to FANG. That doesn't mean that they are "bad" engineers. Overall I think you can replace Facebook with Google/Apple/Microsoft/Netflix/... in the blog post and the end result would be the same.

These days I honestly think that a developer who is marginally above average but plays well as part of the team is much more valuable than someone super smart who isn't a team player. We rarely need to solve complex algorithmic problems these days, just plug some components together and work out why they aren't working.

I have not seen any interview problems where you have to debug an issue having limited information as often is the case in embedded systems. You have a set of logs and the source code to look at. The description of the problem is "X doesn't work" where X is some protocol or procedure. This is something that took me a lot of time to become good at (to not freak out, but to be systematic).

I saw it once, I think it might have been in an interview with Scale API?

I worked at a company, not a FANG, but had interviews like a FANG. We had a solid team. But some of us believed we wouldn't be able to pass our own interviews.

I think there's a natural desire to want to hire people who are better than you are. Sprinkle in a little dunning kruger effect and I can see how a good team can end up feeling like that.

isn't this what's happening at FANG companies: the gatekeepers (i.e. people giving interviews) have an incentive to not let people in too easily? This limits the pool of employees, and since what's rare is expensive, makes insiders more valuable?

Also at FANG companies, interviewing feels (to me) like hazing that is unrelated to what the day-to-day job will be like. Some interviewers I had obviously had a very high opinion of themselves..

Our incentive is not (as you imply) a selfish desire to enrich ourselves though artificial scarcity, but rather the knowledge that a weak team member hurts everyone and is hard to get rid of. At my firm we have the explicit goal of hiring people who are better than half the developers at similar level. A little math will show you that if you do not do this, your average talent level goes down over time.

Oh I wasn't thinking of selfishness in this situation (I didn't use that word, but i was thinking of how purely rational economic actors would act), merely that there is a subconscious incentive to act one way. Of course you are right, interviews serve as a filter, one wants the newcomer to increase the output of the team, not decrease it ;-)

Another issue is that hiring is expensive and FANG companies have a ton of applicants. Raising the bar on algorithmic interview performance is a straightforward way to filter applicants that is relevant to job performance. After the initial screen it's still hard to make the case to hire a smart engineer if one or two of the interviewers have concerns about their interview performance.

> I'd argue that points to a massive monoculture problem at Facebook, but I'm massively anti-Facebook so I'm biased.

I'm pretty sure that's the point. Massive enterprises like Facebook have no need for creative "outside the box" thinking anymore. They need dependable, solid developers with a standardized skillset that they can plug into a position like lego blocks, easily replaced whenever they burnout or stop toeing the corporate line.

I kind of agree with your cynicism, but I'm partial due to having been refused by Facebook, twice.

The first time I made the mistake of using Python (because of its whiteboard value) while not being proficient in it. They really didn't like me Googling some basic stuff.

The second time I still used Python, but had 5 years experience using it behind. Can't be objective but it was probably the best interview I've ever done. Reviewed my code afterwards, and could only come up with minor improvements. Got refused, I asked what could I improve and I got a very generic "not a good match for the team" which, in retrospect, reading your comment, could have been very accurate.

Coding a good solution is necessary but not sufficient to pass an interview. Maybe you asked too many questions or not enough, maybe you solved the problem too slowly. Interviewers for better or worse look for specific signals that clue them into your being a good coworker. It's why even if you're a good programmer you may need to apply multiple times before the right set of interviewers grant you admission into their club.

> It's why even if you're a good programmer you may need to apply multiple times before the right set of interviewers grant you admission into their club.

That would imply to me that their interview process is fundamentally broken.

It could also imply that they simply get more good applications than they need. Everyone and their grandma seems to want to work for Big N, after all.

There is this weird meme that using Python is beneficial during interviewing -- you mention it, the OP mentions it, I have experienced it myself and seen friends mention it.

I don't know how or why this meme infects people; in my interview experience (MSFT, Google, Oracle, FB, Amazon, other smaller places) nobody ever batted an eyelid on me using C#. My advice would be to only use a language you know best, as long as it's appropriate for the role -- and most mainstream languages would be appropriate for generic FAANG SDE roles.

Using the language you know best will bring all sort of benefits -- you'll code faster, you'll be more confident, you might even find a place to show off a little. There is no good reason to give this advantage up.

Python is beneficial in that everyone understands or can learn to understand basic Python in the time it takes to do an interview.

However, due to the whiteboard and performance focused aspect of the typical coding interview, Python is actually kinda an awful language to interview with. Plus, if you want to be terse with Python (whiteboard space is limited after all), it quickly becomes alphabet soup.

If I had to describe the perfect interviewing language, it'd be something with C/Java-like syntax, but without the cruft, that can optionally be typed, with easy fine grain control over looping. All the big-tech companies work with way too much Java, but Java is way too verbose for coding by hand. C# is about as close to Java as they come. Scala/Kotlin is excellent if you write it like Java.

O(n) is O(n) in any language. And how does Python become alphabet soup?

This, absolutely this! I did a lot of interviews (as interviewer) at a non-fang-but-close-enough, the guideline was to tell interviewees to pick the language they most prefer. Even if we didn't know it, the valuable part was the problem solving, and the candidate could display good communication skills by explaining the language features you were not familiar with. This is much better than picking a language that you don't know (happened several times that someone picked python, and when asked to write a class said "I know how to write classes in java". We switched to java, no problem.)

It took me 1 second to think that Python has divmod built-in whereas you must import Math in C# to use DivRem. It's just little things like that - as well as boilerplate - that really makes a difference in these interviews. How many of these interviews resulted in a job offer? I disagree with eyelid-batting being the new success metric.

I feel that you think of the interviews as if they were a competitive programming contest.

If I needed a DivRem function I'd just write it in, `import Math` optional. In fact I probably wouldn't remember the exact name of the function and would've just 'created' a new one: `Tuple<int, int> DivideWithRemainder(int dividend, int divisor)`. You can just write signatures for functions like that on a separate side of the whiteboard and invite your interviewer to tell you if they want to see any of them implemented.

I would advice this as a general approach -- split things into (reasonable) parts and implement them in order of importance. In one interview (Amazon) I ended up implementing every small thing I parceled out. In others my interviewers seemed to appreciate that we both care a lot about the `solution flow` and the `technically hard` parts and not at all about `DivideWithRemainder` or `import Math`.

I got offers from most of the places that I interviewed at.

Can fail behavioral or design interviews while passing coding and not get hired. Can also have written what you thought was good code but have been given too many hints. Or, could have written good code to the question asked, but took so long that interviewer didn't get to a second question and you wouldn't ever know that.

>plug into a position like lego blocks

Every time I hear someone from big tech talk about being a "L"-something (or in this blog they're "E" levels), I wonder if they know they sound exactly like the bureaucracy talk of the US Federal Government employees and their "GS" "E" or "O" levels.

For better or worse, when you get to a certain size you absolutely NEED that level of bureaucracy. You can't get 120,000 full time employees plus probably another 100,000 contractors to work together without establishing a clear hierarchy that everyone inside it understands. A smaller company can have different approaches because they will have a dense network of employee relationships, and can work together off of those relationships. However, at six figure employee scale by necessity you will end up with a very very sparse matrix of employee relationships, so you have to have something else to get results.

A lot of really big companies have super flat hierarchies when I worked at one we had MPG2, MPG4 then Senior Management U,T,S

Promotion was brutal you might have 20 MPG4 slots every 18 Months for the entire Division (60k FTE) - just getting to the Board Stage was tough enough.

I think a MPG2 was equivalent to a Captain an S was a Grade 7 (GS15 in US terms I think) Full Colonel

You just proved the GP's point. Whether the hierarchy is flat or not is irrelevant, they still have the bureaucracy around leveling and authority/responsibility.

I also think FB, contrary to many other massive enterprises, suffers extra much from this bcs it doesn't even make sense as a massive enterprise. It's a social network platform and when it grew too large it mutated into something that in its worst days looks like a scene out of 1984. Hence Lego recruits are needed not just bcs its massive but because they shouldn't be asking the difficult questions.

You can't be more far away from the truth.

Thinking outside of the box is very much encouraged and more senior engineers are expected to come up or shape, lead and deliver projects.

FB is company where individual engineers could go and do any project they want - they can even invent it - if they believe that it will deliver big enough impact. After 1 year at FB you can switch team any time you like and your manager does not even need to know what you are working on (it's probably better if they know, as they could many times help you, but no one is micro managing you).

You are assessed every 6 months based on impact you deliver. Your manager supports you, but you need to drive it and deliver it.

Tooling/languages are standardised, but FB does not care whether you do know Hack, or JS. You can do interview in any language (if you are going for generic engineering role). So far at FB I have coded in 4 different languages and picked up all of them as I joined teams.

Even though FB is enterprise company, it feels like startup with great salary, benefits and more manageable work-life balance. Before FB I was 7 years in startups and I have worked longer hours, got paid much less and wasted more time.

I couldn't disagree more with your post. The author is basically just putting out a detailed study plan for passing an exam. If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!" That seems like a ridiculous stretch in my opinion.

To your second point, I hear this all the time in threads about tech interviewing: "Tech interviews are biased and make no sense" and also "I'm too busy to have to do a lot of work for this interview." If you don't want to put the time in to prepare, fine, don't, and then see how you do. Again, in my mind it's very similar to studying for the medical boards - in most cases doctors have many, many thousands of hours under their belt in training before still needing to study a ton to pass their boards.

>in most cases doctors have many, many thousands of hours under their belt in training before still needing to study a ton to pass their boards

The difference is that what the doctors put so much time into learning can actually be quite useful for their job. The vast majority of competitive coding stuff isn't. Interview procedures based around it completely fail to assess some of the most important abilities in software engineering, like API design. As anyone who's ever used any of Google's open source libraries would have noticed, hiring people who do well at competitive coding problems is no guarantee they'll be able to produce decent software.

> The difference is that what the doctors put so much time into learning can actually be quite useful for their job.

I'd be curious to hear what a doctor would think about that. My intuition would be that, as for almost any exam, a lot of time is spent on things that will not be useful for any other purpose than the exam itself.

Even if it isn't, do doctors have to retake these exams multiple times (as developers have to do this for multiple interviews) every two years when wanting to switch jobs (doctors often don't have to switch jobs, they often have their own practice).

In somewhat of a parallel, you don’t have to switch jobs either, you can start your own software company at any time ;)

I've tried doing freelance before, and I was a terrible marketer for myself. While that's definitely an option for people in this industry, I'm not sure it's a great path for me.

Same with medicine. Although under-served markets are common you still have to market yourself in private practice. New specialists advertise to GPs to get referrals for example.

They also have to go to school for 10 years before they’re even allowed in the job market.

I’ll take our sometimes silly interview processes over that.

>They also have to go to school for 10 years before they’re even allowed in the job market.

Not to mention that during that time they are accruing loans in insane amounts (we are talking about $200-300k) and get worked in insane shifts (24-36 hour shifts are not unheard of during residency rotations).

Oh, and they don't get paid at all until they start residency rotations which is AFTER 4 years of med school, and their pay during residency is on the order of $30k-50k for what effectively amounts to 80-100 hours a week. Mind you, that's on top of the fact that in the US, you only enter a med school after you already got a college degree. So you enter a med school at the age of 23.

I have respect for the doctors, but I definitely do not envy their position. Their real work doesn't even start until their 30s, at which point they are already really deep in student loan debt. Of course it is manageable, since they get paid handsomely. But their work-life balance and the entire process where you start your "real work" after the age of 30 with $200-300k in loans, at that point, isn't something that a lot of people consider when they think "those doctors are having it nice."

It isn't even a second thought to me that I would much much rather study for interviews every single time i switch a job as a software engineer than deal with what doctors deal. And that's not even mentioning that studying for a typical software dev interview is absolutely nothing compared to the studying that med school students have to do in order to pass their board exams.

If there were poor doctors who had to drive for Uber eats after hours we would be hearing about it

I am not saying that doctors in the US are poor, quite the opposite.

They are, however, very poor (and in tons of debt) until they actually become a full doctor (which is typically in their early 30s, after they are done with med school, residency, and board exams) and extremely overworked (which still holds true for most of them even after becoming "real" doctors).

You don't hear about "poor doctors", because during the decade in which they are poor they are counted as "students" by most people, and poor students isn't exactly something surprising or eyebrow-raising for most people. It's just the magnitude of that poorness and overworking is completely invisible to most people who don't have someone in their friend group or family who just recently became a doctor.

Is that true? I don’t know anything about medical licensing, but after having a few friends take the California bar exam, I’ve heard endless complaints about having to study things like divorce law in order to become a privacy advocate.

Law might be different. An anecdote my Dad (Lawyer) used to tell me.

> I went to school to learn the law. After school I had to teach myself how to be a lawyer.

Yes, the bar exam requires you to learn much law you'll never use. They are a general test that covers all areas of the law.

Boards are for specific specialties. You don't take a board to be a doctor, you take a board to be a podiatrist, etc.

Personally, I think both exams are about protectionism more than anything else.

Source: have taken a bar exam, have a wife that's a doctor.

It's the same in land surveying with the LPS licensing exams.

I agree with your comment. My wife took USMLE exams (all three steps) and she would complain to me that most of the stuff she memorize there, she'd forget them in a year or so (and eventually resort to Google and/or https://www.uptodate.com/home to refresh/review). :)

But in the case f doctors and lawyers, they pass it once, not every time they interview for a new job. Software doesn’t have licensing, so we do this bullshit every single time.

We would still do it if there was licensing. Doctors and lawyers still interview for jobs.

> We would still do it if there was licensing. Doctors and lawyers still interview for jobs.

People interview in most jobs, but people in licensed professions don’t generally have exams testing minimal professional competency in interviews because assurance of minimal professional competency is delegated to the appropriate professional licensing body, which implements entry exams, continuing education requirements, professional complaint/discipline processes, etc.

Minimal competency screening is abstracted out to a reusable, memoizing, component.

Medical boards are at the specialty level, so there is no equivalent. An OB is not going to have to answer primary care questions, for example. They'll all be very specialized.

Futhermore, you actually practice for several years prior to taking your boards, at which point you submit a representative subset of your cases from actual work, and a bunch of folks toward the end of their career grill you on them, then decide if you pass.

I tend to be on your side of the fence but I have to nitpick your argument:

At these companies, algorithms and the basics are fundamentally important. Because you tend to work on tiny parts of a massive whole, there is no tolerance for cowboy-coding and not following best-practices. IMO the interviews test that you can fall in line and follow the patterns that have been in place for decades.

With regards to using API design as something that is not assessed: System design questions do test this. Also at a company like FB, there's a handful of people designing APIs that are at the top of the pyramid, and even then long-standing conventions around API design at those companies will short-circuit the need for most devs to think about how to organize and name their endpoints.

At my small startup where most of us write an API endpoint, it's important to know. For a UI dev or someone optimizing DB lookups at massive software companies, API design is not something that needs to be tested.

Personally I can admit to feeling frustrated that passing these types of interviews is not my forte. It sucks that I would have to study for weeks to not flop these interviews even though I consider myself a good software engineer. But that doesn't 100% invalidate their interview process.

That all makes sense for hiring people to work on big existing systems, but many of these large companies are also trying to innovate and build new products with smaller, more agile teams.

Sure, you’ll still need to integrate with established APIs and focus more on scalability than you would at a startup, but the kind of people who excel in each type of role will have very different personalities and skillsets. Grading them on the same curve in interviews seems like a pretty bad idea.

> That all makes sense for hiring people to work on big existing systems, but many of these large companies are also trying to innovate and build new products with smaller, more agile teams.

Which innovation of Facebook are you describing? Instagram, WhatsApp, or the stories?

Not products in the typical sense, but these are some interesting technologies coming out of Facebook that I can list off the top of my head (many of which I have used personally):

* https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...

* https://osquery.io/

* https://rocksdb.org/

* https://fbinfer.com/

* https://flow.org/

* https://prepack.io/

You just listed a lot of tools where a deep knowledge of data structures is extremely important :)

Most of these things need to be created to scale and stabilize the existing system.

I mean you listed several database libraries, static analyzers, and a code optimizer.

Is it your suggestion that those kinds of applications do not require solid knowledge of a variety of different data structures and algorithms?

> I mean you listed several database libraries, static analyzers, and a code optimizer.

Correct.

> Is it your suggestion that those kinds of applications do not require solid knowledge of a variety of different data structures and algorithms?

No -- precisely opposite.

Your response confused me quite a lot, but after some thought, I think I've realized how things have become mixed up. I took this for sarcasm:

> Which innovation of Facebook are you describing? Instagram, WhatsApp, or the stories?

Why did I take that for sarcasm? Because it is apparent to me that Instagram, WhatsApp and stories are not innovative. So I thought the main point of the poster I was replying to was to take a dig at Facebook. I didn't realize that we were in agreement about the importance of data structures and algorithms, but then I also didn't realize that we were still on that topic: my intention was purely to refute the [what I believed to be the implied] notion that nothing innovative was happening at Facebook.

Thanks for the clarification. We're in total agreement.

I listed the most innovative things that happened. They were product innovations that could have killed Facebook as a company, not RocksDB or React. At the same time I'm a software engineer, and I could write a database much easier than create something that grows faster than Facebook.

I use instagram and WhatsApp, no Facebook anymore (except messenger), as young people went there (and I'm following).

TikTok is a bit too much for me though, I think creating videos for it takes too much time, while for Instagram it's easy to take nice photos while I'm travelling.

> but the kind of people who excel in each type of role will have very different personalities and skillsets. Grading them on the same curve in interviews seems like a pretty bad idea.

I haven't interviewed for senior level positions with FANG. But aren't interviews usually different based on the job? I assume that interviews for job families like front end/backend/sre should all test different skills. And if you are interviewing with a specific team the manager can judge your background and interviews for fit with their team. The interview bar for algorithms is probably too high at some places, but those skills are relevant for all engineers.

Overall I agree with your point, I just wanted to add that my experience with small startup vs FAANG is that it was the opposite experience for me.

Small startup involved wearing many hats, but in general was a more specialized role than FAANG.

FAANG was significantly more breadth than startup (and why I’d say it’s a great experience for beginners to gain a breadth of knowledge).

I could see how some teams are very specialized in FAANG however.

> At these companies, algorithms and the basics are fundamentally important. Because you tend to work on tiny parts of a massive whole, there is no tolerance for cowboy-coding and not following best-practices. IMO the interviews test that you can fall in line and follow the patterns that have been in place for decades.

... have they gotten a lot better since 2015?

https://www.darkcoding.net/software/facebooks-code-quality-p...

My ex girlfriend is a pediatric cardiologist who recently passed her boards. When I talked to her about it, she was very much on the side that she wished she didn't have to study for it because it didn't have much to do with her job at all. She just wished she could spend her time getting better at the skills she actually used rather than a wide range of academic material that didn't matter to her day to day.

Her friends from residency thought similarly. That's just a few data points and maybe some doctors are helped, but it definitely isn't every doctor.

Similarly, I spoke to a pharmacist recently, and they said the same thing: the board exams expected the person to know information about medication that was no longer even in use.

Is it that they need to create some objective barrier to entry?

Yes. It's a way to artificially limit supply, to prop up wages for people on the inside. It's common to most "licensed" professions.

> "What the student thought was it temporary concession to the system-"I'll play along just enough so that I can get what I want from the system"-turns out to be the beginning of it forced, permanent adjustment to the system."

This is common to all professional disciplines.

https://www.amazon.com/gp/aw/d/B008GRDKPG

I've wondered about this for forever. Thank you!

> just wished she could spend her time getting better at the skills she actually used

I can so relate to this when I look back at 4 years I spent studying for a CS degree. The first year had just 3 subjects out of 17 that had something to do with CS. The rest were wildly off the mark. Like engineering drawing, metal workshop, and what not. The second year was slightly better but just. It was crammed with electronics; and only from the 4th semester did things took a definitive turn towards CS topics. I'm sure the curriculum designers had a certain plan in mind but this was devised something like ~60 years ago, when engineering meant mostly civil engineering.

This was all 20 years ago, and I recently checked the syllabus out of curiosity, and no it's not changed one bit. One precious year of learning period down the drain.

Engineering drawing is character building though.

My third daughter was delivered by the anesthesiologist, because the ObGyn was stuck in traffic and the anesthesiologist was the only doctor on the floor. Doctors don't need that stuff outside their specialty... until the day they do.

If you pulled someone off the street, odds are that that person would also be able to successfully deliver your daughter.

How much did the anesthesiologist help, above that baseline?

He made an incision that was needed for a successful delivery. I don't want a random person off the street doing that, no.

Funny how humans were somehow able to reproduce just fine for millions of years before surgical deliveries.

https://www.youtube.com/watch?v=_YruT2ROEUc

Many women died giving birth.

Oddly enough, the US has the same pregnancy mortality rate as places like Latvia, Moldova, Romania, and the Ukraine. Tied for 56th out of 186 (there are lots of ties)

> When I talked to her about it, she was very much on the side that she wished she didn't have to study for it because it didn't have much to do with her job at all.

I assume you're referring to your ex's exam to become Board Certified in her specialty, which, if you are, makes this statement incredibly hard to believe.

A specialty's Board exam is comprised of simulated cases from that specialty. Your ex wouldn't have to prep for geriatric internal medicine or stroke rehab in pm&r. Basically everything asked in the exam for board certification is related to one's specialty.

It is not a general exam like the STEP exams.

Virtually every FANG interview I’ve done has covered API design as part of system design.

My brother is currently in med school, a huge chunk of his time studying is spent on rote memorization. Their Leetcode equivalent is Anki (flash cards) which they spend hours on every day, for years. At least with Leetcode, it’s taught me to quickly recognize algorithms and implement my own when needed.

Very good point.

I completely agree that being good at designing new APIs is one of the most valuable qualities of a programmer and I have never seen a job interview or test that could check this.

It's one of the questions I ask when I interview people.

I could care less whether you remember some algorithm you could look up in Knuth. I want to know if you can put yourself in your customer's place and design an API that meets their needs.

Language design is one of the hardest skills to master, and as the qualities of a good language include maintaining backward compatibility and longevity, most people who do master it never get to apply what they learned. Instead we only get to see their practice pieces. Their almost but not quite masterpieces.

It’s why I could immediately see that XML was going to fail in the long run. Everyone is a language designer? Sure, that’s going to work out.

APIs are tiny languages, so learning to do it well is a microcosm of language design. You don’t have to be good at all parts, but if the API you need isn’t in your wheelhouse, everyone will know. And if you build enough of them you’ll discover the limits of your skill.

The content of the boards exam is actually quite comparable to the content of these interviews. They both cover general knowledge and fundamental concepts that very few working programmers or doctors will ever use, but absolutely should know.

I always wondered why every OSS software project done by / blessed by Google or FB ends up having a terrible API and developer experience (think Angular, React, Go, Tensorflow, Kubernetes), while delivering great functionality (heck, I used all of these and endured the pain for it).

I was going for people scratching their own itch during their OSS-at-work time and wanting to show off - but this could very well be a better explanation.

I don't think that a comparison to a doctor is warranted:

1) Every employer of a doctor doesn't force them to sit boards for every interview, or ask a cardiologist to know the same as an oncologist. (Sure, there is a good deal of overlap, but there is a good deal that isn't either.)

2) Doctors are a licensed profession and have specific requirements.

> If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!"

If the exam was used to determine seniority of both dermatologists and anaesthesiologists, instead of basic competency heck entering the field, it would indicate a problem.

The OP doesn't say it's for all technical roles at Facebook, it mentions one specific job title.

Senior software engineer is specific?

Yes! When a Senior SWE gets promoted the next title is Staff SWE. See also E5 and E6 at http://levels.fyi.

A level is a rank. Not a specialty.

Ah, I see, exactly the way an plastic surgeon gets promoted to pediatrician.

> The author is basically just putting out a detailed study plan for passing an exam.

My issue is that someone at a senior level (yes I realize at some of these companies "senior" means "two years of experience") should have to study for 30 days to pass an interview. It should not require the equivalent of preparing for an advanced CS course final exam to evaluate the abilities of someone who has presumably been in the industry for many years.

Agreed, just because you're a senior engineer with decades of experience doesn't mean you shouldn't brush up on general fundamentals every once in a while. Leetcode, while being pretty useless in the real world, does get your brain into "answer hard questions under pressure" mode. Systems design questions prompt you to architect things which may be considerably different than you deal with during your day-to-day.

Preparing for an interview, for more senior developers, is mostly mental - even if you know the information required, can you retrieve it quickly? Do you get flustered under time pressure? Are you in hour 4 and getting tired/sloppy? A bit of studying can help make some answers automatic, and help you present your best self.

The interview pressures and the job pressures are completely different.

A better comparison is getting into Harvard. Do you really want to go to a school where getting in is a matter of acing a prescriptive test? There's a reason college applications value experience and diversity.

Yea, to keep the Jews out.

https://www.businessinsider.com/the-ivy-leagues-history-of-d...

This hasn't been the case for decades. Go look up how many Jews are in the Ivy Leagues now.

Yes, now it's used to weed out the Asians.

I can't speak for Harvard, but in the vast majority of the world, going to college is strictly on the basis of entrance exams, with some countries also using high school grades, nothing more.

This is done to avoid bias and/or favoritism. I am not an expert in U.S. admissions but my understanding is that they give points for things like whether your parents are alumni or have donated, whether you play sports, whether you were school "president" or other tests of popularity, and a host of things that in my opinion are pretty poor indicators of whether one should be admitted.

High stakes entry-exams have their own problems. Among many other issues, they measure peak performance, rather than sustained performance.

US college admissions have many problems, so don't hear me say they don't need reform, but you are also assuming that academics are the sole thing that college is about. It isn't, at least not in the US. US schools value many things beyond pure academics. Among them being leadership (whether or not you were class president is one such indicator), personal initiative, success against the odds and many other things.

"[T]hey measure peak performance, rather than sustained performance."

I never saw it expressed so succinctly. Excellent!

It captures well the frustration around tech interviews. You might be a very competent worker (sustained performance), but fail miserably during interviews (peak performance). Ideally, you could show a body of work during your interview, but this isn't possible with most commercial software companies. If you are lucky to work on open source for your job, it is easy to show your work.

To manufacture a public body of work for myself, I built two open source projects and published them on GitHub. (Please do not read that as advice!) I can share and discuss them during interviews.

The US Medical Licensing Examination is mainly for medical students not "senior" physicians, and the pass rate is extremely high for U.S. M.D. medical school graduates, over 90%. https://en.wikipedia.org/wiki/United_States_Medical_Licensin...

In other words, it's not a standard job interview technique for doctors, it's a one-time requirement for licensing.

The other difference of course is that doctors are legally permitted to open up your guts with a knife, unlike Facebook engineers.

There are specialty board exams that you take once you're done with residency. Some are written exams. Surgical specialties do oral board exams where they present cases to you and question you on management. Pass rates for those are not as high. Many specialty boards make you take recertification exams every x number of years.

But again, these are not job interviews, they're professional licensing requirement imposed by the government, not by employers. And I don't think Facebook requires its engineers to re-interview for their own jobs every x number of years, so that's disanalogous too.

Ironically, the last thing that Facebook engineers want is for the government to regulate them. Just wait until they face the professional ethics boards. ;-) When has a programmer ever been kicked out of the industry for unethical behavior? More likely, they get promoted.

Doctors don't need to pass the medical boards for every job they apply to. I don't see how there's even a comparison there.

They do need to retake their boards periodically to stay certified. My surgeon father was pulling out his textbooks periodically into his 60s.

If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!" That seems like a ridiculous stretch in my opinion.

It's more like an oncologist posting that every doctor needs to revise cancer treatments for a month before applying for a role in a hospital without realising that other doctors have spent 10 years specialising in different areas of medicine, and then the hospital being amazing at treating cancer but wondering why they're absolutely terrible at mending broken arms.

In this analogy cancer is advertising, and broken arms is privacy.

this is off topic, but medical training (at least in the US) is unfortunately about as dysfunctional as you describe.

there's are years of inefficient labor from students, residents, fellows, and junior doctors on procedures they'll never do again (because they relatively cheap)

I’m not sure exactly what you’re describing but sounds like they could be getting practical experience? Like a junior dev doing some scripting grunt work that no one else wanted to do but they are gaining other skills along the way possibly?

But at least when you're 10 years into your career you aren't judged based on your boards any longer

You do need to take them every so often to stay certified. This cartel isn’t for slackers, come now. (I jest - half my family is in the medical business. I studied economics for a while)

First of all, I'm not sure where this "10 years" is coming from. I know many/most "senior" developers who reached that level long before 10 years out of university.

Secondly, programming doesn't have a standard licensure process like medicine. If it did, I think a lot of these kinds of interviews that companies do would not be necessary. But as it stands I've interviewed many engineers with years of experience who couldn't competently program, and I'm talking about maybe a tad above FizzBuzz level proficiency.

> First of all, I'm not sure where this "10 years" is coming from. I know many/most "senior" developers who reached that level long before 10 years out of university.

That's because it's a near-meaningless title that has been watered down. Everyone is a "senior" now by their second year working.

It really depends on the place and nearly always applies only to experience specifically in the exact role you are in.

I have 15yrs experience and moved sideways a few times and I am in effect treated as if I were new in my current role.

So senior doesn't so much translate to experience or even transferable working knowledge but rather 'how well you have done politically to gain position in this specific company'. Yes I am cynical :)

As of 2-4 years ago, the number of programmers working in the industry was doubling every 5 years. That might not seem relevant until you realize that it means half of all programmers have less than 5 years experience. If you have 10 years in the industry, you're more senior than 75% of your co-workers.

That's why anyone with 5 years on the job is considered "senior", even though most in most professions you're just getting out of the entry level after 5 years.

The most frustrating thing about this post for me isn't the "10 years" issue, but rather this:

Most of these companies have solid internship programs, and almost all E3 (entry-level) positions are offered to returning interns.

What this means is that there's no track into a junior position where you can gain experience and work your way up to senior within a FAANG if you're older than a recent college grad. That's unfortunate, because as someone working for a mid-tier company I'd like to work hard and land a senior role at a FAANG but I often wonder if these companies would look down on candidates who have spent years at lesser companies.

But as it stands I've interviewed many engineers with years of experience who couldn't competently program, and I'm talking about maybe a tad above FizzBuzz level proficiency.

I've interviewed close to 400 developers over the past couple of decades, and I've not met many who can't code. Some are great, and some are clearly at the bottom end of the distribution, but most are just OK. They can get the job done, they can do good work given a good team to lean on, but they're not force multipliers or anything special. My experience is what you might expect given an normal distribution of skill levels.

If you've come away from lots of technical interviews thinking the candidate can't code I reckon it's more likely due to you. Perhaps you can't put a candidate at ease and find areas where they can talk about their ability in a positive way. That seems more likely than "many engineers with years of experience who couldn't competently program". I guess it's also possible that you simply work somewhere that good candidates don't bother applying to though. Either way, I don't think your experience aligns at all with mine.

I am not sure whether you have an incredibly good filtering system or have got incredibly lucky.

I have interviewed similar numbers and have been repeatedly complimented on my ability to put people at ease, but have encountered exactly what the grandparent comment says. It really opened my eyes seeing so many with many years on their CV but struggling with (literal) fizzbuzz.

This experience accords with most I have read about online (starting with the semi-famous coding horror article [0]). It is your experience that differs from the norm, honestly.

[0]:https://blog.codinghorror.com/why-cant-programmers-program/

Same here.

I've only been on the interviewer side a few times (roughly 10), but even then I've run into 2 candidates that couldn't code.

If interviewers are screening candidates for certain attributes (regardless of how well those attributes map to being good at the job) you should expect most candidates to lack those attributes. Candidates who have them get hired after a few interviews, candidates who don't have to do many more interviews to find a job (or get discouraged).

It really is about interviewing skills. I noticed a strong trend over time that the people I interviewed kept doing better. You need to engage with people without letting things get confrontational.

The best advice I can give is look at how entertainers get random audience members to relax and engage in front of huge audiences. Many people lock up in such situations and can barely say their own name, yet with the right approach it’s a non issue.

Compare that to the rapid fire technical questions I have watched people get into and it’s obvious what’s going on. Someone fumbles something and then gets flustered and shuts down. But, pepper the exact same questions into a larger conversation, perhaps going so far as to occasionally complement them, and shockingly they do better on the exact same problems.

> and have been repeatedly complimented on my ability to put people at ease

You calling them a liar eh?

No, I am saying putting someone at ease is only half of it you need to keep them at ease. The standard script I see people use is basically some warmup conversation where everything seems fine, followed by a grilling.

Conducting a full interview “without letting things get confrontational” is difficult. However, unless the job actually requires intense face to face confrontation you want to know how well they can do the job, not how well they can interview for it.

No you're assuming that this is what happened because it contradicts your assertion. Your opinion flies in the face of my extensive experience and that of the majority of people, you may want to start considering whether it is you who is mistaken.

I don't think a candidate who I put at ease then absolutely hammered would compliment me on putting them at ease would they? Or does your theory stretch to them somehow having short-term memory loss?

When in the face of empirical evidence I adjusted my world view from close to yours to where I am now. Based on your other comment you’ve having people do fuzzbizz, simply split things into two samples and see which they do better with. Interactive face to face help, or an open IDE they can run code on uninterrupted.

If the second group preformed better then presumably the testing methodology played a role with a higher percentage of people being able to actually program than your suggesting.

Granted it takes a lot of interviews to build a reasonable sample, but we aren’t talking about 1% better performance here.

>Interactive face to face help, or an open IDE they can run code on uninterrupted.

I've tried both. I've tried leaving them to it entirely, I've tried leaving them to it then if they get stuck helping both from a lesser to a greater degree.

It really makes no difference - the bad coders struggle on that and other problems, they just lack the ability to think through the problem.

And again I've seen enough anxious candidates to see the difference. I'm pretty good at gauging things well as to how and when to help.

Overall I'm not hearing many specifics more 'I am great at interviewing'.

The empirical evidence is overwhelmingly that there are many bad programmers out there with long CVs. That's also my experience WITHIN companies, though a lesser proportion.

Fair enough, I can accept it could be a difference in candidate pools or something. That said, I personally saw a bump from about 40% to 90% using different methods for what it’s worth.

In terms of a test I use mean, median, mode, and range for an array. Then go into basic performance trade offs.

You're just making assumptions again.

I have witnessed a huge range of anxiety levels from candidates and when you get used to interviewing it is pretty clear what comes down to anxiety and what comes down to simply not being able to program.

When a candidate struggles, I gently lead them and help move things along in a very collaborative way - I am also very tolerant of mistakes or poor starts and proactively give every opportunity for those to be discounted.

If somebody, after 10 hints as to the ordering of the if/else if/else of fizzbuzz, still cannot figure it out when you have held their hand for 30 minutes that's not because you lack interview skill.

Interviewing is inevitably vastly imperfect and many aspects that are not relevant to the job will play a role (for example - time constraints dictate that you must ask small questions that are sufficiently challenging that might not always be entirely representative of the job) - nobody who is honest could claim otherwise, but that is the nature of the task - it has to be an approximation - and you have to asssess actual ability to code and do the job.

Handholding doesn’t solve the problem of someone second guessing themselves, and can make this much much worse. Outside of pair programming it’s normally a solitary activity where people get plenty of time to reflect. Interjecting in the middle of this is again very different from a work environment.

Most people are really terrible at interviewing. And why are we surprised? It's not a skill many cultivate.

I'm sure many people from Facebook switched from the advertising department to the privacy department.

Really bad analogy. Look at the post, these are basic computer science topics he is recommending for study, things like data structures and algorithms, not any specific technological subspecialty. A better analogy is that all doctors need to pass licensure exams in basic medical knowledge (e.g. anatomy, physiology, etc.)

>A better analogy is that all doctors need to pass licensure exams in basic medical knowledge (e.g. anatomy, physiology, etc.)

The problem with the situation is that doctors don't need to do that every time they change jobs.

That’s a great analogy but doctors will work on saving lives and Facebook’s software engineers will work on ... ads

Isn't this just one person's opinion? It's not like this was posted on Facebook's blog - right?

At a company Facebook's size - a random Senior Engineer doesn't carry that much weight.

> If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!" That seems like a ridiculous stretch in my opinion.

This analogy doesn't work. It's basically the final part of your education in that field (and others). If every hospital / medical center made you quit for a few months to study for their interviews when you switch jobs it would be an analogy. Oh we only hire people who can find a vein in 15 seconds under a suboptimal lighting situation.

If every hospital felt the need to interview doctors assuming they didn't know how to practice medicine, doctors would definitely take time off between to study. But they don't, because they know everyone has a base level of knowledge. On the flip side I've interviewed people who simply cannot do basic coding tasks.

I'm not sure in which universe you live but I've met plenty of incompetent and ignorant doctors who gave advice which didn't make any sense.

Same with lawyers and accountants (accountants have so many certifications it borders the ridiculous).

More than the knowledge you've proven to have once, it's important to evaluate ongoing performance and care on the job.

That's something you can hardly prove during an interview.

A market based model of work with a system of reviews would be an improvement in my book

This feels like a troll post : comparing a final exam with a job interview. One is the end, total sum, of 10 years of study, the other is just... a job change. It's important, but not worth a month of my lifetime. I've only got a few hundreds of those.

> If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!"

That is fairly close to describing a well known issue with MCATs and medical school admissions, as well as boards, see [0] - note, while I'm not familiar with Pacific Standard, I felt that article gives a good overview of the issue and acts as an omnibus to a number of links of the supporting scholarly information.

[0] https://psmag.com/education/be-a-good-doctor-study-the-human...

From the article it would appear that anyone with a computer science background and a decent amount of experience as an engineer should pass the technical test without the need to spend the whole month revising.

If you don't have a computer science foundation it's probably a good idea to learn the basics anyway, rather than learning just to pass the interview.

The bar for Facebook is something like being able to solve two medium-difficulty problems in 45 minutes.

If you want to test yourself, you could try these, which are popular questions:

https://leetcode.com/problems/find-all-anagrams-in-a

https://leetcode.com/problems/subarray-sum-equals-k/-string/

Note that it's not enough to present any solution - you need to present a solution that is efficient. Also, you should be able to write the solution correctly without looking up anything and without running the code before declaring that it is complete.

> Also, you should be able to write the solution correctly without looking up anything and without running the code before declaring that it is complete.

That’s the bullshit part. This doesn’t happen in any other context in software engineering except interviews. This just test the ability to memorize algorithms. People with a life are at a disadvantage by either accident or by design, not sure which is worse.

Those links get 404?

Here you go

https://leetcode.com/problems/find-all-anagrams-in-a-string/

https://leetcode.com/problems/subarray-sum-equals-k/

Optimal answers expected.

Thanks, links work.

As someone who interviewed people applying to Facebook (or Oculus anyway), the coding tests were intentionally told to be structured as one easy question (so that the candidate could build some confidence and provide some signal) and one medium/hard coding question (ie can they write more substantial solutions and solve harder problems). That’s for the traditional “CS” coding interview. The other technical part is an open ended design question (whiteboard/hand-waving diagrams/explanations with no code).

For me, at least, there’s a big difference between having the knowledge of how to approach these problems and having the practice fresh enough in my mind to solve them quickly under pressure. The latter is what the month (or whatever) is for, and it’s absolutely necessary for me personally. I think you have to be pretty dang smart for it not to be.

Algorithms was one of 18 courses in my CS major.

You want to check my computer science background, ask me about: regular languages, LR0 grammars, interpreters, compilers, system calls, threads, virtual memory, concurrency control, TCP, consensus protocols, raytracing, scene segmentation, sensor fusion, database indexes, block cipher padding schemes, etc.

But no one cares about the other 17 courses, they just want me to have internalized a crazy level of detail on one in particular, as if I had studied nothing else for 4 years.

The performance problems I've been called on to solve, I solved by having a vague idea of what's going on at the OS and network level, something that apparently makes me a wizard at a company that allegedly selects for "CS fundamentals."

Wrong. If you are a serious Software Engineer with 15+ years of experience you will easily fail their stupid interview process.

Why? Because most of the people on the loop have far less experience than you. They aren't any good at measuring those who are truly skilled and are just looking for clones of themselves that are happy to reinvent the wheel constantly.

The basics aren't really crucial to developing most software. Not the way Faceboook is testing them at least. They want you to spout off the typical college explanations for things you do in just a call to a library.

No serious systems developer gives a shit about how to implement sort these days. It's a waste of time.

The only way to measure the value and experience of senior developers reasonably is to have in depth discussions about their experiences. Using college type tests is just absurd and idiotic.

Probably revising to remember it without needing to look it up ;) I can't be bothered to remember specific details like algos, I normally look them up.

The author mentions CLRS. It’s an introductory level algorithms book and is used in Junior/Senior years of undergrad. Expecting a senior engineer to be well versed in undergrad level algorithms is not a monoculture problem.

The problem is not the expectation but that something like that can even come up during an interview for a senior position!

It is like testing a surgeon's suturing skill during a job interview. Of course, it is an essential skill for them to have, but that's something for a school exam and not job interview for someone with verifiable credentials. Or do you think that surgeon didn't suture in their previous job and just "winged it through" for years? What exactly do you hope to achieve with such an interview question?

That's exactly what is wrong with software engineering hiring and interviewing. It is focusing on examining nonsensical minutiae instead of whether the person has any sort of design skills, is capable of teamwork or has any sort of project management skills.

These are way more important for a senior engineer than whether or not they have crammed algorithms for a month and can reproduce them on the spot in front of a whiteboard (and will promptly forget them in a week or two again). That algorithm can be looked up in 5 minutes if needed, lack of project management skill could pretty much doom the company in the worst case.

>that's something for a school exam and not job interview for someone with verifiable credentials

The problem is the "verifiable credentials" vary widely in rigor. There is no analogous standardizing and credentialing body like their is in medical fields. So the "basics" need to be tested repeatedly at every new interview. The solution is to have an analogous standardizing body, but people in this field seem to be reflexively against it.

A standardizing body has its own downsides. The medical credential stigma is real- nurse vs traditional school vs osteopathic school, many of which have been closed to specific races or gender identities historically.

EDIT: Of course, that and the fact technology is extremely rapid. Does this mean software people need to re-credential regularly?

That's BS. Verifiable credentials mean that you pick up a phone and call the references the candidate gave you.

What you are describing is essentially "it varies widely in rigor - so we must subject every candidate to a full CS exam, because we don't trust anyone."

Even in medical field the schools and standards vary, especially between countries. And there are good and bad doctors. Heck, some have even got their diplomas fraudulently.

However, that doesn't mean you will have the prospective hire sit in for an multiple hours/days of redoing university examinations during an interview - as it seems to be the rule in software engineering (and pretty much nowhere else). You would be laughed out if you tried that.

Especially for a senior position, where the candidate has a past experience you could ask about (i.e. not a freshly out of school student).

> It is like testing a surgeon's suturing skill during a job interview. Of course, it is an essential skill for them to have, but that's something for a school exam and not job interview for someone with verifiable credentials. Or do you think that surgeon didn't suture in their previous job and just "winged it through" for years?

Yes, absolutely, I think that some surgeons can be less skilled at suturing after years of experience, and it'd be wise to have them demonstrate these skills in an objective way during a job interview rather than relying on credentials. eg:

https://www.sciencedirect.com/science/article/pii/S187887501...

> Most methods currently used to assess surgical skill are rather subjective or not adequate for microneurosurgery. Objective and quantitative microneurosurgical skill assessment systems that are capable of accurate measurements are necessary for the further development of microneurosurgery.

and

https://well.blogs.nytimes.com/2013/10/31/a-vital-measure-yo...

> To the researchers’ surprise, there were huge variations in operative skill between the practicing surgeons, with the lowest ranked surgeons working at what the reviewers considered a level only slightly better than a trainee at the end of residency, and the highest-ranking surgeons working like “masters” in their field.

Software engineer interviews are absolutely imperfect, but I don't think other professions have this figured out either.

And you want to say that such assessment is actually done during a job interview and not during, you know, actual surgeries? With a more senior doctor on the team evaluating (and likely mentoring) the new hire?

Seriously?

I was going for brevity. You might be missing my point here, which is: relying on credentials isn't working out as well as people might think for surgeons. They have a much stronger credential requirement, so if it isn't working for them, it probably won't work for hiring software engineers either.

But to answer your question, of the two links I included:

* the first is an artificial test that can be taken any time. Yes, it could be actually done during a job interview, and maybe it should. Alternatively, maybe it should be done yearly, whether that's enforced by the medical licensing board, the hospital, or insurance (either the patients' insurance forces it or the doctor's malpractice insurance).

* the second mentions criteria for ranking performance from a video of an actual surgery. No, I'm not suggesting applicants perform unnecessary surgery on a live patient during the job interview. They can bring a video of their most recent surgery instead.

The details of the best method for surgeons might not be that relevant to hiring software engineers, but I do think for both it's better to evaluate current skill rather than rely on exams from school years ago. Software engineering does this better than most fields, even if it sometimes leads to really bad results like not hiring Dan Luu. [1]

[1] https://danluu.com/algorithms-interviews/

Only if the role you're hiring for requires directly applying those algos. A high level understanding is good but implementation knowledge isn't.

I've been in this industry for almost 15 years. I've never once had to write a low level algo implementation. On the few occasions I had to dig that deep into code I looked up what I'd forgotten. If someone asked me to whiteboard bubble sort I'd choke.

There's no need to know it all by heart and recall it on demand unless the job you're doing requires it.

You rarely need to write your own sort or hashmap, but you should absolutely understand at a high level how those algorithms work, how to analyze them, and the key concepts that go into their design.

The point of the undergrad CS syllabus is not to teach you specific algorithms, but to give you a toolkit for solving problems. The goal of a SWE interview should be to test your ability to apply that toolkit to a "new" problem.

Amazon asked me to implement a hashtable and email the interviewer the solution by the next morning.

I politely declined; was heading off to Spain for a long weekend.

IMO that's not a good interview question even f2f, let alone on email. As an interviewer I would learn nothing from that, and I agree it's unreasonable to give an interviewee homework.

As far as I know, that is not SOP for FANG interviews.

This was nearly 10 years ago.

Disclaimer: I'm in a position at FB where I participate in candidate reviews.

> If someone asked me to whiteboard bubble sort I'd choke.

I came in to FB just shy of 20 YOE, and I consider "Google" to be a valid answer to that sort of question. Writing low level algorithms is a waste of time, not a skill. That said, I think it's ok to expect people to be aware of them.

Could you describe the algorithm for it, though? What about traversing a tree? Would you be able to talk it through and then be able to implement it? What about proactively verifying that your algorithm was correct for standard and edge cases? Can you evaluate your solution for time & space complexity?

If the answer to these is yes, that's sufficient to pass the coding interview. This is also where I think think more experienced candidates really shine. Aside from handcrafting algos that are best left to libraries, the others are things that senior folks who have been there and done that just do intuitively.

Interviewers definitely want code that works, but being able to do the other things is equally important. The review process itself also doesn't allow one bad interviewer to sink the candidate.

that's a hell of a time investment if you're not planning to stay at FB for a long time.

I think that right there is a good enough reason for them to do it. They probably want to weed out anyone that is not planning on staying for a long time. In general, I imagine the more applicants you have, the more difficult you have to make it to get through.

Your points are basically true across $MANGA as well. (Microsoft, Apple, Netflix, Google, Amazon)

I think it’s more a symptom of interviewing being broken than just being a monoculture. They’re probably very related, though. Bad interview practices produce bad results, etc.

Why is interviewing so broken? Why isn’t there something like certifications? Do things like unions address this? They seem to in construction, plumbing, and trade jobs as well as even acting.

> $MANGA as well. (Microsoft, Apple, Netflix, Google, Amazon)

I must say this is a new acronym (backronym?) for me. Why do people insist on shoe-horning in Netflix in there? Yes, I'm aware without the N these acronyms can collapse into a more distasteful and off-topic term, but is that the only reason?

I'm sure Netflix is a "wealthy" company with a competent engineering org, but surely they are nowhere near the scale that the rest of the letters operate in? Netflix's competitor is just one of many subdivisions in Amazon, after all.

Mostly because Netflix has very high compensation for senior engineers.

And a well above average expectation of skill. IMO the most difficult interview to pass in that group.

I made it up. I think it's hilarious with Netflix in there cause, MANGA.

My experience is that the expectation is the same for ALL big tech companies: you need to spend about a month revising problem types that they consider important for an interview. If someone fails on this, it is enough for them to pass on a candidate.

FB pays astronomically well. You don’t have to work there, but if you do, this is what you have to do. Saying that it creates a “monoculture” is like saying that soccer teams only hiring people who can run this fast, jump this high, and kick the ball this hard get to be on the team. Sure, they might miss the occasional great talent who is unathletic but has some great gift for the game, but it’s not a bad set of hiring standards for the task at hand.

This is a poor analogy. It's like making a soccer / football player answer a test on the history of the sport, how the ball is made, the geometry involved in kicking the ball, the mesh size of the goal net, etc.

There may be some relevance but in the end if they're a good player none of that matters. You'd be testing the wrong things to know if they're a good player.

I think this is an equally poor analogy as it assumes Facebook wants to hire all the good people it can, which isn't the case at all. Facebook is trying to limit false positives. They would rather deny 10 world-class developers than hire one person they need to fire 6 months later.

Facebook, who is paying a lot of people to optimize its hiring processes, has found a correlation between the objective of "lower short-term attrition / first-year PIPs" and "quiz people about the mesh size of the goal net." I'm not saying it's the best long-term or that I agree with false positive bit as a business decision, but I find it hard to believe they're doing stuff like this just because they feel like it without any data to back it up.

Also the big tech companies only need "world class" developers in under 10% of their positions. Reducing latency on Oculus Rift? OK you need a Carmack. Building a compliance portal for some new law passed in Kerblachistan? A lot of people can do that, and a company like Facebook has a lot more of the second type of problem than the first.

That's a real understatement. Privacy and legal compliance toward evolving laws in a massive codebase + many datasets spanning multiple complex systems is a company-wide effort that takes some serious system engineering ingenuity. Some of the smartest people at these FAANG companies are currently working on privacy engineering.

Sports scouting and evaluations are also notoriously unreliable. For every Messi or Ronaldo there are literally thousands of players who were scouted as having potential but washed out almost immediately.

I'm sure it's not optimal. But it's worked for Facebook very well so far. Why would they change? They don't need every talented developer under the sun. They just need a large group of developers who can do the work, and a small group of developers who can push the envelope on the most cutting edge stuff.

I'm an athlete-turned-software engineer at FAANG. This is the NFL scouting combine:

40-yard dash, Bench press (225 lb repetitions), Vertical jump, Broad jump, 20-yard shuttle, 3 cone drill, 60-yard shuttle, Position-specific drills, Interviews – each team is allowed 60 interviews in 15-minute intervals, Physical measurements, Injury evaluation, Drug screen, The Cybex test, The Wonderlic test

I would consider this set of proxy tests to be roughly analogous to the FAANG interview loop for screening world-class engineers. They're representative tests with predictive validity for the separate, more meaningful task of Game Day athletic performance -- since you obviously can't hold a real Super Bowl as a scouting combine.

Other than Wonderlic everything you listed is directly related to athletic ability and are things athletes do on a regular basis. You're supporting my point. I'm saying testing should be directly related to the position.

If someone doesn't need to do binary math or write complex sorting algos from scratch you don't test those, just like how you wouldn't ask an athlete the mundane questions I posted above. You might ask high level questions to demonstrate knowledge of sorting, but not ask someone to implement that algo from scratch.

If someone is trying out for the NFL they're not going to have to demonstrate baseball skills, how their shoes are made, engineering questions about how the stadium is built, what software should be used for the ticketing system, or any other questions unrelated to the position. You have them to demonstrate skills directly related to the talents they need to fill their role, like standard field drills.

But the engineers at FB do need to be able to write sorting algorithms from scratch rather than just have knowledge of sorting. The reason is that the engineers have to be reasonably fungible so that they can be easily moved between projects as projects are started and stopped. So they could easily be tomorrow thrown into an environment where a sorting algorithm is needed, they are the ones responsible (so they'll need to build it, not just have a high-level idea of how to do it), and at FB scale every bit of squandered efficiency is very expensive (if their photo search algorithm, let's say, takes 5% more memory than it needs to, that will end up costing the company much more than their salary).

Yes, if you aren't dealing with CS fundamentals directly in your work, you aren't working on the kinds of challenging engineering problems we face on a day-to-day basis. For example, a coworker applied some arcane number theory to one of our hashing algorithms, saving the company millions and was just recently awarded a patent for it. You can find many other, more specific examples in our Engineering blog. We're a mature product operating at scale so small, but meaningful statistically-significant % metrics gains are actually quite large when it comes to real business impact, and so chasing these gains actually requires a serious academic toolbox.

FB has thousands of employees who write code. I highly doubt many of them are writing sorting algos from scratch. They should know which sorting solves the problem and use an appropriate library.

The same applies to most other low level problems. They should understand the problem and the best practice to solve it. In most cases writing low level solutions from scratch is not the best practice.

FB is a mature company now with a slowed growth rate. They've been dealing with scale and performance for long enough now that it shouldn't be necessary to write all of these things from scratch.

Facebook has pioneered multiple languages and programming API packages. I'm certain they have had to implement library functions "from scratch" multiple times.

I can assure you that the growth rate has not slowed. Do not use the USA as a proxy for global behaviors.

I don't see a correlation between product growth and engineering complexity.

So what would you do instead? Being able to write some code on a simpler problem vs real-life code is an equivalent of a 40 yard dash vs rushing for a touchdown (or whatever). Being able to find special cases, or design, or figure out a simple algorithmic puzzle is the equivalent of the same for larger problems. The alternative is letting the candidate talk about their projects or to have some hand-wavy design exercise, something too easy to BS.

You really think a professional football player wouldn't know tons of random trivia about their sport? They probably could spend hours talking about the various pros/cons of different cleats...

Though I guess it's technically not necessary to know those things, I would be surprised that someone would put in the work necessary to succeed without being at least a bit interested in the details.

>Secondly, the author believes that senior developers, who likely have 10+ years under their belt if they're senior, need to spend a solid month revising in order to be successful landing a role there.

FWIW, I joined FB at 20 YOE and spent about 3 hours on Leetcode problems just to get my mind back to being able to handle "stupid computer" tricks. Array manipulation, algorithm cleverness, etc. are things that I hadn't really done since the early days of my career. Aside from that, the only real challenge was a system design interview with a VERY junior engineer where I had a really hard time keeping things at a level they'd understand while not coming across as patronizing.

I had the same experience. They only asked about things I haven't focused on or cared about in over 20 years.

The person on the other side of the design interview also seemed very inexperienced and wasn't able to follow things that would be obvious and simple to anyone who has actually done system architecture.

>...things that would be obvious and simple to anyone who has actually done system architecture

Load balancing web servers was one of those that almost got me in trouble. I just assumed that any sane web infra would balance load.

I think the real issue here is this post reads like a "person who's only been working for a few years" or "has only worked at one company" guide to getting into FB. It represents a very NARROW view of who wants to work there and how they got there.

1) This isn’t unique to FB. 2) The kind of interview being described has been critiqued by many people, many times on HN itself (I am definitely one of those). The problem is that there are no good alternatives. One suggested alternative, take home exercises, became a mess because a lot of companies, and individuals at companies, started treating them as free labor. Beyond that, they need to be more complex to the point that an interviewee is doing actual work. 3) The best way to look at these interviews for senior engineers is them testing your ability to learn something “new” at a very fundamental level. It’s the equivalent of them selecting people based on their success in a badminton tournament. You will most likely need to pick up the game and it doesn’t have much to do with your day to day job, but it does say a lot about your ability to pick up new skills/tech ologies. The difference is that these interviews, unlike a game of badminton, actually have something to do with your job.

To be honest, it’s not ideal, and I particularly hate it because I find it hard to find time to study and prepare when I have a family that I don’t want to neglect, and also a full time job that i would find immoral to take time away from. But it’s simultaneously hard to find better alternatives.

There are plenty of good alternatives. One is: Talk to the fucking candidate and ask them about the things they have done over the course of their career. Have them explain something you don't know about yourself and see how they do.

The key thing here is you need senior engineers conducting the interviews to be able to judge properly, not the 3-4 yr out of college monkeys that Facebook uses to interview.

I (as a senior) had a rather bad experience interviewing with Facebook; I was mostly interested in interviewing for whatsapp, the recruiter went and put me in front of someone not at whatsapp, I programmed in an erlang-vm language, so the interviewer was already confused by the code I was writing.

The interview was conducted over coderpad, and at the outset, the interviewer asked if I was familiar with it (I was; I've conducted interviews over coderpad), and I wasted a lot of time commenting out the interviewer's cut and paste instructions and writing out the tests, because when I wanted to actually test out my code, to my surprise, execution was disabled!! I didn't even know that was an option in coderpad.

So, basically one of the key tools I use in my day-to-day coding workflow was kneecapped. As a result I wasn't able to run the quick tests I had written, and I had mixed up two similar algorithms in the implementation, but not in the tests. I would have noticed this IMMEDIATELY if I could have run my code! Needless to say I failed the interview at the first stage.

Oh well. I probably prefer working at startups anyways (I landed at one in the domain I wanted to be in, working in the language I prefer, get paid reasonably well, and have sizable equity in a company that has a good shot at high upside in a short timeframe).

"Hey are you experienced with coderpad?" "No obviously I have never encountered coderpad in my 20+ years of writing software and will have a hard time using a simple online text editor." Facebook interviewers are such insulting morons to senior engineers.

I agree that actually running code, seeing the errors and fixing them in like 10 seconds is a common behavior amongst those of us who have been coding for ages. One can write code that works without doing that but it is a drag and wastes time.

These are very basic/generalist things, not a specific mould. Refreshing your skills here and making sure you're comfortable with everything on this list will help you be confident that you can pretty much do the kinds of work available to you as a senior engineer. And if you are lacking in any of these, it almost certainly will show up when you're trying to function in the role. I run into this every day with entry level engineers - they have to rely heavily on others and also have to spend a lot of time ramping up on exactly these kinds of things.

Put another way: if you did get hired for this role and managed to keep it, you'll be a master at this stuff within a couple of years. This is because these skills are generally useful no matter what specifically you are doing.

"if you did get hired for this role and managed to keep it, you'll be a master at this stuff within a couple of years." I wholeheartedly disagree. I have a total of 14 years of experience. I've been at Google for the past 6 years. I'm an L5 (Senior Engineer) and I get good performance reviews. I interview candidates on a fairly regular basis on behalf of Google. I am fully confident that if I had to re-interview for my job today, without extensive pre-prep like the author suggests, I would have a very slim chance of passing. The fact is, these algorithm quizzes have nothing at all to do with our job. On the off chance once ever 5 years you actually do need to apply an algorithm, you would do extensive study into the possible options and solutions, write a design doc, have it peer reviewed, and then go down that path - not pull something out of your ass in 15 minutes.

> these algorithm quizzes have nothing at all to do with our job

There are no algorithm quizzes here, and it's not saying to prep for one. It says you should have a good grasp on these: arrays, heaps, linked lists, searching, etc. And it provides quality references for refreshing that knowledge and for getting practice thinking and speaking about them in human language instead of internal abstract thought. I think we agree that if you are in a senior engineering role, I don't necessarily care if you can implement a linked list in an interview time slot, but I sure as heck care that you know how it's different from an array, how it generally functions, when you would use it, in what situations alternatives might be better, and so on. When and why would you use a linear search instead of a binary search, are you aware of how hashes actually work and that hash collisions may occur and need to be handled in some way, can you identify that a particular problem is best solved by recursion or by dynamic programming even if you can't whip up a functional solution in an hour, etc, etc. Some interview candidates literally can't tell you why you would use a linked list instead of an array - it's just an ordered collection to them. That's what this is about - it's not about quizzes, its about fundamentals. These are what our systems are made of and understanding them is valuable to do the work we do.

And aside from data structures and algorithms and being able to talk and reason about them, I also need to see actual code of some kind that solves an actual problem in this interview, with appropriate questions around the presented ambiguity as well as be able to talk about its trade-offs, potential improvements, testability, maintainability observability, and so on. But these are not necessarily anything like an algorithm quiz

CLRS is a literal algorithm textbook. They recommended grinding HackerRank or LeetCode too.

You're saying applicants have to revise their skill sets but I don't think brushing up on algorithms is a very big change.

I think you meant mold. Not all Facebook employers have to be mouldy.

that gives that company way more credit than it IMO deserves.

> Secondly, the author believes that senior developers, who likely have 10+ years under their belt if they're senior, need to spend a solid month revising in order to be successful landing a role there

As others have noted, the same seems to be true of a number of other computing companies: the "technical interview" is a sort of qualifying examination (largely focused on undergraduate algorithms/algorithm puzzles/leetcode type problems) that is unrelated to the actual work.

When conducting interviews, I like to ask questions that are similar to coding problems I've actually faced.

That said though, in general the coding interview doesn't need to be directly related to work to be useful signal - in fact, to the extent that it's not similar to the interviewee's day to day work, it successfully measures the interviewee's ability to quickly pick up and excel at a new tech / framework / skill.

Every time I read these posts I find them very depressing. Crunch through an enormous bunch of algorithm problems in order to perform well on some unrealistic whiteboard programming (I think the system engineering problems are actually more useful though) - as usual we've focused on the easy to measure metric rather than anything actually useful. Maybe these things are meant to be a proxy for how good you are at other development tasks, but it has never seemed to work out that way to me. Some of the very successful people I know at FAANG companies have told me that they would not pass the algorithm interviews without months of preparation and that they don't really use those skills.

It is a proxy or how good you are at other development tasks. I think it's a bad proxy. Mostly because I've read and studied CLRS at school. And I don't use the fun parts much in the wild. I'm also not expected to be able to recall things that you can look up.

One 'slightly' shameful things I noted about myself reading that list of system design interview questions is that I actually don't use most of those systems or know their features well enough. Other than YT of course.

I feel like the simpler interview process would be to just take a person and do a hand wavy system design interview. Then if they pass, hire em on probation for 2 months and slam them with work. They get paid, you maybe get a feel for them.

They sink or swim. You keep em' or toss em' away at the end of the two months.

Hmm.. this is how I got hired last year. I told the employer that I wanted to test them and to get me a short term project we could use to determine if company/me are a good match.

That approach would work for a startup, but not when you’re hiring 100s of engineers on a weekly basis. Not to mention the amount of bias that approach will introduce. At least with the current approach, you know exactly what the criteria is to land the gig.

I don't know that it's depressing, more that it's indicative of a culture I don't want anything to do with, which is fine with me. At least it's truth in advertising.

After 20 years in software, I had a phone interview with an Amazon guy who sounded half my age (at most). Asked me to write some kind of function to do something, sort some stuff or some such. I described verbally how I would do it, almost line by line, in pseudo-code. He said "I need you to write it out in [some language]". I said "But why? I just told you how I'd do it." But he needed me to literally write the code out, as though I couldn't easily copy-and-paste something for him. I thanked him and hung up. All I learned from that encounter is that I'd be very unhappy working with people like him. Bullet dodged. Sure, I use my knowledge of algorithms, and I frequently look such things up on StackOverflow and improve my knowledge; we all do. But these interviews seem designed to filter out experienced, pragmatic programmers and just bring in more cookie-cutter software engineering BS/MS recent grads who speak their language. A far cry from the startup environment that most of these companies began as!

"But why?"

Because most people can't. And they want to make sure you can.

And it proves what exactly? Except that they have lost out on a good hire only because that hire is not familiar with that particular programming language that the interview is.

But that's not how it works. You are almost always free to use why language you want. There are exceptions to this but in those cases it would be clearly indicated in the job description.

We have approved languages for projects at work (Java, Scala, Go, and Python in special cases), but I let candidates use any language I can read, and it’s never been a problem.

These types of interviews are very similar to the Confucian Imperial Examination tests (Keju) of China [0]. The Keju's main purpose was to exclude peasants while giving the imperial bureaucracy the image of a meritocracy and therefore legitimacy. They also helped enforce a common culture, script, and style of writing for the large empire. To be clear, the Keju changed a lot as China's history evolved and it changed with China and is not a unified 'thing'.

The expense and time for study excluded many people and I have heard that whole villages would pool resources for just one son to buy the exam materials and take the time to study for the exam. Richer families didn't have need to sacrifice as such, of course. Typical success ratios were ~1:50 exam sitters. The Taiping rebellion was a direct result (among many) by such a man that failed his exams a few times (later declaring himself the brother of Jesus, but that's whole other story).

Though exam subjects changed over time, it typically included recitations of Confucian poetry, calligraphy, instrumental music, and other such gentlemanly subjects. You know, things you really need your bureaucrats to know to run an empire well.

Similarly with FAANGs (and previously with GMC/Ford/Chrysler, or in academia), the interview/exam is geared not towards the actual specifics of the job, but rather in the 'pruning' of the people and the appearance of legitimacy. They are selecting for people that will go through the hoops and the nonsense without questioning it and will make good bureaucrats (loyal, command-able, lacking vigor). Boat-rockers are selected out before they even start the irrelevant studying process.

[0]https://en.wikipedia.org/wiki/Imperial_examination

lot of paper tigers out there

Then pick up a phone and call their references. A "paper tiger" with 10+ years experience (since we are talking a senior position) likely could not have just "winged it through" the entire time.

Subjecting such person to a CS exam totally unrelated to what they will be doing (such as project management and leading a team of developers) is a complete waste of time for both sides and you still don't test whether that person has the skill they will actually need for the job.

But yay, you have found that they are great at inverting a tree or designing a complex hashing scheme at the whiteboard under pressure. Exactly what your company needs. Not.

This is the answer right here.

We always allow the candidate to use any reasonable language. We're not testing if someone knows Java/Python/Lisp (I wish). We're testing if they know any language. I can confirm seeing people with resumes who nevertheless could not write any code even in the language they professed to be "expert" in.

Same. I learned through experience to ask for a candidate to write a couple of lines of code.

Usually it's just some simple question that requires a single loop. We explicitly tell them they can use any language including one they want to make up as long as they are ok explaining how it works. When possible, I try to relate it to the conversation we've had up to that point.

I've had someone start off by writing "four" on the board when prompted to write a "for" loop and get stuck. I'm still not sure if he was truly inexperienced or just trolling. The resume looked solid to me and he spoke well about his experience. I had almost decided to just skip the coding question as a result.

Yep. I just want to actually see you plop some if-else and for/while loops on the board in any Googleable language. I'm the one with the laptop/phone and I can learn that language on the spot if I need to.

It's basically "find the first string in an array of string that has the letter 'b'" difficulty of questions. Anyone who actually codes can whip something up in a minute and we can move on. But it's always surprising how many people spend half an hour on that and still don't get anything workable.

If you can describe an acceptable algorithm with enough detail in words, you can code it.

If some guy had a good employment history, maybe a GitHub with some examples of their skills and described an algorithm to me... Why would I doubt their ability to write it in code?

I can. You can. But apparently, not everyone can.

> If you can describe an acceptable algorithm with enough detail in words, you can code it.

I wouldn't take that for granted. It's easy to gloss over details and edge cases when talking through an algorithm and it's not apparent until you actually write the code. Similar things happen when discussing things in meetings vs writing a formal document. I've interviewed plenty of people that were able to quickly come up with algorithms to solve a problem but really struggled to translate them into code.

Exactly this.

I interviewed lots of people for a small company and multiple times I became convinced the person across a table would be a good hire (based on past work experience and soft talk) only to see them bleed to death on the first technical question. Demonstration of technical skill is absolutely crucial for an interview.

Personally I don't care about pseudo code vs real or syntax errors, but the price of a bad hire is much higher than a few more questions or round for a candidate. Also FAANG will always have enough senior CV on their desk to miss a few good hire...

Most people with 20 years of experience can't write basic code? Come on.

I have been a tech interviewer for a decade, and this is spot on. The entire reason FizzBuzz-style questions are popular in screening interviews is that most people fail them.

I imagine this problem is much worse at large, highly paid, highly desirable companies. My experience in hiring at smaller companies has not shown this. I've never had a candidate with 10+ years of experience who couldn't code.

We are a smaller org and hire occasionally for roles that are most suitable for early career applicants.

We always get several applicants with 10-20 years of experience who have programming projects on their resume or described in their cover letters.

But in our (very minimal) technical evaluations, lots of these candidates can't do anything at all. No coding, psueudo-code, nothing.

Usually, it turns out they have been really doing light IT work for years - using reporting tools, maintaining little scripts, even just some Excel jockeying. But they still think of themselves as software engineers.

My gut feeling is that lots of these candidates could learn (relearn?) to code, but have spent years not coding.

I don't have the numbers in front of me, but I would guess that the majority of these types of candidates (10-20 years of experience) that apply to our roles can't code in an interview situation and haven't been programming recently.

It is definitely not all of the experienced candidates who fit that profile. The few very experienced candidates we get who can code are often excellent but are looking for salaries well beyond our range.

You must not have tried to hire a software engineer before. In a hiring cycle I encounter multiple "Senior Engineers" who can't write basic code. Fizzbuzz. Can't do it. Engineers should absolutely expect to write real code in an interview. It's preposterous to think that someone can claim to have 20 years experience writing code and then be offended to spend 20 minutes doing it in an interview.

How do they react when they fail Fizzbuzz?

I make a judgement call - either I end the interview immediately or skip most of the rest of the interview, let them think they made it all the way through the interview and say that we will get back to them with a decision later. When I end it immediately they usually take it badly but these are times that I just can’t justify wasting any more time on them. The bad reactions run the normal gamut of bad human reactions: angry, sad, indifferent, humor, etc.

That's interesting:

> [I] let them think they made it all the way through the interview

Maybe then, although they get rejected later, they still won't be particularly upset at your company -- since the in person interaction was friendly and positive (i suppose), and you can take some time and write a friendly rejection email or phone call too (i suppose you have a template)

We hired one who couldn't. He turned out to be more of a mentor/big vision/best practices guy. Which is probably OK to have one or two of those if you're a large enough org.

But we had 3 devs. I think he gave some great advice (and looking back - still think so 12 years later), but it just wasn't what we needed at the time.

The funny thing is, when we let him go (he knew it was coming - he wasn't blind to the problems) he got hired at a company we worked regularly with. Things worked out much better for him there.

What was some of the advice, if you happen to remember?

One of my biggest interviewing mistakes was voting "hire" on a guy despite his seeming difficulty with coding during the interview because he was such a great talker and had great sounding experience. He came on board, couldn't deliver on anything, and sapped the team's morale. There are plenty of people out there who have bullshitted their way through a career.

If you're the one copy pasting code, aren't you the cookie cutter software engineer?

They didn't say they copy-paste code. They pointed out that the algorithm's actual code could very easily be copy-pasted from, e.g., Stack Overflow, without deeply understanding it. By contrast, describing an algorithm in natural language demonstrates actual understanding.

Both are necessary but neither is sufficient. If you have someone who perfectly understands the algorithm but can’t write the code, that’s a different utility than someone who can write code but doesn’t know the optimal algorithm solution. You can say “at work I’d look up a reference” but in an interview setting that’s not helpful where the interviewer needs both. That’s kind of why I really don’t like remote tests. It’s really hard to filter out those trying to cheat. I’ve observed how leetcode stuff tries to track you looking stuff up and it’s theater. Just get a tablet or second laptop (or even use your phone) and the site can’t track if you’re actually looking that up.

I get annoyed with those tests and interviews too, but I’m aware of the challenge on the other side so I take it with a grain of salt and would never let my ego make me arrogant enough to take umbrage at being asked to write down a piece of code. I can understand the frustration, but this process is applied equally along all levels. Hell, the most talented people I worked with were regularly interviewed on coding by people more inexperienced/less talented than them. I would have a hard time any of them expressing anything other than mild annoyance at the system that this is still the best we’ve managed to do and no one would think to say “what right does this young inexperienced person have to ask me questions”. If anything, that attitude would instantly disqualify someone on the “fit” axis of the interview even if they passed on the technical merits.

Thank you, yes, that was my point. The interviewer gave me a choice of languages, as I recall in fact he said "use a language you're comfortable with" and I thought to myself, what does this prove? I can google the answer and paste it in without him knowing. Whereas, I can explain instantly how I would do it, too fast to have googled it, and he could maybe interactively ask me "what about this condition? how would you check for errors?" etc. The other thing is, he was unwilling to answer any of my questions until we got through this exercise, and I felt he was being rude and somewhat arrogant though I was being quite polite. I'm more than happy to show off my coding skills - I know lots of languages - just wanted to cut to the chase. Maybe I was too impatient. Or, you know, what they say about trusting the first impression is true!

He may not have been able to understand your answer without seeing it in code.

you seem to be protesting too much. I think it's entirely reasonable for a tech company to ask for code, even if you can describe the algorithm in plain english. Surely writing the code is significantly less than the effort you're expending right now to demonstrate to us why they are unreasonable?

You have a hard time at Amazon

For what it's worth, I don't think he'd disagree with you.

Additionally, I would probably translate that to be, "Unwilling to put up with what appears to be needless effort."

I am often on the other side interviewing the candidates for company I work for. For junior positions we do ask them to write some simple code e.g. matching parentheses or the like. It makes it very clear how much experience writing code given candidate has - typing speed, how they move around source file, even if they can seamlessly copy paste their code, etc., are all very telling.

> how they move around source file, even if they can seamlessly copy paste their code, etc., are all very telling.

This reminds me of the test for cooks. Make them slice up some fruit or vegetable. If you have worked in kitchens for years, you can do it really quickly. Fast and easy test, and nothing to prepare weeks or months for.

For nearly 2 decades, vi(m) (or a vim emulator or integration layer) has been my daily editor.

I recently had an interview where I had to use some remote collaborative web application and it was genuinely a horrible experience. The main interviewer (lead for the team I was applying for) was visibly annoyed with me because, for whatever stupid reason, some of the keyboard shortcuts he kept trying to bark at me, as I was working through some truly asinine leetcode-style questions, for things like block indentation were not working on my end and I had to manually tab multiple lines, etc...

The entire editing experience threw me really hard and was so distracting that I was fumbling what would've otherwise been trivial algorithm questions for me. Despite my 15 years of professional experience and a deep understanding of their tech stack (which, of course, was not a main discussion point at any stage of my interview process -- one of many red flags for me), if you had watched this you'd have thought I barely know how to write code.

I don't know what the answer is here but I have decided, and thankfully I have the privilege of making this decision, that I am done interviewing for a while.

While I have sympathy for the idea that some of these interviews can be ridiculous, however it doesn't seem like the interviewer was in the wrong here. As an interviewee you should have known what interview process is like, I worked at Amazon and I know the recruiters brief the candidates on what to expect in the interview, so you should have known going in that you'd be expected to write code, you could have said no right there and then in the email instead of hanging up on the guy.

They didn't brief me to expect that. Or, to be fair, maybe they did and I missed it. I didn't mention above that he refused to answer a couple of basic questions (what type of work is it? what language? where will the job be? can I be remote?) until he got through the script. It was like talking to a machine. And he was rude. I got a negative impression. I know, sometimes recruits are expected to put up with some rudeness or brusqueness to show how flexible they are, can put up with different personalities etc. But this guy just came across as kind of immature and arrogant. Sorry, but I'm quite glad I terminated the interview and he also seemed unwilling to push at all, just said "okay!" in a sing-song voice that implied "yeah whatever, go die". At least be polite and try to convey some professionalism or you're going to turn off people who prefer to work around professionals.

My one face-to-face interview (put me off for life): Some interviewers were there because they’re committed.

Some were doing it because they had to (last-second substitute) and it showed as they were rude about it or highly disorganized.

You don’t have to take it and it’s okay to cut interviews short as the interviewer (I’ve done it before), but it’s a mistake to be unprofessional about how it’s cut short.

> he also seemed unwilling to push at all, just said "okay!" in a sing-song voice that implied "yeah whatever, go die"

Is the idea here that you wanted the interviewer to beg you to stay on the call?

I interview for a BigCo. Most of us do it not because we love interviewing but because 1) It's a way to check the "citizenship" box on performance reviews. 2) A director or VP sent a mass email exhorting us to join the interviewer pool. Everyone I know in fact views interviewing as a chore that takes away from one's day job. But, there's standardized training and emphasis on objective tests and rubrics to minimize bias. Given this assembly line process and the fact that most interviewers want to be elsewhere, there's very little reason to expect a random interviewer to want to sell you on continuing a process that you consider yourself above.

If a candidate proclaimed that they didn't agree to the terms of one of my interviews midway through, I'd certainly exchange a few words with them to try to make them more comfortable, but in the end I would by fine with bidding them farewell and being glad that writing up that interview feedback would be easy.

I mean, yeah, you're probably right. I might have stayed on the call if he'd explained why the actual code was necessary, could even have met me halfway by saying "Yeah, I know it's kind of silly, but it's a requirement. Would you mind doing this, and then we can get on to more interesting stuff?" Or something like that, but he didn't have any kind of friendly or diplomatic response, maybe I was feeling impatient that day; I honestly can't remember because this was like 10 years ago.

Yeah, one consequence of hiring exclusively based on technical skill is that you end up with some employees that are empathy challenged. My employer recently added one "are you a human?" interview to every loop presumably for this reason.

Yeah, you're getting a lot of pushback from the corporate drones on here, but you 100% made the right call. If you want to be a part of the FAANG hive mind, you have to be willing to jump through a bunch of hoops. The job itself is mostly just cranking out/maintaining a bunch of boring backend plumbing for boring stuff, with little to no correlation between the value you bring to the company and your compensation. Saved the company a million bucks a year? "Great, here's a $25,000 bonus." Saved the company a million bucks a year, but your VP lost a fight with another VP? "You're just not a team player, no bonus this year"

I know you’d like to believe this. But I see a constant stream of challenging software problems at FAANG

Yeah, but basically anyone at a FAANG company who landed in any other non-FAANG company would be able to singlehandedly revolutionize the tech at that company.

Those same skills that let you plug Machine Learning Library A into Tracking Database B could make things that vastly increase productivity for a bunch of regular people, and if you're doing it for yourself or a small enough shop, it could actually pay off.

I can’t tell if this is sarcastic or not

ah, you'll probably get there someday.. Hopefully via observation and not via getting repeatedly screwed over by politicking middle managers

Companies like Amazon have standardized procedures for interviews. At the company I work for, the person interviewing isn't going to be the same person who hires you, so they need more data that just the interviewer's notes. Also, deviating from the standard procedure opens up the effect of unconscious bias.

This is the correct answer. The interviewer is only the to gather data, the hiring committee makes the decision and they need concrete days to look at. "Take my word for it" doesn't fly as an interviewer.

I would not attribute the requirement of writing out code as something your interviewer personally demanded. He was simply following a template.

The point is that when you write out the code, there will be several other people who will end up looking at it as part of your “packet”. This can actually be beneficial for the interviewee: if you use some technique or library that the inexperienced interviewer has never seen, they might be confused and write negative feedback, but someone down the line will be able to see what you wrote and say, “Oh, this is actually really good.”

I have 20 years of experience myself, and I've interviewed and worked with a lot of people with same experience that couldn't code properly (and some of them were actually good engineers). Yes, they'd describe roughly how something should work, but the actual implementation would be super buggy, ignoring any corner cases, etc. People who stopped doing any hands on work more than a decade ago, and are just coasting without touching any code, by having more an architect/mentor/org-expert role.

If someone feels "insulted" by having to actually write code suggests that you're looking for a role where you aren't expected to actually write code. That's fine, but probably not what they're looking for.

Also, I'd advice you to be little more open to a fact, that someone with less experience than you is asking you questions. That's not a great attitude to find good jobs at big IT companies, that are often full of young, often brilliant people.

edit: typo

I never stated that I felt "insulted". You're just projecting that, maybe based on bad experiences you have had.

There's an old saying: a job interview is a two-way street. You are interviewing them (or should be) every bit as much as they are you. If the applicant asks a basic question about the position, the interviewer has a duty to either answer the question or say "I'm not sure what role this is for; I've just been asked to check your technical knowledge, and then we'll get you to the actual manager who can give you a better answer. Okay?"

If the interviewer is immature, arrogant, rigid, etc., and regards the interviewer-applicant relationship as an antagonistic one, and views the applicant as incompetent and dishonest until proven otherwise, the interview will have that flavor. To me, that is a red flag about the organization. Indeed, I've heard from many sources that Amazon is a toxic environment; I have yet to hear anyone say "Amazon is a terrific place to work! [for engineers/programmers]" I suspect that if you're a high level product person who comes up with a clever idea like an AWS feature, and are able to pitch it to the top management, then you're a star, you're well paid, and life is good. But for the people in the trenches... not so great.

Original comment started by stating your many years of experience and noting that interviewer was much younger. Then complains about being asked to do coding. And then, based on just those two, saying that you know you'd be unhappy working with people like him.

Amazon isn't great environment in most of the pockets of the company (haven't worked there, but worked with a lot of people who came from there), so it's quite possible that you "dodged the bullet".

But only when pressed, you start to complain how interviewer is immature, arrogant, rigid. That's not what you originally stated - you had issues with an interviewer age and being asked to do coding. I'm not trying to defend the interviewer - it's very possible that they were bad interviewers - big tech companies push people early to start interviewing. But things that you complained about initially make it sound like you maybe also not a very pleasant candidate to work with, that comes into the interview with a lot of bias.

I didn't state that I had issues with his age. I merely observed that he was probably half my age; he talked and behaved rather immaturely.

I work with younger folks all the time and 90% of them are perfectly fine; actually I enjoy their energy and drive (and there are plenty of older jerks out there). This guy, I didn't enjoy. When I hung up the phone, I was not angry, as I recall. Just disappointed that a great company would have such petty people vetting applicants. You don't have to agree with me. I'm not even sure what we're arguing about at this point; if you're just trying to prove I'm a jerk... fine, I was a jerk that day. Happy now? Have a nice day. I don't work at Amazon and I'm having a wonderful day :)

If it didn't matter you wouldn't have mentioned it.

Unnecessary description.

Interviewers at most tech companies have to follow a script, one that most definitely requires them to ask you to code.

The interviewer has no choice other than to ask you write code. You describe the interviewer as arrogant and immature, but to me the candidate who hangs up fuming because he was asked to do a little bit of typing is the one who is antagonistic.

Maybe he had requirements to get actual code samples from applicants. He probably trusted you could do it, but companies have protocols, they probably would want to run analyses on the answers, too.

Why is the fact that the interviewer was half your age relevant? I interview and reject senior engineers with 20+ years of experience every day. They are extremely good at throwing out the right buzzwords and sounding smart, but digging a bit further it's obvious that they have spent the latter part of their career playing politics at large companies rather than doing any real engineering work. A simple FizzBuzz is enough to weed out most such candidates, and if someone refuses to spend 5 minutes of the interview writing actual code (in their language of choice) they are an automatic fail.

Yes, a simple FizzBuzz can certainly weed out people who aren't very good at playing the FizzBuzz game.

I wouldn’t blame the specific engineer for this too much (for asking you to write down the code). If Amazon is the same as Google, then there is a lot done to standardise interview scoring. Part of the guidance given to interviewers is to make sure that the candidate has produced actual “working” code. The code is included in the interview feedback that the interviewer writes.

Source: Interview trained at Google

I'm quite sympathetic. I think there's a huge domain of experiences that engineers bring with them.

However, I also see some wisdom here. I still don't full agree with it, but I see some sense too. These are core skills for an undergraduate Computer Science degree. They represent the bulk of our abstract knowledge of how to compute well, how to think about & break down problems. Without proficiency here, a coder risks creating potentially dangerously inefficient solutions, that, at Facebook's scale, may well literally cost the company millions of dollars in server costs, or which could make the difference between a successful on-time positive-PR roll-out, & a failed highly-negative public-relations roll-out.

That you can gain this knowledge in a couple of months is fairly remarkable in & of itself. Most engineering domains have a much broader swarth of core knowledge. Computer science literally has algorithms.

> Without proficiency here, a coder risks creating potentially dangerously inefficient solutions, that, at Facebook's scale, may well literally cost the company millions of dollars in server costs, or which could make the difference between a successful on-time positive-PR roll-out, & a failed highly-negative public-relations roll-out.

This is a common refrain, but juniors and mid-levels don't work on stuff like this at FAANG. If there's anything those guys are good at, it's making sure that you don't have too many cooks in the kitchen. Interviews like these don't find cooks, which is somewhat the point.

my experience in the industry of coding has driven home to huge points:

1. that each individual & each team has an enormous amount of leeway & personal responsibility. teams are vested with what power they take & how far they & their environment let them.

2. complexity is everywhere & typically to work, to produce, is to add complexity & create new ways for things to go bad. indeed part of what is most notable about FAANG companies is that they have colossal staffs- & notably many of their senior engineer ranks- working to manage & reduce complexity, by inventing continuous integration/deploy systems, by devising trackers for cyclocmatic code & cyclomatic data-dependency/data-access-pattern complexity, by creating more resilient infrastructure & new ways to administrate systems.

i fully agree that there is a huge opportunity cost. i think it's madness how focused & specific these interview courses are, what a set path they are on. but i also think it's been underspoken that learning algorithms & data-structures & less so systems are fairly core material to the industry, that these are basic truths that underpin every single thing we do. and i think the knowledge is acquireable and important.

and i think just as much, it's unsaid, culturally, a lot of my first point: that individuals in this industry have enormous liberties, that they are sent off to incredible & weird tasks, to go drag something or other back to the company. notably, it's just so so so so hard for a company to take responsibility for "it's" code, to re-integrate, to handle, the new complexity that gets dragged in to base, by each individual contributor. there are so few repeatable processes, so few really good ways for a company to systematically remember what any given thing is, how it works, why it works, what it does. code-bases are bits of the wild, collected from all over, so often from one or a couple of individual contributors who set forth on some expedition. even, yes, the juniors. hacking new tweaks, changes, sometimes it doesn't feel like big stuff, but to software engineer is to set out upon wild land, most every time.

the sociology of this is fascinating to me, the dynamic is incredibly strong, incredibly asymmetric in how much responsibility is given to the developer, how wild the tasks are, & the difficulty & crudeness with which companies step up to re-integrate, take in, take responsibility for, manage the work that gets done.

This may be an unpopular opinion, but I like how it is very objective, measurable, and somewhat specific. If I get fired and suddenly have my days free, I can simply study algorithms and leetcode and get a job elsewhere. It seems easier than worrying about everything else that could be asked during an interview.

I feel the same. It's also much more meritocratic. People from no-name schools and no-name companies study leetcode and get into FAANG all the time. Do people really think it would be better to base it on resume and YOE?

It's not an "either/or" choice...

These companies treat it as though if you can't recite a leetcode answer line for line then you're no good.

A software developer skillset is a lot more varied than reciting 5 leetcode answers for algorithms you won't ever use in production code 99% of the time. And that 1% of the time you do? You're just going to Google the algorithm again anyway.

It's an almost pointless interview exercise.

Partially agree. But developers have to often create custom algorithms that are very specific to their business requirements, and these algorithms cannot be simply googled. I agree they would never write a "sort" algorithm, I suppose interviewers use these generic algorithms, rather than take the additional time needed to explain a real world, custom set of requirements.

The interview is not just about leet code. There's also a behavioral loop and a system design loop, and both of those are extremely important as well. In fact most candidates vastly underestimate their importance.

In my experience the leetcode questions were quite easy from an algorithm standpoint: string operations and traversals and things like that. You are judged not just on correctness but also your communication, requirements gathering, ability to catch edge cases and bugs, and general code quality. In other words, things that are absolutely relevant to the actual job.

You know that the writer that coined the term "meritocratracy" thought it was a vary bad thing

Even if you are not actively trying to find a job I find leetcode/hackerank useful to do a bit of coding in case your current position moved away from that or maybe you want to repeat some of it with a new programming language.

> Maybe these things are meant to be a proxy for how good you are at other development task

They are also a proxy for how hard you are willing to work to join them. I don't find that a useful metric as it implies a huge power imbalance in their minds... nevertheless, sometimes hiring processes make you jump through hoops just to prove that you are willing to do so.

It's sad but yeah it's true that you have to prepare for interviews. The reality is that the breadth of topics that you have to have good knowledge on is larger than the scope of work you've probably been working on in your current job.

I had work at a FANG before, but after a few years doing a startup, I had to go over and learn topics that I had no understanding on to get good offers again. I summarized what I felt were useful tactics for prepping system design interviews here (https://www.reddit.com/r/cscareerquestions/comments/kd13sx/s...) and a summary on a list of core topics I put together here (http://gum.co/sysdesign).

HN loves to hate FAANG interviews. There's always a monthly passion post about how flawed they are.

I don't think it's unfair to say that Google and FB are considered to have strong engineering talent. So the interview process has to have _some_ hand in that success, even if it's also turning away some would-be strong performers.

I'm not saying the interview process shouldn't be criticized or that it's beyond improvement. And, yeah, it's a little silly to go memorize a bunch of algorithms so you can recite them on the stop. Furthermore, so many interview questions are posted on leetcode... and there's so many more flaws to be pointed out, but in spite of that, they still manage to have a high engineering bar.

But if you only read HN you'd think it's a total failure.

On the other hand, learning algorithms is probably more fun than the actual work at Facebook.

It's a game, some people are willing to play it.

Besides the usual advice, this observation is very interesting:

> Applying for senior engineering positions (>E4) in FANG companies is one of the best ways to get into them.

This comment by a veteran senior engineer confirms to me that Facebook, just like most other FANGs, does a poor job of promoting from within.

There are multiple comments to the same effect from many other FANG employees: It's much easier to get recruited for senior roles from the outside, then get promoted from the inside.

The result of this failure is that job-hopping is the most valid career strategy for aspiring seniors.

I don't necessarily agree with your observation. The issue here is that companies like Facebook hire a ton of entry-level (E3) engineers each year that come from their intern pool. Although many of them get promoted, not everyone can pass the bar. The need for more senior engineers is persistent in the company. Another thing to mention is that typically there is no headcount for E3 engineers at Facebook (besides returning interns) for external hires.

Not sure the source of downvotes, what you are saying seems true. From my experience they will generally not even interview a new grad who has experience for E3 jobs with an internal referal.

What do you mean "pass the bar"? Promotion is a process of supporting and grooming someone for advancement once they have been selected by the promoter. There is no bar to pass.

What companies do you know work this way? Most of the FAANG companies I know only promote you once they think you’ve met that level of proficiency (not to groom you into the position later)

This is a major issue that causes major frustrations to the people working on such companies.

I have heard similar comments from multiple FAANG employees.

It's worth noting that Facebook has a separate recruiting team for higher-level hires, starting at either IC5 or (more likely) IC6. In any case I know because it included me. From what I can tell, hiring at IC7 and above is so hard that the process for most candidates deviates in some way from what's usually described. I saw some really great hires (that might otherwise not have happened) that way, and some that were ... less great. Basically it increases the variance that the standard process is constructed to minimize at lower grades.

> The result of this failure is that job-hopping is the most valid career strategy for aspiring seniors.

The same is true at my work which is not FAANG, but one of the big four in its industry. I guess it's just the nature of corporations.

working at different organizations builds engineering and emotional maturity, no?

Perhaps, but rampant job-hopping as a norm is definitely not the outcome these tech companies aspire for.

Either this or junior/non-senior engineers at FB are already long gone before they have a chance to be promoted to senior because they job hopped somewhere else.

I interviewed at FB and Amazon last summer and I asked how long people stay once they are hired. At both companies I was told the average tenure is about 1.5 - 2 years. That was a big yiiiiikes moment for me. People don't stick around long enough to get promoted.

> People don't stick around long enough to get promoted.

Why do you think that is? Perhaps because the odds of getting promoted are smaller than hopping to a better position in a different company, which is what I argue.

If the odds of internal promotion were good enough, why would these employees take the risk and hassle of hopping?

Very good point and definitely something I can personally relate to.

RSUs from your signing bonus vest fully at 2 years (atleast at Amazon). A lot of people bail as soon as that vesting happens.

That screams terrible job. If it's a good place to work people wouldn't immediately leave.

It also says something about the people that are willing to stick around. Not good things.

This is not true. RSUs vest fully after 4 years. They begin vesting (meaningfully) after 2 years.

I don't remember the fully vest time at amazon but at FB it was 4 years.

IMO this is the wrong metric to look at. Any company that has experienced hyper growth (like FB or Amazon) will see very low average tenures simply because of math. The right metric is avg tenure at time of attrition.

Typically when tenure is mentioned, it’s only referring to the people who were hired and left (not people who are still working)

I think you’re misunderstanding the author. The sentence after the one you quoted is

> Most of these companies have solid internship programs, and almost all E3 (entry-level) positions are offered to returning interns.

The author is saying that getting an entry-level position without an internship is very difficult at these companies and so if you want to work at one, applying as a senior engineer is a much easier route.

FWIW, I work at one of those companies and have found senior roles and promotions to actually be pretty biased toward longtime employees

Not at all, Facebook does the best job out of any FAANG at promoting, and most E5+ are internal promoted. External E5 hires are less common, external E6 hires are rare.

Netflix does well here too (I worked there for 5 years). There are no levels for ICs at Netflix. You can hop over to the management track if you like which does have levels. But ICs can grow and take on more responsibility by their own volition. Your impact gets reflected in the annual compensation adjustment.

How can anyone work at Facebooks nowadays and have a clear conscience.

Is it just the salary? It is, isn't it? Just money. How depressing.

I know multiple people that have taken jobs at Facebook in recent years that feel it is a net negative in the world but could not resist the paycheck and justify it by committing to either by work hard as user advocates from the inside, or just finding open source work that doesn't directly exploit users to drain their resources on.

I for one have taken interviews at Facebook with 0 intention of working for them just because they have a tough process and it is good practice. Wasting some of the time and resources of an organization that inherently evil also makes the world that much better.

So, they didn't make you an offer.

How is Facebook inherently evil?

Turns out you got to pay bills even if you are on a moral high horse. Besides if one has to have a clear conscience to match everyone's standard here, one should stop working at FAANG, stop using FAANG products, maybe stop using big oil products, stop using big pharma products, is it ok to pay taxes to a govt if you don't agree with something they did or should one pick up and move too? what else did I miss?

HN is so much of a echo chamber lately for some topics, there was a recent discussion about FB head of integrity leaving the company and the top comment and thread was a personal attack on the FB CEO's integrity without even understanding what an integrity team/dept does in these companies. I could just as well have been reading youtube comments. I see threads with some topics now and I can pretty much be sure to not expect to learn anything new or get a good discourse. Just people thinking they are better than others.

You are doing a whataboutism just like many others. Among FAANG, Facebook is distinctly more problematic. If you don't see that, you are just unaware of the scandals upon scandals from the last 5 years.

True but I am tired of seeing a free pass for the leaders, legislators, board, share holders etc. but bring out moral pitch forks for engineers who perhaps have the least amount of decision making powers in a company as massive as FB/FAANG. I am willing to bet that even the ones here that are in disbelief about how one can work in such a company, I bet uses their products and/or is invested directly or indirectly with these companies and don't complain when their portfolio makes bank.

> least amount of decision making powers in a company as massive as FB/FAANG

They have the power to choose not to work there.

So one can use FB products to stay in touch with their family or engage with the customers of their business but one should be ashamed to work there.

Is one held to this standard if they are a facebook engineer? What about a FB bus driver? house keeping staff? kitchen or security staff, content moderators? contractors? Just trying to gauge the paycheck $ value at which the conscience should awaken.

It's like asking the frycook to quit his job because the CxOs lead the company to make very tasty but unhealthy food, it's so good it's almost addictive. Surely the frycook has a conscience, no? Soon all the frycooks in the world will refuse to work there and we would have solved the problem!

> So one can use FB products to stay in touch with their family or engage with the customers of their business but one should be ashamed to work there.

No, I don't think anyone should use any facebook tools either. It's perfectly doable.

The company needs to die.

Being more or less problematic shouldn’t be an issue.

If you have moral issues with a company, you should have it with all companies, regardless if one is more or less problematic. Otherwise, it’s just hypocrisy.

Give me a break, a job with Facebook isn't the only one that pays the bills.

Well you list the company name and enough ethical failings can be found for that also

I'm certain the small startup I work for hasn't failed too badly ethically. But I don't own a home in SF so... failure?

They may not have failed ethically yet.

It’s virtually impossible for a company the size of Facebook to be free of controversies.

But then I'd just find another job (when it was clear that something was rotten). There's an argument here about the ethics of having helped build something that ultimately became terrible, however I don't think inability to predict the future equals complicity.

>Turns out you got to pay bills

I'm sorry but if working for a FAANG is the only way for you to pay your bills you need to learn how to budget... How absurd.

FAANG aren't the only jobs that can pay bills but they certainly are one of them and as good as any.

An effective way to change a culture is to participate in it.

Changing a company's culture is nearly impossible at a startup, let alone a behemoth like FB.

Google did just vote to unionize, so it's not impossible, but very difficult.

Between 200 and 300 Google employees formed a union. Google didn't vote to unionize.

I could agree if by "participate" you mean come in as the CEO and clean house, like what happened with Uber when Dara took over from Travis.

You might possibly be able to do something as a high ranking HR person, but as a L5 engineer, the amount of cultural impact you can realistically impart isn't that big.

Did the current political situation in US (and most of the world) not teach you that it's really really dangerous to think that most people in your environment conform to your morality and agree with the sources you're basing it from?

You’re taking about the dangers of living in a bubble and from consuming misinformation, right? Two things that FB hasn’t exactly helped with.

There are many teams trying to fix the negatives of FB - sure you can’t fix everything but overall the intention and effort is there

Sincere question: How can an outsider like myself believe that Facebook is actually working to "fix the negatives of FB"? This is the same company that, in 2016, let Russian accounts pay for campaign ads in the US in rubles, according to Congressional testimony.

Facebook said they'd prevent such errors in the future by creating an election oversight board. Despite the fact that they had four years to prepare, their oversight board took their first case... on December 1st, 2020, conveniently after the presidential election was over--and hundreds of millions of ad dollars were spent.

I'm sure that Facebook has teams working on privacy and good governance. This is basically a public relations spend for them. Their business model is collecting as much data on people as they possibly can and then selling ads based on that data. The idea that "overall the intention and effort is there" seems laughable at best.

But, as someone who seems to be an insider, do you have any information you could share that contradicts that narrative?

https://thehill.com/policy/technology/358102-franken-blasts-...

https://news.yahoo.com/facebooks-oversight-board-announces-1...

I don't have the answers for if Facebook's good outweighs the bad, nor do I want to get into a debate. I'm just clearly laying out - and I understand that you mean well with the question and I hope others who understand this better will answer - that money and clout are not the sole reason people join Facebook.

Not everyone follows American politics and watches sensationalized American news media all day. Facebook is a great place to work, has some of the best tech in the industry and its products have done a lot of good for the world, especially in developing countries.

Facebook's impact on the world today isn't sensationalized (quite the opposite), nor is it exclusive to American politics.

I really wonder what good they have done. All of their initiatives are self-serving. And at the end of the day, no amount of good they do will ever make up for all the damage they cause to their users. I am not even talking about the American politics, just the amount of psyops tricks to get people engaged and addicted to the platform, manipulation of one's sense of wellbeing, the social anxiety they cause. They make Big Tobacco look like saints.

As for "being a great place to work" or "the tech": how much of soul-less drone one has to be to look at all this shit and still think "but the tech is cool and they pay really well!"?

Cigarette smoking causes about 480,000 deaths per year in the US alone. Does Facebook have a body count?

Yes, when you consider the people killed by its spreading of fake news, anti vax etc. For example, https://www.buzzfeednews.com/article/pranavdixit/whatsapp-de....

However that being said, if I got an opportunity to work at FB, I would.

Is the best defense for Facebook that they don't have a body count?

RIAA/MPAA does not have a body count. Patent trolls do not have a body count. Ballmer's Microsoft did not have a body count.

"Not having a body count" is quite a low bar for a moral compass, don't you think?

Facebook almost certainly has a body count!

Well, I have never applied to FB and don't plan to in the short term, but I can tell you that I don't see any reason not to.

They offer me a service which is quite useful: Keep me in some form of contact with long lost relationships I had while I lived in the UK, Germany and several cities in Mexico. I've done really good friends in those places over the years, and it makes me happy to see what's happening in their lives and even "react" to minor stuff that they post there after months of no interaction with them.

Before I had facebook (around 2004) I used to write an email every December to a list of friends I had from different places, just to make sure we had some contact. And I also used to ping them in chat (Windows Messenger), but the problem there was that the conversation was just "what's going on", "nothing here, what's going on there...." , "nothing". Whereas with Facebook, the moment one of my friends opened a tatoo place, I could write some small comment and we would "virtually hug" and exchange thoughts for a minute.

Regarding the "conscience" thing, Personally I don't see anything terrible that Facebook is doing. As long as people understand that this is the internet, and whatever you upload in ANY place in the internet is inherently public, all is fine for me.

>Is it just the salary? It is, isn't it? Just money. How depressing.

Of course it is. FAANG is just the 1980s Wall Street of our day. I can only pray that eventually people will realize how predatory and dangerous these companies are and decline to work for them. But Ivy League/Elite Uni grads only care about prestige and so as long as working there is seen as prestigious they will continue to sell their souls.

You can say that for any FAANG company really. I would rather work for Facebok than for the "cult" and $20 charging bricks..

They have differing moral foundations. I have no problem with Facebook. (I don't work there though)

Here's an honest answer

* spread of misinformation on the platform/genocide in Myanmar/election integrity - this to me is the scariest thing about FB, but also something the company is dealing with and working on and trying to get right. It's not an easy problem to solve either.

* Targeted ads - This really doesn't bother me. Tracking user interests/behavior and using it to serve ads they are way more likely to engage with, is creepy true, but also quite innovative and effective and the reason the company makes billions of dollars. It's hard for me to get worked up about showing users more effective ads. There are some interesting nuances around whether this should be opt in or opt out and giving users control over how their data is used. Some of this will be determined by laws which seems better to me then having it fall on individual companies. FB does give users control btw.

* Too much/not enough censorship - this topic is a complete shit show and no one agrees anyway on how much is or isn't enough. FB's stance is basically to remove hate speech and calls to violence and allowing anything else. I'm fine with that.

* buying out competitors like IG and What's App - it's normal for companies to do this and for the government to step in when it's too much

* Other misc. shady things - there's other things that come up from time to time. I agree that some of it is shady, but imo is standard for what you find in American capitalism: ruthless competition and cutting corners to get ahead as opposed to evil maliciousness towards users and subverting the law.

* Leetcode style interview questions - I have no problem with this whatsoever. The goal is not to ask difficult questions that trick candidates. It's to ask medium difficulty questions and hire people who can quickly and effectively solve them. Not everyone who fails the interview is bad, but the people who pass should be decent.

* Users getting addicted to FB and IG/it makes them unhappy - I don't have a strong opinion about this topic. I don't really use the products since they don't appeal to me. They do appeal to (a growing) many and I think it's a bit presumptuous to point to those people and say "but really it makes you unhappy." I'm open to studies and scholarship that say otherwise.

I'm not sure if I covered everything the OP had in mind, since they were not specific. Probably there are some other objectionable things I missed.

To your last point: the issue here is that Facebook is not interested in making users happy. They are interested in keeping them engaged so that they can sell ads. No studies are needed to show that if users' happiness or well-being gets them in the way of selling more ads, fuck the users.

It is no different than Big Tobacco putting all kinds of additives and carcigenic substances on cigarettes to get people more addicted to it.

No company on earth is interested in making their users happy, they're just interested in making money. This is some silly moral purity test where a company has to have pure intentions in order to do good. Our society works because people have the space & incentive to do good regardless of their intentions, and many Facebook users seem happy to use the service and find value in it regardless of whatever sinister intentions you might speculate of Facebook.

Though not direct, there should be alignment between what a business creates and offers and consumers' (society's) satisfaction.

"Users seem happy", the same can be said about smokers and tobacco. The issue is not even with the smoking per se. If tobacco companies were simply processing the plant and giving users what people have done for hundreds (thousands?) of years, it would be fine by me. The problem of Big Tobacco is in developing the mechanisms where they stopped satisfying consumer demand and artificially creating it.

Facebook (not just them, you can include actually all of Big Media) is doing the same thing to people. I'd be ashamed to work on FB, or Fox or CNN just the same way I would if I were working on Philip & Morris

I have to disagree that they're the same. You're right in saying that "user's seem happy" is not the only metric, but it's quite a stretch to go from "Facebook doesn't optimize for holistic well-being" to "Facebook is as addictive & harmful as Big Tobacco". It's certainly something I believe reasonable people can disagree on and I don't think it's appropriate to shame people for working at Facebook.

It's a little off-topic but honestly the idea that Facebook is somehow the the cause of all these modern problems is pretty tenuous to me. Most Facebook users don't go crazy & belligerent from use, the effects are not at all like the consistent & universal harm of nicotine and cigarette smoke. It suggests to me that Facebook might exacerbate existing problems, but it is not the straightforwardly harmful product that people claim it is.

You are missing the point. It's not a matter of being "as harmful" as tobacco companies. It's a matter of having a business that thrives by exploiting people's regulatory mechanisms to get them to do something that goes against their self-interest and well-being.

They don't have to be "the cause of all modern problems" to be frowned upon. Just the fact that they are part of the problem and not part of the solution is enough for me to want to get rid of it and to think poorly of anyone that wants to work there.

> get them to do something that goes against their self-interest and well-being.

This is where I stop agreeing with you. It is an established scientific fact that smoking is harmful to anyone doing it. Why are you confident that social media is also harmful or goes against people's self-interest? People choose to use it; they connect with people they know on it. Is there some study I'm missing that shows social media causes clinical depression or some other adverse affect?

editing: rereading what you wrote and it sounds like your issue is not that FB is harmful but that it is purposely addictive/getting people to do something they wouldn't otherwise. Hmm...when people talk about addiction like alcoholism, gambling, drug use etc. it's always connected to adverse affects -- like overdose, job-loss, divorce etc. The addiction interferes with a person's ability carry out their normal responsibilities. People are not becoming homeless because of Facebook addition. You could make a similar argument about caffeine which causes chemical addiction to change people's behavior but is widely accepted. BTW how do you feel about World of Warcraft addiction?

AFAIK, no coffee producer competes on the basis of having the coffee beans with the most efficient caffeine delivery rates or gets a premium for being more addicting than strain A or B. Starbucks' stock price is not affected by how addicted to caffeine they get their users to become. If the consumer base decided to switch 100% to decaf coffee, they would still have a profitable business just the same.

WoW addiction? Bad for sure, but Blizzard does not make more money in direct correlation with the time that the people spend playing, do they? Does a 3h/day gamer makes only half the revenue of a 6h/day gamer? I guess not.

You keep using "addicting" in a misleading sense. Facebook does not optimize for addiction, it optimizes for engagement. The addiction that makes nicotine and other substances so harmful refers to the physiological & psychological dependence these substances create. Repeat engagement is not the same as actual addiction and it's misleading to conflate them.

Coffee companies do the same, their goal is that you repeatedly come back to consume more of their coffee, decaf or not. The more frequently and voraciously customers consume their coffee, the more money they make from coffee sales. You think they don't also market test coffee variations for popularity?

Almost every company in the world optimizes for more; more consumption, more usage, more sales. The idea that Facebook is somehow in a league of its own for how it optimizes is clearly not true.

Whatever you need to tell yourself if it helps you sleep at night...

I am using the term in the same sense you are. People feel dependent on their social networks, their apps and even declare to feel things akin to withdrawal syndrome when they are away from their devices or haven't checked their networks for updates.

And again, the fact that "other companies do similar things" is not an excuse, less so due to the fact that Facebook has way more reach and uses technology that can amplify their effectiveness infinitely. I don't have Starbucks baristas knocking on my door offering me coffee, I do have Facebook listening to conversations inside my house because of my wife's phone.

Nevermind all that.. you'd have to work with PHP. No thank you.

Got offers from almost every FAANG last year. Decided to join FB, and it was not about money (in fact it depends on your negotiation skills). The reason I joined was the culture and people who work there as well as growth opportunities. One might say PSC are stressful but that depends on personality. I don't know why I should not have clear conscience. Should kitchen knife company be also upset about people are being killed by it?

Do knife manufacturers make more money by making more lethal knives, the same way that Facebook make more money by getting more eye balls and manipulating more of people's perception of and interactions with society?

Ahh, so they're not actually looking for seniors then? Sounds like they want people who are "passionate" enough to spend months prepping for an interview so they can milk them dry without the risk of pesky things like "free time" and "family" getting in the way.

Tongue in cheek analysis aside:

- A phone interview to weed out timewasters.

- A RELEVANT technical take-home task that could be done feasibly in a few hours.

- A long, informal, in-person chat to determine "culture fit" and personality.

- Actually checking references.

That's all you need, anything more is just self-importance - or worse - time wasting.

I interviewed a bunch of fb E4s at previous gig and yeah imo not a lot of them would have senior title if you rewind industry say 10 years back. Once you deviate from their canned prep it all falls apart. They’re almost all very good with basic algo stuff tho

technical take-home task is mostly time wasted for the candidate, working for hours just to be ghosted again and again, you will be selecting for people who have nothing better to do.

I'd skip that (and leetcode) entirely and during in-person chat put emphasis on discussing prior projects in detail.

As for "system design" ask a question on your current architecture, how would they approach solving a particular problem you actually have/solved, and see what questions they ask.

That's how good people who built the tech industry used to get hired in the old days (i.e. when they were not friends of friends)

"Prior projects in detail" is a great idea until most of your desired candidates can't do that because of NDAs. Most of my NDAs do not permit me to discuss anything except the broadest strokes of my past projects.

I've been programming professionally for 12+ years. I haven't had a need to look at CLRS since I took my graduate (!!!) algorithms course in college.

I don't work in FAANG, but I am a senior developer in another industry. It would take me way more than two and a half weeks to work through all of the problem sets in CLRS; two and a half weeks is more for someone who is a year or two out of college. I don't think being able to work through the problems in that book is indicative of a senior developer either...

Anyway, this is why I'll probably end up never changing industries. The barrier to entry is (too) high; especially for those of us who already make comparable money.

I don't think many people who got a job at these companies used CLRS to prepare for the interviews. At least not the ones I know. There's a reason leetcode is so popular. In my own experience you really need to know how to solve the typical easy/medium questions quickly, interviewers themselves don't really want to ask hard questions. The infamous CTCI covers them, EPI is better from what I've heard.

The author suggests studying Programming Pearls. Bentley wrote there:

As soon as we settled on the problem to be solved, I ran to my nearest copy of Knuth's _Seminumerical Algorithms_ (having copies of Knuth's three volumes both at home and at work has been well worth the investment). Because I had studied the book carefully a decade earlier, I vaguely recalled that it contained several algorithms for problems like this. After spending a few minutes considering several possible designs that we'll study shortly, I realized that Algorithm S in Knuth's Section 3.4.2 was the ideal solution to my problem.

Why is vaguely recalling an algorithm studied years prior and needing to look it up indicative of a poor candidate in an interview?

> Why is vaguely recalling an algorithm studied years prior and needing to look it up indicative of a poor candidate in an interview?

The article does not imply that it does.

The article doesn’t but I think OP’s point was that relying on knowledge / algorithms designed and provided by others would mean an immediate fail in a FAANG interview, but it’s exactly what successful engineers do when employed at FAANGs.

And the reason is that you have to stand out from other candidates. If enough candidates do know algorithms on the whiteboard, then they can set the bar that high.

As someone who just went through the FB E5 interview process and got an offer, this is largely incorrect. Or, doesn't reflect how my E5 interviews goes and doesn't match up with what I've heard from friends. This is all anecdotal of course and based on personal experience.

1) DDIA is way too deep for E5, system design or product design. In general, the book is just too deep for any interview. It's a fantastic book but it's dense and too detailed for a 45 min interview.

2) The system design interview is largely around communication and thought process, not spouting techniques and flexing. I feel like candidates have a fundamental misunderstanding of what the system design round is and why it's used. It is not simply a time slot to rattle off design concepts.

3) The big elephant in the room are the coding questions. 2 med/hard per coding round, and you need to nail it all. Not only that, but expectations are higher. So no bugs, test all your code, perfect one shot solutions in optimal time complexity. This is very difficult to do under pressure.

4) At E5 level, I found the system design portion fairly easy. If you've been through the sys design interview before or currently work as a senior, it won't be a big deal. I think people are blindsided by it because they are trying to up level themselves from L4 or E4, and then hit the "senior wall".

5) Behavioral is really important. Unfortunate to not see this being mentioned.

tldr, E5 is hard because of the coding, not the system design. The system design at FB was similar to design questions and depth for all the major tech companies (MS, Amazon, Goog, Apple etc)

Re 3 really seems over kill an unrealistic for an interview, and maybe some times you don't need optimal time complexity.

And TBH with a background in real technical computing I would probably look at buying in any required algos in from people like NAG.

Your not really testing for those that can think outside the box in this style of interview.

That's what I thought too, but I've heard from friends that didn't get offers that not getting the optimal solution is a reject. Even things like O(n) to O(log n). I don't agree with it at all, just communicating what my experience has been (and people I know that have gone through it).

Obviously this is completely anecdotal.

Posts like this remind me immediately why I stopped bothering to apply for software jobs at other companies and stayed at my current place of employment to climb the ladder. The interview process is almost universally terrible and consistently tests you on a nearly useless subset of computer science that doesn't correlate well to actual implementation practices in the event you are hired. It really is a painful process, and probably needlessly so for most cases.

This definitely isn't the only post you'll need to read, because it doesn't talk at all about the behavioural interview. Which at Facebook is actually one of the most important factors in terms of job levelling.

The more senior a level you're aiming for the more important the behavioural interview becomes (because the less the job becomes about pure technical skill, and the more it becomes about people).

Unfortunately - or fortunately, depending on your perspective - the behavioural is also one of the harder interviews to prepare for.

CLRS is over 1000 very dense pages. I assume the author just did a fairly casual reading and didn't work through many problems.

Even still, this is a full month of study just for the interview process, and little of this sticks unless you practice it. This basically says to me that big companies just want to hire new grads or people who have copious amounts of free time to waste on studying, or perhaps enough wealth and freedom to take several months off (someone I knew with several children and a dependent wife took 3 months off to prep for interviews and got multiple offers! But this is only possible if you are already wealthy because of the high risk involved and lack of income).

I'm not saying I haven't done an extensive amount of prep - I own 3 of the 4 mentioned books plus CTCI, though I've only read the latter and DDIA, and I just did advent of code 2020 - but I'm a man with a remote job and no children and it's still a pain for me to stay at my current level of being moderately competent at algorithms. And then, of course, you'll get into BigTech and spend time fiddling with frontend components or configuring infrastructure or gluing apis together and you'll never need any of this again - with the exception of the content of DDIA, which would be a much better focus for senior engineering interviews and you end up learning/using a lot of this in practice.

> CLRS is over 1000 very dense pages. I assume the author just did a fairly casual reading and didn't work through many problems.

When I saw his day to day plan include things like chapters 22-26 of CLRS, I thought the same and casual might be an understatement unless he has read this book multiple times already.

DDIA was by far the preparation reading I've enjoyed the most. I'm currently reading it again. It is so eloquent and fun to read but other than just the fact that internalizing these topics to a level where one can feel comfortable discussing and reasoning about them, you can also use this book to navigate a deeper learning path through its many footnotes.

He also mentioned in his article:

> When studying CLRS or PP, it’s essential to solve the exercises at the end of each chapter. That will help you to solidify what you have learned into your brain.

That's what boggled my mind when I read this. There's no way that he read multiple chapters of CLRS a night and did all of the problems at the end of the chapter. I've done most of those exercises; some of them took a long while to get through.

I guess that's why I take issue with the advice that is given in the article. It is kind of unrealistic for any 30+ professional with a family, children, etc. to study this much for an interview.

> CLRS is over 1000 very dense pages.

CLRS is in fact over 1000 pages, but it's not very dense, quite the opposite. It goes in painstaking detail about every single minutia you could possibly be thinking of, often formally proving things that everyone with even a modicum of mathematical education should be able to independently come up with a proof for (white path theorem, anyone?).

All of that is great for beginners (there's a reason it's a standard textbooks), but I remember that even when I was in school I found it a little too verbose and used to prefer the Sedgewick.

With that said, I still agree that the author's timetable is very optimistic.

I recently interviewed at Facebook with ~10yrs experience. I didn't get an offer. Their process was really quite rudimentary compared to the other companies I interviewed at, namely Google who I see as their most direct competitor for engineering talent.

* Every single coding problem was about iterating over a string or an array and doing something with it. Seemed like there was no coordination at all on what's being asked from one interviewer to the next. For a senior infra engineer interview I'd expect them to touch on concurrency, or service architecture, or recursion, or debugging, or... anything besides strings and arrays (which I'm good at!).

* The system design question they asked me was about how to design a frontend feature for live-updating comment chains. I understand the ideal that the questions are so high-level that it's an even playing field regardless of background, but the reality is that every problem is going to be close to _someone's_ domain and far from someone else's. I wish they had chose something at least related to infrastructure services, because I don't even know the 101 on how social media frontends work.

* The interviews didn't include any time for me to ask meaningful questions of the interviewers. I was assigned to engineers at random, rather than based on where I'd likely be working.

* None of the interviewers conveyed any enthusiasm about giving the interview. I could tell that speaking to me was a chore distracting them from what they wanted to be doing.

Overall the process felt haphazard and low-effort, like I was Candidate #24601 in the machine for the week. Stark contrast to Google, where the interviews left me _more_ excited about working there, despite Google being more than twice Facebook's size. Fortunately I didn't get the job so I didn't even have to ponder any ethics questions :^)

> The big tech companies will not get pedantic on the language that you decide to use in your interviews.

Ten+ years ago, but I received an email minutes before my second phone interview with Facebook that they were passing on me for not being adept enough with JavaScript.

I was supposed to be going over a take home project with the team on that call. They never even saw the project I’d spent the entire weekend on, and I’m still salty.

I'd try and view it positively: you dodged a bullet in that you avoided working with a shitty organization that does things like that.

If it's a front-end position then that makes sense, considering there is really no alternative to JavaScript (or rather wasn't 10 years ago).

While it was indeed a front end project. I was not _unskilled_ or unfamiliar with JavaScript, and had been working with it since the late 90s. I made this abundantly clear going in. It just had not up to this point been my focus, but I was very excited to grow into the position.

They could have at the very least looked at something they had me spend hours on. Honest to god, if they'd had a single person cast eyes on it for 15 seconds I wouldn't hold this grudge.

I still have the code in a private repo on GitHub and looking at it now it's very clean and with small exception not unlike code I would write today.

They passed on the WhatsApp guy too and that cost FB $20 billion. So moral of the story is start a startup!

While I agree that these interviews can be a bit much but what's the alternative? If I am a job seeker I feel much more comfortable knowing that they expect me to write code and answer DS+Alg questions and prepare for it as opposed to companies selecting based on the the prestige level of the University you went or based on subjective judgments based on the resume and/or company fit. As someone who went to a University in Canada that no one working at big tech companies in SV would have even heard of I appreciated that I was given a chance to show my skill as opposed to them just hiring out of Ivys/Stanford/MIT or other big name schools (like what happens in Law).

I also hate the new trend of "take home" tests. That just seems disrespectful of the candidate's time.

People are just salty.

Not at all. You're going to give me a take-home, and you're I've only got a 2% chance of getting hired? Get lost.

That's not "salty". That's refusing to be exploited.

>While I agree that these interviews can be a bit much but what's the alternative?

So somehow literally every other industry on earth has figured out ways to interview people that don't involve whiteboard hazing but you think there is absolutely no alternative? Have you actually thought about what you are saying at all?

Might want to check linkedin because I can guarantee most of your bosses are from Ivys/Stanford/MIT/etc

>I also hate the new trend of "take home" tests. That just seems disrespectful of the candidate's time.

But doing leetcode for 2 months is somehow better? Are you high?

> I also hate the new trend of "take home" tests. That just seems disrespectful of the candidate's time.

And there lies the problem: I would prefer a take home test way more than whiteboard interview. With the take-home test I would feel more comfortable.

As a VP of Engineering in a growing startup, I have to deal with interviewing 2 or 3 candidates every week. We have settled for a process which has given us good results. But for me the key has been to avoid taking tests "literally" but use them more as tools to get to know the candidate.

To give you an example: I have had jr people that did too little in our "onsite" (a 3 hour coding challenge of modifying some source-code) but at the end we took a chance and offered 3-month internship with possibility of becoming full time after that. We have had success with that.

I've had people who just flunk the interviews but I see something in them and we take a chance. Similarly, I have seen people that pass the interview pretty well but it so happens that they are just not cut for a startup culture (I had a guy coming from a"big corp" Tata/HCL/Cognizant/AmDocs kind of culture who struggled to strive in the uncertain and dynamic environment of a startup, after several months, we decided to end it (the nice thing in Mexico is that, by law, we paid him for 3 months severance) because both sides were suffering.

A take home test is fine as long as it is expected to take < 2 hours. One company expected me to spend a whole day on their test and it's like I'm sorry, I don't have time for that.

The alternative according to HN is to just recognize my genius based on my resume and what my friends say about me, and throw an offer at me.

I'm not interested as I think it would be hypocritical and immoral for me to persue a job at Facebook. Considering Facebooks current issues I'd be interested how people would justify this career path to themselves.

It's like wanting to sign up for the UK armed forces in the middle of the Iraq war. Like, it's a really bad idea. What are your principle, are they summed up as "I want as much money as possible and who cares how"

I'm surprised how far down I had to scroll before I found a comment like this. I was approached by a Facebook recruiter twice in the last year, both times I gave a polite "not interested", with a list of reasons why.

Some people probably _did_ sign up for the armed forces in the middle of the Iraq war. Not that I agree with them, but they probably saw themselves as patriots. Sometimes people just have different morals, try speaking to people who work in the MIC and you’ll notice that they all think they’re doing good.

You can simplify the coding preparation by just getting a basic LeetCode subscription, filtering down to problems asked at Facebook in the last six months, and then sorting by frequency (how many times each question has been asked recently, according to user reports). CLRS, etc., are nice books, but if you're seriously considering a senior role at Facebook presumably you already know the basics and just need to memorize all the tricks for LeetCode problems.

For system design, though, it actually is worth reading through "Designing Data-Intensive Applications."

Yep, most of their questions are straight out of leetcode.

> Day 12 — CLRS (ch 22, 23, 24, 25, 26)

> When studying CLRS or PP, it’s essential to solve the exercises at the end of each chapter.

I spent the last 2-3 weeks of 2020 going through these exact chapters, 22-26 (solving every exercise and problem) and it took me about 15 hours a day. Toward the end of chapter 26, it got extremely difficult (Goldberg and Tarjan's push relabel algorithm for max flow).

The suggested schedule is ridiculous, and I am not convinced it’s a good way for preparing for the interview.

Still, the author didn’t say that he actually got the job.

The author is already employed at Facebook.

> People must avoid using less mainstream languages in their coding interviews as it’s possible that your interviewer might not be familiar with those languages.

As a former FAANG coding interviewer, I would disagree with this. Use your strongest language: being visibly fluent in any language gives a much better impression than trying to stumble through in a language you're rusty or unfamiliar with. The interview is (meant to, anyway) focusing on your thinking process, logic and data structures, not the details of syntax.

I would avoid functional languages like Lisp or Haskell though, they're just too weird/different for most people and you risk coming off as an impractical idealist.

This just confirms how terrible FB's hiring process is. If you ask candidates questions about things they won't use on a weekly basis you're doing it wrong. No one should have to study for an interview.

Sad to see that FAANG is so attractive - sure, pay is nice, technical problems are nice - but you are actively working on walled gardens. You become a walled gardener.

Hey, someone's gotta paint the roses red.

I used to believe that when I was younger.

Now that I'm older, I'm understanding of people optimizing pay and intellectual challenges. At the end of the day, people have to optimize for their own interests because the world sure as hell doesn't care about your or my sacrifice. Even my best friend who took a job at a non-for-profit for many years helping those in need eventually joined BigCo to be able to afford things in life.

Yes of course. You have to give in at a point, because you have no options, it's probably simple as that.

Most of the people I know who did competitive programming in high school spent a just a few evenings preparing for FAANG interviews and still got offers in the end.

I have the feeling that all the bitterness towards this interview process comes from people who refuse to do the initial investment of time to learn the foundation for solving coding challenges. Once you go through and understand a few hundred coding challenges, things start to repeat themselves and then it just takes practice and consistency.

Personally, I find coding challenges fun and even quite enjoyable at times, so I don’t see why it’s a waste of time to get good at them. At the very least, I learned a lot about Java doing them than I would‘ve learned if I did a side project where I‘d need to use some framework or library that’s based on Java.

Edit: grammar

In my experience, most people who do coding challenges are the younger folks. As we get older, we have better things to do than do coding challenges, especially a "few hundred" on our spare time. They might have other hobbies or responsibilities.

ditto. I like to play with these as a fun intellectual challenge, even though I've never been interested in FAANG.

The problem is that coding challenges are OK if you are hiring for an entry level position and need to make sure that the fresh grad can actually write some code at all (surprising amount of them does not).

However, what exactly are you hoping to achieve with this when hiring a senior engineer who is likely to have 10+ years of experience in the field? With verifiable references?

You are only wasting everyone's time. Sorry but I am really not going to spend a month preparing for a single interview where I have no guarantee of neither an offer and not even knowledge of the team/project I would be working on (Google recruiter calling me seriously thought that this is normal - you apply "blind" and only after passing through their hiring "torture test" of 7 or how many interview rounds you get told which position may be "the best" for you. I said "No, thank you" and hung up.)

The issue with this is that you are both testing the wrong skills (senior engineer really shouldn't be doing basic algorithms but system design, leading teams and managing projects!) and that this is "senior engineer" position is likely senior only in name because the recruiters want to attract more competent people. In reality it is an entry level job ...

You're taking a personal feeling and extrapolating onto others. Not everybody finds sitting on leetcode 3 hours a day a fun task. I'm one of those people. It's absolutely mind numbing.

A few hundred coding challenges is months and months of preparation if you're actually trying to internalize everything very well. Kudos to those who can do it and have the willpower to, but I can't seem to get past 3 weeks tops before my body starts physically rejecting these problems.

It also seems to skew towards recent grads and single people that can spend all of that time on these problems.

the problem is that DS/Algos interview questions, besides deep in low level programming, have little relevance in real life work scenarios. The only thing of value that my formal CS education gave me in respect to my day to day, really is the ability to problem solve.

Also, the reverse can be said about this - that individuals who had a more formal CS education are feeling bitter that more and more people are starting to realize that their time spent in "coding challenges" prove to be of low value in their work, so they keep hammering them in the only place they can - interviews.

Mainly it's just annoying if you've been working for 4+ years and haven't touched that stuff in a while. It's an entirely separate skillset separate from your role as a developer. The fact that there have now been several studies showing it doesn't correlate with job performance makes its emphasis in interviews questionable.

There's also some fear on the "poseur" factor that people worry about. If candidates can simply rote-learn their way into senior roles I wouldn't really feel comfortable having them as team members.

With that said, I do like think the advice of reading Programming Pearls and Designing Data-Intensive Applications -- two books useful for the job at hand, and just your general knowledge of how systems work and how to approach problems. Leetcode, by contrast, is empty calories.

> I have the feeling that all the bitterness towards this interview process comes from people who refuse to do the initial investment of time to learn the foundation for solving coding challenges.

My bitterness comes from the fact that the interview process does not reflect what happens in day-to-day work. If I had to invert a n-ary tree, I would google how to do that, which I can't do during the interview.

> Once you go through and understand a few hundred coding challenges, things start to repeat themselves and then it just takes practice and consistency.

Assuming you spend about an hour to solve and understand a given coding challenge, that's a couple of hundred hours. Assuming an hour a day, that's about 3 months for 100 questions. That's not a trivial amount of prep.

>Personally, I find coding challenges fun and even quite enjoyable at times, so I don’t see why it’s a waste of time to get good at them.

Personally, I would prefer to spend that time enjoying my life. Whatever floats your boat.

> Personally, I find coding challenges fun and even quite enjoyable at times, so I don’t see why it’s a waste of time to get good at them.

You really can't imagine that someone feels differently? Please try to have a more open mind.

I, for one, would much rather spend my free time on my side-project that is actually used by people. I would have a hard time working on something that was a throwaway. (Which is what actually happened when I tried to interview at FB. I spent more time working on the side-project than studying leetcode. FB promptly told me I couldn't code... "OK")

I think we have a thread about software interviews every week, with the same discussion topics. Isn't this a problem solved by technical certifications? I mean, if the Top 100 companies do the same tests over and over again, with a very similar mindset and process, why not delegate that to a third-party? Then you just hire people that have Certification X, which matches your lust of algorithmic puzzles or whatever.

I'm fine with meaningless tests that don't prove anything, as long as I don't have to do them for every single interview. I would gladly study for a certification, because it means I get to do it once and then I can prove everything you want me to prove in order to get a job to change button positioning.

That seems like something you could build. There's a handful of YC companies working on that.

I don't think FANG companies are likely early adopters of that. They are all relatively conservative with hiring. Navigating the organization to find an internal champion who's incentives are aligned seems really tough. Internal established recruiting teams seem disincentivized to use a 3rd party certification. Using that might reduce the number/importance of the internal recruiting team.

The advantage is that it would reduce total recruitment cost and burden. I mean filtering on a CS degree and school should be enough but apparently it isn't. There are also non-traditional programmers. There's a finite set of reasonable problems so there will be some difficulty in hiding the answers when you have access to Google vs in person.

Outside of that, the most important skill is gathering requirements, gathering requirements and gathering requirements. In the startup world this is called finding product market fit.

System architecture design and computational thinking are also necessary but I don't think any software engineer can do those well without gathering requirements which is basically about identifying product market fit within your corporation.

There are several problems with certifications.

The first is that the certifying authority gets paid by the candidates. Therefore the trend over time inevitably is to make the certification easier and easier to get so that the candidates keep paying them.

The second is that the field tends to move more rapidly than the certification. What does a certificate from 10 years ago about how well I know Python and JavaScript tell you about my current skills as a developer? Not a whole lot.

There are reasonable certifications out there put out by companies for those who wish to work on their technology stack. (Open source, not so much.) The company has the resources and motivation to make sure that people who are certified for their technologies are going to be reasonably competent. But now the certification becomes a sales pitch. The company shows you how to use the latest version of all of their tooling with all of the optional side products. You go out into a real company and they are a couple of versions behind and didn't license all of those optional add-ons. You, the certified expert, are likely to become the person asking for everything to be upgraded and for a ton of new licenses for stuff that is only marginally useful. This isn't necessarily in the company's interests.

True story. Many years ago I worked at a large FAANG. To limit how much time was wasted on bad candidates, they built a machine learning system to filter out bad resumes. In practice it was better than a recruiter at identifying promising resumes, but worse than a developer. But it limited how much recruiters had to bug developers with bad resumes.

The machine learning system picked up all of the things that you'd expect. For example someone who thought it important to list Microsoft Word as a skill probably isn't a viable candidate for a senior software engineer.

But the single strongest signal that it picked up was kind of interesting. At the time the MCSE (Microsoft Certified Solutions Expert) was one of the most popular certifications around. Anyone listing that was unlikely to be worth interviewing.

Even the ethical questions about working at facebook aside, as an engineering environment fb doesn't seem like that great of a place. Kent Beck was fired from fb, he worked there for a few years and shared his experience of the culture there https://softwareengineeringdaily.com/2020/12/10/facebook-eng... It doesn't sound like a place I'd want to work at.

Edit: Updated the link to the right podcast.

I'm not at the level of a FB Senior SWE, but how does one do anywhere from 1-5 chapters of CLRS each day? Doing a single chapter of CLRS would take me multiple days.

Is it that I'm just that far off from the level of a senior SWE? Can most of the experienced, talented programmers here cover multiple chapter problem sets of CLRS in a day?

Exactly so, if they can actually read, understand, internalize and apply the dense content that CLRS delivers, 5 chapters a day (and mind you, he mentioned some of the more dense chapters in one of these 5 chapters days), that would have made for a much more interesting post.

I would never recommend anyone to try and read CLRS in two weeks, or even a month. Even if you could do that, I think it would be much better to get through a chapter then try to apply the algorithms of that chapter to Leetcode/Codeforces question and cycle through the subjects as you advance through the book in a spaced repetition technique.

For me and for many other people the linear approach for studying that they suggest is far from ideal.

I passed a Facebook Infra interview three times: 2007, but I declined the offer (whoops); 2009, accepted, worked there for 4 years as an IC5; 2016, returned for 6 months (whoops).

The 2016 interview was much harder due to the influx of leetcode-style questions. I don’t think I’d pass one in 2020.

Sleep well, Eliminate stress from life, get a decent job that allows you to explore things you want to do on side, spend time with family and lead a happy life. Note that this is a very ambitious route to follow, most people never understand this or get to live like this. But if you are super ambitious and have a domain that you are interested in, go create a product, become an entrepreneur. There is nothing as rewarding. Please don't stress and burn yourself out for a job.

Been reading, "Disciplined Minds: A Critical Look at Salaried Professionals and the Soul-battering System That Shapes Their Identities"

https://www.amazon.com/gp/aw/d/B008GRDKPG/ref=tmm_kin_title_...

It's seems like qualifying exams seem to mirror tech interviews in structure and purpose.

got to last round for E6 and found it frustrating. Answering the technical questions required intimate knowledge of production systems that scale to billions of users with proprietary hardware (i.e. no cloud). It seemed to require previous experience at facebook, google, or amazon.

How was your overall experience through all of the rounds?

The first 3 were fairly standard and can be practiced using the booklet and/or leetcode. I found the facebook recruiting process to be very organized.

A warning from a Python developer & hiring manager: The Python used in Elements of Programming Interviews in Python is NOT clean or idiomatic. Perhaps they designed it for whiteboard-style interviews, but if you walk into a Python shop that does stuff with coderpad/screen-shared you code like in the book you're not going to make the best impression.

As a person working in Facebook for 7 years I feel like this post is incorrectly portraying FB's process and culture:

- First, Facebook avoids titles, so there's no such thing "senior software engineer". Levels are generally unknown by people so ICs get judged by their ideas, and not their title. - If there was such a thing as "senior" in Facebook, it's not starting at the E4 level. (If you look at levels.fyi and align the Facebook levels with Google you might get that an E5 is a senior) - This entire list of chapters of CLRS chapters is ridiculous. It's a great book and I'd recommend it for people into theory and who will be around Computer Science. But if you didn't go through a college degree and algorithms course, and need to interview, do yourself a favor and go directly for LeetCode or Cracking the Coding Interview. YMMV as to how much you need to learn. Some people I know can easily breeze through these interviews with no prep, those people are also super smart. Some smart people I know have a harder time, no system is perfect. - To actually get hired in one of higher levels at Facebook you will need to go through the design interview, which is a very different type, and the career experience one. No matter how well you ace the coding, you will not get an offer for a high level if you didn't succeed adequately in these. - All of my coding questions in the last few years required knowledge I learned in my first year learning programming. This is usually the norm.

Of course, this is my personal experience at Facebook, but it is based on quite some time and a lot of interviewing.

> First, Facebook avoids titles, so there's no such thing "senior software engineer".

How egalitarian. Let me guess: you are an IC6, or perhaps IC7? You just give off that vibe.

I joined Facebook 7 years ago as an IC3, and am still around so you could probably do the math.

Had the same vibe to me when I was a new grad (well, maybe a less polished one) and got a lot of respect then. I also knew which people I enjoyed working with and trusting without ever knowing their level. I could make an educated guess of course. But those cases when your guess is wrong are the important ones.

This is all not to say there's not plenty of issues with this system, and I totally get where your snark is coming from, but I would personally still stand by this idea over many of the alternatives.

Good that it’s working well for you! :)

It is worth noting that interviews vary a large amount within Facebook depending on which organization you report up through. While I’m no longer at Facebook, I used to interview a number of senior engineers within AR/VR, and cramming CLRS would not really help with our Ninja loop at the time. Maybe it is different now?

Actually, I don’t need to read it, as I would never work for a company like Facebook - Facebook itself least of all.

One thing to note is that FB has two system design interviews. There is an "infrastructure" track and a "product" track. The former is like the classic sys design round described here, but the latter focuses more on APIs and application level design.

It's interesting that the same questions apply to both a mid-level + senior-level technical interviews, but the answers+prep can be quite different:

* Mid-level: Mostly topics you can learn in your 2nd/3rd year of college + having worked on 1-2 web data projects. Basically performing recall on textbooks and architecture powerpoints.

* Senior-level: You can always go crazy on the same technical topics, such as by replacing "recite a paragraph from your old CLRS textbook" with "... and here's how that'd look on a multi-gpu/asics cluster". I didn't see anything directly on technical leadership, so maybe rethink the architecture questions from team/HR + product design + company/LOB perspectives. Weirdly, prepping at the CLRS-level seems like you're aiming for a more junior technical role / org, and I'd think more about 'revisit track record' and 'networking' than 'prep'.

Curious how FB folks see that -- I'm probably misunderstanding something as there's a wide spectrum between 'Mostly knows how a production system works' and 'Ready to lead tech for a new team/LOB'.

The best way to prepare for a fanng interview is to have friends there and get fast tracked on easy mode.

FB rejected me twice and both times I followed a study plan much like the blog and in my case it turned out that I got too complicated with it and spent too much time on cool shit like dynamic programming, tries, all-pairs shortest paths but I should have stuck to drilling the simple data structures like stacks and BSTs cause that is all I ever got asked about.

I also got backchannelled during the behavioral the 2nd time around which I suspect may have been defamation. In the end my fan club did me a favor helping me dodge a bullet because I probably would have accepted an offer until I read about how bad morale at facebook really is (which in hindsight was reflected loud and clear in the conduct of the aforementioned behavioral).

One thing I have noticed about remote interviewing in general but especially with facebook is how disgustingly filthy some of the panelist's backgrounds were. During the portion where the candidate is allowed to ask questions I wanted to ask "Damn, you live like this?"

It seems to me to be almost superhuman to read multiple chapters and solve all the exercises in a single day. Maybe that's just the normal level of ability for FAANG staff?

EDIT: maybe it's more reasonable if you're doing this full time. 1hr/question and checking the next day if you get stuck, as he writes in his blog, seems a lot more reasonable.

> Maybe that's just the normal level of ability for FAANG staff?

Based on personal experience, I think you certainly need to be "above average" to get hired by the big tech companies, but it's more like "top 20% of graduating class" and not "only the very best."

When I was a little younger, my dream was to land a job at a FAANG company, although I was thinking Google. Nowadays, I'm disgusted by the idea. Large and bulky internal processes, levels, interviews testing useless shit and constant controversies from management decisions. Now I'm actively avoiding anything that's like these.

The question for those of us that aren't leetcode fans - what are we going to do about it?

We should make it easier for people to get a job without leetcode. Here's a job board I made for jobs without leetcode. https://say-no-to-leetcode.netlify.app/

Also https://github.com/poteto/hiring-without-whiteboards

Interviewing at some of these companies has become less about skill and more about having an abundance of time free from other responsibilities (work, family, etc). Perhaps that's the selection criteria intended since it indicates ability to work long hours?

I like their interview process (minus the leetcode grind that’s been happening lately). They focus on fundamentals and core CS knowledge. Other company interviews, like mine, focus on knowledge or current trends, which change over time.

I read some devs simply did 1-2 months of interview training to get such a job.

Learning what they ask and how to solve it.

Had nothing to do with their work there, but it sure was a good filter against unmotivated people and idiots.

I wonder who the author was thinking of as the audience to this post? It looks like a manual that's targeted at young software engineers to recruit them into FB. And by proxy, the agism that goes on in that company.

I just can't imagine a senior software engineer needs to be told that they need to pick a language to solve puzzles in, "I decided to go with Python" or being reminded that "To refresh my knowledge of the language" is a wise thing to do before an interview.

I bet this guy is a manager.

If you can read CLRS in a month thoroughly, the developer deserves more than a Senior Software Engineer position at FB.

Pick a language that you don't have to "brush up" on before your interview -- the one that you work with on a daily basis and know like the back of your hand. Bonus points if it's a language with which the interviewer is less familiar.

Facebook is unethical, immoral and destructive to human nature. No merit working there.

I deeply regret clicking this. I've never worked with FAANG however I've been through 5-6 interviews. The way I see it, it's material that can be studied/recalled but you can make much more difference in your life with that amount of energy, unless you're a new graduate OR your job is interviewing other people. I understand the side effects that study can bring on to help ease the pain, though it won't work if you only rely on knowledge alone. That's where experience/context helps. Just be aware that fangs are not a measure of what a best software engineering can be, they're the ones make use of their branding well as a high entry wall. So please do yourself a favor and don't take the harsh to your heart, keep enjoying what you do.

Yes, please join Facebook and destroy what little is left of our democracy.

Do people have any pride? Why would you subject yourself to this?

300-500k/yr total comp

A post about hard work and diligent learning about CS concepts followed by an offer from a top-tier tech company will always be greeted by a bunch of dinosaur software engineers who feel entitled to a job in this industry for life purely because they have some arbitrary number of working years.

If you're applying for an IC role, code or shut up. I don't care if you have solved wicked problems before, it's all talking and hand-waving. Can you take a hard problem, and apply CS concepts and good ole problem solving to produce working, succinct and well written code? That's what you're being hired to do, stop complaining.

Excellent work and congratulations on the job. I like people who set themselves a goal and find a way to accomplish it, so I hope you find yourself successful at Facebook.

I wonder if studying those books in such a short time only helped him to get through the interview process or actually helped him with his daily work at Facebook?

lol, 'your dream job at Facebook' to me would be pulling the plug and stopping it from earning money that doesn't come from benefitting humans.

Stopped reading here.

Not just for Facebook but a decent study guide in general.

How is the author of this article getting through multiple chapters of CLRS a night?! This by itself is very difficult to do in a few hours everynight.

Maybe it's imposter syndrome, but it often feels like these interviews were designed to discourage self-taught developers ¯\_(ツ)_/¯

Facebook have been contacting me for years on linkedin and email asking me to interview. This is exactly why I have never responded.

Unless these skills that are interviewed for are directly translateable to the job, it seems like this "prep work" filters out busy candidates who are already working and have families, kids, lives. Actually maybe that is the intention, QED

I'm absolutely distrustful of any companies where an interview requires prep work. Who is woth more? That who remembers 50% of a heavy algorithms book right after reading it or that who remembers 20% of it after having used it as a display riser for the last 5 years?

Working as intended.

We need people who are willing to be worked to the bone and only bleed FB-brand blood :D

While this may not be inviting to you, I think there is a flip side to the "wide-net" that big companies cast on LinkedIn and such. Instead of just hiring from a pool of "well-established" candidates, they give a chance to a wide variety of people from different backgrounds - as long as they can pass the interviews.

This may not sound like much to anyone who is established in the industry or happened to be in the right places for a good career head-start, but for people coming from non-traditional backgrounds, industries and especially places where there's no tech - being able to study-up and land a job at some of the most well known names in the industry can be life-changing. I think this is a very under-appreciated side effect of the "recruiter spam" from FAANG that everyone seems to dislike if they can afford to.

What's the point? You can get favourably as compensated in a much less competitive more friendly atmosphere elsewhere.

It's just a job.

The biggest thing I came away with is that their interview process is just as dystopian as at other places.

> People must avoid using less mainstream languages in their coding interviews as it’s possible that your interviewer might not be familiar with those languages

You'd think the CS knowledge would be prized more than the application, but I suppose that's not what these roles are for...

Fcbk doesn’t deserve to have devs working for them

Imagine studying for an interview. Not about the company or its products, but bloody algorithm textbooks.

I arguably have a pretty good job currently in the public sector which has a fair amount of autonomy and prestige that have been earned within my current organization over ~13 years.

Last spring after COVID hit I was reached out to by a Facebook recruiter with the conversation morphing after a few months (and two other individuals on their end) until having a really exciting conversation with a recruiter in early August that was just refreshing since it actually seemed like Facebook's hiring process wasn't that bad and that they might actually value me and my existing experience.

Part of my challenge is that my current role is not completely coding focused so I really don't have that "true" software engineering background and find it hard to figure out where I'd fit in a typical tech company's role structure. Instead, I have experience coding my own projects for my organization and taking them from concept to production in weeks and maintenance over timespans of years, along with management and tech leadership experience within my own organization.

Since coding isn't a daily focus all the time, my programming skills tend to need to be dusted off each time I take on a new project, and I know I'm not the best algorithmic expert, etc. but I'm reasonably intelligent (in my own humble opinion) and able to learn from others when I have that opportunity available (learning about extreme scaling techniques and certain advanced topics that might only be encountered within a tech-focused organization is unfortunately something I can't easily do within my current organization, and team-wise I'm the primary person interested in these sorts of topics so don't have others to really discuss the ideas with, which leads to that interest in potentially moving to a tech-focused company). I feel like my existing experience and ability to work with others and learn quickly would have some value (especially when you consider that new graduates don't necessarily have a lot of these experiences under their belt, but they are still considered for hiring...their algorithm knowledge might just be a bit fresher/recent).

Switching back to the interview...I spent a bit of time studying for the initial coding interview and felt like I had done decently well, but still received the "thanks but no thanks" email a few weeks later.

After that rejection (along with others over the last several years from companies I saw on the monthly "Who's Hiring" threads that intrigued me) I'm kind of done with trying to apply for tech jobs at the moment.

I'd love to earn more and work remotely from my current location (now that the pandemic has made this a little more possible) and be able to contribute my working days to contributing to the success of a tech-focused company, but it's not easy to be accepted by a tech company when you don't have the right background or exact skills upfront, so at least for the time being I need to be happy with my current work situation (even if it isn't always the most glamorous, tech-wise, and doesn't pay the same as a large tech company might).

This is just one personal anecdote of course, but I do wish there was a different hiring process for folks wanting to break into a tech company with existing experience that would be valuable, albeit non-traditional to typical hires.

Been there. Done that. Fuck Facebook.

They focused way too much on "college mentality" skills and zero on long term knowledge or experience with developing software in the field.

They also didn't ask jack shit about my past experiences.

Basically Facebook doesn't care about hiring specialists. They just want generic robots who will do their bidding.

But how can they do in a way that scales?

Certain people seem to be annoyed that they don't just ask questions that can't be verified and take the candidates word at it.

It is better to hire fewer employees that last. That is, more effort should be spent on retention and less on acquiring as many disposable employees as possible.

Most of the big companies treat their employees like trash and lose them rapidly. They think "Well we pay a lot so we have tons of people banging on our door to work for us, so we don't need to worry about getting new employees." This is a bad mentality.

New software engineers need to always be interviewed by those who are senior to the level at which the employee is being hired for. You will never be able to reasonably determine candidate level if you don't have more experience than they do.

The notion of "always hire employees smarter than yourself" is cute, but you don't have any way to determine rapidly that someone is.

Some recommend take home projects. I don't think those tend to work well for various reasons...

Things I do think work to find good employees:

* Give adequate time for whatever task is assigned during the interview. I nearly always see that the interview is rushed because there is inadequate time given for what is being done. If time is not available, just do a portion of the tasks and quick fail if the candidate does not pass that portion. If they succeed schedule additional interviews.

* Require open source contributions of meaning for higher level candidates. Have an interview ( an entire interview ) centered around reviewing their contributions with the candidate and discussing them.

* An interview ( 1 hr ) of the following type: Tell the candidate "Convince me why I should hire you. You have 30 minutes to present your case. I will say nothing that whole time. Afterward Q&A about what you said for 30 minutes.

* Ask questions of the candidate and don't bother with all the trickery. Bring me any software engineer and let me just ask them about random stuff freeform and I'll tell you if they suck or not within an hour. Don't demand some specific stupid process for interviewing them. You have to trust those you use to do the interview process and give them the authority to determine what the next best questions are always. The moment you turn the process into some "by the book" shit, you will get a shit process.

* If a coding test must be done, it needs to be just like on the real job in that full access is given to use websites to rapidly acquire the information needed to give the best result. Also, let candidate use their own IDE setup, and have them ready to go ahead of time. If anything, give a loose idea of what the coding task will be without details, to give the candidate time to prepare in whatever way makes sense for them to be able to tackle a task of that time.

* Give more time to accomplish tasks. So so so many of the stupid tasks I've been assigned in interviews cannot be reasonably and cleanly done within the 20-30 minutes usually given max to do them. Creating quality software takes time. Rushed software = crap software. Be real.

Facebook is pure self-parody at this point. This post is tragic comedy with no practical value besides entertainment. Anyone pursuing job options following advice like this has a severe problem with lack of self-esteem and capacity for independent thought.

100%. There’s an assumption in articles like this that you even want to work for said FAANG company. Additionally, these posts assume a one-way interview process, which is a sure fire way to end up places you don’t want to be. Jump through all the hoops like a good little show pony, then maybe if you’re good enough, you get an offer and... what? Congrats, now you work for a terrible organization at a level where you’ll never be able to affect real change - you’re a literal cog. Bravo.

Do the research and learning out of a genuine kernel of curiosity and self-betterment, not to whore yourself out to some corporation.

The comp offers aren’t even that great, even compared to midrange tech companies, especially for senior / staff level engineers.

I worked at a midrange ecommerce and content licensing firm, about 20-25 years old, in a major US city, and my total comp as a senior engineer (6 years of experience then) was in the range of $350k between salary, equity and bonus, and this was over a decade ago.

If you find a company that values you and needs your skills, you can get high comp at lots of places, and many have much better work / life balance, less wanton dysfunction and less political drama in the workplace.

Even a 50% or 100% increase over the $350k isn’t worth debasing myself with “dance monkey dance” whiteboard hazing. You might as well ask Facebook to give you a dunce cap on your first day, or a t-shirt that says, “My lack of self-respect is so severe that I agreed to do Facebook’s interview process.”

The mere fact that I’d actually be valued at the $350k place and wouldn’t be rectally probed to ensure I am fungible with every other assembly line programmer is a big indicator that my total earnings over a long time are likely to be much higher away from a place like Facebook. Generous scheduled equity refreshers are no match for actually rising in responsibility and skill growth to critical new positions in a firm.

Has anyone outside US has had any success to be interviewed by one of these big companies? (it does not have to be a FAANG). I have worked a lot in my interview preparation but then I get stuck in the "We wont sponsor any visa" wall, especially grating in the case of Canada because that completes the circular requirement that in order to get an express visa you need a job offer.

It seems to me the only realistic option is to be hired at your home country, but the country I live is very small and I am not legally allowed to work here in any case.

I assume things have changed in the last 4 years but before that all large software companies were sponsoring H-1Bs.

A lot of companies are still sponsoring H1B, but it definitely got more difficult.

One thing to note is that most companies only sponsor visas for senior level engineers (FB/Google level 5 or above). It's not easy to get that level, especially in bigger companies. I would say the best bet is interviewing for unicorn startups. They are hiring more aggressively and probably more willing to give senior level offers.

I’m in Canada and US recruiters reach out occasionally.

The TN visa makes it easy for US employers to recruit here.

Yeah, same for a few of other nationalities (Chileans, Mexicans, Aussies), as for the rest...not so easy. Things like these is why I laugh when people talk about globalization going too far. This is only true for powerful organizations

All to sell ads.

Firstly, the OP didn't say that you had to do what they did to get through the interview, they said what they did. If you think you don't need to do that much work, great, go for it and hope for the best. However, if you really want to work somewhere fang or not, the preparation might well be the difference between getting in and not. Too many recruits I have interviewed barely bothered going onto our website - are they really going to be bothered in the job?

Secondly, these kind of posts always start the "technical interviews are terrible" bandwagon. As someone who has been on both sides of it, on the one hand, I was disappointed when I didn't make the grade at one agency but I have also wasted countless days of my life on candidates that claim to have what it takes but really don't. They might have LOTS of experience but objectively score very low in ability - honestly, people who take 5 minutes to write a 1-liner to split a string on a comma! They might be young and keen, but again, that in itself doesn't really count either way - unnaturally gifted or just over confident?

Multiply that by 1000 for larger companies who must have hundreds or thousands of applications and how are they supposed to separate good from bad? By taking your word for it? By assuming that because you have worked for 10 years in the industry that you must be really good? Because you used to work on XYZ at a previous company? Unless you wrote it single-handedly, it is hard to know what value you added personally. They will test you in the best way they know how.

Also, the testing is not just about being able to do what you and they already do, that is not worth $150K, they want someone who is flexible, a fast learner, someone who can approach problems creatively, who can tackle something that has not been done before without needing someone else to tell you how. Confidence is good unless you are unnaturally gifted and things like working well as a team etc. are minimum requirements for most organisations, not nice to haves.

The technical tests then broadly fall into two categories - 1) find out exactly what you know about e.g. scalable systems by asking very specific questions. If you don't know how redis differs from SQL or the file system for caching, you are not suitable for a senior position in a company that operates only at scale. Most interviewer probably won't care if you have forgotten a subtlety or detail but phrases like "I know they are different, I can't quite remember why", don't sound so great. 2) The really strange questions where they are not looking so much for an answer as an approach - the one I heard about was, "how much would you charge to clean all the windows in Seattle". Any decent engineer should be able to reduce that to a set of assumptions or questions and then produce some kind of mathematical model in exactly the same way as being asked to write a complex program to serve one of your fang companies.

Leetcode problems are good because they select for people who are willing to put in the hours to get good at them. Aka, hard workers. Above all else, what predicts success at a job is work ethic. This is even more true at FAANG.

The hardest workers I know put up with the least bullshit.

Putting up with bullshit is also a desirable characteristic for FAANG

Sure. It just doesn't test work ethic.

Facebook stopped being a /cool/ company to work for about 4 years ago.

How can they expect to attract the best when they’re so lacking in corporate ethics? Don’t say it’s the almighty dollar because anyone with the chops to make $200k/yr from Facebook could start their own SaaS and make $400k/yr without too much effort. So what’s left to be proud of about working at FB? You don’t even get a private office anymore.

Downvoted.

And, for all that money, they can't seem to keep any of the features working.

Their biz model and revenue aren't based on user features working. The priority is on keeping what we can't see working. Most everything else is window dressing.

Put another way, the engineering heavy-weights work on the important stuff. Interns and such gets the rest.

Please tell me more about these SaaS ideas that will make me 400k/year.

> anyone with the chops to make $200k/yr from Facebook could start their own SaaS and make $400k/yr without too much effort.

Or, I mean, they could start their own SaaS that for any one of a thousand reasons ends up making them $0k/yr.

That is the rub of it. Making software and selling it are different skill sets. Not everyone has both. Selling things about getting others to think your incentive is good enough. Not everyone has that skill set.

I was with you until the third sentence. The better argument is that talented developers can get jobs at companies with similarly great engineering culture and good compensation but with better corporate ethics than Facebook's.

This sounds naive. I've been involved with several early stage SaaS companies. You'd be surprised how difficult it is to make any real money from it. Even if the business has good margins, the growth is often so slow, you'd do better getting a regular job and investing on the side.

> anyone with the chops to make $200k/yr from Facebook could start their own SaaS and make $400k/yr without too much effort.

I'm sure some can.

But "coding well enough to get a job at Facebook" and "being able to sell something to someone willing to pay for it" are two completely different set of skills.

Some people have both. Most do not.

Reply on news.ycombinator.com