Either these CEOs are insanely incompetent leaders who have gone on obviously unnecessary hiring sprees as late as a few months ago, or something else is up. Either way, it takes a particularly dishonest leaders to suggest that the main problem is low employee productivity.
It’s no secret that most people at Google hardly work. It’s been like this for years but you’re right it’s management’s fault for allowing this culture.
As an end user of Google Ads/Analytics what frustrates me the most is every time I have some question it’s like at least 3 meetings with different people explaining the same problem and the answer is always to pass the buck down to some “specialist”. It’s like no one even understands their products anymore. You have a “measurement specialist” and like three layers of specialists in that layer. You actually can’t get your questions answered because no one person seems to know how everything fits together. Just passing the problem from one so called specialist to the next.
Allowing? They've encouraged it by creating a system where there is very little relationship between what gets you promoted and what is good for your business unit. That's why you have 13 failed exciting messaging apps, all of which got lots of ICs promoted, instead of 1 successful boring messaging app that just kept getting maintained in a wise manner, getting very few people promoted.
Doubtless those honest, selfless CEO's were completely duped by evil conspiracies of rotten & incompetent middle managers, who've spent the last decade or two building ever-larger pyramids of bloat to set their golden thrones on top of...
Google would have been a lot more productive if it had hired people to work on one good messaging app instead of 13+ bad messaging apps.
Google has long had an attitude of "we hire the best so we can afford to have them stand on one leg and balance on a ball while holding a cane in their mouth and balancing a bunch of dishes on the end of the cane while typing with one hand on a chorded keyboard and looking at a monitor through a mirror." I've heard stories that range from "of course I am productive, I am shooting the s--t all day with the smartest people to" to "I have no idea of how what I'm doing impacts the bottom line".
Blaming the employees smells like a smokescreen for poor management IMO.
Who's to blame for lowered employee productivity: employees who are disconnecting from work more to avoid burnout thanks to corporate BS like paperwork and constant report filing? Or the managers who impose those requirements on employees but fail to empower the individual contributors beneath them in the org chart?
I recently left a large-medium sized tech company that failed to address massive structural issues in my department for years. It's not like these were a secret -- I brought them up constantly in my 1on1s, and tried to brainstorm solutions with my management chain.
When I left, the head honcho begged me to stay, and when I brought up those issues... told me he had no idea that was such a problem! But also refused to address it because he had to "gather information" about the issue.
I'm much happier at a smaller company without so much bureaucracy. At some point, managers are so disconnected from their underlings that they are completely incapable of improving work conditions. And when you need high-level approval to make a big decision... more often than not, the big decision just never gets made.
If you choose not to decide, you still have made a choice.
We’ll a lot of their products come out if individual side projects, Google is an incubator of sorts so I’m not surprised that’s how their product gets made.
... There was that time that top management thought reverse imperialism was a good idea so they dumped a perfectly good Google Wallet in the U.S. for something that was big in India... No thought of cultural sensitivity. A few years later they reversed the decision, with no consequence for the people who made it.
If you are doing that for your products though you are never going to get long-term traction no matter how good or bad your engineers or marketing people are.
I don’t know what you’re trying to say? Are you saying they discontinued a product that was big in India? How is this reverse imperialism? What is reverse imperialism?
The "while balancing on a ball while holding a cane in their mouth..." thing really resonates with me.
Something that really surprised me at Google is how many core services had very thin test suites. I'm the kind of person that sees 100% code coverage and thinks "that's a good starting point". If I don't have that, I'll definitely break something important in 6 months. There were a lot of people at Google, though, that definitely didn't need those guard rails. The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.
It wouldn't work for me but there were a lot of people at Google that absolutely didn't need to follow "good engineering practices" to do good engineering. I was impressed. A lot of people less smart than them try this and fail, but they made it work.
> The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.
I think testing at Google is excessively complicated for a myriad of reasons, and the unit-test-style "coverage" doesn't really map well to how things work together in a larger system. That system-wide thinking is where the "read a code change and know exactly what's wrong" intuition becomes invaluable. *Integration* testing is especially hard for some reason (probably complexity in the serving stack, at least for many teams I've worked with), so you end up getting this pattern where people get better at other production health stuff like canary systems, release management, etc.
After 3 months at Google I've come to realize the high hiring bar is there because you need to be particularly smart just to get basic shit done in their environment. I spent 3 hours the other day trying to authenticate to one of Google's own internal APIs from within the Google network using their bespoke IDE. In the end the code necessary was pretty simple. But I'd tried many incorrect solutions before that. The API library itself is "deprecated" but the API is still very much in production and not changing any time soon.
1) Treat services you call like your own code. Familiarize yourself with the server code. Try running it locally and poke at it. If you run into problems in staging/production, go look at their logs and monitoring dashboards (if that's still allowed; I have a feeling that things have changed around permissions since I left). What I learned that there was never an error I needed help with as soon as I read the code and error logs of the app I was trying to call. "Oh, this deprecated field is actually still required, it's just IGNORED now", that sort of thing. In the real world, it really helps with open source libraries. There is never any useful documentation. So get used to reading the code, and you'll never notice it's missing. As you get good at it, it really becomes a productivity superpower.
2) Fill out all available forms. I wrote and maintained a monitoring system at Google. I remember going to some tech talk about how the network worked, and realized that I could be using a high network priority instead of Best Effort, just by filling out some form. In the unlikely event of a network problem, we'd probably still have monitoring! Fill out the form I did. And one day there was some network incident where a lot of consumer-facing apps were slow/down, and my service didn't miss any messages. No unnecessary outages or pages or a long night, all because I filled out a form that anyone could fill out. I honestly felt a little bad because I guess we could have lived without the monitoring if it would have saved GMail. But hey, victory goes to the team that's willing to fill out the form and maybe have a quick meeting about it. Not everything in software engineering is programming.
There is quite the ramp up time, and there is a lot of learning to do, but once you get a handle on it, you can really do great things at high speed. If you ever leave, you will miss it. As much as people complain about the tools/systems/libraries, it is all really top notch. The "real world" is a hodgepodge of half-baked systems that all cost $30,000 a year. (Whoever wrote Prometheus left too early and cloned varz instead of Monarch. Hurts my soul every single day.)
I most miss D, Spanner, Blaze, and Monarch. Spanner you can buy from Google, but I can't afford it. Bazel is open-source. The rest... you just have to settle for something not as good.
I like some of the tech so far. And I have a good amount of startup experience, so I know the world of paying for SaaS instead of having your own special internal solution. Sometimes paid SaaS is superior. It's built for users more so than developers. That limits your powers but also means it's meant to be used by someone that doesn't know how it works.
Blaze seems very nice. I'm deep in a special domain far from g3 - so I only came across it this week. But it has worked exactly how I want it to and has given me no trouble, only a good experience so far. Much better than the terrible world of whatever build system NodeJS is using this week.
And the perks are pretty nice. Not enough to make me never go back to startups. But I appreciate them. Extra days off that no one else would get. Free trips to amusement parks. Days off to go sailing. Good free food. Good free cappuccinos. Good free snacks. Free car charging. I'm shocked so many people living in Mountain View refuse to commute in after working from home for two years.
Writing a messaging app is a fool's errand. You either build a chat app with someone elses money, invest in all chat apps (1/n) and hope you score a big one - e.g. like textbook publisher, or you wait and M&A the successful ones.
The barrier to entry to write a chat app is zero. Even if you are brilliant you will compete against hundreds other chat apps one of which will beat out with pure luck. Never compete against luck.
Google has Android, which is a lot better than luck. Apple made iMessage popular just by putting it on every phone. Google did that too, but they did it wrong.
Yeah so you compete against luck by leveraging your prior dominance in mobile OSes with a committed iMessage-like approach, instead of waiting for two former Yahoo! employees to eat your lunch then launching several competing apps that you kill off later.
As a Google employee, the profusion of chat apps is caused by:
* a genuine interest in trying new things and trying to see if they'd stick, without the baggage of established UX & customers - Allo/Duo are like this. I don't think people give the company enough credit for this.
* leadership downplaying the cost to the Google brand of shutting things down all the time. When brought up internally, execs shrug saying that we must be willing to try and see if things stick. This makes sense, but why are people particularly mad at Google for doing this? It must be for a good reason, not merely a meme.
* org silos. The org behind Google Docs / Chat has a different reason for a chat app (chat as a checkbox for enterprise office suite sales) than the one behind Google Maps (you can chat with restaurants or whatnot)
* a lack of a good "design dictator", meaning our chat apps, as with other apps, falter for lack of great UX and don't gain traction. The biggest example I can think of is how Google Chat has a loading spinner for the emoji picker - this simple thing should be lightning quick, but it took a year for someone to even prioritize it.
* faulty marketing / branding. Taking the simple, beloved "GChat", which was the dominant chat app between AIM and FB Messenger, and wringing it though "Hangouts" and "Allo/Duo" and "Chat" - that's no fun for users.
I think the lesson here is that people want a simple, hyper-fast app that gets out of their way and slowly adds nice things on top. I'd say the apps that are most fun and fast to use are Messenger and iMessage. (I have plenty of problems with both - unremovable stories on Messenger, lack of archiving chats and general slowness on iMessage).
> leadership downplaying the cost to the Google brand of shutting things down all the time. When brought up internally, execs shrug saying that we must be willing to try and see if things stick. This makes sense, but why are people particularly mad at Google for doing this? It must be for a good reason, not merely a meme.
Because it doesn't actually make sense.
* Google has an audience. I suspect everything Google does is a good enough idea for a small subset of people -- or solves a problem for a lot of people but isn't profitable, like Google Reader -- and because it's Google doing it, a lot of people hear about it and use it. So the shutdown of Google's random ideas affects more people than the shutdown of some random startup.
* Google just kills the products completely instead of spinning them off or selling them to interested parties as earlier incarnations of Silicon Valley tech companies would have done. A company not bloated from search advertising revenue would have happily sold something like Google Reader for some money instead of just killing it.
When I joined Google, I realized it was the same on the inside as the outside. There's a lack of direction. It's not just chat apps, and it permeates the entire company including Sundar. Maybe it's just too easy to lose focus when nearly all your income comes from one product and none of the others matter.
Most of the problems with product @ today's Google come from "shipping the org chart." You touched on this in your third point.
This was one of the major factors that led to me walking away from there after a decade.
That, and it's just a slow boring place to work most of the time. One spends the bulk of one's time basically seeking permission to do the thing that needs to be done -- by this I mean: get in the right MDB groups, get the right sign off on design docs, be sure to be in the right team, be sure to have gotten the right people on your code reviews, made sure there's visibility to the right stakeholders -- and hope to god the thing you're working on isn't sexy enough that somebody better connected won't just steal it from you when you're halfway through it anyways. Or just take credit for it.
And the perf process and the culture around it produces terrible results on top of that.
Paid well, but was a terrible place to work. Especially once COVID hit and the free gourmet food and subsidized massages were a thing of the past.
I see this as more or less a ruse to justify ridding the companies of all the now remote people who moved away to live in Cheap Town during the pandemic. This is a pretext for the typical Corporate House Cleaning/Reduction In Force scenario. Some people do well working remote (Im one of them in fact) but I suspect and from what I've seen the majority of people simply cant handle the responsibility/self management of working remote.
Alternatively, the economic forecasters at these companies see trouble on the horizon economically and know that layoffs to boost stock price will be necessary. In such case, best develop a pretext for these layoffs thats not "We're having financial trouble so we're laying people off". Instead it's "Nope, nothing to see here, THIS IS FINE - we're just cutting dead weight!".
I don't work for either of these companies nor do I know anyone personally who does, but I have to wonder if a sort of entitled, country club culture developed there and this an effort to reign in that behavior. Maybe someone with some inside insight can comment here?
"I suspect and from what I've seen the majority of people simply cant handle the responsibility/self management of working remote." While this may be true, if this has to be solved by forcing everyone to move to SF/NY - then couldn't you just save more money by firing their managers?
Exactly. You can’t make this claim without saying that your managers are incompetent all the way up to the C level because it means nobody was measuring performance even though that’s a core job requirement.
It is extremely rare for management, especially higher levels, to have any method of distinguishing smart and hard working people from duffers or from “managing upwards” big talkers. Git logs sort of help much interpretation is so context sensitive that the signal is blurry.
So while measuring performance might seems like a core job function, de facto it is not.
Also people that find this thread interesting should join Blind.
Would you say that software engineering and architecture aren’t core job functions because they require skills and experience to do? It’s not effortless but these people are being paid top salaries so it doesn’t seem unreasonable to expect them to have at least a rough idea of what the people who report to them are doing.
This goes double for the other concerns you mentioned: if you’ve created an incentive system where people commonly BS their way into promotions, that’s a major management failure.
> Also people that find this thread interesting should join Blind.
What is "Blind" ? Is it some sort of think-tank ?
If the manager has done a good job he/she has hired people that are more knowledge and experienced in their specialization fields then the manager.
This is only true for "intellectual" work though, if the employees do physical work, like laying bricks, you can measure performance on how many bricks where laid.
For example, one employee might have spent 3 weeks carefully reading code to find a bug. Not a single code push for a whole month. And might not even have found the bug. But likely found lots of unused code that everyone been too scared to touch. So if you're measuring performance by LOC written, that person could end up on the nagive.
Blind is an app that has people with confirmed company affiliations but anonymous, if you trust them. People speak openly if very greedily about wrk place shenanigans. It seems like an informative if distorting and addictive sort of thing. I check it every few months or if there is something big going on, e.g. layoffs or whatever. There are sections only your company can see and then more shared areas where you can read the woes of a PIP at Amazon or the rest and festers at Google, etc.
"Rest and vest" is a phrase that gets bandied about often -- including by people who are trying to do it.
I couldn't tell you what fraction of employees, but there are folks hiding in all of the big tech companies that are happy with their comp, aren't trying to advance, and have adopted the "do the minimum to not get fired" approach to their work.
If too many of these get together in one org or on one team, the whole thing gets poisoned and everyone starts barely getting anything done.
My experience at Google (which matched other large companies I've been at) was more that the "smartest" (I.E. earliest) members of a team laid down so many road blocks for later members, in the form of tech-debt and undocumented knowledge, that the output difference between coasting and working yourself to death was pretty small. It's an easy environment to get discouraged in.
My fear is that is what I'm doing right now. I've been writing code alone for a while, it's very possible it will be hard for new hires to understand or update. I know there is tech debt but I don't have time to fix it (because I'm alone, natch).
Oh well. Maybe they can spend their time replacing my work.
My experience at Google was that until I decided the company was kinda directionless and started selectively ignoring leadership to get stuff done. Of course avoiding the "insubordination" line. Turns out they're still happy as long as you give them what they want in the end, or if not, what their boss wants. And I'm happy to see things work.
> that are happy with their comp, aren't trying to advance
Why does this
> and have adopted the "do the minimum to not get fired" approach to their work
necessarily have to go with this?
What's wrong with deciding "I don't need to advance further; I like the work I do, I make enough money; I don't need to be hustling anymore"?
It seems to me the concept of "enough" is hard to grasp for a lot of people, especially those who are deep in any high-paying field (not just SV tech types, but certain kinds of doctors, lawyers, etc).
If there's no place in Silicon Valley for people who know what "comfortable" feels like, then it's definitely a place I'd prefer to stay away from.
A rational actor will notice they get either a promotion or less work in the high/low work instances. If you work in between those boundaries, you get nothing extra.
This seems cyclical to me. If you do the bare minimum and get fired, that is a contradiction.
If the bare minimum is getting promoted then that means there is no room to slack.
If you look like you are slacking to your coworkers, then you probably are not doing the bare minimum. The bare minimum would be exactly what it takes to keep your job.
So I believe what you are saying is that there are multiple bare minimums from various perspectives. In those cases, you take the biggest one.
Another example for a gameable aspect of promotion is cutting up your achievements to look more favorable during a promo round e.g., salami slicing. If you hit a promotion, save the extra stuff for the next round.
And if you are at a large organization, you certainly have the data to estimate exactly the bars for promotion.
The key delta is often that the bare minimum to keep your coworkers from being demotivated by you is a bit higher than the bare minimum to keep your manager from noticing your underperformance.
If the work you are doing falls in this middle range, then your slacking will harm those around you but you probably won't get fired (if it takes longer for a manager to get fed up than the mean time between reorgs, you probably can survive indefinitely)
If the game was fixed and everyone had full information, there isn’t a reason this would happen.
But I agree if the promotion/firing is relative or dynamic in some way, then you’d race down to arbitrarily low effort.
The real problem is correlating work with value in an unbiased way. If you had perfect information on the value of each worker, I can’t see how it would be complicated to do a cost/benefit analysis.
But without reading/predicting the future you can’t usually figure out value because an unfinished product has no current value and a finished/legacy product has fixed value. In either case the worker has no marginal value.
There are lots of people who are comfortable where they are and continue to do solid work. I'd say that's probably almost half of folks at the mid-career levels in the big tech companies. This is actually why rest-and-vesters are so damaging. If you get a couple of these people on your team, they tend to bring down the morale of the much larger group who are earning their keep.
It's easy to be happy getting paid your current rate for doing a good solid job. But, it is really hard to stay happy in that situation if the person sitting next to you is getting paid the same, but doing almost-but-not-quite nothing.
In this situation, the previously-happy-worker types tend to either 1) seek a new team where they're not working with a rest-and-vester, or 2) slowly degrade into emulating the rest-and-vester because they feel demotivated and that their work isn't appreciated (since it isn't being appreciated more than the rest-and-vester's non-work)
Good managers identify this situation and put the rest-and-vester on notice to shape up (many of them will if you work with them -- many of them used to be the previously-happy-worker but at some point got poisoned and just need to have the callouses removed. (And a few of them just need the boot)
--
On the other hand, in tech really you are either growing or dying. That doesn't mean that you have to be growing in promotion/job-ladder-shaped ways. But if you're not learning something and growing in some way, you're probably regressing.
> But if you're not learning something and growing in some way, you're probably regressing.
but this has nothing to do with your work - you grow and learn as part of your personal desire or interest. If it happens that your personal interest intersects with your job, then that's a great coincidence.
Doing work is a low status activity. If too many people in your team or org are trying to get ahead, you will be drowning in project management and recurring cross-team syncs and grand plans but with hardly anyone writing code.
“Realistically, there are probably a bunch of people at the company who shouldn’t be here,” Zuckerberg said on the call, according to a Reuters report. “And part of my hope by raising expectations and having more aggressive goals, and just kind of turning up the heat a little bit, is that I think some of you might just say that this place isn’t for you. And that self-selection is okay with me.”
For companies that adjust salary for remote workers, those employees who moved to Cheap Town are now cheaper for the company to pay than those who work in Silicon Valley.
They're right, but they aren't getting to the root of the issue. Most dev teams don't communicate anymore, and people just work on their siloed projects and "throw it over the fence" to the code reviewer when done. There's very little collaboration or ad-hoc knowledge transfer. This leads to a disjointed, unworkable codebase. If I'm seeing this at the piddly little startups I have worked for during the pandemic, then I'm sure the effect is amplified at the most exclusive development teams in the world.
What's wrong with taking a break to run necessary errands or pick your kids up from school? As long as you're meeting performance expectations, it should be fine.
Is Zuck really slaving away at his desk 9-5 everyday? I don't think so.
Sounds like another case of "One rule for thee and another for me"
I agree 100%. However, if someone schedules a meeting for work hours and 50% of the people can't make it because they are grocery shopping I can understand the frustration. These aren't low paid employees. Meta is paying 300k+ for mid level engineers.
This is inherently a problem with full-remote or hybrid work.
People will point to "studies" showing how remote work improves productivity. Maybe it did initially but eventually, people will check out, feeling isolated, feeling less motivated.
Some people who worked remotely before covid swears that it helped their productivity. But these people are biased because they were probably one of the few who were disciplined enough to make it work and they gained the employer's trust over time.
There were a lot of reports of Zuckerberg bemoaning about productivity. Tim Cook wanted everyone back in the office full-time before Delta. Google also wanted everyone back in the office. Clearly, these CEOs aren't just making decisions on a whim and they have real data on productivity rather than some 3rd party studies.
This opinion is not popular here but this is how I see it.
I mean the middle men meeting where someone translate business requirements to technical solutions. Engineers should be treated as problem solver and not code monkey
You do realize that most engineers would hate to have to do the work of a PM? Talking to users. Analyzing data. Coming up with solutions. Convincing executives. Convincing designers. Convincing dev managers. Convincing devs. Writing specs. Handholding the project through the finish line.
You told me you don't want more meetings. But you realize that you'd have to have a ton of meetings to do the above? You think a spec just magically shows up and a ton of work was not done before it ever makes it to your queue?
>Engineers should be treated as problem solver and not code monkey
Engineers solve technical problems. Some engineers want to solve business problems too. Those might be good candidates to become product managers.
Based on previous experience at a SV "unicorn", more often than not, a ton of work was not done. The "specs" were vague and poorly written. "Lacks attention to detail" is how I would describe most PMs at that place. I think they had a 1:1 ratio of PMs to engineers.
I was only slightly exaggerating. Though I do remember being in my daily standup, and regularly there were 3 engineers, a dev manager, 2 PMs, the product directory, and a designer of some sort.
The translation is a legitimate skill that should not be underestimated. Especially when you add in that there ought to be flow the other way as well. As an engineer, I want to be involved early in the business processes, because as we all know sometimes business people assume that very hard things are easy, but sometimes there is something I can offer them that they don't have any idea is easy. It's best to work through the cost/benefit process together, rather than the business people huddling in a corner before flinging over a set of requirements to engineering as Holy Writ.
(Kinda struggling with that now; I'm peripherally involved in a project with big monetary implications. The "solution" is to build a big system as quickly as possible and run around making super-high-priority requests across a whole lot of teams, almost all of which need to be in place before any value is obtained, and which consequently is behind schedule and dragging out. On the other hand, a week, some database queries, and a reasonable amount of manual labor could get about 50-75% of the value now. But none of the project managers are interested in that fact, which frankly boggles my mind. I'm not sure if they just don't understand what I'm saying, or are just so stuck on the solution they designed that they've lost all ability to think outside it. One thing I have confirmed is that it isn't just that I don't have a full picture of the problem, which is the usual situation; I'm quite confident what I'm thinking would work.)
However, while that skill is not necessarily something you need a graduate degree for and 20 years dedicated experience, and engineers can pick it up, there are engineers who don't have it yet, or even won't pick it up because they despise it. The list of skills required to be an engineer is already pretty long, requiring this to be added as well raises the bar even higher.
I disagree personally but voted up because this is a valid opinion and I suspect this is the reason why it feels like we get less done. Personally I feel like I thrive remotely, probably work too much but I like it so there's that.
It comes down to some people thrive working remotely and some don't. At any level higher in mgmt than a single team there isn't really any way to determine who can thrive and who can't. Pretend its a 50/50 split across 100 people, the only way upper mgmt can see to get pre-covid productivity is to go back to the office.
I will say another unpopular related point on this: people with young children are more than likely to not thrive working remotely. Or at least they've probably never had the chance to see if working remotely is good for them because they may have had their kids home with them these past couple years. You know how we don't like distractions when trying to do focus work? I can't imagine trying to do focus work with a child or two under the age of 5 there with you all day.
We're thriving, just in a different work/life balance proposition. Of course, sterilizing entry-level engineers would lead to much higher overall productivity + zuckerbucks for shareholders. Maybe we need to have that conversation.
I’d agree with this. Anecdotally speaking I have never met anyone on my team and I honestly can say that I feel like I’m a mercenary whose job is to just destroy tickets and keep a lookout at our monitoring. It feels so impersonal and is it really my fault or my colleagues that they don’t feel as invested?
Messing with k8s, looking at logs, or occasionally hopping into a zoom to discuss architecture for an upcoming project that I don’t find any interest in beyond ensuring the stock goes up, it feels like I’m a cog and I just do things and somehow we keep going.
Three years ago I would be super engaged and going to conferences to show off our latest work. Maybe it’s the combination of doing boring (to me) infrastructure and dev ops work along with zoom culture. Back in the day I was a mobile application developer so that was quite a different lifestyle compared to this. Idk man, I’m doing my best to do a good job but honestly it is the worst experience of my life so far. I’ve been spending my time outside of work in evenings and weekends hacking away on side projects. They give me far greater joy, which I used to find previously at work.
I found much greater joy going to the office everyday, working, meeting with my coworkers, doing things after work like grabbing a beer in the kitchen, etc. I really missed those things. Now I'm just staring at a screen for 10 hours a day. Two extra hours because I feel like I need to prove that I'm working while I'm remote.
It sucks. I feel way less energy and less passion for the company.
Completely agree. There is no more banter. No sharing of ideas. No creativity. It's all just zoom bullshit.
I keep wondering when this crap is gonna end and people will realize that this "pure remote" shit absolutely kills innovation and creativity. But man... it's super depressing. I used to love my work. Now it sucks.
I think it will take many years before this shakes out. I think companies that are in-person will out-compete and out-innovate those who aren't. I think the pendulum will start swinging back to in-person.
I dunno. It's exhausting though. I feel very trapped by all this crap. I could only imagine being a new-hire or some fresh college grad...
>Clearly, these CEOs aren't just making decisions on a whim and they have real data on productivity rather than some 3rd party studies.
Asking people to 100% return to the office is unpopular (or at least controversial) to some, right? If there was "real data", why wouldn't they mention that in their communications to staff? Instead, it's full of wooly statements like "there's something missing" and vague stuff about collaboration.
This seems to be a more generalised fallacy - "The <government/CEO/authority figure> don't do things on a whim, therefore they must have additional (secret) information on <controversial decision>. Based on this, they're obviously correct - after all, they've got that secret info!".
>Asking people to 100% return to the office is unpopular (or at least controversial) to some, right? If there was "real data", why wouldn't they mention that in their communications to staff? Instead, it's full of wooly statements like "there's something missing" and vague stuff about collaboration.
FYI, Facebook and Google CEOs both said productivity is down and they expect more out of their workers. They said so to their employees which obviously got leaked because there are tens of thousands of them. I'm guessing that they don't want to specifically blame remote/hybrid work because it might offend a lot of people and get bad PR. Instead, they're slowly nudging their workers back into the office.
Apple never said anything publicly or to their employees about the lack of productivity and they never will. They will never do so because it'd be a huge PR hit. It's not Apple's style.
I don't think that this is about anyone's slacking off. If you're going to reduce staff, you make yourself look better by dressing it up as improved productivity and efficiency, that's why Zuckerberg is making these statements.
Bingo. Nothing about a "recession" makes it easier or harder for upper management to manage performance. If they were good at it before they're good at it now and if they were bad at it before, they're not going to suddenly get any better at identifying poor performers. But if layoffs are going to have to happen for unrelated reason, might as well try to spin it so that those that are left behind feel grateful and prideful rather than resentful and worried.
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.
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.
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.
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.
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.
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!'
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'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.
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.
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.
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.
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 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 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.
> 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.
> 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.
> 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.
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.
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.
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.
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
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.
> 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.
+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.
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".
>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...)
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”
This seems like something that should be expected? Every time the WFH battle has come up over the last few years, there are always people talking about how they’re able to do all their days work in 4 hours and spend the rest of the time idle “pretending to work”. Is it really surprising that as a result of this companies are reevaluating how much slack time their employees have? Especially as wages and demand for wages due to inflation have spiked, you can probably shore up some of that demand just by dropping some of those 4 hour employees and using their wages to pay others to become 6 hour or 8 hour employees. Sure it’s unrealistic for a company to expect every employee is 100% engaged 40 hours a week, especially in knowledge / creative work we’re sometimes unplugging and downtime is exactly what the job requires. But it seems equally unrealistic to crow about how the pandemic has demonstrated that WFH is perfectly fine and had no negative impacts because everyone was already only putting in 20 hours a week and not expect that to have caused companies to make a shift.
I think we've built companies and cultures that are incompatible with long-term employment and happiness.
Anyone who joins a company can crank full 8+ hours a day for a while to establish themselves (and a reputation).
The "problem" is, as people establish themselves, the problem domain becomes less exciting. There's less urgency to crank indefinitely. They settle into a pattern that involves fewer hours, though those hours are more productive because they know the ropes.
There is a sweet spot where someone knows enough to be productive but isn't yet complacent. This is the spot that every employer dreams of: employees cranking, full speed, productively, for 8 hours.
It's just not sustainable. You can fire people and try and keep turning over staff such that everyone stays in that sweet spot, but you'll eventually end up with a different sort of headache when your staff has no organizational memory for why decisions were made. The people who built things and have the long-term visions have left, and those who pick up the torch try will never have the same big-picture in their head.
The challenging bit is how do you separate someone who works 3h a day because that's all they can sustain (and they're just being realistic), and those who work 3h a day, could work more, but chooses not to? I'm not sure you want to force either out, but can you incentivize the latter to produce more?
Here's the real challenge: stop thinking in hours, limit upper bounds so employees don't inevitably fall into a race to the bottom (like what is happening now).
If your 3-hour-could-be-8 made adequate contribution, whatever that is, that's enough. If it takes them 8 to get to where the other is, incentives will push them to do so.
> If your 3-hour-could-be-8 made adequate contribution, whatever that is, that's enough. If it takes them 8 to get to where the other is, incentives will push them to do so.
This works great until you PIP an underperforming female, minority, or person over 40.
The discrimination lawsuits will make the company regret their progressive stances.
You wouldn’t believe how many times I have seen this happen.
The median outcome is a settlement with no admission of guilt (usually because it’s cheaper than the alternatives), and the person now has a job for life or is given severance until they get a comparable position elsewhere (and they won’t be rushing).
I think there's plenty of people that would crank out code* given a sane supporting organization. The issue is that most organizations aren't sane and there's little incentive to crank out code. Incentives are generally (1) finish 5 points of stories per week and (2) build a resume/promotion package. Both of those sound okay but tend to be wrought with perverse incentives.
(1) leads you down the path of padding estimates so you don't miss. It also means if you finish early you don't really want to pull in more stories. That tells people you're padding estimates and they'll push you to lower estimates or take on more stories. Then when you need that padding it's not there. So if you finish your work on Wednesday it's better to chill and look busy instead of doing more.
(2) is just obviously bad. Delivering complicated projects and supervising other employees makes you look better. So projects get complicated and teams get bloated.
*Crank out code should probably be "build functionality according to good practices" but doesn't really change the point.
There’s no way you can sustain 8 hours/day of productive work 5 days a week as a developer. It’s not working a field or packing boxes, there’s a mental component that gets exhausted over time.
You have to open the file, find the email you were going to respond to, double check with whoever that the answer is “yes”, look up the other attorney’s phone number, double check your calendar to make sure the date works, call you spouse to make sure they can pick up the kids that day, and then call the other attorney.
If you think Biglaw clients, with in house counsel that used to be at biglaw, blindly pay padded bills at $800/hr, you are mistaken.
Does that job involve constant creativity, or is it more about applying existing knowledge? I have no idea, but the amount of knowledge that law students need to cram in a few years makes me think it's a lot of the latter.
> Biglaw attorneys routinely bill 2200 hours a year in 6 minute increments.
A surprising portion of that work is random menial stuff, they don't actually end up doing 40hr/week of mentally demanding work.
> Plus, they do this into their 50’s.
The ones that survive to make partner do. But its well-known that BigLaw absolutely burns through associates. Very few BigLaw associates make it past 35, most eventually leave for saner pastures of corporate counsel/government/etc jobs.
This analogy is interesting do you think there are some lawyers that consider themselves 10xlawyers haha. It make sense that a lot of it would be similar to documentation and meetings and various agile ceremonies and not just 2200 hours of straight legal argumentation and writing.
Biglaw clients aren’t suckers. They don’t pay $800/hr for agile ceremonies. They go over their bills with a fine tooth comb and have ML systems to detect padding.
Not sure if this is changing with all the time tracking software now but it's easier to bill by tenths than it is to track/calculate exact minutes and any larger unit might involve too much rounding up. e.g. .1 for a quick email reply is more palatable than a .25 (1/4 hour, 15min) minimum.
And more than that - it's abstract problem solving. Sometimes the problem is never gonna have an answer until I am washing my dishes after breakfast tomorrow. My subconscious & creativity can't be sped up.
It's this idiocy that you can convert time into software at a fixed rate that got us into this mess.
I recently read through that book and it's nuts both how prescient it is and how different some of the suggestions are than what anyone now would consider.
For instance, there was talk of a team structure with one programmer and everyone else in specialized, supporting roles. That wouldn't fly today because everyone is obsessed with employee fungibility and bus factor.
> That wouldn't fly today because everyone is obsessed with employee fungibility and bus factor.
Rightly so. Job hopping is much easier in the software industry now than it was when that book was written. Average tenure in software jobs is significantly lower than the average for all professions, and even that general average is only around 4 years.
burnout only happens if you are working on something you hate and actively have to force yourself to work on it or have external stress from bad coworkers, managers, or general life stuff. I've worked 12+ hour days on side projects for fun and felt fresh and mentally sharp because I enjoyed what I was doing.
The idea that the human brain hits some brick wall at the scheduled 40 hour work week and can't do anymore thinking is comical
The difference between working from home and working in the office is not how many hours of productive work you do, it's in what you do with the rest of the day.
Every single study done on it shows that creative staff (including engineers) are more productive working where they are less disturbed, that open-plan offices are the least productive environment, etc. So it's utterly unsurprising that people get more productive working from home and can do 8 hour's office work in 5 hours at home.
But even aside from that, if you can complete your work in 6 hours, but can't leave the office for another 2-4 hours because of the office culture, then you'll spend those 2-4 hours doing random stuff in the office. If you're at home, you can leave Slack on and go do something useful. It's not only that WFH gives people more time, it's that it removes the "you must pretend to be busy for 25% of your workday" restriction.
As always, a negative reaction to WFH is a sign of bad management culture. Good managers are happy that their people are getting more done and happier about it. Bad managers see "they're only doing 20 hours a week if they work from home!" and are angry about it.
I'm not sure I understand your question completely, but if I understand it right, this is more a question of "are you hired to do 40 hours a week at work, or are you hired to perform a set of tasks?".
The objections to WFH tend to come from managers who manage by insisting their employees do at least 40 hours in the office each week, rather than measuring actual output and productivity, because it's easier. A similar question is: If you're super efficient and get your work done quickly, can you end your day early and go home?
In your GP comment, you say "But even aside from that, if you can complete your work in 6 hours, but can't leave the office for another 2-4 hours because of the office culture, then you'll spend those 2-4 hours doing random stuff in the office. If you're at home, you can leave Slack on and go do something useful."
I think I agree with your second paragraph entirely.
To me, two issues are being conflated here: the location of the work (wfh vs office) and the length of the work day. The benefits of wfh you are describing sound like they could more or less also come from a 6 hour work day. Ignoring commute time (it's an issue, but just for simplicity's sake). You'd be able to do useful things around your house just the same if you were in an office for 6 hours and able to go home.
Some would describe what you're saying as "slacking" for those hours outside the six, but I don't see it that way. Instead, wfh has become a socially acceptable vehicle for a shorter work day. It allows workers to achieve a shorter work day while bypassing those arguments. I think productive discussion around the issue is impossible until these issues are disentangled.
> Some would describe what you're saying as "slacking" for those hours outside the six
this is the core issue - are you hired to do 8 hours of work, or are you hired to complete a set of tasks?
if the former, then yes, you're slacking off if you stop after 6 hours
if the latter, then no, as soon as you're done with those tasks then you have completed your day's work and can go do something else.
old-skool authoritarian management tends towards the former, and tends to measure time-at-desk rather than actual productivity. Hence they don't like WFH because it forces the latter.
> Every single study done on it shows that creative staff (including engineers) are more productive working where they are less disturbed, that open-plan offices are the least productive environment, etc.
Do you have any specific sources on hand (preferably a good meta-study)? I've heard this claim a lot, and I'd like it to be true, but I've never seen it sourced. Also, I feel like it could depend a lot on the individual, but anecdote is not data.
Sorry, I don't. I did have it when we were discussing productivity during my MBA, and the lecturer gave us a bunch of references for the studies that have been done, but that was a few years ago and they're probably out of date now.
It's one of those well-known truths ("diverse teams are more productive" is another one) that's well-supported by the literature and generally agreed on, but still comes up as "needs citation" every time. I should go dig out the citation so I can avoid this when I bring it up ;)
> you can probably shore up some of that demand just by dropping some of those 4 hour employees and using their wages to pay others to become 6 hour or 8 hour employees.
Sure. Do this if you want to kill morale and be chronically understaffed (either not enough bodies or not enough qualified bodies) for the rest of your existence.
This type of mentality breeds mediocrity for a number of reasons, the main one being that A-players will run away from teams/companies structured around these heuristics. Furthermore, they will make sure all of their A-player friends are aware of this environment.
Good managers and good management teams have no issues with productivity of in-office or remote workers. If your team or company is actually having productivity issues (rather than using productivity as a precursor to a rif), then point that finger at the management and management culture.
I think all successful companies' products have already been built - and have been built for quite a while, most of the work that gets done is just polishing, window dressing, adventures and reorganizing things for the sake of it.
Most of the software and libraries I use nowadays have existed a decade ago, and truth be told, weren't that much different.
I thought it was a widely-known-secret that at least part of the insane hiring of engineers without clear teams, projects, etc for them to work on initially was to prevent individuals working for current-or-potential competitors.
Purposely over-hiring to prevent work being done elsewhere, and then claiming there is not enough work to be done, feels like it shouldn't be surprising to anyone.
Hell, Google has created ~18 (I think?) different messenger/chat apps at this point. If you wanted a clue that there wasn't enough work to go around (and that your promotion incentives may not be aligned with the business), this should have been the first clue.
> I thought it was a widely-known-secret that at least part of the insane hiring of engineers without clear teams, projects, etc for them to work on initially was to prevent individuals working for current-or-potential competitors.
Wow, I've suspected this for many years and people told me it was nutty.
That's because it is. It makes no sense whatsoever to think that could be a deliberate strategy.
Managers are happy when they get their hands on a new role to hire into because they all have more projects than they (think that they) can deliver at good quality with the people they have.
>I thought it was a widely-known-secret that at least part of the insane hiring of engineers without clear teams, projects, etc for them to work on initially was to prevent individuals working for current-or-potential competitors.
I've heard this claimed but not sourced, and it doesn't really make sense - there are millions of software engineers out there and Google or Meta only employ a tiny fraction of them.
100,000 of the best out of a pool of approximately 10 million professional software engineers worldwide is a sizeable portion. Additionally, not all 10 million are even close to being up to BigCorps peculiar standards (perhaps the standard is "someone competent enough that they could potentially build a competing product line").
Goog, Meta, Amazon, Apple, Oracle.. all have huge rosters and it adds up to a significant portion of the market. There is also a huge amount of medium sized whales such as SAP and PayPal who in total end up also consuming a lot of the talent.
Arguably that's Google and Meta's strategy (maybe even Apple) but that's certainly not Amazon's. They just mass hire anyone without a care in the world. Not sure if Oracle even belongs in this group.
It definitely wasn't Meta's strategy when I was there in 2018. They hired a lot of junior software engineers but all other positions had relatively limited headcount (which I mostly think is a good thing).
I believe it. Every single day I get emails from various Amazon recruiters. Often it's for positions I'm barely qualified for. As much as I think AWS is a great service, I'd be terrified to learn what lies beneath given how low their recruitment standards are.
Based on what I've seen from the outside about their corporate culture, I'm not in any way interested in working for Amazon/AWS.
That said, the interactions I've had with the people working on AWS have been uniformly positive. They're easy to work with and obviously very skilled engineers.
Their recruiting reach is high, but it doesn't have that much to do with desperation, and their actual interviewing standards aren't low.
The recruiting reach is high because every single sub-group of teams within amazon has their own recruiters, and none of them communicate with recruiters from outside of that. Sometimes i get multiple emails from different AWS sub-group recruiters per day, but it isn't because AWS is desperate for me. It is simply because for them, the existence of the other ones reaching out at the same time is completely immaterial, just like if they were recruiters from other companies.
And while yes, Amazon's interviewing bar might not be as high as Meta/Google/Dropbox/etc, it isn't far behind at all, and it is pretty much on par with Microsoft.
Disclosure: never worked at Amazon, but interviewed with them and the rest of the companies mentioned, and worked at (or got offers from) some of them.
So for each company they represent at most around (edit: 0.3%) of all professional devs, and presumably the "overhired for anti-competitive reasons" portion is a small fraction of that.
(edit: parent originally claimed 30 million professional software engineers worldwide, then edited in a revised estimate of 13 million.. which is in the ballpark of my original figure? :)
Just because someone "uses JavaScript" doesn't mean they are a full-time professional. In fact, most are dabblers. The number depends entirely on the definition - are all IT professionals considered software engineers? If so, that's about 24 million.
I am talking about full-time SWEs.
In any case Drew, it sounds like we're mostly in agreement. What a relief! :D
We can't really know what is in the minds of Zuckerfk and Pikaichu, in the end it's all speculation.
Yeah sorry I did edit the number down based on digging deeper into my link based on your comment here. I still think 0.3% (my original number was 0.1%) is not a meaningful amount of engineers for a "starve the rest of the world of talent" strategy to work.
I think it's plausible that the superfluous hirings are caused by hirings of key individuals.
It's quite common for these big tech companies to poach each others department heads and other key personnel. This can cause significant damage to a company so can be an attractive tactic. The downside is that in order to retain these people you don't just have to pay them a lot of money you also have to give them big projects and resources to implement them, i.e. lot's of people get hired. This can a problem when these projects aren't supported by the wider company but are just someones pet project.
I'm glad you put it that way. It's not necessarily smarts or talent, but it does take a particular willingness for the institutional peculiarities to integrate with a big organization. I'm not one of those people, I tried it, and I will never do it again. I did note, you either had people who had just joined, or people who had been there for nearly a decade or more. I think of the word "institutionalized", as in, they had bought into the institution lifestyle, and were so full of it's arbitrary knowledge that moving on would be like starting over.
Well, Google's and Facebooks definition of 'the best' engineers.
I don't think grinding leetcode for an interview is the best indicator of a good engineer, and graduating from a prestigious university is not always an indicator either. imho it seems like the best engineers now are the ones doing their own thing outside of the large companies, or are at smaller startups.
Some engineers see themselves as merely tools, so they "sharpen" themselves to be used effectively. Why would MAANAM (FAANG is a bit outdated) want more creative ones? They will get bored and leave.
No, but if all of FAANG are hiring by that criteria, it still works; startups can hire good talent because they break the pareto equilibrium, but that's ok for FAANG because they obtain that tech through acquisition after the idea and execution are derisked. The system works!
That question is pretty meaningless unless you can somehow measure the quality of an engineer. Is it the engineer who can build systems nobody else can, the one who can build the cheapest system that performs to spec, the one that can work well in a team, the one that is always available, the one that can teach others, etc etc etc etc. I'm sure anyone can think of many more aspects to being a good engineer.
I bet NASA and NIST have a great bunch of quality all-round engineers, but I'd be surprised if they were better at leetcode than the average FAANG dev. After all, FAANG devs have literally been filtered through an "are they good at leetcode" process. FAANG may be full of money chasers, but if the way to get more money there is by "being a good engineer" that does not mean much.
Indeed, but "works to the highest (quality) standards" is only one of the many aspects of being a good engineer. For example: government engineers are often not as good at completing projects within budget.
As someone who was a government worker, a lot of the issues why projects go over budget is because management believes that a single developer can do the workload of 4. So the product never gets delivered and that developer leaves to work somewhere else.
I think that dilutes the meaning of "quality" to nothing. Like if someone says "that's quality work" or a "quality engineer" I think of something specific.
For example I'd call a BMW a quality car. I wouldn't call a Lada a quality car, though it's much cheaper and has a much higher bang-to-buck ratio than a BMW.
In that sense sometimes government work has to be the highest quality, especially when it concerns security or safety. Sure it could end up being magnitudes more expensive but I'd say that's a question of efficiency not quality
As the sole maintainer of a popular open source NASA project (and contributor to several others), I can say that my open source work reflects very poorly on my work overall. We have a real problem in that there is a drive to open source things, but there is no money at all to support open sourced work. As soon as the open sourced work is no longer something I use day to day, I have to either maintain it on my personal time or it gets abandoned.
NIST and other government institutes are not known for open source work mainly because most of their work is a combination of science and technology communication. They deal in publications, conferences, and reference datasets. In my industry, NIST and the NIH produce the most important R&D reference datasets in the world, and everyone else looks to them for guidance. With that said, the NIH also occasionally produces world class software too (NCBI BLAST, etc.) although they do have some issues with parts of their software engineering culture being a bit out of date.
Using open source to judge quality seems wild. Maybe people just have no interest in maintaining an open source project. Looking from the outside at some of the stuff people put up with, it doesn't look worth it at all. I'll just work privately
That would surprise me. I have attended targeted career fairs with both FAANGs and national labs recruiting, and the national labs give off way more 'work-life balance' vibes. Plus, as the largest bureaucracy in the history of the world, the federal government isn't a good place to get a high return on brain damage when you want to actually get something done.
Having said that, the national labs do seem like good places to go geek out in your own advanced intellectual cul-de-sac.
Well from experience of being an undergrad and going to career fairs, this assessment is spot on. You don't realize this whole thing is bullshit until a few years into your career.
Because my frame of reference is being early or maybe early-mid career, where you can't possibly have the necessary experience to be 'best' without working significantly more than 40 hours weekly, and from my perspective most of getting there in the future follows that path too. I'm not discounting that some top engineers could exist outside of working a lot, but for most people the path to that distinction is a lot of work, and in most places that lot of work gets done outside of the hours when people are distracting you with meetings and small talk, which means not stopping at 40 hours weekly.
Having said all that, I don't discount the possibility of work life balance in the 60-80 hour range, but that's a whole separate skillset.
FAANG's currently have a problem with ideological mono-culture. I dont know if recruitment has exactly suffered because of that, $$$$$ can allow for a lot of suppression of personal beliefs, but I do know a few people that have outright refused to work in those companies because of that, who are pretty excellent programmers
Feds have some of the most useless engineers/bureaucrats in the world. They do have a very, very tiny amount of mission motivated folks who are the best of the best, but that number is a rounding error. Ask anyone who has left.
Not firing folks, low pay, focus on the best work life balance in history, heavy affirmative action, politics, and having to work hard to carry the coasters isn’t an environment that naturally attracts skill and competence. Work 500% harder than the next guy and get the same promotion. No thanks.
The gov and contractors, like it or not, are jobs programs first and foremost. A remarkably effective jobs program if you just measure folks employed and not output.
> Well, Google's and Facebooks definition of 'the best' engineers. don't think grinding leetcode for an interview is the best indicator of a good engineer
Their employees are also the subset of those who can get to a location where they have offices and have the relevant work permits. Those who do not object to and specifically want to work at those companies. Those who find their technical challenges of interest. Those who do not already have a satisfactory job elsewhere and are actually in the market for a job.
Everyone claims they hire the best. For a long time Google and others had atypical hiring practices which they have since abandoned. I suspect this is because they discovered the techniques were less effective than originally thought. So 'best' by what measure?
I've worked with some really good engineers who came out of google, but I've worked with far more that were extremely arrogant but could not actually get anything done. One of the startups I worked at got an "advisor" from Google (as part of a startup program) that probably set us further back than it ever helped. Anytime this guy didn't understand something he just got extremely belligerent instead of actually trying to get the problem. In general his advice was ignored because it didn't make sense, and he never delivered on any of the promises he made. Not to harp on this guy, as he's just one example amongst many, but it's reached the point where if I see google engineers on the founding team for a company I typically won't consider working for them.
It turns out that being able to solve cute little puzzles while interviewing doesn't really help with systems level thinking.
> Anytime this guy didn't understand something he just got extremely belligerent
I think he might have backed himself into a corner by coming in as an 'advisor'. How can I be an advisor if I look like i don't even understand what is going. That must have been his mindset. So the only escape is being arrogant and belligerent.
Hording talent could be a leftover Chesterton's fence from when they had an illegal agreement between Google, Apple, etc. to not recruit each other's employees, but Facebook was never found to be part of that.
Where are you getting the 10M number? Just curious not a criticism. I was thinking it would be around half of that(5M), with a tenth decent enough to work at most tech companies 500k, I think the bay area has 1M tech workers so half of them are engineers and thats one of the largest cluster of engineering on the planet.
A few years ago I was super curious how we stack up numbers-wise compared to doctors and attorneys (quantities artificially limited in the USA because of licenses). I did the research to calculate based on the number of CS graduates being produced by universities, combining it with average number of years worked before retiring. Unfortunately I don't have the references handy at this point.
Interesting, thanks for that info, licenses in other industries artificially reduce participants in that field. I wonder if tech not having them has resulted in our field to dominate most of the economy in the past 5-10 years(or helped that domination).
I work for Amazon - for a decade. I love it - best job I've ever had. And historically, while it's been a tough place to work, we've always been able to attract top talent. Partially - impactful work. Partially - stock doubles every year.
Well guess what happened in 2020/2021? Despite incredible perseverance through the Pandemic, the stock stopped doubling.
Meanwhile, Microsoft, Meta, and others figured out that they can poach our engineers with a promise of way more base salary, and a less intense work environment.
We've had SDE1s (Juniors) leave Amazon for Meta because they got more money than our SDE3s (Seniors) were getting.
SDE2s (Intermediate) looked at their status quo thought "I COULD bust my ass and get promoted to Senior...or I could go to Microsoft TODAY, get a Senior offer for what I'm already doing, and for more money than my raise would be". (No offense to any of my friends at Microsoft, but https://www.levels.fyi/?compare=Amazon,Microsoft&track=Softw... doesn't lie)
I've talked to a few acquaintances that have left and the universal responses is: "My job is so boring now. I miss Amazon. But It's not stressful (because there is no pressure on me), and I get paid more money".
How can anyone think there is anything wrong with that? You can't. You can speak about Mission and Impact, and some engineers will be attracted to that - I work on building Forever APIs in the AWS Cloud that gets millions of transactions per second. That to me is WAY more interesting than working on Chat app 15/18.
But for most people they just want to make money and live their lives. Fair enough!
The result? Even though Amazon has adapted somewhat by bumping salaries, they've still lost an ocean of people to nothing particularly ambitious or interesting. They're being parked by Microsoft/Google/Facebook to work on boring unimpactful projects so they can't help Amazon kick their asses.
Sometimes one way to make your house nicer is by breaking the windows in the neighbor's house.
Every competitive has a stack ranking system whether they admit it or not.
They put lipstick on a pig but everyone's getting ranked and the lowest performers getting weeded out.
The whole "People get fired even if they're doing a good job just by being a low performer on a strong team" is an edge case that happens INCREDIBLY rarely but when it does gets all the attention.
Makes me wonder if junior developers are getting bait and switched.
They get pulled away by the lure of money into an environment that causes them to stagnate in their skill and career development, then companies pull the rug after only a few years of this high pay with layoffs. Now you've got hoards of developers with junior/mid skills who expect senior salaries and can't find jobs. Amazon doesn't want them anymore, because the new grad pipeline has plenty of people nearly as technically capable and much hungrier.
Only those who manage to recognize this short term period of plenty and rapidly stack investments toward financial independence will be alright in the end. Those who thought the raining cash would never end are in for a world of hurt.
On the bright side for Amazon, they get to trim off the employees who a) aren't paranoid enough about the viciousness of the business world, and b) are looking for a way to cruise and do minimal work.
> They get pulled away by the lure of money into an environment that causes them to stagnate in their skill and career development
Microsoft is in an insane number of markets, far more than Amazon. While at Microsoft I did everything from compilers to robots to wearables, and if I talk to 10 Microsoft alumni they will have a job history of working on a completely disparate set of amazing technologies.
If you are bored at Microsoft change teams. You can find teams writing assembly, or C++, or C#, or Rust, or JavaScript, or Typescript. You can find teams working on browser engines, on ISO standards, or consumer tech.
Get bored with all of that, go work on video games for awhile.
People are typically ranked by influence at companies as well. If you want to increase your influence, hire more people beneath you. Amazon managers specifically will be looked at for how good they are at hiring and how many people are beneath them to see if they're ready for the next level. At least this is what an Amazon EM told me.
I worked for a while at another company also known for being hyper-aggressive and a brutally difficult work environment -- probably the poster-child for that sort of thing, back then. I burned out hard after a couple years and ended up prioritizing "work-life balance" in my next job searches.
I landed at a 40-hour/week place where I usually work less than that. There's a strong appeal to working so little for a solidly decent salary. I have to remind myself often how good I have it, especially when others don't have jobs at all -- or they have to do back-breaking labor for table scraps.
But I agree it's also undeniably boring. I constantly find myself fantasizing about being back in the adrenaline-fueled environment of my last job. A large part of why I burned out was my own poor stress-management skills, and I like to imagine that I could probably perform well -- and excel -- in that sort of boiler-room environment now. (Especially if the comp could be what it was, too!)
On the other hand, I think all companies that have tried that aggressive approach have not made it sustainable. People burn out, or the whole company burns out, or both. It's tough to keep it going without lots of support and motivation (financial and otherwise).
The idealistic part of me likes to imagine it's theoretically possible to sustain such a thing, though -- a healthy, psychologically-safe place where people could work on ridiculously impactful things at a velocity and scale not available anywhere else. But it doesn't seem like anyone's cracked the code -- not my former employer, who faded away in a blaze of toxicity, and certainly not Amazon.
I personally don't believe this at all. I think it's almost entirely bureaucratic inertia, and a prisoner's dilemma among the management. One who bloats, floats.
This is the truth. Many managers are valued on how large they can grow their team. Also, if you have 10, 20, 100 direct reports .... how can they fire you?
On the other hand, if no-one stops it, there are always incentives to grow your team as much as possible.
As leader this increases your status both in absolute terms (100 vs 10 people under you makes a difference on your CV and on the title you can claim) and in relative terms (your team is larger than the teams of your peers and you can get ahead that way).
And so every leader at every level tries to expand their team.
Google et al. cargo culted SGI culture -maybe it works for a class of geeks. Anyway they often coddled employees and treated them "like family" as they like to say and tell them they are special and the lucky few. You can bring your pet to work (if no one has allergies to it), you can waltz in late, go get a snack, log in, chat with your friends, play with new gizmos, then go to a meeting, get lunch, then work out, then have another snack and then the last meeting of the day before you cut out early to get in the (Co.)-bus home before traffic gets bad.
Where the hell did they think productivity would go?
Easy: it goes both ways.
Keeping employees happy means they are willing to voluntarily spend more time at work. "Chatting with friends" is more often than not informally discussing work projects. Going home before traffic gets bad and working a few hours from home is the sane thing to do.
My current employer is very lenient, and as a result I am very happy working here and put in more than I am required to. If they were very strict, I would work _exactly_ 9 to 5 and not a second longer - if I even wanted to work there at all.
Fact is, you simply can't be 100% effective 100% of the time. So you either end up with people _pretending_ to be busy, or people who are free to openly de-stress and are way happier employees.
I don't disagree with you there, but also companies that have to be mindful of their cashflows can't afford to have people work for them who think it's a club-med for work. I'm not advocating that employees have to work it to the bone to be productive as we need long term productivity, but at the same time we need conscientious contribution and productivity.
> If you wanted a clue that there wasn't enough work to go around (and that your promotion incentives may not be aligned with the business), this should have been the first clue.
There is definitely enough work to go around at Google, Amazon, and Apple.
Whether promotion makes any sense, and whether people are working on the things that actually move the needle is a different question.
> "I thought it was a widely-known-secret that at least part of the insane hiring of engineers without clear teams, projects, etc for them to work on initially was to prevent individuals working for current-or-potential competitors."
It's widely known among the sort of person who tends to believe in conspiracy theories, I suppose. The oppressive bureaucracy and misaligned incentives that allow senior leaders to destructively compete among themselves is more than enough to explain why ill-conceived and ill-run projects are common at FAANG-level megacorporations without resorting to making things up.
Your theory and the theory you are replying to are indistinguishable for an outside observer: big player with hiring power and hubris compete for employees; in one case it is companies and in the other it is managers.
Even if I admit yours sounds more likely (companies choosing to spend more of their own money vs managers choosing to waste the company's money)
Then why is their hiring geared toward brain teasers and Bigoh notation? If they want to keep people from building the next Facebook (costing them M&A money, because they'd have to acquire it), why not hire based on ability to get things done?
> To be sure, the Covid-induced pandemic saw Meta embark on a massive hiring spree, growing its number of full-time staff from 48,000 at the end of 2019 to more than 77,800 — a 62 per cent jump. But now the firm must “prioritise more ruthlessly” and “operate leaner, meaner, better executing teams,” Meta Chief Product Officer Chris Cox wrote in a memo, which appeared on the company’s internal discussion forum Workplace before the Q&A.
The article doesn't mention a different problem. Those new hires entered at extremely inflated salary levels due to literally every other company doing the same thing at the same time. Righting that ship means not just layoffs, but recalibrating salary expectations. The process is just starting.
When the acronym was coined, Netflix was in the process of disrupting the entire entertainment industry and it looked for all the world like it was going to eat them all. As it happened, the industry (well, Disney and HBO at least) figured things out faster than expected, so much of the speculation on Netflix turned out to be wrong. But they absolutely were a Top of the World tech innovator for a while there.
But it's just an acronym, it's not perfect. The other big error is that, obviously, Microsoft needs to be in that list given their pay scale and hiring process.
Yes, top reason an average enterprise developer has to deal with a distributed mess as opposed to a more manageable monolithic one: "we will do microservices despite being nothing like Netflix". On the upside, more developers are now required.
Few work, mostly because the desire to get stuff done gets nixed from day one by process, bureaucracy and business drones. Also, the prospect to make an actual fuckton of money is completely unlikely these days.
Google can't get anything done for a very simple reason:
a) comps are way too high. why bother doing anything when gold rains from the sky every day of the year.
b) you're never going to make it to 50 Million at Google however hard you work, unless you make it to SVP, which is a 15 year endeavor. In other words, strictly no incentives to do amazing stuff when compared to a startup.
c) the environment is highly political, actual entrepreneur spirit is long gone and/or smothered by product type folks.
If what you're looking for in life is a civil servant type of highly paid cushy job, Google is the perfect place to be. If you want to innovate and change the world, flee this godforsaken place as soon as you can.
How would they get that comparable info from other companies? Do the CEOs all have a secret slack channel were Satya is bragging that one MS dev equals 3 googles programmers?
All you have to do is take the company's rev/profit and divide it by the number of employees (factoring in how much you pay an employee)
So yeah if MSFT can make 3 billion dollars with 1000 engineers, and Google makes 1 billion dollars with 1000 engineers, then 1 MSFT eng is worth 3 of Googles (simplified - obv business involves sales, marketing, etc)
That's not a measure of how much work engineers are doing. It's a measure of how effective the company is at making money from the work their engineers are doing.
Right. Consider how different the profit of a company hiring $300,000/yr software engineers to mow lawns 8 hours per day might be, compared with another company hiring them to... write extremely valuable software 4 hours per day.
The company with (let's say) identically-skilled employees putting in twice as many hours probably won't be the more profitable of the two.
Replace "mow lawns" with "write pointless, doomed-from-the-start messaging apps" and the actual problem starts to become clear.
Or more exactly how much work the engineers have done in past and how big moat the management or luck have build... Sometimes I really wonder how much the current employees contribute in companies like MS, Google and Meta...
Is that really an accurate way of measuring anyways? Company A may just have a more complex product and need more developers. Doesn't mean Company A should just remove developers since Company B doesn't need that amount for their unrelated product.
I'm a bit worried that this will trigger some kind of move to measure productivity in increasingly crude ways -- i.e. exhaustive, invasive telemetry that tracks every mouse click and keypress.
Why give an inch? Meta is struggling because they put all their eggs in one basket, and turns out that was probably not a good bet. And now they're struggling for it. That's leadership's problem.
FAANG employees make up a group of some of the most hire-able employees I can think of. If leadership makes work hard, they will quit.
(Baring H1B employees, they just get the shit stick all around, but that's not unique to this particular issue)
Technical people often believe using more/new tools will solve people problems. "If only we could measure more by better decomposing tasks in Jira, then we'd know how to be more efficient! If only we could add micro-specific tags to or documentation, then anyone can search for what they want and find the resource! We just need to put every single process anyone has ever heard of into confluence; then anyone can look them up and follow them!"
Tools don't solve people problems because at the scale of people problems everyone has a different philosophy about the tool (and the problem). Communication is what solves people problems.
How do they conclude that “few work”, other than through some expectation of productivity compared to head count or payroll? Do they have a problem with employees literally not working? How do they conclude that?
Could it be that meetings can often happen in email, and if the meeting is important use Skype or another in office messenger app so that employees don't need to leave their desks?
1,148 comments
[ 2.6 ms ] story [ 304 ms ] threadFar too often middle managers are incentivized to build the largest team possible.
While the message from the top may be "lean and mean" but you compensate middle managers based on team size...
Perverse incentive certainly comes to mind.
Google has long had an attitude of "we hire the best so we can afford to have them stand on one leg and balance on a ball while holding a cane in their mouth and balancing a bunch of dishes on the end of the cane while typing with one hand on a chorded keyboard and looking at a monitor through a mirror." I've heard stories that range from "of course I am productive, I am shooting the s--t all day with the smartest people to" to "I have no idea of how what I'm doing impacts the bottom line".
Who's to blame for lowered employee productivity: employees who are disconnecting from work more to avoid burnout thanks to corporate BS like paperwork and constant report filing? Or the managers who impose those requirements on employees but fail to empower the individual contributors beneath them in the org chart?
I recently left a large-medium sized tech company that failed to address massive structural issues in my department for years. It's not like these were a secret -- I brought them up constantly in my 1on1s, and tried to brainstorm solutions with my management chain.
When I left, the head honcho begged me to stay, and when I brought up those issues... told me he had no idea that was such a problem! But also refused to address it because he had to "gather information" about the issue.
I'm much happier at a smaller company without so much bureaucracy. At some point, managers are so disconnected from their underlings that they are completely incapable of improving work conditions. And when you need high-level approval to make a big decision... more often than not, the big decision just never gets made.
If you choose not to decide, you still have made a choice.
If you are doing that for your products though you are never going to get long-term traction no matter how good or bad your engineers or marketing people are.
Very different to Wallet.
Something that really surprised me at Google is how many core services had very thin test suites. I'm the kind of person that sees 100% code coverage and thinks "that's a good starting point". If I don't have that, I'll definitely break something important in 6 months. There were a lot of people at Google, though, that definitely didn't need those guard rails. The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.
It wouldn't work for me but there were a lot of people at Google that absolutely didn't need to follow "good engineering practices" to do good engineering. I was impressed. A lot of people less smart than them try this and fail, but they made it work.
> The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.
I think testing at Google is excessively complicated for a myriad of reasons, and the unit-test-style "coverage" doesn't really map well to how things work together in a larger system. That system-wide thinking is where the "read a code change and know exactly what's wrong" intuition becomes invaluable. *Integration* testing is especially hard for some reason (probably complexity in the serving stack, at least for many teams I've worked with), so you end up getting this pattern where people get better at other production health stuff like canary systems, release management, etc.
My two tips are:
1) Treat services you call like your own code. Familiarize yourself with the server code. Try running it locally and poke at it. If you run into problems in staging/production, go look at their logs and monitoring dashboards (if that's still allowed; I have a feeling that things have changed around permissions since I left). What I learned that there was never an error I needed help with as soon as I read the code and error logs of the app I was trying to call. "Oh, this deprecated field is actually still required, it's just IGNORED now", that sort of thing. In the real world, it really helps with open source libraries. There is never any useful documentation. So get used to reading the code, and you'll never notice it's missing. As you get good at it, it really becomes a productivity superpower.
2) Fill out all available forms. I wrote and maintained a monitoring system at Google. I remember going to some tech talk about how the network worked, and realized that I could be using a high network priority instead of Best Effort, just by filling out some form. In the unlikely event of a network problem, we'd probably still have monitoring! Fill out the form I did. And one day there was some network incident where a lot of consumer-facing apps were slow/down, and my service didn't miss any messages. No unnecessary outages or pages or a long night, all because I filled out a form that anyone could fill out. I honestly felt a little bad because I guess we could have lived without the monitoring if it would have saved GMail. But hey, victory goes to the team that's willing to fill out the form and maybe have a quick meeting about it. Not everything in software engineering is programming.
There is quite the ramp up time, and there is a lot of learning to do, but once you get a handle on it, you can really do great things at high speed. If you ever leave, you will miss it. As much as people complain about the tools/systems/libraries, it is all really top notch. The "real world" is a hodgepodge of half-baked systems that all cost $30,000 a year. (Whoever wrote Prometheus left too early and cloned varz instead of Monarch. Hurts my soul every single day.)
I most miss D, Spanner, Blaze, and Monarch. Spanner you can buy from Google, but I can't afford it. Bazel is open-source. The rest... you just have to settle for something not as good.
Blaze seems very nice. I'm deep in a special domain far from g3 - so I only came across it this week. But it has worked exactly how I want it to and has given me no trouble, only a good experience so far. Much better than the terrible world of whatever build system NodeJS is using this week.
And the perks are pretty nice. Not enough to make me never go back to startups. But I appreciate them. Extra days off that no one else would get. Free trips to amusement parks. Days off to go sailing. Good free food. Good free cappuccinos. Good free snacks. Free car charging. I'm shocked so many people living in Mountain View refuse to commute in after working from home for two years.
The barrier to entry to write a chat app is zero. Even if you are brilliant you will compete against hundreds other chat apps one of which will beat out with pure luck. Never compete against luck.
iMessage is nice but has far far fewer users than WhatsApp, WeChat, etc.
* a genuine interest in trying new things and trying to see if they'd stick, without the baggage of established UX & customers - Allo/Duo are like this. I don't think people give the company enough credit for this.
* leadership downplaying the cost to the Google brand of shutting things down all the time. When brought up internally, execs shrug saying that we must be willing to try and see if things stick. This makes sense, but why are people particularly mad at Google for doing this? It must be for a good reason, not merely a meme.
* org silos. The org behind Google Docs / Chat has a different reason for a chat app (chat as a checkbox for enterprise office suite sales) than the one behind Google Maps (you can chat with restaurants or whatnot)
* a lack of a good "design dictator", meaning our chat apps, as with other apps, falter for lack of great UX and don't gain traction. The biggest example I can think of is how Google Chat has a loading spinner for the emoji picker - this simple thing should be lightning quick, but it took a year for someone to even prioritize it.
* faulty marketing / branding. Taking the simple, beloved "GChat", which was the dominant chat app between AIM and FB Messenger, and wringing it though "Hangouts" and "Allo/Duo" and "Chat" - that's no fun for users.
I think the lesson here is that people want a simple, hyper-fast app that gets out of their way and slowly adds nice things on top. I'd say the apps that are most fun and fast to use are Messenger and iMessage. (I have plenty of problems with both - unremovable stories on Messenger, lack of archiving chats and general slowness on iMessage).
All these are my opinions.
Because it doesn't actually make sense.
* Google has an audience. I suspect everything Google does is a good enough idea for a small subset of people -- or solves a problem for a lot of people but isn't profitable, like Google Reader -- and because it's Google doing it, a lot of people hear about it and use it. So the shutdown of Google's random ideas affects more people than the shutdown of some random startup.
* Google just kills the products completely instead of spinning them off or selling them to interested parties as earlier incarnations of Silicon Valley tech companies would have done. A company not bloated from search advertising revenue would have happily sold something like Google Reader for some money instead of just killing it.
This was one of the major factors that led to me walking away from there after a decade.
That, and it's just a slow boring place to work most of the time. One spends the bulk of one's time basically seeking permission to do the thing that needs to be done -- by this I mean: get in the right MDB groups, get the right sign off on design docs, be sure to be in the right team, be sure to have gotten the right people on your code reviews, made sure there's visibility to the right stakeholders -- and hope to god the thing you're working on isn't sexy enough that somebody better connected won't just steal it from you when you're halfway through it anyways. Or just take credit for it.
And the perf process and the culture around it produces terrible results on top of that.
Paid well, but was a terrible place to work. Especially once COVID hit and the free gourmet food and subsidized massages were a thing of the past.
Alternatively, the economic forecasters at these companies see trouble on the horizon economically and know that layoffs to boost stock price will be necessary. In such case, best develop a pretext for these layoffs thats not "We're having financial trouble so we're laying people off". Instead it's "Nope, nothing to see here, THIS IS FINE - we're just cutting dead weight!".
I don't work for either of these companies nor do I know anyone personally who does, but I have to wonder if a sort of entitled, country club culture developed there and this an effort to reign in that behavior. Maybe someone with some inside insight can comment here?
So while measuring performance might seems like a core job function, de facto it is not.
Also people that find this thread interesting should join Blind.
This goes double for the other concerns you mentioned: if you’ve created an incentive system where people commonly BS their way into promotions, that’s a major management failure.
What is "Blind" ? Is it some sort of think-tank ?
If the manager has done a good job he/she has hired people that are more knowledge and experienced in their specialization fields then the manager. This is only true for "intellectual" work though, if the employees do physical work, like laying bricks, you can measure performance on how many bricks where laid.
For example, one employee might have spent 3 weeks carefully reading code to find a bug. Not a single code push for a whole month. And might not even have found the bug. But likely found lots of unused code that everyone been too scared to touch. So if you're measuring performance by LOC written, that person could end up on the nagive.
I couldn't tell you what fraction of employees, but there are folks hiding in all of the big tech companies that are happy with their comp, aren't trying to advance, and have adopted the "do the minimum to not get fired" approach to their work.
If too many of these get together in one org or on one team, the whole thing gets poisoned and everyone starts barely getting anything done.
Oh well. Maybe they can spend their time replacing my work.
Why does this
> and have adopted the "do the minimum to not get fired" approach to their work
necessarily have to go with this?
What's wrong with deciding "I don't need to advance further; I like the work I do, I make enough money; I don't need to be hustling anymore"?
It seems to me the concept of "enough" is hard to grasp for a lot of people, especially those who are deep in any high-paying field (not just SV tech types, but certain kinds of doctors, lawyers, etc).
If there's no place in Silicon Valley for people who know what "comfortable" feels like, then it's definitely a place I'd prefer to stay away from.
In others, as implied by the post I was replying to, people think that if you're not constantly Striving, you're not good enough.
If the bare minimum is getting promoted then that means there is no room to slack.
If you look like you are slacking to your coworkers, then you probably are not doing the bare minimum. The bare minimum would be exactly what it takes to keep your job.
So I believe what you are saying is that there are multiple bare minimums from various perspectives. In those cases, you take the biggest one.
Another example for a gameable aspect of promotion is cutting up your achievements to look more favorable during a promo round e.g., salami slicing. If you hit a promotion, save the extra stuff for the next round.
And if you are at a large organization, you certainly have the data to estimate exactly the bars for promotion.
If the work you are doing falls in this middle range, then your slacking will harm those around you but you probably won't get fired (if it takes longer for a manager to get fed up than the mean time between reorgs, you probably can survive indefinitely)
But I agree if the promotion/firing is relative or dynamic in some way, then you’d race down to arbitrarily low effort.
The real problem is correlating work with value in an unbiased way. If you had perfect information on the value of each worker, I can’t see how it would be complicated to do a cost/benefit analysis.
But without reading/predicting the future you can’t usually figure out value because an unfinished product has no current value and a finished/legacy product has fixed value. In either case the worker has no marginal value.
There are lots of people who are comfortable where they are and continue to do solid work. I'd say that's probably almost half of folks at the mid-career levels in the big tech companies. This is actually why rest-and-vesters are so damaging. If you get a couple of these people on your team, they tend to bring down the morale of the much larger group who are earning their keep.
It's easy to be happy getting paid your current rate for doing a good solid job. But, it is really hard to stay happy in that situation if the person sitting next to you is getting paid the same, but doing almost-but-not-quite nothing.
In this situation, the previously-happy-worker types tend to either 1) seek a new team where they're not working with a rest-and-vester, or 2) slowly degrade into emulating the rest-and-vester because they feel demotivated and that their work isn't appreciated (since it isn't being appreciated more than the rest-and-vester's non-work)
Good managers identify this situation and put the rest-and-vester on notice to shape up (many of them will if you work with them -- many of them used to be the previously-happy-worker but at some point got poisoned and just need to have the callouses removed. (And a few of them just need the boot)
--
On the other hand, in tech really you are either growing or dying. That doesn't mean that you have to be growing in promotion/job-ladder-shaped ways. But if you're not learning something and growing in some way, you're probably regressing.
but this has nothing to do with your work - you grow and learn as part of your personal desire or interest. If it happens that your personal interest intersects with your job, then that's a great coincidence.
HP did this back in 2013; be in the office or resign.
Is Zuck really slaving away at his desk 9-5 everyday? I don't think so.
Sounds like another case of "One rule for thee and another for me"
People will point to "studies" showing how remote work improves productivity. Maybe it did initially but eventually, people will check out, feeling isolated, feeling less motivated.
Some people who worked remotely before covid swears that it helped their productivity. But these people are biased because they were probably one of the few who were disciplined enough to make it work and they gained the employer's trust over time.
There were a lot of reports of Zuckerberg bemoaning about productivity. Tim Cook wanted everyone back in the office full-time before Delta. Google also wanted everyone back in the office. Clearly, these CEOs aren't just making decisions on a whim and they have real data on productivity rather than some 3rd party studies.
This opinion is not popular here but this is how I see it.
You do realize that most engineers would hate to have to do the work of a PM? Talking to users. Analyzing data. Coming up with solutions. Convincing executives. Convincing designers. Convincing dev managers. Convincing devs. Writing specs. Handholding the project through the finish line.
You told me you don't want more meetings. But you realize that you'd have to have a ton of meetings to do the above? You think a spec just magically shows up and a ton of work was not done before it ever makes it to your queue?
>Engineers should be treated as problem solver and not code monkey
Engineers solve technical problems. Some engineers want to solve business problems too. Those might be good candidates to become product managers.
I was a PM for many years. Now a tech lead dev. My job as a PM was significantly harder and more stressful than being a dev.
(Kinda struggling with that now; I'm peripherally involved in a project with big monetary implications. The "solution" is to build a big system as quickly as possible and run around making super-high-priority requests across a whole lot of teams, almost all of which need to be in place before any value is obtained, and which consequently is behind schedule and dragging out. On the other hand, a week, some database queries, and a reasonable amount of manual labor could get about 50-75% of the value now. But none of the project managers are interested in that fact, which frankly boggles my mind. I'm not sure if they just don't understand what I'm saying, or are just so stuck on the solution they designed that they've lost all ability to think outside it. One thing I have confirmed is that it isn't just that I don't have a full picture of the problem, which is the usual situation; I'm quite confident what I'm thinking would work.)
However, while that skill is not necessarily something you need a graduate degree for and 20 years dedicated experience, and engineers can pick it up, there are engineers who don't have it yet, or even won't pick it up because they despise it. The list of skills required to be an engineer is already pretty long, requiring this to be added as well raises the bar even higher.
It comes down to some people thrive working remotely and some don't. At any level higher in mgmt than a single team there isn't really any way to determine who can thrive and who can't. Pretend its a 50/50 split across 100 people, the only way upper mgmt can see to get pre-covid productivity is to go back to the office.
I will say another unpopular related point on this: people with young children are more than likely to not thrive working remotely. Or at least they've probably never had the chance to see if working remotely is good for them because they may have had their kids home with them these past couple years. You know how we don't like distractions when trying to do focus work? I can't imagine trying to do focus work with a child or two under the age of 5 there with you all day.
Messing with k8s, looking at logs, or occasionally hopping into a zoom to discuss architecture for an upcoming project that I don’t find any interest in beyond ensuring the stock goes up, it feels like I’m a cog and I just do things and somehow we keep going.
Three years ago I would be super engaged and going to conferences to show off our latest work. Maybe it’s the combination of doing boring (to me) infrastructure and dev ops work along with zoom culture. Back in the day I was a mobile application developer so that was quite a different lifestyle compared to this. Idk man, I’m doing my best to do a good job but honestly it is the worst experience of my life so far. I’ve been spending my time outside of work in evenings and weekends hacking away on side projects. They give me far greater joy, which I used to find previously at work.
I found much greater joy going to the office everyday, working, meeting with my coworkers, doing things after work like grabbing a beer in the kitchen, etc. I really missed those things. Now I'm just staring at a screen for 10 hours a day. Two extra hours because I feel like I need to prove that I'm working while I'm remote.
It sucks. I feel way less energy and less passion for the company.
I keep wondering when this crap is gonna end and people will realize that this "pure remote" shit absolutely kills innovation and creativity. But man... it's super depressing. I used to love my work. Now it sucks.
I think it will take many years before this shakes out. I think companies that are in-person will out-compete and out-innovate those who aren't. I think the pendulum will start swinging back to in-person.
I dunno. It's exhausting though. I feel very trapped by all this crap. I could only imagine being a new-hire or some fresh college grad...
Imagine trying to build a relationship over Slack and Zoom as a new hire. I'd be lost and frustrated.
It's just not the same.
Asking people to 100% return to the office is unpopular (or at least controversial) to some, right? If there was "real data", why wouldn't they mention that in their communications to staff? Instead, it's full of wooly statements like "there's something missing" and vague stuff about collaboration.
This seems to be a more generalised fallacy - "The <government/CEO/authority figure> don't do things on a whim, therefore they must have additional (secret) information on <controversial decision>. Based on this, they're obviously correct - after all, they've got that secret info!".
FYI, Facebook and Google CEOs both said productivity is down and they expect more out of their workers. They said so to their employees which obviously got leaked because there are tens of thousands of them. I'm guessing that they don't want to specifically blame remote/hybrid work because it might offend a lot of people and get bad PR. Instead, they're slowly nudging their workers back into the office.
Apple never said anything publicly or to their employees about the lack of productivity and they never will. They will never do so because it'd be a huge PR hit. It's not Apple's style.
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.
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.
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.
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.
Worse, it's often over-fitted to memorized specific solutions to esoteric comp-sci algo problems.
So you end up with a bunch of, admittedly smart, developers who all have the spare time to memorize an entire suite of algo problems and solutions.
Some of those developers are going to have copious amounts of spare time while working at your organization as well.
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.
That would be a surpreme waste of company money, and probably they have engineers working for them who are far better developers than they are.
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.
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 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.
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.
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.
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.
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.
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).
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.
1 - https://nypost.com/2022/07/01/rotterdam-wont-dismantle-bridg...
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.
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.
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.
Relatedly, I still don't understand why people are upset at these companies' hiring practices.
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 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.
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.
1. https://developer.squareup.com/blog/ace-the-square-pairing-i...
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 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.
Some people love going to trivia night! Get some friends, get quizzed on some stuff, feel smart.
Lots of people are not interested.
Are you sure "need" is the right word here? Whatever Boeing's been doing recently hasn't been working very well for them or 737 Max passengers.
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, 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'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.
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.
https://news.ycombinator.com/item?id=27571707
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.
if you've got a tank of gas you can go a long way slowly, a short way quickly.
a flywheel takes a lot of effort to spin up or spin down. once it's going at a certain speed it tends to stay there.
so if you tend to get home, eat burritos, and watch netflix, you'll keep doing that.
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.
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.
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.
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.
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 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.
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...)
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.
Anyone who joins a company can crank full 8+ hours a day for a while to establish themselves (and a reputation).
The "problem" is, as people establish themselves, the problem domain becomes less exciting. There's less urgency to crank indefinitely. They settle into a pattern that involves fewer hours, though those hours are more productive because they know the ropes.
There is a sweet spot where someone knows enough to be productive but isn't yet complacent. This is the spot that every employer dreams of: employees cranking, full speed, productively, for 8 hours.
It's just not sustainable. You can fire people and try and keep turning over staff such that everyone stays in that sweet spot, but you'll eventually end up with a different sort of headache when your staff has no organizational memory for why decisions were made. The people who built things and have the long-term visions have left, and those who pick up the torch try will never have the same big-picture in their head.
The challenging bit is how do you separate someone who works 3h a day because that's all they can sustain (and they're just being realistic), and those who work 3h a day, could work more, but chooses not to? I'm not sure you want to force either out, but can you incentivize the latter to produce more?
If your 3-hour-could-be-8 made adequate contribution, whatever that is, that's enough. If it takes them 8 to get to where the other is, incentives will push them to do so.
This works great until you PIP an underperforming female, minority, or person over 40.
The discrimination lawsuits will make the company regret their progressive stances.
You wouldn’t believe how many times I have seen this happen.
The median outcome is a settlement with no admission of guilt (usually because it’s cheaper than the alternatives), and the person now has a job for life or is given severance until they get a comparable position elsewhere (and they won’t be rushing).
(1) leads you down the path of padding estimates so you don't miss. It also means if you finish early you don't really want to pull in more stories. That tells people you're padding estimates and they'll push you to lower estimates or take on more stories. Then when you need that padding it's not there. So if you finish your work on Wednesday it's better to chill and look busy instead of doing more.
(2) is just obviously bad. Delivering complicated projects and supervising other employees makes you look better. So projects get complicated and teams get bloated.
*Crank out code should probably be "build functionality according to good practices" but doesn't really change the point.
Looking at my day as a carpenter, then:
- 30 minutes break
- 30 minutes startup/cleanup
- 1 hour moving stuff/between jobs
- 6 hours ostensibly working; 4-5 hours focused
And what I expect of SDEs, now:
- 1 hour breaks
- 1-2 hours communicate (email, CRs, meetings, etc)
- 1 hour continuing education/corporate overhead
- 4-5 hours writing code/tasks
I’m always skeptical when I hear people are doing more than around 4 hours of coding a day — and start to wonder what’s being skipped.
Add in nonbillable work and self-written off time, and many of these attorneys work 60+ hour weeks. Plus, they do this into their 50’s.
You have to open the file, find the email you were going to respond to, double check with whoever that the answer is “yes”, look up the other attorney’s phone number, double check your calendar to make sure the date works, call you spouse to make sure they can pick up the kids that day, and then call the other attorney.
If you think Biglaw clients, with in house counsel that used to be at biglaw, blindly pay padded bills at $800/hr, you are mistaken.
How much you bill and how much you work aren't necessarily the same. Why would you think they are?
> Biglaw attorneys routinely bill 2200 hours a year in 6 minute increments.
A surprising portion of that work is random menial stuff, they don't actually end up doing 40hr/week of mentally demanding work.
> Plus, they do this into their 50’s.
The ones that survive to make partner do. But its well-known that BigLaw absolutely burns through associates. Very few BigLaw associates make it past 35, most eventually leave for saner pastures of corporate counsel/government/etc jobs.
Not sure if this is changing with all the time tracking software now but it's easier to bill by tenths than it is to track/calculate exact minutes and any larger unit might involve too much rounding up. e.g. .1 for a quick email reply is more palatable than a .25 (1/4 hour, 15min) minimum.
It's this idiocy that you can convert time into software at a fixed rate that got us into this mess.
[0] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
For instance, there was talk of a team structure with one programmer and everyone else in specialized, supporting roles. That wouldn't fly today because everyone is obsessed with employee fungibility and bus factor.
Rightly so. Job hopping is much easier in the software industry now than it was when that book was written. Average tenure in software jobs is significantly lower than the average for all professions, and even that general average is only around 4 years.
The idea that the human brain hits some brick wall at the scheduled 40 hour work week and can't do anymore thinking is comical
Every single study done on it shows that creative staff (including engineers) are more productive working where they are less disturbed, that open-plan offices are the least productive environment, etc. So it's utterly unsurprising that people get more productive working from home and can do 8 hour's office work in 5 hours at home.
But even aside from that, if you can complete your work in 6 hours, but can't leave the office for another 2-4 hours because of the office culture, then you'll spend those 2-4 hours doing random stuff in the office. If you're at home, you can leave Slack on and go do something useful. It's not only that WFH gives people more time, it's that it removes the "you must pretend to be busy for 25% of your workday" restriction.
As always, a negative reaction to WFH is a sign of bad management culture. Good managers are happy that their people are getting more done and happier about it. Bad managers see "they're only doing 20 hours a week if they work from home!" and are angry about it.
The objections to WFH tend to come from managers who manage by insisting their employees do at least 40 hours in the office each week, rather than measuring actual output and productivity, because it's easier. A similar question is: If you're super efficient and get your work done quickly, can you end your day early and go home?
In your GP comment, you say "But even aside from that, if you can complete your work in 6 hours, but can't leave the office for another 2-4 hours because of the office culture, then you'll spend those 2-4 hours doing random stuff in the office. If you're at home, you can leave Slack on and go do something useful."
I think I agree with your second paragraph entirely.
To me, two issues are being conflated here: the location of the work (wfh vs office) and the length of the work day. The benefits of wfh you are describing sound like they could more or less also come from a 6 hour work day. Ignoring commute time (it's an issue, but just for simplicity's sake). You'd be able to do useful things around your house just the same if you were in an office for 6 hours and able to go home.
Some would describe what you're saying as "slacking" for those hours outside the six, but I don't see it that way. Instead, wfh has become a socially acceptable vehicle for a shorter work day. It allows workers to achieve a shorter work day while bypassing those arguments. I think productive discussion around the issue is impossible until these issues are disentangled.
this is the core issue - are you hired to do 8 hours of work, or are you hired to complete a set of tasks?
if the former, then yes, you're slacking off if you stop after 6 hours
if the latter, then no, as soon as you're done with those tasks then you have completed your day's work and can go do something else.
old-skool authoritarian management tends towards the former, and tends to measure time-at-desk rather than actual productivity. Hence they don't like WFH because it forces the latter.
Do you have any specific sources on hand (preferably a good meta-study)? I've heard this claim a lot, and I'd like it to be true, but I've never seen it sourced. Also, I feel like it could depend a lot on the individual, but anecdote is not data.
And yes, open-plan offices truly suck.
It's one of those well-known truths ("diverse teams are more productive" is another one) that's well-supported by the literature and generally agreed on, but still comes up as "needs citation" every time. I should go dig out the citation so I can avoid this when I bring it up ;)
Sure. Do this if you want to kill morale and be chronically understaffed (either not enough bodies or not enough qualified bodies) for the rest of your existence.
This type of mentality breeds mediocrity for a number of reasons, the main one being that A-players will run away from teams/companies structured around these heuristics. Furthermore, they will make sure all of their A-player friends are aware of this environment.
Good managers and good management teams have no issues with productivity of in-office or remote workers. If your team or company is actually having productivity issues (rather than using productivity as a precursor to a rif), then point that finger at the management and management culture.
Most of the software and libraries I use nowadays have existed a decade ago, and truth be told, weren't that much different.
Purposely over-hiring to prevent work being done elsewhere, and then claiming there is not enough work to be done, feels like it shouldn't be surprising to anyone.
Hell, Google has created ~18 (I think?) different messenger/chat apps at this point. If you wanted a clue that there wasn't enough work to go around (and that your promotion incentives may not be aligned with the business), this should have been the first clue.
Wow, I've suspected this for many years and people told me it was nutty.
Managers are happy when they get their hands on a new role to hire into because they all have more projects than they (think that they) can deliver at good quality with the people they have.
I've heard this claimed but not sourced, and it doesn't really make sense - there are millions of software engineers out there and Google or Meta only employ a tiny fraction of them.
100,000 of the best out of a pool of approximately 10 million professional software engineers worldwide is a sizeable portion. Additionally, not all 10 million are even close to being up to BigCorps peculiar standards (perhaps the standard is "someone competent enough that they could potentially build a competing product line").
Goog, Meta, Amazon, Apple, Oracle.. all have huge rosters and it adds up to a significant portion of the market. There is also a huge amount of medium sized whales such as SAP and PayPal who in total end up also consuming a lot of the talent.
That said, the interactions I've had with the people working on AWS have been uniformly positive. They're easy to work with and obviously very skilled engineers.
The recruiting reach is high because every single sub-group of teams within amazon has their own recruiters, and none of them communicate with recruiters from outside of that. Sometimes i get multiple emails from different AWS sub-group recruiters per day, but it isn't because AWS is desperate for me. It is simply because for them, the existence of the other ones reaching out at the same time is completely immaterial, just like if they were recruiters from other companies.
And while yes, Amazon's interviewing bar might not be as high as Meta/Google/Dropbox/etc, it isn't far behind at all, and it is pretty much on par with Microsoft.
Disclosure: never worked at Amazon, but interviewed with them and the rest of the companies mentioned, and worked at (or got offers from) some of them.
Most of those companies have less than 30k SWEs, not 100k - https://twitter.com/gergelyorosz/status/1527004655540133888?... (feel free to google the others)
So for each company they represent at most around (edit: 0.3%) of all professional devs, and presumably the "overhired for anti-competitive reasons" portion is a small fraction of that.
Just because someone "uses JavaScript" doesn't mean they are a full-time professional. In fact, most are dabblers. The number depends entirely on the definition - are all IT professionals considered software engineers? If so, that's about 24 million.
I am talking about full-time SWEs.
In any case Drew, it sounds like we're mostly in agreement. What a relief! :D
We can't really know what is in the minds of Zuckerfk and Pikaichu, in the end it's all speculation.
I'm glad you put it that way. It's not necessarily smarts or talent, but it does take a particular willingness for the institutional peculiarities to integrate with a big organization. I'm not one of those people, I tried it, and I will never do it again. I did note, you either had people who had just joined, or people who had been there for nearly a decade or more. I think of the word "institutionalized", as in, they had bought into the institution lifestyle, and were so full of it's arbitrary knowledge that moving on would be like starting over.
I don't think grinding leetcode for an interview is the best indicator of a good engineer, and graduating from a prestigious university is not always an indicator either. imho it seems like the best engineers now are the ones doing their own thing outside of the large companies, or are at smaller startups.
I bet NASA and NIST have a great bunch of quality all-round engineers, but I'd be surprised if they were better at leetcode than the average FAANG dev. After all, FAANG devs have literally been filtered through an "are they good at leetcode" process. FAANG may be full of money chasers, but if the way to get more money there is by "being a good engineer" that does not mean much.
For example I'd call a BMW a quality car. I wouldn't call a Lada a quality car, though it's much cheaper and has a much higher bang-to-buck ratio than a BMW.
In that sense sometimes government work has to be the highest quality, especially when it concerns security or safety. Sure it could end up being magnitudes more expensive but I'd say that's a question of efficiency not quality
Maybe there are some super great private projects but I expect those amazing capabilities would still be evident in the stuff that is put out.
Note, there’s some good stuff out of NIST and NASA (check out open.nasa.gov) but I don’t see things being handed off to Apache and stuff.
It’s hard to judge “great programmers” so I think the best is to proxy using whatever factors you have access to.
I guess it could also be books written and presentations given. Or contributions to other projects using nasa and nist addresses.
Point being, I don’t think there’s any evidence to think that nasa and nist have great progs.
Having said that, the national labs do seem like good places to go geek out in your own advanced intellectual cul-de-sac.
Seriously - why does this not mean they're the best engineers (as opposed to the most prolific).
Having said all that, I don't discount the possibility of work life balance in the 60-80 hour range, but that's a whole separate skillset.
Not firing folks, low pay, focus on the best work life balance in history, heavy affirmative action, politics, and having to work hard to carry the coasters isn’t an environment that naturally attracts skill and competence. Work 500% harder than the next guy and get the same promotion. No thanks.
The gov and contractors, like it or not, are jobs programs first and foremost. A remarkably effective jobs program if you just measure folks employed and not output.
Their employees are also the subset of those who can get to a location where they have offices and have the relevant work permits. Those who do not object to and specifically want to work at those companies. Those who find their technical challenges of interest. Those who do not already have a satisfactory job elsewhere and are actually in the market for a job.
It turns out that being able to solve cute little puzzles while interviewing doesn't really help with systems level thinking.
I think he might have backed himself into a corner by coming in as an 'advisor'. How can I be an advisor if I look like i don't even understand what is going. That must have been his mindset. So the only escape is being arrogant and belligerent.
Yes, but they are competing for the same tiny fraction.
I work for Amazon - for a decade. I love it - best job I've ever had. And historically, while it's been a tough place to work, we've always been able to attract top talent. Partially - impactful work. Partially - stock doubles every year.
Well guess what happened in 2020/2021? Despite incredible perseverance through the Pandemic, the stock stopped doubling.
Meanwhile, Microsoft, Meta, and others figured out that they can poach our engineers with a promise of way more base salary, and a less intense work environment.
We've had SDE1s (Juniors) leave Amazon for Meta because they got more money than our SDE3s (Seniors) were getting.
SDE2s (Intermediate) looked at their status quo thought "I COULD bust my ass and get promoted to Senior...or I could go to Microsoft TODAY, get a Senior offer for what I'm already doing, and for more money than my raise would be". (No offense to any of my friends at Microsoft, but https://www.levels.fyi/?compare=Amazon,Microsoft&track=Softw... doesn't lie)
I've talked to a few acquaintances that have left and the universal responses is: "My job is so boring now. I miss Amazon. But It's not stressful (because there is no pressure on me), and I get paid more money".
How can anyone think there is anything wrong with that? You can't. You can speak about Mission and Impact, and some engineers will be attracted to that - I work on building Forever APIs in the AWS Cloud that gets millions of transactions per second. That to me is WAY more interesting than working on Chat app 15/18.
But for most people they just want to make money and live their lives. Fair enough!
The result? Even though Amazon has adapted somewhat by bumping salaries, they've still lost an ocean of people to nothing particularly ambitious or interesting. They're being parked by Microsoft/Google/Facebook to work on boring unimpactful projects so they can't help Amazon kick their asses.
Sometimes one way to make your house nicer is by breaking the windows in the neighbor's house.
They put lipstick on a pig but everyone's getting ranked and the lowest performers getting weeded out.
The whole "People get fired even if they're doing a good job just by being a low performer on a strong team" is an edge case that happens INCREDIBLY rarely but when it does gets all the attention.
"My job is so boring now. I miss Amazon. But It's not stressful (because there is no pressure on me), and I get paid more money"
They get pulled away by the lure of money into an environment that causes them to stagnate in their skill and career development, then companies pull the rug after only a few years of this high pay with layoffs. Now you've got hoards of developers with junior/mid skills who expect senior salaries and can't find jobs. Amazon doesn't want them anymore, because the new grad pipeline has plenty of people nearly as technically capable and much hungrier.
Only those who manage to recognize this short term period of plenty and rapidly stack investments toward financial independence will be alright in the end. Those who thought the raining cash would never end are in for a world of hurt.
On the bright side for Amazon, they get to trim off the employees who a) aren't paranoid enough about the viciousness of the business world, and b) are looking for a way to cruise and do minimal work.
Microsoft is in an insane number of markets, far more than Amazon. While at Microsoft I did everything from compilers to robots to wearables, and if I talk to 10 Microsoft alumni they will have a job history of working on a completely disparate set of amazing technologies.
If you are bored at Microsoft change teams. You can find teams writing assembly, or C++, or C#, or Rust, or JavaScript, or Typescript. You can find teams working on browser engines, on ISO standards, or consumer tech.
Get bored with all of that, go work on video games for awhile.
I worked for a while at another company also known for being hyper-aggressive and a brutally difficult work environment -- probably the poster-child for that sort of thing, back then. I burned out hard after a couple years and ended up prioritizing "work-life balance" in my next job searches.
I landed at a 40-hour/week place where I usually work less than that. There's a strong appeal to working so little for a solidly decent salary. I have to remind myself often how good I have it, especially when others don't have jobs at all -- or they have to do back-breaking labor for table scraps.
But I agree it's also undeniably boring. I constantly find myself fantasizing about being back in the adrenaline-fueled environment of my last job. A large part of why I burned out was my own poor stress-management skills, and I like to imagine that I could probably perform well -- and excel -- in that sort of boiler-room environment now. (Especially if the comp could be what it was, too!)
On the other hand, I think all companies that have tried that aggressive approach have not made it sustainable. People burn out, or the whole company burns out, or both. It's tough to keep it going without lots of support and motivation (financial and otherwise).
The idealistic part of me likes to imagine it's theoretically possible to sustain such a thing, though -- a healthy, psychologically-safe place where people could work on ridiculously impactful things at a velocity and scale not available anywhere else. But it doesn't seem like anyone's cracked the code -- not my former employer, who faded away in a blaze of toxicity, and certainly not Amazon.
On the other hand, if no-one stops it, there are always incentives to grow your team as much as possible.
As leader this increases your status both in absolute terms (100 vs 10 people under you makes a difference on your CV and on the title you can claim) and in relative terms (your team is larger than the teams of your peers and you can get ahead that way).
And so every leader at every level tries to expand their team.
Where the hell did they think productivity would go?
My current employer is very lenient, and as a result I am very happy working here and put in more than I am required to. If they were very strict, I would work _exactly_ 9 to 5 and not a second longer - if I even wanted to work there at all.
Fact is, you simply can't be 100% effective 100% of the time. So you either end up with people _pretending_ to be busy, or people who are free to openly de-stress and are way happier employees.
There is definitely enough work to go around at Google, Amazon, and Apple.
Whether promotion makes any sense, and whether people are working on the things that actually move the needle is a different question.
It's widely known among the sort of person who tends to believe in conspiracy theories, I suppose. The oppressive bureaucracy and misaligned incentives that allow senior leaders to destructively compete among themselves is more than enough to explain why ill-conceived and ill-run projects are common at FAANG-level megacorporations without resorting to making things up.
Even if I admit yours sounds more likely (companies choosing to spend more of their own money vs managers choosing to waste the company's money)
The article doesn't mention a different problem. Those new hires entered at extremely inflated salary levels due to literally every other company doing the same thing at the same time. Righting that ship means not just layoffs, but recalibrating salary expectations. The process is just starting.
But it's just an acronym, it's not perfect. The other big error is that, obviously, Microsoft needs to be in that list given their pay scale and hiring process.
Yes, top reason an average enterprise developer has to deal with a distributed mess as opposed to a more manageable monolithic one: "we will do microservices despite being nothing like Netflix". On the upside, more developers are now required.
I've always felt that leaving Microsoft out was a bit problematic. But FAAMG does not sound very threatening.
Google can't get anything done for a very simple reason:
a) comps are way too high. why bother doing anything when gold rains from the sky every day of the year.
b) you're never going to make it to 50 Million at Google however hard you work, unless you make it to SVP, which is a 15 year endeavor. In other words, strictly no incentives to do amazing stuff when compared to a startup.
c) the environment is highly political, actual entrepreneur spirit is long gone and/or smothered by product type folks.
If what you're looking for in life is a civil servant type of highly paid cushy job, Google is the perfect place to be. If you want to innovate and change the world, flee this godforsaken place as soon as you can.
So yeah if MSFT can make 3 billion dollars with 1000 engineers, and Google makes 1 billion dollars with 1000 engineers, then 1 MSFT eng is worth 3 of Googles (simplified - obv business involves sales, marketing, etc)
The company with (let's say) identically-skilled employees putting in twice as many hours probably won't be the more profitable of the two.
Replace "mow lawns" with "write pointless, doomed-from-the-start messaging apps" and the actual problem starts to become clear.
FAANG employees make up a group of some of the most hire-able employees I can think of. If leadership makes work hard, they will quit.
(Baring H1B employees, they just get the shit stick all around, but that's not unique to this particular issue)
Tools don't solve people problems because at the scale of people problems everyone has a different philosophy about the tool (and the problem). Communication is what solves people problems.