This career feels like a few key hours with year-long cool-down periods
reddit.com
reddit.com
Yeah, life isn't fair, let alone performance reviews. No matter who you are, someone else has it easier, like the trust fund kid you see driving past in the Tesla, but do you think he's happy?
We all have to eat, so by all means take the next job that will pay you more. But when you're at that job, whatever you are working on, take pride in it! Always do the best you can, even if you hate your boss. This is not for the benefit of the company, it's for your own mental health and integrity. Over time this builds your skills and competence, which opens more doors. Petulantly slacking off because you weren't sufficiently recognized hurts no one but yourself; the universe does not care.
You can love your job and hop out sometimes. But petulantly slacking off like OP says, is not going to make you happy.
Op is not saying he’s slacking off. He’s saying it doesn’t matter what he does.
Regarding promotion and being indispensable, that cuts both ways - in some roles being impossible to replace also means you are impossible to promote, since the next step up the rigidly defined corporate ladder may not have sufficient overlap with your current role.
Sure about this? This isn't even possible everywhere - doing the next job, for example, isn't generally possible for lower wage jobs. How the heck are you going to train for a shift manager position by learning the job when you literally don't have the authority access to do it?
You don't.
Terrified that you leave? Try that in a call center. You, no matter how good you are, will be easily replaced with another warm body or two and folks quit these jobs all the time.
Are you sure petulantly slacking off won't make one happy? I mean, what if you get joy out of seeing how far you can push that button - or alternatively, don't get satisfaction from a 'job well done' like you are told that you should? Or maybe you only do well for some recognition that you aren't getting... or maybe jobs don't give you satisfaction at all. They merely give you the means to do stuff that does make you happy.
That said, even in software, you don't always 'have the authority' to do that other job. But does that matter?
Example: you're the junior, new to the team. When the team does backlog maintenance, everyone just slaps some estimate onto the barely defined ticket and calls it a day. Sprints slip all the time because tickets "explode" once you actually start working on them. The team lead does nothing about it, the PO couldn't care less, he just screams at everyone when none of the tickets are done at the end of the sprint.
The junior could just resign himself and play along. Or he can start asking "dumb questions" during backlog maintenance. I.e. start a proper discussion. Suggest tickets to be split etc. The bad team lead and PO might ignore this and even actively try to get back to just slapping on estimates, not actually do the splitting or say "yeah I'll do the splitting by the time we do sprint planning" and then obviously nothing ever happens.
Do it yourself! Offer helping out, to give them a chance to be part of it. They might refuse or try to "pull rank". Ignore them. Split the tickets. If you can't do it before a sprint starts (e.g. cause they'll notice and try to pull rank), split them after you've started on one of those bad tickets. Split it into 3 nicely sized ones and at the end of the sprint you can show that hey, ticket 1 is finished, ticket 2 is almost done and ticket 3 isn't even started yet. We can release the functionality of ticket 1 to customers even!
You've just done all of the following:
Shown that you're not the junior you've been hired as but much more!
Ignored the team lead's authority when it became clear that even when shown the proper way, he's not going to act
Ignored the PO's authority when it became clear that even when shown the proper way, he's not going to act
Let's take this to the call center:Folks quit these all the time, like you said. Even the shift leaders or managers. I don't know enough about call center operations to know what the equivalent tasks of the little story above are but I do know from experience w/ some of our guys that it's totally possible there as well. We had a really great QA that came in through the call center. Started as a regular rep, became a shift lead, moved into QA and then became a BA. He was awesome at that. Knew everything by heart or was able to quickly try it out in-product. Heck the department lead came in through the call center as well. Similar trajectory but didn't move over to the software side and stayed on the business side.
I would argue that tying your self-worth too closely to your career can be even more corrosive. Sometimes doing the bare minimum and saving your mental, emotional, and physical energy for your life outside your work is even more rewarding.
I say this as someone who has spent time at both ends of the spectrum. I have had stretches in which my career is my only focus and times in which I honestly put in maybe half a day's worth of real effort in an average week. Which is better all depends on the specifics of your life, your job, and your personal motivations at the moment. And it is probably worth noting that my career didn't progressive any faster during those workaholic periods compared to my slacker periods. However those slacker periods were clearly better for my life outside of work.
I worked a lot on my studies, mostly in studying faster and a fair bit in obtaining high grades and studying wide/broad and studying deep (I studied for 8 years). Some things I have done were claimed to be impossible feats. I have taught others how to do it, how to think about learning, even one article was written about me.
But the resulting job search was so brutal that I flipped to the other end. For 18 months, I couldn’t find a job and I applied to a very broad bunch of positions and companies taking 4 hours on average to write a motivation letter and tailor my cv. The result? No response. No company cared what skills I have gained during my studies. They see courses like hardware security as non-practical and a course on multithreading as mostly theoretical. They couldn’t care less that a part of what I learned there are transferable skills.
When I learned that hard work isn’t proportional to career advancement, that’s where I decided to do whatever I feel like. I have too little control over it anyway.
This is a European perspective. I doubt that things would’ve gone this badly if I was American. My way of thinking seems to fit better there (though I could be wrong).
I wouldn't take that personally, or even as a strong indication of a problem with your hard skills.
Sometimes recruiters mainly look for real-world experience because that makes a hiring a candidate easier to justify. People without work experience or a portfolio are a crapshoot. Also, resume embellishment is indeed a common problem, thus great but unverifiable CVs might raise a red flag. Furthermore, if a company is looking for someone to tighten nuts but they get a CV from a highly trained engineer, they might prefer to pass on him. After all, if he's being underemployed then he might not be planning on sticking around for long.
And finally, but not less importantly, soft skills matter. Sometimes they matter far more than hard skills. A recruiter can tolerate a competent candidate that is eager to learn, but they will be less inclined to tolerate an outstanding developer who is unbearable, insufferable, or unwilling to learn from (and work with) team members.
In the end it's all a crapshoot anyway. There is a lot of confirmation bias, and a lot of lottery winners offering advise on how to win lotteries, but we would do well to acknowledge that the stars need to be aligned for good things to happen, and often they aren't.
Additionally, they will have you stuck doing mostly low-tier work spawning from bad decisions in the past instead of biting the bullet and having someone fix the foundation, and often perceive fixing that foundation as a skill only seniors / architects possess. I've met my fair share of seniors who believe design patterns are some of the highest order knowledge, despite having to learn them during my bachelor over a longer span of time than they get taught in-house, let alone having to actually use them.
NB: this is not a jab towards seniority. But I do believe most corporates do not value educated juniors correctly, often equating them to uneducated juniors, as well as underestimating what makes a senior a senior. Basic CS fundamentals shouldn't be a skill exclusive to seniors.
Yeah, no.
Usually these people come in two flavors: Those actually smart and developing an understanding for what it means to sell software and have customers with demands, and those who live in their little bubble where they're the most awesome person on the planet, and everybody else is just retarded. Halting all development for a year and refactoring everything according to what they think would be way superior after spending 5 minutes with the codebase is obviously a sane thing to demand.
And I usually try to let them fall into this trap in a controlled manner, like when it's a relatively unimportant component/feature, or just one customer where I can more or less directly relay the expected complaints to the junior dev. Usually playing the "this guy is responsible for your paycheck" card makes something click after a while.
Sure, but this only paints one extreme. It's fair to expect adults to realize money has to come from somewhere, and halting any development and even bugfixes won't keep customers. On the other extreme, we have sales and management pushing insane demands, which get tacked onto already poor code, degrading further, causing bugs in the future, increasing the risk factor, on top of already taking more than 5x as long as it reasonably should with no difference in features whatsoever. Which further escalates into high turnover rates, worse code quality, dissatisfied employees, no seniority willing to come in unless they get paid big time, and more. It's a fine line no matter how you slice it. Both extremes can run a company into giant losses or even bankruptcy.
Additionally, demands on juniors to prove a business case are often far higher than their seniors or managers, despite giving juniors less resources to do so. With such a simple mechanism in place, it is fair to assume the juniors who do go through the trouble of speaking up care about the quality of the product and their responsibility in the matter. Likewise, I've seen plenty of seniors fall into the same trap you described, either halting all progress or spending (read: wasting) months developing a strategy out of analysis paralysis only to not even have a business case. If anything, they tend to be able to do this even easier, since they are met with much less resistance thanks to their reputation and/or authority.
You are wrong, unfortunately. There's a reason for the saying: "The A students work for the B students, the C students run the business, and the D students get the buildings named after them."
A less cynical take is that in school, marketing skills (e.g. self-promotion and self-inflating) are irrelevant. In industry, they are at least on par with technical skills, and in most roles I've encountered, even more important. Look at the people you know who were fired (directly or made miserable enough to leave voluntarily): People are more likely to get fired for not understanding and exploiting social dynamics than for being poor in the technical arena.
Also, in school, they care about objective evaluation, and usually your performance is not dependent on others. At work, your work is heavily dependent on others, and almost no one tries to objectively evaluate your work (unless you're in sales or something).
> objectively evaluate your work
I suppose if you're talking about code quality et. al, yes, but you definitely do get evaluated on its impact on the business. If you are part of a successful product launch and you engineered major features (even if other people could've written those features) you get rewarded.
> I suppose if you're talking about code quality et. al, yes, but you definitely do get evaluated on its impact on the business. If you are part of a successful product launch and you engineered major features (even if other people could've written those features) you get rewarded.
A few remarks:
If you do something fairly major, then probably yes.
If you do something fairly major, there will often be people around you who will attempt (and often succeed) to take a fair amount of that credit without having contributed much. So yes, you get rewarded, but so will others who shouldn't. This is very common where I've worked. I think it's generally the case in large companies.
We should not focus on major product launches where you did major work. Say there is an existing product and most of the work is bug fixing and adding features. This category is where most of the work in industry is, and is where my comment mostly applies. This is also the category where innovation is highly touted but rarely rewarded. I've certainly been in jobs where innovation is needed, but the one who steps up to solve those problems is often the one who gets poor reviews, because everyone in the team becomes more productive because of him, and the manager sees less output from him because he spent a big chunk of his time solving infrastructure issues.
When I speak of objectively measuring performance, people often compare how it's done between jobs. This is not the point. Compare with how it's done when you were a student. In most technical courses, it's highly unlikely that someone who barely understands the material gets an A grade while simultaneously the one who understood the material well gets a B or a C. In industry, this scenario is quite common.
With that horrible plastic interior? I doubt it.
The guy in a mclaren or a rolls royce? Probably.
Are you so much a slave that you have to search for meaning in the nobility of work? Work does not offer us purpose because there is no purpose in the operation of institutions in the modern world. Where the driving philosophical principle of an enterprise is "make as much money as possible", who among us can wring out a meaning that satisfies us spiritually?
Where even our charities are corrupted by the guiding principle of more money more good - from where is the conscious worker to draw their meaning?
We exist in an age of spiritual and moral vacuum and there is no guiding principle at this time that a non idiot can align themselves with while retaining some semblance of internal consistency.
How is Elon Musk working magic? A big part of it, apart from not being just another idiot with an MBA, is that he is giving people an actual purpose they can get behind. A purpose that is not just something slung over a money making machine in a vague attempt to align the workers. No, a real bottom up purpose that drives the enterprise. With that kind of purpose a team can move a mountain.
You have to ask yourself... If you are not trying to save the world from cooking itself, or trying to end poverty or trying to cure cancer, or trying to ensure the existence of humanity into the far future, what the bleep are you working for? Answer: You're working for the thoughtless vacuous industrial machine that is devouring both our souls and our physical world.
You should be depressed because this sh* is depressing. You should be angry because this sh* should make you angry. These emotions are deep intuitive reactions, they are drivers for change, hear them and move to change the way you work.
The additional counterbalancing layer on top of this is an internal drive for justice - this is what pushes me to work for a big tech company rather than doing something which gives me more self-respect. If other people can earn 6+ figures to fuck about with computers all day and deliver nothing of true societal value, why should I be the sucker doing scientific research for a fraction of that?
Some people consider life to be a party, hence they are working to "get more beers" and to "wire up the amps" that the band will use to play.
In other words they spend time in working mode today in order to spend future time in leisure mode. And in their mind the future leisure mode is somewhat "better" or "more abundant" than the leisure they could have if they retired today.
Not saying they are right or wrong, but most people don't have the need to become the undisputed savior of the world.
I think getting emotional and screaming at them because they are focused on things that the intelligencia perceives as mundane is not the right way to encourage a healthy exchange of opinions between the aforementioned intelligencia and the general population
This sounds like accepting and denying more than anything. I would wish anyone a job they are actually valued in, a job they like.
For some context: That subreddit is historically very cynical. It's more of a support group and a place to vent than an actual advice forum. A lot of people arrive on /r/cscareerquestions thinking that the only way to succeed is to spend all of your spare time doing side projects and grinding leetcode while pursuing FAANG jobs.
I would sometimes try to answer questions there in between long builds but it became very demoralizing. Many of the regulars there are struggling with their careers or disgruntled with their jobs and they extrapolate to the entire tech industry.
There were occasionally people putting in good comments in the sub, but it tends to get drowned out by cynical complaints. You know how internet relationship advice forums devolve into everyone telling the OP to break up or get divorced? That sub felt like the CS equivalent of a relationship forum: The advice is always to blame your employer or the industry and quit your job, ignoring any nuance in the situation.
Exploit the corporation. Give them exactly what they pay you for an not an ounce more. Stay within the bounds of the law and your personal ethics, but extract from the Corporation just as the Corporation extracts from everything else.
Don't tie your identity or self-worth to your contractual obligations to the Corporation. Use the money you extract from the Corporation to enjoy life and the things that do define you and give you your sense of self-worth.
The universe does not care if you're good at your job or not. You've only got so many years until you're dead and gone, spend as little of it as possible working and as much of it doing the things as you enjoy. If working is what you enjoy, good for you, but it's not everyone's cup of tea.
I'm in the "not an ounce more" camp, but I also don't expect a cent more than I'm owed in return. Those who do push themselves further for the benefit of humanity deserve more than I do.
There are not enough upvotes in the world for the parent post, but please add yours.
Also unlike a lot of the other tech companies, the salaries of the engineers aren't their biggest cost -- content is. So they don't take as big a hit on their stock price or profitability when their engineering costs go up because they are dwarfed by content costs.
And lastly because they believe that overpaying for talent makes sense in the long run because then a lot of the best talent wants to work there, so they can get paid a lot and be surrounded by other people who like a culture where poor performance is rewarded with a big severance.
I won't lie, the culture isn't for everyone. I personally enjoyed the pressure of having to constantly perform, I felt it made me do better work, but not everyone is like that.
I made a big miscalculation with Disney+ because when I heard stories of many good engineers leaving BAMTech in the initial rollout I thought these guys are clowns run by non-tech savvy executives. But I was proven wrong when they didn't crash and burn. Since then other companies that seem like legacy firms that don't know anything about tech are also rolling out services and they are more or less working.
Just a theory: Maybe enough top tier people won't want to do this work at any price as they will be wasting valuable time not innovating on the cutting edge.
At Netflix I felt the goal was to get the right people working on the right problems, and the rest would work itself out.
I never detected a sense of “fungibility” of engineers at Netflix the way I have at previous gigs. Job reqs weren’t job reqs, they were definitions of problem spaces and each team owned their own interview pipeline. Each team defined their own job postings, cultivated their own talent pipelines, and conducted their own interviews. At least from my experience, you don’t interview for Netflix. You interview for a specific team at Netflix. I’ve met at least one NFLX engineer that interviewed for a half dozen teams before getting to “yes.”
But I think that has to do with the fact that we only hired senior engineers. At the other BigCos, they are hiring junior engineers right out of school who aren't specialized yet, so for all intents and purposes, they are fungible.
Even the BigCos hire for specific roles at the higher levels.
Other companies don't want to be so aggressive, so they take a similar but related tack; give you a lot more money for promos if you perform, and hope you just leave of your own volition if you don't hit those marks and get those raises.
https://www.levels.fyi/?compare=Netflix,Google,Facebook&trac...
The pay raise between levels at Google or Facebook is about 20-30%
First, this works in your early career where growth and learning are very fast, but at some level of seniority this strategy wont work as well.
Second, I disagree that "what you do in between barely matters". Is like an athlete winning a medal and saying that those years of training were useless. That time is where you learn, grow, and get prepared for the next jump. If that's not the case, you are setting yourself up for failure.
Third, the market is red-hot right now. It says more about the market than your personal abilities. It might not be always be like this.
Fourth, companies are terrible at retaining talent, and sadly job hopping is often the easiest way to get a raise and a promotion. That's the point you got completely right.
Of course, interviews are meant to test candidates on their career development and growth as well, but in reality, it is uncertain whether they do, especially if they are focused on LeetCode/theory questions.
Interviewed with a different group for the role I wanted and got it with a few hours of interviews. It was absolutely not the case that I learned anything relevant from my experience trying to switch roles on my current team. It absolutely was the case that the 3-4 hours of interviewing (plus luck of the draw on my interviewers and their questions) meant way more to my career than months of planning and effort.
Also the best time to make friends and/or build your network. Let people remember you (in a positive way).
I wonder though if it's about hiring or about raises. Maybe it's the well paying companies that hire people who already get paid a relative lot and for the current employer that raise would be out of budget.
I don't think this comparison works at all. An athlete is attuning both their body and mind for years for an increase in the exact same activity. An employee is largely waiting for their time to shine hitting a challenging breakpoint, and practicing repetition of that challenge will have diminishing returns kick in very, very quickly. At the same time, the payoff for going beyond that diminishing returns is highly arguable.
As an example, in most companies, the far majority of employees will spend months doing ridiculously similar, low scope issues. These low scope issues frequently have very, very little to do with what is expected in the next tier. Changing a few variables every day has much less in common with making a basic tool after analyzing requirements. Comparatively, a runner practicing for years is directly practicing to run faster, it's the same toolset more carefully honed.
The far majority of us are waiting for those challenges to come up while doing those low scope, low pay-off issues. The common advice is to "seek those challenges yourself" or to "do the low stuff faster so you can get more challenging things quicker" is cute, but doesn't nearly apply in practice as often as the frequency of this advice makes one think. Think of bureaucracy, managers getting in the way, petty office politics, bottlenecks, and more. Which only leaves practicing in one's own time.
From the way I read it, OP is saying that there's far more of a difference between what one learns during those small challenging periods of time than the downtime of repetition compared to other fields. Which shouldn't be a surprise as software dev is largely a field of practicing mental challenges and logic puzzles, not honing physical skills.
While maybe not necessary to use Pandas or an ARG parse framework, or even Redis caching, I found by adding little things like these to smaller projects I was able to maintain interest and motivation. While counterintuitive, I also usually delivered a better product even though a tool I wanted to learn was a bit shoehorned in.
Now I'm about four years in, competent and confident. 100% worth it.
Take a look at startups with strong engineers they got from FAANGs. I'm willing to bet in most cases, those people jumped because they were sick of being denied promotion.
Take a look at the number of engineers on your team who have been contributing for years and are still stuck at junior engineer level. The next candidate who "seems strong" will get slotted in higher.
The situation is even dumber when you consider the costs incurred by on-boarding new employees and the knowledge lost when employees leave.
Source: I was involved in comp decision meetings in previous jobs. They don't say it explicitly but the expected rates lead the discussion. Blame investors and boards whose goals are never past a year or two. This is the same in startups and in large companies.
Honest, curious question- What exactly is it that's wrong about that? Doesn't that exactly reflect the point that "they are still competing with the market to retain their existing employees"?
So the corporation knows that 99% of the employees showed up for work the day after their $10K paycheck, and the replacement for the guy who quit won't show up for less than $11K. Well, if they give no one a raise next payroll will cost 99 x 10 + 11 = $1001K, and if they give everyone a pay raise then no one will quit but payroll will cost 100 x 11 = $1100K. That's an extra $99K and that's gonna cost some HR exec her bonus.
So you can guess what strategy they pursue.
Companies also have a political/cultural/religious view that individual contributors are instantly interchangeable cogs and they have MASSIVE cognitive dissonance if you point out thats not true and the recruitment and onboarding process are staggeringly expensive, so everyone job hopping all the time would cost like 25% the total labor budget so you're paying (in the example above) $1001K but who cares whats outgoing, you're only getting at most $750K of work out of them when they're hopping vs you'd get $1100K of work out of them if they didn't hop. And you're financially in the long run far better off paying $1100K for $1100K worth of work output than paying $1001K for $750K of actual work output. But like I said that goes against their political/cultural/religious views so they'll slap hands over their ears and chant "nah nah nah" when you point it out.
You get more of what you measure, and cutting productivity by a hard to measure 25% is worth it in a corporate Dilbert sense, if it saves an easy to measure $99K.
Tech companies known damn well which employees they should retain and which ones they are happy to have leave.
It's a problem for the FANGs to fix. Leave, get hired for a role that pays better/has a better environment, and don't look back. There will always be another tech company to work for.
I've found the opposite. Nothing will make an engineer resign faster than promoting them to tech lead.
I agree though I got a 40% raise jumping to a new job, I'm still below $100K but it's something for me in the midwest.
I don't aim to stay in it professionally for a long time though, will save/invest and get out. Do it on my own time for fun/to build things.
Edited: took out random crap about me not relevant
Email in profile
I checked out your sites, pretty cool what you do.
Yeah, imagine what kind of nerd would be interested in the field and genuinely want to learn all they can, ha ha.
I do have random interests though and write code outside of work in other topics.
I guess specifically I don't know much about algorithms/big-o stuff like that (working on it, trying to change fields where I can use that).
I do acknowledge being weak in math, I'm concerned if I can actually do ML.
I'm a glue-er is the term, crud apps. The OT talked about leetcode/that's something I hear people grind while also applying to "hundreds" of jobs.
That is why I find Leetcode dull. I can't really do much with it as if I needed it, I would pull it from a library.
Yeah, this comment grinds my gears.
So much "knowledge" in the software world (and parts of academia, and probably many other parts of society) is completely arbitrary bullshit that gets perpetuated because people who are familiar with it want to maintain their position of authority.
Actively taking pride in this is not inherently a good thing.
I'm sure someone knows. I'm also sure that I don't care: why didn't they use the standard library function for it?
Whereupon a huge proportion of early bugs were programmers who believed they were easily smart enough to write doubly linked list handling methods proceeded to ongoingly and continually screw up writing doubly linked list handling methods while refusing to use standard functions.
This isn't hypothetical.
Also the article you linked doesn't argue that you shouldn't know how to write a linked list, it argues that you should implement ADT operations in functions instead of trying to wing it with ad-hoc logic all over the place. Blizzard's developers were definitely smart enough implement a doubly-linked list one time, they were just fallible humans who got tripped up consistently implementing the same logic in a hundred different places.
So many "nerdy" circles seem to be plagued by this subculture where your competence or intelligence is measured by how much obscure and useless knowledge you can accrue.
The fact that Max's experience creating and maintaining the single best package manager on macOS (by a country mile, too) was considered less important than whether or not he knew the minutiae of a particular form of logic puzzle is bullshit, and I can completely synpathise him in that regard.
But that is not this. In the case of inverting a binary tree, what you call logic-puzzle minutiae is just taking a fundamental building block in computer science (binary trees) and asking the person to demonstrate even the faintest ability when it comes to writing an incredibly basic algorithm. Max Howell not only can't do it, but he doesn't even see why he should need to know how to do it!
That kind of proud ignorance is what grinds my gears. I'm sure someone can gather requirements and deliver value to customers and fix bugs and string together code and everything without knowing how to work with trees, but I don't really care. If they've somehow gotten that far without even a glimmer of curiosity about the fundamentals of computer science then something is disturbingly wrong, and I would worry about what other mammoth blind spots they inexplicably have.
If you went through a CS path then I would say you should know about it. I'm trying to pick it up due to FOMO. I hear about it.
I do get where you're coming from there, but I interpreted the Tweet very differently. He wasn't just asked "how does a binary tree work?", but asked to go through an extremely specific process manually, on a whiteboard.
And if I can just interject my one little quip (I come from a EEE background, stumbled into software engineering and then left after a couple of years to do my own thing), all of this knowledge of the academic aspects of CompSci doesn't seem to help people build code that is reliable and performant. We weren't taught it in EEE (we learned about programming and digital logic, but in a different, much more concrete way), and yet EEE-written code runs flawlessly on 8-bit micros in safety-critical systems for decades at a time without a single crash or missed timing constraint.
The thing is that most programmers are not computer scientists anymore, in the same way that most computer scientists are not mathematicians anymore. In many CS101 courses there's only a very brief study of algorithms and data structures and most of the course is about using this or that language (probably python, these days, java back in the day, Ada further back etc).
This is partly the fault of universities, in a "the road to hell is paved with good intentions" kind of way. Universities try to prepare their students for the industry, except they seem to be in lockstep with the industry's requirements, but with a ten-year gap. So they try to teach students programming, rather than computer science, because they believe that's what the industry is asking for, then the students go to interviews and find themselves staring at a binary tree on a whiteboard.
Also, to be fair, the majority of programmers nowadays are not nerds, anymore, and they're not even that interested in computers, or even progamming. Most of my class in my degree and in my Master's just wanted a cozy job at an office. In one company where I was hired through a graduate programme, all of the guys in my cohort came in with a qualification in CS, then immediately sought the better-paying manager jobs in the corp (and I left to go to academia because [edit:] they didn't let me train neural nets on their mainframes :P).
I usually don't need complex algorithms in my line of work, but I can't count how many times I've needed to implement topological sorts, for instance, or non-trivial tree traversals, or to rewrite code to increase parallelism, or to be able to quickly spot that a poorly performing algorithm was O(n^2) or O(n^3).
And sometimes, it actually gets complicated. Sometimes, it's about increasing cache hits. Sometimes, it's about making sure that stuff gets allocated in the right order or in the right place in memory. Sometimes, it's about rewriting the IPC layer. Sometimes, it's about reimplementing foreign key logics in a low-level database/file system. Sometimes, it's about writing custom locking data structures or non-blocking algorithms, or a custom memory allocator or GC to match specific performance requirements. Sometimes, you need to do all of this without a debugger or a profiler or even logging.
If you can't handle the simple tasks from the first list, well, how are you going to tackle the issues from the second?
And if you're not curious, how are you going to learn all of this?
Personally I wouldn't start writing a single line without doing some research first. I'd look around on the web for some sample implementations or at least pseudocode. I'd probably get one of my algorithm books down from the shelf to make sure I understand the basics -- and check for "gotcha" edge cases.
So this is still wildly different than Max's interview environment, where the expectation is that you can effectively invent the algorithm.
Also do most software problems involve optimizations at scale like at Netflix or Google ? It seems mismatched to assume that an esoteric use case is the gold standard.
I'm sure that not all companies need this kind of skill. But I'm not surprised if Google feels that they do.
However, I have needed to do most of the above. Usually as part of a team, thankfully. Happy to learn that you didn't. YMMV.
I'd guess that Google wants to hire engineers who can do that, too.
The point of interviewing about algos or ACID or SOLID is fast inter-team communication and less wasted effort.
So you have two sysadmins talking about some database's filesystem options and they talk about sync-writes vs non-sync writes and they immediately see a problem they need to research WRT ACID's "D" and sync writes and there are of course many solutions historically and workarounds and on the whiteboard they just look at each other and say "ACID's D" and the other nods knowingly and they know what to research and are on the same page and it took about 30 seconds total interaction. I mean two people who know about durability and sync writes are going to like "wink and nod" and they're on the same page and they're both productive in minutes.
Then you meet some joker who don't wanna learn nothing about nothing he just does stuff that seems to work and googles for how to fix it later, and the guy doesn't even know the concept of what the "D" in ACID means and when the tickets start rolling in, tries to reinvent the wheel all himself and its just awful to see and he can't explain it was well as a textbook or wikipedia and you try to point out this is all old stuff "Everybody doing DBMS stuff should know" and "eh its just some trivia thing from the old days nobody knows like back when you wrote Perl for money" and its just a train wreck watching the guy. OR he doesn't get hired for the position because only 50 bazillion social media posts explain this employer loves "useless trivia stuff" and if you know anything about DBMS the concept of the ACID acronym makes so much obvious sense you can learn it well enough to BS past an interview in like two minutes, if you're a DBA worth anything. But nah they're too lazy, which is how its gonna be day to day if they get hired accidentally and nobody wants to deal with laziness either.
The guy who invented homebrew and famously couldn't get hired at google wasn't not-hired because he couldn't flip a binary tree, but was not-hired because he couldn't talk like a programmer with programmers about programmer stuff quickly in a standard documentable format in the trivial and non-commercial sense of flipping a binary tree. So he could have memorized every algo just in case, or he could have learned to talk like a programmer with programmers about programmer stuff but he never did either, so ... that didn't work out well for him.
As a terrible car analogy you wanna hire two car mechanics to change tires at a tire shop and one guy knows all the names for all the tools and parts and can at least BS plausibly at the interview how to fix something obscure like a malfunctioning TPMS, at least his answer sounded believable or rational if not perfect. The other guy doesn't know the names of any of the parts "This is the growly thing that twists the shiny things off the side of the heavy bouncy circles" and you ask him how he'd troubleshoot a broken TPMS in a general sense and he fires back about he don't know no fancy words but he's been changing tires for years and it'll probably be OK eventually. And you're like "Dude, you interviewed at a F-ing tire shop and read online that we'd ask about TPMS systems but couldn't be arsed to bother even looking up what the acronym means?"
Even when you're just working alone, having seen something before and knowing the theory/literature means you can build on it instead of wasting time thinking about how to reinvent the wheel. Like you can imagine someone who knows nothing about ACID or transaction isolation being frustrated by apparent concurrency bugs in their database and hand-rolling some abomination of a locking mechanism to manually serialize database transactions. They're going to waste a ton of time on that, and it'll be fragile and have terrible performance. Or if you're working on some task tracking application and wondering about how you can untangle dependency relationships for users, you should have a basic suite of graph algorithms in your head so that you can use them effortlessly and focus on the actual problem instead of being mired down in retreading basics that every CS graduate already knows.
Also it doesn't seem like an issue of communication in the case of the homebrew guy; he was just stumped.
And what does Google invent, anyway, given that their biggest financial successes have been acquisitions?
The OP suggests some "decision" was made so employees compensation is increased minimally, unless you change jobs.
The only decisions that was made was by complacent individuals, which are apparently also here in the HN comments.
Change jobs more frequently. If we all do that, the compensation increases from performance and job-change will converge.
This comment immediately reminded me of Alan Watts’ description of the scoundrel. I’m inclined to consider this to be the correct framing and attitude.
If you're switching jobs just for more money and don't get any useful experience or skills along they way, effectively coasting along and becoming a junior with X years of experience, then yes you can be replaced.
However, if you're smart and a little bit selective, making sure to only job hop to gigs that provide some challenge and growth opportunities, not just going with every recruiter that promises you more $$$, then the skills you'll develop and pick up should guarantee that no junior can easily replace you.
My $0.02.
The market is filled with "Juniors with X yrs experience". Even 10, 20 yrs experience. No kidding.
A lot of newer developers are more accustomed to copy-pasting React stuff from SO. Which is fine, but it doesn't solve all problems.
That's how you end up with people that only know how to deploy stuff using Docker containers (which, again, is fine for most situations).
At some point the grown-ups have to show up. Can you be the grown-up?
There are very few senior people.
It actually matters because no matter how much you're getting paid, your time is on the line. You could be doing something better. If you decide to do something, and start it, why not do a great job?
Suppose you're working on a 5 year old project that has a small and dwindling user base, the only contact you get from users is complaints and requests for features that are strictly forbidden by legal. The UI is incomprehensible to users and product management keeps trying to make it more complicated or add features that won't be useful. Would you be focused on doing a great job, or just putting in time while you looked for something else and played Ping Pong?