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.
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.
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)
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.
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 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/
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.
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.
You calling them a liar eh?
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.
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?
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.
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.
In terms of a test I use mean, median, mode, and range for an array. Then go into basic performance trade offs.
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).
That's because it's a near-meaningless title that has been watered down. Everyone is a "senior" now by their second year working.
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.
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.
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 :)
The problem with the situation is that doctors don't need to do that every time they change jobs.
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.
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.
How much did the anesthesiologist help, above that baseline?
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.
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.
This is common to all professional disciplines.
There was no affiliate link in the original post.
ref= is not an affiliate tag, it's an Amazon ref tag.
tag= is an affiliate tag.
https://google.com/search?q=amazon+affiliate+code+url
https://medium.com/feedium/how-to-tell-if-a-link-is-an-amazo...
are you really claiming that "redir_mobile_desktop" or anything afterwards is an affiliate tag?
You can choose to believe what I wrote, or not. But it's inappropriate to try to put words in my mouth.
Either way, I'm not interested in arguing with random griefers in the internet.
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.
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.
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.
Which innovation of Facebook are you describing? Instagram, WhatsApp, or the stories?
* https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...
Most of these things need to be created to scale and stabilize the existing system.
Is it your suggestion that those kinds of applications do not require solid knowledge of a variety of different data structures and algorithms?
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.
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.
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.
... have they gotten a lot better since 2015?
https://www.darkcoding.net/software/facebooks-code-quality-p...
> I went to school to learn the law. After school I had to teach myself how to be a lawyer.
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.
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.
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'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.
I’ll take our sometimes silly interview processes over that.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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...
At a company Facebook's size - a random Senior Engineer doesn't carry that much weight.
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.
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.
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.
https://www.businessinsider.com/the-ivy-leagues-history-of-d...
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.
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.
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.
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.
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.
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.
That would imply to me that their interview process is fundamentally broken.
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.
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
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.
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.
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.
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.
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.
I can assure you that the growth rate has not slowed. Do not use the USA as a proxy for global behaviors.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Seriously?
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]
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.
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).
EDIT: Of course, that and the fact technology is extremely rapid. Does this mean software people need to re-credential regularly?
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.
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.
I politely declined; was heading off to Spain for a long weekend.
As far as I know, that is not SOP for FANG interviews.
> 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.
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..
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.
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.
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.
https://leetcode.com/problems/find-all-anagrams-in-a-string/
https://leetcode.com/problems/subarray-sum-equals-k/
Optimal answers expected.
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."
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.
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.
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).
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.
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.
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
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.
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.
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.
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.
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.