Hacker News Reader

Comment by onion2k | Hacker News Reader

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.

View on HN

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...

> 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.

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.

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.

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.

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.

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.

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.

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.

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.

> 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.

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.

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.

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.

Reply on news.ycombinator.com