Maybe it’s not the employees fault, but the management who hired them… or maybe it’s the fact that it takes forever to get anything done at FAANG nowadays.
Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders.. but a great way of identifying people who can hack a process to secure maximal reward.
Look, if I can ‘crack the coding interview’, then I can certainly crack ‘how to do as little work as possible and stack paper to the ceiling while my stock vests’.
I wonder when the last time was that Mark or Sundar actually wrote any code they pushed to prod.
> Look, if I can ‘crack the coding interview’, then I can certainly crack ‘how to do as little work as possible and stack paper to the ceiling while my stock vests’.
What's worse, many of the jaded people going through the motions probably started out gung-ho but then got frustrated to see how little impact they were really able to have and eventually became checked out. These kinds of things are self fulfilling prophecies in organizations.
Motivation is finite. By the time you get the through red tape to get approvals, permissions, and a million of other things, you have nothing left in the tank to code.
All enterprise is, fam. Everything slows down and bureaucracy and politics take over. Watched it happen in real time at the last acquisition and have decided to only focus on startups for the next decade. There's way more speed, passion, and fulfillment..
I can't think of any work to be done for a Meta company that I'd find meaningful in any way. I imagine there are plenty of people who only figured this out for themselves after coming on board.
Creating a VR game that your friends and family can play? Adding an API to React that shapes the course of frontend development for millions of people?
And in this photo, grandson, you can see where your grandpa spent 2 years running into walls at different angles, as part of the daily regression test for players being able to clip outside the world.
Of course in the end it turned out you could clip out of the world by summoning your horse in a doorway - but not by running into a wall, no siree not on my watch.
Did you know it was the first ever game where the in-game billboards for each player were auctioned dynamically? A complete auction took place in less than the time it took to draw one frame on the screen! I wish I could show you the game itself - such a pity they decommissioned the servers 15 years before you were born.
Yeah, it's legit difficult to find work that is impactful and fulfilling. Making incremental changes on a product that a billion people might actually use isn't the worst thing imo. I worked hard at startups on projects that, while fun, very few people really use. After a while I gotta wonder is it really worth the effort.
> React
How come that FB is inventing the most sophisticated, cutting-edge web technologies, but at the same time their core products (Facebook app, Messenger & Instagram) are an absolute mess both in terms of performance and usability, not to mention a ton of bugs that haven't been fixed for years?
If I'm being honest, I'd probably be happier at a place where my contribution was a small drop in a giant bucket than a place where we were much smaller but my input was being largely ignored.
If you have time to faff around at a FAANG, you have time to be cultivating your network to include some very influential people, you have time to be taking advantage of training resources or learning from the experts there that are completely free that most ordinary developers would have to pay thousands to get access to, you have time to work on side projects either for the company or, if you dare, for your own personal benefit, you have time to be hunting around for internal transfers that will boost your career, etc.
If you want to rest and vest, hey, more power to you but the smart ones are taking advantage of the gigantic cornucopia of opportunity presented to them by merely getting in the door of an obscenely wealthy FAANG to catapult their careers ahead.
This is fair in theory, and I imagine that some smart, high-agency people take advantage of the situation, but as is often the case, “down time" leads to more down time rather than more time to devote to career advancement, networking, and so on.
In fact, one might think that one day, when free of obligations and with plenty of gas in the tank that is currently used for work, one will pick up the barbell, take long bike rides, and build the body one has always dreamed of showing to their partner. But they are much more likely, instead, to spend more time watching the latest horrible Netflix TV series or eating burritos. The right analogy for mental and physical energy is not the tank, but the flywheel.
It is imperfect like all analogies, but let's take a toy example to clarify what I think. Let's say you are going to start something in 3 months, a new job or maybe you want to finally get in shape. If you think that your energy, will, and desire are like fuel in a slowly refilling tank, you might want to stop what you are doing now to save the energy that will have to be spent in 3 months.
I remember years ago, when I was a serious sportsman, we had a few days off at Easter. And I rested. I came back flat, dead, without energy.
Now the flywheel accumulates energy when the motor to which it is connected is working. The flywheel stores energy during the expansion phases (the combustion phase in an ICE) of the engine to return it during the passive phases.
Which, going back to the dilemma "when you have long-term down time, you have energy available to do other work, for networking, etc.," if the flywheel analogy is the right one, it means that you store energy to spend when there is down time by doing work, not by turning the engine off for days or weeks.
If no work is done for a certain period of time (the motor is off), the flywheel does not accumulate energy to spend, it is dead, needs time to accumulate energy again.
If you don't go to the gym one or two days after a period of serious training, which may be a week or a month, the training session is likely to go well. If the rest period, "I'm so tired, I need a break," is longer, say two weeks, you are likely to come back not invigorated, but flat, without desire, you may think about putting it off for another two weeks because you still feel tired, the tank has not been filled with fuel, you may think. But it is because energy, will and desire work like a flywheel.
Not at a FAANG but at a large company that has its fair share of world experts in various technical disciplines.
At least in my company, the path you suggest will make you miserable (it did me). You are not seen to be at their level, and you will more likely become a pawn and someone to offload grunt labor to. Yes, you will learn, but you have less than a 10% chance they'll let you use that knowledge to do work at their level: They need grunt laborers, and you are more valuable to them as one because you've gained that knowledge.
Oh, and they always had more pathological behavior amongst them. Very poor at teamwork, etc.
There are exceptions, which is why I said "10% chance" instead of "0%" :-)
The good news is whenever I went through this and switched to a less sexy team, I was seen as "the really smart guy who worked with the smart people" and the new team would value more than they should.
Snap. I, for my sins, am new at a WITCH company (please don't throw rotten fruit at me), and there is an obscene amount of dead time in my calendar and will be for the foreseeable. I'm rinsing their training and development resources and should have the full suite of certs I want within 6 months completely free. Certs that would literally cost thousands to acquire privately. If they want me to do some actual work I'd be delighted but I've worked at multinationals before and I'm not holding my breath. What I won't do is sit around doing nothing.
I posit there is another category: people who don't accept or can't deal with being idle, but are not careerists and so instead of following your advice or resting-vesting, they find ways to spend their time helping solve actual problems in the company.
My theory is that these people keep many companies afloat, because they go proactively solve the problems the resters are not solving because work, and the job-optimizers won't touch because not promotion-track.
I don't think there's anything on the list I mentioned, other than the "working on personal projects" one, that conflicts with that. Augmenting their own capabilities increases their effectiveness at "solving actual problems in the company" in addition to benefiting themselves. It's their own choice as to whether they do that.
What is the value of one’s career? To make more money? Why is it smart to devote so much effort to moving up when you’ll be dead and your work completely forgotten much sooner than anyone cares to admit? If you’re seeking lasting glory then the well trod path there is politics, war, or art: technologists generally are not remembered outside their time (with maybe literally a half dozen exceptions since antiquity).
I ask this honestly, because at this point in my own career the only answer I can come up with is the personal satisfaction of getting better and more knowledgeable about something I at one time enjoyed.
> Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders.. but a great way of identifying people who can hack a process to secure maximal reward.
If anything, that might be the best way to identify someone that fits in a large corp like Google. Someone that doesn't mind going thru the drudge of studying esoteric CS problems probably will be more attuned to go thru the drudge of working for a large company like Google.
I'm thinking most of the time spent at Large Corp. Inc. is doing menial work, rather than hot projects where you learn and get to work on the cutting edge.
I'm not sure I understand the comparison. CS interview problems are interesting, well-constrained math riddles with endless variety. As far as I can tell, they're nearly the opposite of menial drudgery.
I don't think they're great for interviewing, on account of how they don't resemble what programmers actually do, but I do think they're a heck of a lot more fun than menial labor, especially when job offers aren't riding on it.
The CS interview problems that are asked are a very specific view of CS that not everybody finds interesting or works on. There is a lot more variety to CS and software engineering than string and graph algorithms, which is all I've ever been asked at Google (where is numerical optimization, statistics beyond basic counting, all of graphics, etc). I also never get asked anything with regards to actually engineering software by them, whereas I have been asked that at Apple for example.
You'd be shocked how many people plan to crack the coding interview by memorizing every problem on leetcode letter for letter without ever trying to solve one without looking up the answer.
It was only 4-5 years ago that Google was considered the pinnacle of Engineering centric culture. It was still considered top up until last year. Something is going off the rails in the big tech firms if people now view big-tech work as menial. These were the same companies that pioneered CI/CD, Services, cloud, scalable web services, and myriad other technologies.
Many of the top engineering companies (Boeing etc.) are also objectively crappy places to work at. When you're doing things at the scale of Boeing or Google, you need a lot of process, and it's just no fun to do engineering this way.
That's probably true. Not that there aren't bits of Google doing fun and interesting work, it's a massive company after all. I've worked at a few, what I would consider to be large orgs, but my experience of Google was that it's truly on a different scale when it comes to bureaucracy and company politics.
At large scale you can't hire enough competent people. And scale x low tolerance for error means you can't rely on humans even if they are competent. To fix that you basically have to introduce process. Things are checked and controlled at numerous points, using blanket processes that often don't make any sense for the specific scenario at hand but are needed for something superficially similar. People end up in hierarchies of approval. And that's without even considering regulatory compliance which often simply mandates things at a blanket level because micro-auditing each individual part of a big company is essentially an impossible proposition.
Engineers have the best chance because we have it in our hands to automate so much, but still, we just haven't figured out a better way to do it I think.
Most of the time when I see a heavy process at work, it's a good question to ask who does it serve?
Most of the time, the answer is that it keeps someone important entrenched in work. It's very rare that I see altruistic processes that benefit the customer.
I've had a different experience (at least with engineering processes). Most of the time, it's been due to things in the past that have broken because we didn't check things or we got misaligned on something or people made assumptions that turned out not to be true.
I'm not saying that adding additional layers of process is always the right answer--there's obviously a cost to adding more process so there needs to be a balance and a continual reassessment of which processes are worth keeping. But in my experience, the intention has always been good: to avoid mistakes, problems, and failures that we've experienced in the past.
I got hired by Google in 2016 and I could tell you the interview was a series of interesting tasks all having to do with what I was hired for - working on compilers and related tools.
Though after that I was asked for additional interviews on basic algorithmic stuff cause Google thought original interviews to be too narrow in the scope, anyway hardly any esoteric stuff.
>Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders
The interview process at FAANGs isn't designed to hire the "best" people. It's designed to hire people who are "good enough" in a consistent manner. Any form of standardized interview can be gamed. More personalized interviews can be better in theory, but they also open the door to nepotism and discrimination.
Admittedly, I'm biased because I'm unusually good at Leetcode and a rather lousy in terms of development velocity. With that disclaimer out of the way, I think the last thing that FAANGs need are more "high performing builders". In my experience, a lot of them tend to create a lot of useless passion projects that work their way into being dependencies and end up causing more harm than good. I may be a rest'n'vester, but at least I make sure the work I get done creates positive value for the company.
At one point Waffle House required all of its senior executives to spend time each year working on the line. (They probably still do I just haven't checked in a few years). They feel this is important for their management team to more viscerally understand the lived experiences of the people working, identify issues in their processes and technology, and generally foster team spirit among their staff.
This is about empathy more than contribution, same thing with Quantas right now getting executives to handle baggage. It looks good (see how much we care?), and can be actually positive if it makes senior leadership understand what employees go through, so I think it is valuable for Zuckerberg to do an on call rotation or try and push a documentation change for these reasons
I think there's a story in the news today about Taco Bell doing the same thing.
More relevant to tech -- Automattic, Klaviyo and probably a lot of other companies require people in certain positions to do customer service rotations. Including C-level execs.
I haven't heard of a version of that for coding, though.
I'm pretty sure that's more to remind their corporate employees what life outside the tower is like. 'See how much better your job is than being a courier who barely makes enough to survive!'
I worked for a national us clothing retailer that didn't require but encouraged their 'corporate' employees to spend time in the stores mostly doing reshelves/reracks, tidying the sales floor, etc. Mostly around holidays/sales.
I worked in software for them but 'close to the store' for a bunch of my time there, so I was often in a store somewhere and always would help out as I had time permitting. It was useful for me, it was maybe useful for some of the buyers, I'm not sure it was useful for anyone else.
I consulted for a Fortune 500 where the CEO would spend a hour or so every month taking sales and support phone calls. He would use this information operationally -- he would send out missives to the head of marketing saying "people are not asking about product X." I wonder what he said when people asked to speak to his manager.
I'll tell you one thing though, EHRM user interfaces would almost certainly be less dogshit if the hospital admins who procure them had to actually use them.
Would it? I understand your point, but the counterpoint is that the leaders are in a position to make big changes if something is broken. They could attempt to push some simple change and see glaring process and onboarding problems, which nobody has been interested in prioritizing, and then make them top priority, saving everyone time.
That sounds good in theory but most leaders are so removed from engineering that it would take them a week ramp up to produce even the most basic tiny change/feature to push to production. A VP should not be spending one week of his or her time doing that. They should rely on engineers to identify and fix whatever is broken at that level. That's why we have staff+ engineers.
But that's also pretty divorced from the topic of what makes good interview questions. There's no way that a VP who spent a week to push out a color change to a button in prod would have any meaningful insight into how to change the coding interviews. That should also be left up to the engineers themselves to decide.
They absolutely should be spending their time doing that. They are in the position to say "I have to do X, Y, and Z to push 2 lines of code??" and actually get it fixed. That week could save the company years of developer hours lost to overhead.
Relying on VPs to do every front-line job in order to identify and fix problems would indicate that something is fundamentally broken at the company. That should never be the primary method by which a company identifies and fixes such problems.
As a former engineering manager, if someone on my team walked me through why getting PRs out to prod was an insane nightmare, I'd take note, work with them to gather evidence, and present it to my director and try to escalate it to the point where we could take action to improve it. If the VP is any good at their job, they'll listen and work with us to fix it.
If they aren't good at their job or it is status quo, they will brush it off. Sometimes it takes a new perspective to say what the fuck is wrong with this?
As an example, I joined a company with ~8k employees recently. They over communicate on email. I get 50+ emails a day. I filter heavily. My inbox is still unusable due to the volume of automated junk. I raised this issue in Slack and the majority of responses were just "well, that's how it is".
I am sure the development process has very similar deficiencies that I am blind to because I participate in it everyday.
> If they aren't good at their job or it is status quo, they will brush it off.
In your example, you rely on them to be even better: you assume that they'll be a competent engineer and be able to understand the complexities of day-to-day software development by making a toy PR when many of them haven't done it for years for decades. That's a much stronger assumption than the one that I'm making: that a good VP will listen to their subordinates.
That's about the time I'd expect for a new hire to ramp up on the codebase and submit a PR behind a feature flag and probably experiment that makes it to production. It takes a day to even set up the environment and be able to start looking at and running the code locally. Four days to read through a brand new codebase, identify the changes that are necessary, write a small tech spec (optional based on how small the change is), submit the PRs, get them reviewed and approved, and then merged sounds reasonable to someone who's never worked in the codebase before.
> That should also be left up to the engineers themselves to decide.
I agree with the rest, but I don't agree with this part. Engineers should have a lot of input into the hiring process, but fundamentally management is accountable for business performance and one of the biggest drivers of success is getting the right people in the door rather than just more people like the ones you already have (which is what happens almost always if you don't deliberately shape the hiring process).
The goal of that would not be to get functional code and a decent price, of course. The goal would be to ensure leadership has an accurate view of what that process is today.
Now, that may or many not achieve what the GP thinks it will. But, if you believe the leadership of your org is out-of-touch, it is a natural thing to suggest.
> a waste of company money
Well, I wonder how the CEOs, VPs, and other top level people actually spend their time at work. I get that they obviously must be doing something Very Important And Useful[1], because otherwise it would be a supreme waste of company money to pay them for eating Business Lunches...
As a counterpoint, in most of the Latin American family empires, where the eldest son is by birth designated to be the next CEO of the company, he usually starts working at the factory in childhood, doing all of the menial jobs. Then he's given a job like outbound sales rep and essentially has to "work his way to the top" (of course on an accelerated timeline, and without really needing to be the best at any level). That way by the time he is CEO, he has the credibility and knowledge of how every facet of the business works.
The point isn't that they commit some useful code. It could be something as simple as just fixing a typo. But force them to go through the motions, so they can see the inefficiency in the processes.
And then what? Are they supposed to design a better development process and build tools to improve efficiency? Again seems like both a supreme waste of time and also as an engineer something I really would not want. Or are they supposed to tell the dev experience team to do something. If so why not just have the dev experience team or leader go through the motions instead?
There is some value in technical leadership familiarizing themselves with internal processes. They could take on a small side project (do Google execs get 20% time?) using libraries and APIs with the goal of providing some feedback on what direction those tools should pursue. BillG did something like this with a measure of success.
I am actually writing a book saying exactly the opposite to this.
I think we are seeing the development of "Programmable Companies" - where all aspects of the company and its data are accessible (imagine a code API that reaches down to some sane mix of data structure).
So while it is crazy for Zuckerberg to try and optimise some Ad server, what should / could exist is a Jupyter-like notebook with something like
for minion in mycompany:
if minion.timeatwork < 40:
crapminions+= 1
This is mostly done with crappy spreadsheets, but it does not get to the feedback that this sort of platform (I think) enables.
Anyway. The point is CEOs should code. the reason they have stopped is because their job has not been "disrupted" ... yet
Edit: I think there is a further point here. Managers used to (Drucker?) design and build the systems, the factory floor was a battleground of Kanban and command and control. But automation won out. And now the "systems of production" are designed by coders.
All the managers have left is shuffling around people from project to project. But one lever does not a effective d means of control make.
We have learnt from communism that command and control economy falls over at scale. And what is a company but a command and control economy.
Yes, it's pretty clear that humans were overfitting to their interview objective function: comp-sci algo problems.
For companies with such strong ML backgrounds, in addition to the sheer amount of content dedicated to discussing and solving tech interview questions hosted on their own platform, one would think they would have noticed earlier.
There is a human component to consider: in the case of a change in the interview process, with the new process perceived as easier than the past and current ones, I imagine the bitter protests from the currently employed engineers who would vocally complain that the quality of new hires is much worse than it used to be, and that they have had to pass much more stringent interviews than the new ones, which even a junior SWE employed in an unnamed company would be able to pass.
+1, why blame employees? blame the management. In my previous job, our manager quickly grew team and hired 3x more people just cos he wanted to manage a larger team and get to hire managers under him so that he gets promoted to Sr. Manager.
>Maybe it’s not the employees fault, but the management who hired them…
I think the managers are just putting up a straight face, as they need to respond to the changing circumstances.
I think it has more to do with the economy and the war of Russia against Ukraine. All of a sudden there is less money to go around, interest rates are rising and it got harder to raise money.
And they probably changed their plans, now it is less about 'new features' and more about 'maintenance of existing systems'. But that didn't get into the article, so it's all the fault of the people who will have to look for a new job.
Searching for a new job isn't a pleasant experience, if you ask me.
(I am not working at google or facebook, but I will probably get to feel the implications as well...)
> maybe it’s the fact that it takes forever to get anything done at FAANG nowadays.
At any large company. Tiny changes that should take an afternoon end up taking 6 months once all the red tape is done and all involved stakeholders have signed off.
Yeah at least several years ago I had an explanation for this (though I’m not sure if it still applies). Basically, I think one reason for this weird type of interview is that it was an indirect way to bias towards young hires.
Young people have that energy and naïveté to do a lot of the grunt work. And most work at any established company is kind’ve grunt work. Anyways, just a random theory but nowadays it may be backfiring.
Not sure about Mark wouldn’t be surprised if he still hacks php on the side but Pichai joined google as a manager I think from mckinsey of all places… so Im going with “never”
> Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders.. but a great way of identifying people who can hack a process to secure maximal reward.
I see this argument all the time, but I can't find any other place that it comes from other than disappointment from those that didn't or can't pass those interviews. (Disclaimer, outside of college internships I've never interviewed for a FAANG SWE position nor have I ever worked for one).
Is it an objectively good measure of being a software engineer? Hard to say honestly. I doubt you'll ever find a truly great measure that you can test for in an interview. When I was interviewing candidates for my company, did I ask those leetcode algorithm questions? Not really. Maybe at most one basic tree traversal question (probably would fall under leetcode "easy" if I had to guess, but honestly the kind of thing a student would learn in AP computer science in high school). Most questions were system design and problem solving with a coding challenge (building something simple, not solving algorithmic puzzles). So by evidence of my own actions, I don't believe that they're the optimal questions for screening engineers.
That having been said, I don't understand why people are upset by these interviews. Who cares? If you really think it's suboptimal, then other companies who have "better" interviewing practices should be better at identifying undiscovered talent and hiring them. Better for you if you're hiring in those cases. Let FAANG fail on their own hiring practices. FTR I don't think they're that bad either, they just filter for a bunch of left-brained people who are good at math. Maybe they do make good engineers also. And if results are anything, clearly it's been working for FAANG for the past decade so who's to say that they shouldn't keep doing it?
> Look, if I can ‘crack the coding interview’, then I can certainly crack ‘how to do as little work as possible and stack paper to the ceiling while my stock vests’.
This is a reach (to put it mildly) and unfairly paints people who are good at algorithms as inherently unmotivated and whose primary goal is to cheat the system without any evidence. Are you saying another talented developer who isn't good at algorithms could not or would not hack the system as such? I don't see any reason to expect either to be the case. Hacking said system does not require you to be able to prove the runtimes of a Van Emde Boas queue, it just requires some common sense that any human being has.
> I wonder when the last time was that Mark or Sundar actually wrote any code they pushed to prod.
This is pure ad hominem and unrelated to whether or not these questions are good screening questions. I certainly hope that Mark or Sundar are not wasting even a millisecond of their time writing code and trying to get a PR out to production. It's one of the absolute worst uses of their time. But while we're on the topic, Mark literally built the first version of Facebook (to be fair, probably in a bad hacky way) and Sundar was a product manager so I certainly don't expect him to write code.
> I can't find any other place that it comes from other than disappointment from those that didn't or can't pass those interviews.
Oh, the macro is that these companies are oligopolies. About 15–20 years ago one of them realized that poaching entire teams from the others to enter new LOBs was cheaper than competing. So headcount grew.
Outside of strategic hires it doesn’t really matter who they pick up. E.g. LinkedIn isn’t going to go out of biz if they don’t find productive places for their army of level 3.5 software engineers or whatever. LinkedIn doesn’t have any competition.
I might not be connecting the dots, but I don't see how this is related to the GP's gripe that these interview questions aren't good tools for hiring engineers.
"If you really think it's suboptimal, then other companies who have "better" interviewing practices should be better at identifying undiscovered talent and hiring them. Better for you if you're hiring in those cases. Let FAANG fail on their own hiring practices."
The GGP is using an argument that if these techniques don't work, then the companies will fail, because that's how capitalism works.
The GP is saying that because these companies are oligopolies, they can do a lot of very inefficient things that don't work and distort the market, yet not fail and not be punished for it, thus that's why we should care.
Algorithm-puzzle computer science interviews are hard to prep for. They take a long time to learn. Then, most of the time, when people get hired for engineering roles that use them for interviewing - you find that you spend exactly 0% of your time working on those kinds of problems. Kind of a rug pull.
Lots of people are busy. They don't want to spend time prepping for puzzles they will never solve in their job. They feel like they are qualified for the job, and have great work experience in many cases (let's leave jr devs out of this), but feel like they are being asked to jump through completely unnecessary hoops.
Meanwhile, someone who does have a lot of time on their hands (young, single, no kids, more energy) preps for the tests, and gets paid more money than someone who is older, who has more responsibilities, and who frankly needs the money more.
It feels unfair, in the same way that it feels unfair when rich people get away with crimes poorer people wouldn't.
Well, the rich people used the legal system you say - they paid for attorneys. You could do the same thing, if you had the money.
Well, you don't have the money. And in the case of this analogy, you don't have the time to prep for random CS problems. You don't have the energy, because after work and family obligations - you just want to sleep. Or work out. Or do anything but write and think about code.
To be clear - if you are young, single and have lots of time on your hands - I have no sympathy for you. If you want to work in FAANG, fuck it, grind leetcode. You don't have any responsibilities.
But for those older professionals, with work experience and a track record of success - you shouldn't need to prove competence to write software at a FAANG company. It should come from track record, recommendations, open-source work and other artifacts of your career besides a thirty minute whiteboard session. Depending on the day, the time of day, what food you ate, how much water you drank, you might be absolute trash at coding. And it would be a mistake to sum up someones competency in such a small sample size.
When they interview lawyers, they don't ask them to perform a mock trial. Surgeons aren't asked to 'get their hands dirty' during an interview. Mechanical engineers don't get asked to whip up a CAD diagram in 30 minutes for a part (or maybe they do, what the hell do I know).
Small sample sizes are misleading, large sample sizes (open source work audit, multiple references, perhaps a paid take home project for one of your open source packages) give a much better understanding of a persons skillset than a 30 minute exercise in stress management.
>I see this argument all the time, but I can't find any other place that it comes from other than disappointment from those that didn't or can't pass those interviews.
I have passed these interviews. Had offers from multiple FAANGs, worked at G. The algorithms interview is idiotic. It is a way for them to gate the jobs to people who have CS degrees while being able to say they do not require CS degrees.
I rarely come to the to the optimal solution on my own for a leetcode problem. It is about learning the techniques so you know how to speak about the solutions, then basically learning (by reading) the right answers to different problem types.
This isn't from being hurt, I pass these interviews. I've worked there. It is a horrible selection criteria for what you actually do at the jobs - design docs, meetings, tickets, tests, and code reviews. It creates a ton of false expectations too, you do not need to know advanced algorithms to work on some internal user interface, close maintenance tickets, or to write 10 lines of test code for a 2 line change. You get in there and realize none of the work you are doing is as clever as the interview.
The tasks described above are the reality of working in a large organization. They shouldn't be, but they are. The interview should more closely match that.
That's a great perspective, thanks for sharing that. What would you like to see as the best interview questions then? I'll probably adapt my future interviews based on your ideas (not that I ask any real algorithm questions anyway).
Use them to measure how well people will perform in the tasks that you need them to do. For coding interviews, Square's is really good. [1] I am not sure if they have sample questions written anywhere in the linked blog posts, but very simple things with added complexity.
Example - Write a rate limiter that takes in a timestamp (integer) and returns true if it hasn't hit a rate limit. Ok, now what if we make the rate limiter per user. Just simple things to see how you represent data, store it, create interfaces to it, and how you refactor to deal with change.
Most likely, you want to be having someone write tests for some code and review some code. Then speak to them about their experience. Depends on your organization though, maybe you are small and people need to produce a lot more than the large tech companies.
We have a very nice phrase in Polish describing what kind of employees they are, literally it goes like: "there are those who are equal and those who are equaler".
Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders.. but a great way of identifying people who can hack a process to secure maximal reward.
Look, if I can ‘crack the coding interview’, then I can certainly crack ‘how to do as little work as possible and stack paper to the ceiling while my stock vests’.
I wonder when the last time was that Mark or Sundar actually wrote any code they pushed to prod.