Ask HN: Is all of FAANG like this?
The good: I get paid better than my last jobs. I can browse internal resources to satisfy my curiosity about how things work.
The bad: Basically no work gets done and there's no motivation to do any.
The dev tools, docs and tech debt impart such a slow iteration speed that even when I am working a full 8 hours, only a few very small changes get done, yet somehow this is even more than most of the rest of my team can muster during an entire week.
Because of this, I normally work about one day trickle out my changes during the the week. The other days I only open my computer for standup and if I get an IM. As far as I can tell, if I can be just barely the best on the team by doing there's nothing the company will offer me to work harder. If I get asked about why it takes long to make a simple change I can point to the environment and shrug my shoulders. Of course, it's possible the rest of the team is doing that too, but I have no way of knowing.
This amounts to a glacial development pace and when I look back at the progress made since I joined and estimate the cost to the company (salary, servers, etc) it's frankly disgusting. I don't feel what I'm doing is ethnically wrong, because the company is evidently pleased with my current productivity, but I find it unsatisfying and like a waste of my time on earth.
So my question is: Is all of FAANG like this? If the market value of such incompetence if FAANG salary, how can I do good work and get paid preportionally?
647 comments
[ 4.6 ms ] story [ 334 ms ] thread"Ask HN: I've been slacking off at Google for 6 years. How can I stop this?"
A lot of engineers at startups, like myself, want to work with talent that is skilled enough to get into FAANG bit too bored of the extremely glacial pace these companies work at.
On a more on topic note: I've heard about, and observed, similar behavior from friends of similar companies: doing very minimal work and being surprised at the massive rewards they get.
For example: Optimizing compile time (no need to invest for extra 1 minute speed up), working on high quality labelled data (i came from ML background, this is not possible in most of startups), analytics on data (questionable ethically), working on Ad platforms, working on large scale system.
In the last, Imagine, even making simple changes have bigger impact on real world.
1. a random person from the tech industry, and
2. a random person who has worked at a FAANG company for 1 year.
I'd assume that on average person 2 is no worse an engineer than, and potentially a better engineer better than, person 1.
I’ve interviewed and hired software engineers at small companies where we needed each software developer to be impactful. We needed someone with history of “getting things done”. We can’t tell that by your ability to do leetCode.
On a side note, an Amazon recruiter reached out to me about a software developer position on LinkedIn a few months ago. I knew I had no interest in going through an algorithm interview to prove I was “smart”.
I asked her could she put me in touch with someone from the AWS consulting side since I did have experience with “getting things done” from working for small companies in general and using many of the AWS fiddly bits specifically.
As I suspected, the entire loop was concerned with past projects and “tell me about a time when...”. I breezed through the interview without a single algorithm question even though I am actually doing some hands on the keyboard coding - implementations not sales.
Take a look at the work life of FAANG employees in their APAC and India offices.
You can do good work at any company, but FAANGs especially will reward you with compensation and opportunities if you stand out.
What degree of tenure do other people on the team have? If old-timers aren't on the team, or worse, if they leave the team for others within the company, they might be seeing writing on the wall that you can't. If this is the case, your future on this team, and likely with this company, might be in jeopardy when the reorganization comes.
Is the team just not important? Are you responsible for maintenance of some cost center that isn't worth high-level executives paying any attention to? If this is the case, your future might also be in jeopardy, but the reorganization might be multiple years away.
Are you just not listening to your manager? It's possible that you are going to be "blindsided" by a PIP due to the lack of output. This might happen if the actual output of your team isn't what you are thinking it is. Maybe the engineers who aren't outputting anything visible to you are actually outputting considerably to other parts of the organization. If this is the case, your future is in jeopardy and you'll find yourself out of the company within a year or so (yes, it actually does take a long time to fire people at FAANG companies).
It could be one of these or something else. Since you have so much extra time, it might behoove you to figure out exactly what the situation is on your team, so you can make the necessary preparations (to change teams, to get a new job before you're laid off or fired, to do whatever you think is best).
No one seems to train for this sort of career-self-management explicitly, and most engineering managers are actually not all that experienced or good at managing people. Many will try to make things more comfortable for themselves by being less confrontational and downplaying the negative things which will come back to hurt you later. As such, you should work to combat these anti-patterns, asking your manager on a regular basis questions like these:
- What are the company's objectives and goals for me if I am to remain in my current position? Am I meeting these objectives?
- How about if I want to advance in the company? Am I making progress on these objectives?
- Is there any feedback which I need to take into account which will affect my performance review?
- I have responded to earlier feedback; has my response been satisfactory?
Go over all of these regularly, especially the question of feedback (feedback is much more actionable if it's timely). When you're done, summarize to your manager what you heard, and your sentiment analysis of that. "It sounds like everything is on track for now without the need to make major changes, and I can expect a timely promotion; is this right?"
Take notes every time, noting the date. (They don't have to be long.) Keep the notes organized in one location.
100% agreed.
- Hey X, I brought you into today to talk to you about something I noticed. There is an issue/errors with your work, when doing Y[provide evidence of common errors/average errors of others], I just want to say you're not in trouble, but we want you to improve this area and wanted to make sure you were aware of it.
- I want to extend any resources I have available for you to improve in this area, and of course I have some ideas, I wrote everything down on this paper/email.
- You can come with a plan of your own. Or we can collaborate on it--if you're not sure why issues are happening. Take some time and think about it, and when you're ready to talk about how we might ago about improving in this area, please schedule some time with me and we can work on this together.
It's not about berating anyone. It's about constant subtle modifications. They compare it to driving a car. Even if you're on a completely straight road, you can't just keep your hands off the wheel and expect the car to continue going straight. You provide regular nudges to keep the car on the road.
Maybe this analogy doesn't hold up that well anymore with auto-correcting cars :)
I think your concern about not providing stronger feedback is valid. Highly recommend the series of podcasts they have around this topic. You'll think about feedback in a much different fashion.
Stick to facts. Clearly state your expectation, and show how they are not meeting that expectation. Then place the ball firmly in their court. The goal is not fixing the issue for them, but getting them to take responsibility for fixing it themselves.
Refrain from creating a "shit sandwich" by putting the critique in the middle of praise. That makes the conversation ineffective. These conversations are never fun, but they are important to have, and you eventually get used to it.
FAANG companies like to manage people without giving negative feedback. This can be very confusing if you are used to explicit feedback and come from a more direct culture. "Listening to your manager" can be difficult if you are not used to decoding the issues.
Coasting is often possible. But this is not a good strategy - you are throwing away a huge opportunity to excel, grow and take on more challenges and scale. If you are not having a great time with growth on your current team, it's not advantageous to do the minimum. Instead, look for more exciting projects!
Why do FAANG companies allow coasting? It means people can feel safe, find passions and ideally excel and uncover huge value in these growing industries. Rather than a visible stick, there are (invisible) carrots. Take advantage of these!
As noted, eventually, lack of progression will count against you. You will be overlooked when big chances come up and fail to build relationships that will aid you in your career. It's hard to hire people who find these tasks easy - showing your capabilities will open doors.
I've heard rumors but wow
All the issues you describe are opportunities to have huge impact on a global scale if you decide to solve any of them. But if you truly are disgusted by the state your company then that's not your path. I think you would likely thrive if you set your own path and work in an environment you built. You might need to quit once your creation becomes too successful though to avoid this problem again.
I liked working on parts of search quality for example (or any data mining project), where most of the time (and the way to promotion) is spent on research, not software development. It means that 90% of the code we write don't have to be committed (code reviewed, tested, documented, going through the approval process), just the code that goes to production. The smartest colleague of mine spent a lot of time figuring out the root cause of data/search quality issues, and made the smallest possible change in the system to get his change through. It's an art in itself, and can make a lot of impact and lots of money to the company as well.
I don't think there is anyway way to stop this cycle, I've seen it play out too many times. The only way to sort of delay it is to ensure the C-levels are lined with at least one technical ex-SE type that'll call out BS when they see it.
Not all startups are like this, but yeah few good growing startups.
A lot of companies are not doing that, and in many cases developer hiring and team management is more driven by things like internal company politics, or the desire to use a hiring budget by the end of the year for example.
Also it is sometimes the case that an organization's software development needs are not persistent. Sometimes there are weeks or even months where the bottleneck of the company is far from software development, and until those problems are figured out there's little for the developers to do, but they're on a salary so they have to come in and do their hours anyway. That can be awkward to talk about when those developers are being paid up to a half a million dollars per year.
Back then there was severe priority inversion, anything the desktop needed got delayed by iOS priorities but also the senior engineers with magic rubber stamp powers were working on iOS. So changes for the desktop stack never got approved without significant and needless delays.
It's going to be hard to reverse a trend away from Apple if it starts. Imagine what would happen if Microsoft Visual Studio becomes the IDE of choice for iOS development after devs ditch macOS in droves. Microsoft won't play nice.
Apple isn't watching their flanks by letting macOS atrophy and a competitor will step in if they don't cover it.
There are very few apps that could be web only apps that are making money via in app purchases. Most of the money being made in the App Store are pay to win games. Most of the subscriptions apps that use to allow in app purchases are already forcing users to pay outside of the App Store - including Netflix and Spotify.
Sounds like the Change tool chain is way, WAY more efficient than my "20k+ employees corp but not FAANG" general career experience... Most places I've worked for (mostly mining/engineering) have a change process that takes 2-3 weeks to get something HURRIED through a change process.
Maybe a non-technical role would suit you more. Try asking for "team admin" responsibilities as a route towards team management.
Damn that was bad. Lots of positives in how that huge company handle tech but speed was not one.
Since then I have only worked for startups. Everything is not rosy but we execute very quickly.
On the positive side, it was mostly relaxed, I could think about side projects and actually work on them after work, even though I "worked" more hours than the job after that. I think that's what kept me sane, but it was very refreshing to switch to a small company after that where you could get things done and generally mostly dealt with motivated folks you can get along with.
Worst story so far was from a high school friend who joined a 600k employees monstrosity. Getting almost nothing done because every fart needs to be approved but in addition a very toxic environment with lots of unnecessary conflict and dickery between different teams whenever they had to cooperate on something. Now it's a huge company and probably not all of it is like that, but boy I don't understand how he's still there and not completely dead inside or became an actual psychopath.
If I were you I’d consider an internal transfer. Try to find out which teams are doing the really interesting work.
The age also plays a factor, fb teams are much younger, people have much more energy.
I've been reading/contemplating Willinck/Babin's book Extreme Ownership of late -- I think you might find some resonance there.
Maybe you just had bad luck with your team allocation.
That said, if it's the same in all other teams, I'd totally quit as well; not having a sense of progress is devastating in the long term. (And made me quit science, btw).
I doubt proprietary tech is going to fade completely, but it's true that maybe there are forces that are pushing for big companies to make more and more projects open source. If you think about it it makes sense: the employees are happier because their work has more impact, they also benefit because they can showcase it in their CV. For the company they externalize testing, quality improves because employees are going to be more careful when their code is in the open and they are more motivated. It can also make hiring easier.
This idea will never become a reality for the vast majority of companies, for the exact same reason that companies fear piracy. If I open source my product then anyone who uses that open source code is a lost sale. A lost sale means I make less money, less money means the board is mad, on and on and on...
The bottom line is money, and open sourcing their code means (to them) a loss in potential revenue.
I predict the open source bits will be bait. With many 90% solutions. The proprietary bits will be the ones you need to make it work like a real program. Oh there will still be soup to nuts full on free stacks. But I seeing more and more of this service fee way.
As for making hiring easier? Not so much. When you can get 100+ applicants for 1 position. The reality is at least 99 of those have to go away. One more filter does not do much other than let you round bin things faster say 'cant find anyone' then grab your favorite contracting firm and hire them anyway.
But I went from needing technical support from elastic 4-5 times a year, to zero and found work arounds for the other limitations, like cognito for authorization and storing less data in the cluster. The end result was a six-figure savings on licensing and less weekend work for me at the cost of a five-figure increase in AWS costs.
I'd say it was worth it.
This was Bezos' reasoning for making as much of their internal software available to the public via AWS, a) now it's required to be documented, b) it's now subject to competition, you know it's not the best if no one's using it.
https://www.networkworld.com/article/2891297/the-myth-about-...
GP was talking how this improves reward structure, not about AWS
[1] https://medium.com/slingr/what-year-did-bezos-issue-the-api-...
This was Bezos' reasoning for making as much of their internal software available to the public via AWS
Those APIs had nothing to do with AWS. So how was the original poster not talking about AWS when they mentioned AWS?
Also a clean public interface says nothing about how badly written and documented the underlying code is.
The mandate was in 2001. AWS first launched in 2006. From reading the letter, it wasn’t about being able to make services productizable. It was more so teams could work independently and choose whichever underlying technology they wanted. It also prevents the issue the original poster was having. It’s much easier to make changes to a small API than a monolith.
It takes a lot to go from internal API to product even on a small scale. Werner Vogels said at the last Reinvent that S3 is made you of hundred or more separate internal services exposed internally via an API. My last company we also had a mandate to be “API first”. Not because we were trying to be like Amazon with less than 75 people, but we actually sold access to our APIs to our customers - large business that used them as the backend for their websites and mobile apps. We also used the APIs internally for our websites and large ETL jobs where sour clients would send us files for bulk changes.