Netflix CEO explains why he pays technologists huge salaries
insights.dice.com
insights.dice.com
Failed of course :) But they put me up in a really nice hotel, so there's that. In the years since, I've definitely lost all interest in working in SV (the fact that I've failed every single interview I've had with SV companies admittedly might have something to do with it). Ah well, at my age it's time to accept that the window has closed on some things :)
I'll give Netflix this - I left the interview knowing I'd failed. I was told this, to my face, before being shown the door (The interviewer wasn't mean about it). I'll take that over being told "We'll let you know" and waiting weeks before getting a generic rejection email from HR (or even better, being ghosted).
Why do they do this? Because there is absolutely no downside to leaving you hanging and then they have backup plans to fill the spot. Its also just emails and coordination that pays them no dividends, so they don't care. You're dead to them.
The worst is when companies post a position they never intend to even fill just to collect resumes and see their options.
The whole thing is very reminiscent of the dating scene which is not very professional.
1) to officially reject someone usually needs asking around to build consensus that regardless of any changes to org structure, to outstanding offers, to the current set of interviews, etc. that this person will not get an offer from the company. Information is usually not precise, and often partially missing in the interview loop. Most of the information is focused around the top candidates, so "maybe" tier candidates are less discussed and decisions are not really made on them. So then you have to talk to your manager, colleagues, HR, etc. to make sure everyone is on the same page. A mistake here is costly.
2) you usually make offers to the best candidate, and if they decline, move down the list. So to reject someone means that this best candidate has accepted the offer. But they get a certain amount of time to consider it (often weeks, sometimes months), when you're frozen. Then you have to remember to reach out to the rejected candidates (I guess you put it on your calendar, and someone has to ensure this happens). To do fast rejections, you need short acceptance timelines, which is offputting to some candidates. Why risk pissing off your candidates you're giving an offer to, to make candidates you're not giving offers to happier?
3) even if your best candidate accepts, something might happen before they start (they change their mind), or you find out within a week of their joining that they're problematic. If you didn't reject other candidates, you can still approach them and say "sorry, we originally didn't have a position for you, but now we do", whereas rejecting them "we're moving on" closes that door
4) I haven't even gotten to the legal or reputation repercussions if you reject someone and do it in a way that can be interpreted as a problem. You can't let any employee deliver the news. This all needs policies and coordination.
When I've been involved in hiring, we almost always have more than one opening, so this one doesn't resonate with me. We could always make a decision on 'would we like this person or not'. I've decided to hire an iffy candidate because of a corporate imposed time crunch (position went away if we didn't hire by X, so we went with someone), and it was worse than being understaffed, so I lean heavily towards only hiring good enough people.
1) Not really. Not where I work, not where I worked in the past. Maybe somewhere, but if we are talking about tech, rejections can be very quick. 2) In some companies they made a list and they then go down if the top option(s) do not accept, in others you are either the first or they re-do the search. It is company's/hiring manager culture/decision. 3) Very unlikely. Nobody likes to be chosen explicitly as second or third, as the hiring you also have to deal with someone who you did not want initially because you preferred the other(s) and as the candidate you accept to get into a problematic situation from the start. 4) Plenty of companies reject firmly and clearly with no legal follow-up whatsoever (or it they are very occasionally sued by some candidate, we all know it is part of the business).
Being rude, ghosting people, waiting for other candidates to accept before rejecting is all bully behavior of who's very often in a position of power, that is the tech company.
> went through a lot of grinding to make that happen
Aren't we in agreement?
The comment that replied to you said you can study and pass without your age being held against you.
One person is saying it's hard because of ageism/bias against old applicants.
One person is saying it's hard because you have to study.
The disagreement is not about it being hard, it's about why and it's a pretty substantive difference.
All of them involve being a single person in a huge organization, which is very different from being (for example) the CTO of a lifestyle business or the first hacker of a startup.
A friend of mine works on CSS optimization at Facebook. That is both narrower and deeper than anything you would do at a small company.
There's also the question of who your coworkers are. Large companies are large enough that you can spend all your work time with other devs. That's not true at a small company.
But I didn’t mention age?
I said career stage. You can’t tell me they don’t look at what stage you are in your career.
I think this mindset easily carries over from the investing side into the hiring side. What is an employee, if not a risky upfront investment? Especially at a hyper-growth startup that's already bleeding cash flow. Very few 23-year olds will be productive enough to justify a quarter million in compensation. But a handful of very talented ones, when put in a high-impact position with a ton of responsibility will knock it out of the park.
The median 40-year old experienced engineer is almost certainly more competent and productive than someone fresh out of school. But Silicon Valley doesn't optimize for the median, it optimizes for fat right tails. Hire or invest in a 23-year old SWE and there's always a small chance that you be scooping up the next Elon Musk. At 40, Elon Musk definitely wasn't browsing through monster.com.
However, I believe this paradigm rests on a faulty premise. A more reliable way to create an exceptional organizations is to build an exceptional culture, not try to bottle the lightning of individual superstars. Unfortunately, that approach involves sacrificing some sacred cows of Valley ideology.
Building a strong corporate culture requires effective managers, as well as brilliant engineers. The typical founder does not fit the mold of an effective corporate manager. 28-year olds can be good managers, but a 50-year old with decades of experience is almost certainly more likely. Replacing the founder with a professional CEO is anathema is the modern "founder-friendly" culture.
Beyond that a professional manager at the helm very likely means a more button-down corporate orthodox environment. Not necessarily because it's better, but just as a byproduct of how the CEO is used to operating. Mitt Romney runs a very different shop than Adam Neumann. Put Mitt in charge of the next startup, and things are going to start looking uncomfortably more like Initrode rather than the typical hipster startup.
Plus it seems like major tech companies downlevel you if you don't have relevant experience at peer companies. And salary negotiation is harder if you don't have competing offers.
I was single and was fine renting a small apartment, so the COL hit wasn't too bad. But moving out west if I had a family or owned a house would have been a major lifestyle change.
That's it I think - they see an engineer with relevant experience, but not at the scale of them and think it's not the same. Maybe they're right? I don't know.
All the companies I know of let you interview multiple times.
And here I am trying to work hard like a schmuck.
Even if you assume 150% developers at 300% the cost, it's worth it. The number of communications channels grows quadratically with the number of people in the org. You'll come out ahead at larger organization sizes. Fewer, higher-productivity people is a huge win in software with compounding effects.
And the next problem is most markets in software are winner-takes-all or winner-takes-most. Being the runner-up to Netflix is not a fun spot to be.
The place where 1x developers do well is routine work, especially on smaller projects. For example, in-house IT work at a bank, manufacturer, etc. tends to not have those same economies.
The issue is, whiteboarding people on trivia programming problems doesn't determine if they are a 10x/good developer - it only determines if they understand the particular trivia they are asked.
So you have all these people running these interviews focusing on the problem being asked when in reality, the solution to the problem is mostly irrelevant.
If they can, the next part is fit. You need to get over both bars to be hired.
All of this is incredibly noisy, so part of what happens is you have to set the bar high, since 37% of the people you interview will perform one std. div. above where they actually are, and 5% will perform 2 std. div. above where they actually are. Setting a high bar means you lose a lot of good people due to random error. But the costs of one bad hire are EXTREME compared to missing a few good hires. So it makes sense to do that.
People take rejections personally, but in most interview processes, it's pretty random. You have a bar. You hire people who interview 1-2 std. div. above that bar. You might be perfectly qualified, and I won't hire you if you had a bad day (or even an average day). The risk is too high. If you're 1 std. div. above, I'm moderately confident you're qualified. If you're 2 std. div. above, I'm very confident. And having hired people, that's how it plays out: I mostly hire people who interviewed well, and their performance on a typical day is typically lower than at the interview (not always, but usually).
Hiring is about finding and bringing in good people as efficiently as possible. I'd rather interview 20 people, hire two I'm confident are good (miss six qualified people among those 20 who had bad days), than I would bring in 10 people and hire two of them.
And bad people still slip in. You just can't do that much in an 8 hour interview.
For startups, I go for personal recs and github repos. Does that mean I miss people who aren't in my network, and who don't do open source? Of course. But that's okay. I still find enough really good people that way. (And yes, my network IS diverse, thank you very much).
But big companies need standardized processes, or things get rife with discrimination, nepotism, and all sorts of other nastiness. That easy to avoid small-scale, but with 1000 employees, it takes one bad apple to land on front page NY Times.
If you want to learn and are willing to put in the work you can do it. It will take some number of weeks or months, but it is totally doable with reading and practice. I read and practiced for a few months before getting my job at Microsoft at age 45.
Your age isn’t the problem; I know plenty of young people that don’t want to do the work also.
Any of the fancier in person practice stuff? I'm always curious what people find most effective.
Or driven to make outlandishly high salaries.
Interview practices aside - I find them to be fun puzzles and know plenty of accomplished CS/math people who do too. I understand the anger at corporate tech practices but let's not malign those who find the questions interesting.
"Doing the work" meaning having to study to relearn a thing that I'll maybe use sparingly in my work means the interview process is broken, not anyone's motivation.
It is possible (and in fact common) to lead a full and successful career as a dev, where A.) you don't ever work for FAANG or SV, and B.) You make plenty of money, have plenty of freedom, build high profile, successful technology, have plenty of career mobility.
So, if you believe those things, "Learn these things that you learned in college and then never really touched again directly" seems like an absolute waste of time. You've seen them, and you've seen that while you were _actually building things_, they didn't really come up, or at least directly. And when the value add is "Work for big fancy company for a couple % more money per year", it doesn't really seem like that much of a value add.
I’d never make a bet like that on myself by choice, but in hindsight it would have been an excellent investment years ago. My quality of life is immensely better working for a big tech co than it was at any startup.
There are plenty of big tech companies that pay well, offer a lot of freedom, interesting tech, but are also not FAANG companies with silly interviewing practices.
IMO if a company messes around with soft skills, take homes, techno chit chat, long lunches, brutal arcane automated domain knowledge screenings, shibboleths, “day in the life”, present your solution to the group, heuristics, or some other creative way to justify their own biases, I can be fairly confident that I’ll have at least a few co-workers that really just can’t code very well.
I have not met an engineer at my current company who didn’t impress me when I dig into their code a little. There are low performers, but even they produce excellent code when they feel like it.
Nothing is more frustrating than taking a day to interview and getting maybe 30 minutes of watery technical challenge.
edit Also, to be clear, you seem very proud of your interview, your company and coworkers, and I do not mean to discredit your pride or success. I am simply pointing out that your experiences are not universal experiences and might be due to lots of other factors, totally unrelated to interview methodology (healthy attrition rates, supportive teams, constructive code review, etc).
This is regardless of outcome, including many offers and years of working at companies with broken interview processes.
I don’t think whiteboarding is a great methodology, but the other methodologies are worse.
As an interviewer, I find it stressful to give whiteboard problems and my data point usually feels fairly noisy. At startups I preferred giving a tiny take home and working with the candidate on extending it in an open ended way.
As a candidate, I refuse to do take homes (known too many take homes)
I’d imagine it’s very hard to distinguish between a good talker and a good worker. Maybe some people can do it, but this is not a skill set I’d expect everyone conducting interviews to possess.
The data shows that humans are terrible at every kind of interview assessment. This is why I appreciate an approach with mechanized layers such as “ask problem with known answer, take notes”
I think the problem with whiteboardy-type interviews is they've become closer to trivia. The fact that you grinded LeetCode and others read CTCI kind of prove that, no? As in, people go far out of their way to learn a skill _just to pass the interview_.
> I’d imagine it’s very hard to distinguish between a good talker and a good worker. Maybe some people can do it, but this is not a skill set I’d expect everyone conducting interviews to possess.
Interviewing is a skill and should be treated as such. This means possessing a set of skills any dev off the floor won't necessarily have, and that should be expected. 99% of devs don't have the skills required to conduct a whiteboard interview as an interviewer correctly either, and yet that seems to be generally accepted as okay.
> The data shows that humans are terrible at every kind of interview assessment.
Exactly, which is why, in my posts above, I pointed at things other than the interview as reasons you might be very happy with the quality of your coworkers work. It seems silly to say "The data shows that humans are terrible at every kind of interview assessment", but then also attribute anything from your job to a specific style of interview assessment, right?
You'd get further as a company by investing in training, code quality (review, analysis, etc), leadership, and healthy firing processes.
Names? I’m genuinely interested in places paying near 400k/yr but without stringent whiteboard exercises. Haven’t seen them tho...
Are you currently making 400k a year?
My personal situation doesn't seem relevant to the question. Depending on how you look at it - I am. It's just that over half of it isn't liquid right now - but will likely be next year or the year after.
Very much aware what they pay.
> I'm only going to be joining FAANG or similar if they pay that much as I have no incentive to otherwise
If this is your perspective, best of luck to you, I hope it works out. You've ignored most of what I was trying to say, which is fine. I hope you find the success you're looking for.
And yes, I meant that seriously. Every fortune 500 company is held together at some level with bandaids and bailing wire. Being able to deal with things like that might be important.
In my firm, I know we place a much higher emphasis on being able to just roll with it than technical perfection. But my firm is but a drop in the ocean compared to everyone else.
Companies also need a lot of people that are creative and "think outside the box". With this you are optimizing for conformists and people that "think inside the box", and that optimize to fit the game.
No wonder the big companies have a hard time to create things..
Western society need badly to know how to deal well with impermanence, and this are such a case were there's not much prediction that can be done.. its just like dancing expecting the rain will come.. sometimes it will, and we will gladly think it was because we danced.
The best tip for hiring is someone that you know that knows a little bit to point a couple of good people for you. Because those things are pretty hard to know, and there are very little we can do, without the experience to show for some specific characteristics we need.
I don’t know why people think this. Is there some data to back this up...? I’ve seen great engineers go onto the open market and have to go through the hoops...
Meanwhile I’ve seen plenty of terrible ones have no issues getting through side doors.
After a decade of software being a desirable job and everyone trying to get into it, we can bet good money that it's now a buyer's market rather than a seller's market.
I used to think this too, but as a filter I think it's having the desired effect. From the outside looking in Life at a FAANG seems competitive in nature and they are optimizing for the people willing to push themselves that far to learn something.
The added bonus is all new hires at least know the effects of space/time complexity and how to make space/time trade-offs deeply well. Given they operate at the scale they do, mistakes with those concerns are more likely to have a material impact. Requesting that you know it _now_ and now that you _used_to_ know back in the day seems reasonable.
The upside from the candidates perspective, as ridiculous as leetcode study is, is one set of study applies across multiple companies, so candidates don't have to expend much energy on trying to optimize for how to study for a particular companies interview process.
If that's the way in and you want in, that's just what you have to do. If you aren't prepared to do it, you won't be getting in. If you are prepared to do it, and you do, it seems achievable.
A. Because that's the way we've always done it.
I can't speak for SV companies, but my experience of data is that it can just as easily rationalize preconceptions as be used to inform decision-making. Somebody has to interpret that data, after all.
One of the rules is that you automatically fail the test if you bump a curb with your wheels. That means, when pulling into a spot, you can't inch forward until your front wheels come to rest on the curb. Fail!
At first glance it seems like a trivial thing to fail someone for. I know in normal driving, I use curbs like this all the time. On purpose, and with no hazard to myself or others.
But the fact is, you're told this explicitly up front. "Don't do this, or you fail." Given that you're warned about it—and know this is the one thing you cannot do—if you still contact the curb, then you've demonstrated that you don't know where the boundaries of your vehicle are. (Or maybe that you're not so good at comprehending instructions?)
It works as a simple filter.
(EDIT: I checked with the DMV's test criteria[0], and I don't see this mentioned in there. There's an automatic fail for driving over a curb, but it's not clear if simply contacting it counts. Not sure if my examiner was a sliderule, or if the rules have changed since I first got my license.)
[0, p. 24] https://www.dmv.ca.gov/portal/uploads/2020/04/dl955.pdf
I suspect that people happened to have just zoned out during this part of the class, although a friend of mine recently said he was never taught that one is suppose to stay as far right as needed to allow people to pass on the left either.
And its not just random drivers, the more esoteric parts of the law (driving on the shoulder in TX, free right turns, uturn laws, center turning lane, etc) aren't even understood by many traffic enforcement officers.
In California, for a single left turn lane, you're allowed to complete the turn into any of the lanes you choose.
The driver handbook doesn't go into detail about double turn lanes that feed into a 3-lane cross street. My own rule is that only the inner lane (leftmost) must complete the turn in the matching innermost lane. The outer lane can end their turn in the #2 or #3 lane. I tend to choose the #3 lane just to put as much space between me and the car next to me, in case they incorrectly go for the #2 lane. Unless there's an opposing right-turning car that I trust less :)
Regardless, not touching the curb, even if arbitrary, can be an indicator of competence. It demonstrates control and awareness of the vehicle.
Memorizing an algorithm is a potential indicator of many things, not all positive, but I don't think it says anything at all about competence.
> ...you can't inch forward until your front wheels come to rest on the curb. ...if you still contact the curb, then you've demonstrated that you don't know where the boundaries of your vehicle are.
This demonstrates one reason why whiteboard interviews aren't great. They don't mean what people think they mean, and people think of them in very black-and-white terms. X always implies Y, or at best they say, "Well, maybe not, but..." and then justify the exact same result with only superficially different reasoning.
In your example, the driver might have demonstrated he doesn't know where the front or rear of the wheel is exactly. But it could also be he was just nervous or driving a vehicle he isn't used to using. Maybe he had to borrow his older brother's car when mom's broke down at the last minute. Saying he doesn't know where the boundaries of his vehicle are goes against all the other evidence: he didn't strike anything with the boundaries of his car. The curb is already inside those boundaries, intentionally and by design of the test.
Do they?
In my experience this was true in the early days of white board interviews where the only people that even thought about this stuff were people deeply interested in algorithms and computation.
But in the post-"Cracking the Coding interview" era (including the transition into the full leetcode era) people seem to be able to pass these interviews without really understanding anything in the same way college students can ace calculus while have literally zero intuition about derivatives.
I don't mind whiteboard interviews, they're a fun game you can train for and the practice is interesting. But the big tragedy now is that I feel almost nobody understands algorithms anymore since everything has been reduced white board coding drills and everyone believes they have an understanding of something they don't.
As a great example of this almost nobody today knows any heuristic optimization techniques (think the old ITA software puzzles), which used to be near and dear to anyone that cared about algorithms. But since you can't test for heuristics they same as you can established algorithmic solutions nobody studies them.
Is it though? I'm a hiring manager and don't ask such questions and yet have had no problem hiring really talented engineers.
The reason I don't ask those questions is because I know that cranking up the interview pressure and asking arbitrary, revisable, common interview questions doesn't actually prove anything aside how good the candidate is at being interviewed.
And, it may be some people don't need to be any extra studying work. There are people who do programming competitions for fun, and there was prior discussion of Google saying those people did worse on the job: https://news.ycombinator.com/item?id=9324209
"If X aren't motivated enough..." usually ends up being a really horrible take for most values of X. I'm not so sure it's different for X=employees, specially when the type of interview we're talking about is more burdensome to older folks, folks with certain personality types or anxiety issues, arguably most women, etc. Why should the burden be theirs alone, while employers get a complete pass on setting up whatever arbitrary hurdles they want?
All exams can be crammed, and having crammed into plenty of gated opportunities in life before, I believe you're mistaken if you believe that it produces more knowledgeable workers as a result.
At the end of the day, it's a market like any other. If there is someone who is more willing to do X for Y reward than you are, then they will get that something instead of you. And if you find that there is a shortage of people willing to play ball, you can always work towards bringing in more people who are willing to play ball.
Agree with your last sentence. If you want something, you have to go get it. If employees aren't motivated enough to organize and close the power gap, then employers will continue to be motivated enough to push for and work towards their own goals.
But the parent was on his 30-something when he did the interview, and i bet he had a lot in his curriculum to show for, so in this case the company dont have to guess anymore.
I think it says a little bit that the HR is failing somehow. Failing to adapt to different kinds of human beings.
By the way, there are a lot of psychology into this. Sometimes the right kind of people to do some sort of task is the one that are avoiding the whiteboard tests.
In the end it will lead to an unbalanced company with people very similar and optimized for a couple of areas, but lacking in others.
They are optimizing for people in one of two groups. One is people freshly out of college who still have that stuff at the top of their mind. The other is people who have the free time/energy to bring it back to the top of their mind instead of needing a few extra minutes to go back that far in their memories. Pick your privilege, in other words.
> all new hires at least know the effects of space/time complexity and how to make space/time trade-offs deeply well
In my experience, this advantage fades within their first evaluation cycle. And what they certainly don't seem to learn is when to do these kinds of evaluations. Oh, the number of times that I saw one of my coworkers hyper-optimize some part of a system where both N and K were too tiny to matter, then just cargo-cult a crappy higher-level algorithm where such analysis really would have moved the needle.
BTW, since I know someone will launch a "sour grapes" personal attack (and get a free pass for doing so because I'm on someone's target list) if I don't address it, I passed such interviews at 52 with zero preparation and zero trouble. So no, I don't take it personally. I just recognize this approach's flaws. It's why I refused to do interviews at that company, taking a hit for that every half until I left. Some of us stick to what's right instead of rationalizing what's wrong.
But I also think they only make sense in FAANG scoped companies where all the stack is proprietary. Small companies or companies using opensource tools don't really have this rampup and doing such interviews mostly because others (FAANG) do it.
Create a Job Seeker profile to help the website overcome the chicken-and-egg dilemma - As with any job site, it's free for job seekers and I've tried to streamline the signup as much as possible.
It's fascinating, coming from the world of "Strategy" Consulting, to see the byzantine, bureaucratic shibboleths of dinosaur companies recreated in SV in real time. And justified the same way, no less!
In any case I'm doing ok these days. Most CA employers (short of, say, Google or Netflix) wouldn't offer a big enough pay increase to offset the cost of living, and besides, I hate living in cities. My current dream is to find a good paying remote gig and live someplace... remote :)
It's only an indirect factor, in that of someone at a certain age, tends to focus on more important things, like what it takes to build large systems, avoid mistakes, work well with people. Shooing away folks with experience is a significant loss.
Also, just because you "do the work," it is no guarantee. Very likely they could pull a random question from a subject you haven't done recently.
Huge salaries are one way to mitigate that, by holding on tight to the good ones.
Facebook grew from 17K employees in 2016 to 45K in 2019. 38% annual growth, and the vast bulk of that was in engineering. "Only" 17% at Google, but it was already larger so the absolute numbers are higher. 22% at Netflix. This is hardly a "shit job of hiring" as you say. I often saw such growth numbers at startups, but never at companies with headcounts already in the thousands let alone tens of thousands. They're doing a fantastic job at hiring.
Part of the reason they're hiring so much is because they have to. Again contrary to what you say, they are not holding on tight to the good ones. The number of people who leave after two years - at all levels - is almost as stunning as the number coming in. Big Tech is notorious for this. The good ones might leave to found or join startups, but leave they still do. The high compensation actually facilitates such departures as much as it discourages them (certainly did for recently-retired me), except among the exceptionally greedy.
These companies are not pools of carefully selected and tended talent, with low rates coming in or going out. They're more like massive pipelines, with huge numbers entering and leaving all the time. The coding interviews are a very coarse filter to keep out the worst of the dreck, but they also keep out many good engineers. I've known several demonstrably excellent engineers who failed in that moment, and more who self-selected out of the process for various reasons. The people who can get in are barely distinguishable from those who got jobs elsewhere via more traditional interview processes, except for skewing very young.
Never said, implied, or believe any such thing. If anything, my last paragraph suggests the opposite. And I've been there so, unlike some, I know what I'm talking about.
- It's hard to evaluate the skills you mentioned. They're important, but generally "softer".
- It's easy to validate if someone solved a cut and dry algorithms questions. As far as I can tell, it's basically a proxy for an IQ test.
I'm not justifying this, but that's my guess for why companies do this.
...which sucks for high IQ low EQ persons like myself. My hardest problem to solve at work is always myself.
Instead of "the condition of joining our gang is you need to murder a random in cold blood" they are saying "our hazing ritual is grinding several hundred hours of leetcode and finally running the leetcode gauntlet, if you can endure that, you're in".
"It's not about the solution, it's about how you get to the solution" you say, I say there's better ways of figuring out if you have problem solving skills.
For sure, there are jobs that require such theory, but many do not. And if it's not required, managers need to realise they're potentially missing out on good talent.
They're optimizing for how far are you willing to go to jump through this here hoop of ours?
What you really want to know is whether a person can translate a set of requirements into working code. Algorithms are useful because they reduce the possibility that the candidate failed in the coding test because of poorly specified requirements.
"Problem solving" ability is a different beast altogether.
I think you're overstating the time needed. Passing those interviews for someone who reads HN is basically just reading Cracking the Coding Interview [1] or Programming Interviews Exposed [2] and doing the ~50% of the exercises.
Source: Worked at 2 of FAAMG and got rejected from 2 of them (because I forgot to read those book before the interview)
What resources did you use and what resources would you recommend?
There was a decision point about halfway through the day (after being grilled by engineers) where I was going to be either cut loose or sent on to interview with more senior level people and/or HR.
"How do you think you did?"
"Eh... ok, I think. I was struggling on the data structures."
"Yes, that's what I'm hearing from $ENGINEER. There are reasons for this - maybe you are out of practice, it's been a while since college, or you don't use this knowledge in your daily work. But we do deal with this stuff at Netflix, so for this reason we're not going to move forward at this time."
I was interviewing for a position doing Scala (at that point in my career, I was doing some Scala work, and it was still a fairly new and hard skill to find). The person giving me the bad news was a Lead Engineer and a proponent of Scala, seemed a bit disappointed that I knew Scala but got tripped up by low-level implementation details of some data structure (Naturally, the solution came to me later on the plane ride home). I actually had studied for this interview - but I had studied the wrong things (I was focusing on Scala-specific knowledge, but they really grilled me on fundamentals).
The specific team you were being interviewed for might have this apply, but the claim that "Netfix" (as a whole) deals with these issues regularly is almost certainly an exaggeration (at best).
These interview questions generate poor signals and are best seen as hazing ritual/ego stroking exercises.
And it's likely that that matters.
Having 0.5% of all engineers regularly engaged in working with the implementation details of data structures and algorithms does not justify putting 100% of engineering candidates through interviews centered on that topic.
I did not ever hear from that recruiter again.
It was a pretty gutting way to interview with, at the time, the company of your dreams. Plus, being 20, the weight of that call was a lot greater than it probably should've been.
That said, the thing to remember at all times is that the dude doing the interview is just doing his job and you’re little more than a row in a spreadsheet before and after the interview, perhaps even during, too. I wish this was taught instead of having to be hard won experience, especially since this is obvious as soon as you start interviewing people yourself.
This isn't really a thing candidates should care about, IMO. It is fine to demand decency out of interviewers, and it is fine to callout when bad things happen while people are "Just doing their job."
My god, I'm terribly sorry that happened. I know you're probably not looking for apologies at this point but, as someone who has conducted countless interviews as the interviewer and I've had some really bad candidates on my phone and in person...I cannot fathom doing that to a person.
If we're booked for a 30-minute interview, the candidate is getting all 30 minutes of my time. If I guess fairly early on that the candidate is not the right fit or simply didn't pass, we will talk about general tech topics or I will ask more professional background questions than I usually do (I try to keep to a 50/50 split of technical questions and "tell me about yourself"-style).
If we're booked for an hour, the candidate gets a minimum of 30 minutes, and I shoot for a bit longer. Heck, I've had some candidates turn it around in those last few minutes. The candidate has already slogged all the way to this point. I feel that the minimum level of decency I can offer is to give most or all of the time I've already said I would give. This applies even if the fire alarm goes off; the candidate is going to get each one of those minutes because it's the respectful thing to do.
The interview at my last two jobs (current and previous one) were both vastly based on a coding task. I always prefer this as it is closest to how I work.
Good developers are the ones that create code that resists the slide from a 10x code-base to a 0.1x code-base. Important skills towards this end are a good sense for code architecture and testing discipline. But also: good communication, organization, documentation, teamwork.
As an anecdote, one of my favorite developers to work with at my current workplace is a "high throughput" developer but who is personable, tests and documents the crud out of everything he does and makes it easy to extend and fix bugs in his code for other developers. One of my least favorite people to work with is also a "high throughput" developer who is a prolific creator of software, but everything created by this person is an un-maintainable, un-documented, un-tested, brittle block of procedural copy-pasta that ends up in the critical business path. And yes, this developer "snapped" about a year ago and it has been a 3 person project ever since to scramble to fix this stuff.
So, moral of the story, be very careful with pure productivity as a metric for developers. Maybe a 100x developer is really just a 5x developer who enables 20 teammates to also be 5x developers?
EDIT: I think I maybe didn't make my point super clear. My theory is that there are two (somewhat) orthogonal dimensions that you can judge a developer by:
1) Productivity, ability to get things done, this is what I assume (maybe mistakenly) that people are talking about when talking about an Nx developer because it is the dimension that maps better to a quantifiable value.
2) Quality, ability to create code that is easy to work with and extend. This doesn't map to a Nx scale at all.
One of these qualities contributes towards a goal by compounding linearly, independent of headcount. The other compounds exponentially and also with headcount and is clearly the superior thing to think about when considering developer skill.
Yes, sadly this is honestly true. Especially if you take into account the time spent to manage them, and then cleaning up after them, a person can easily be negative net contribution.
Honestly that's one of the ways I feel I've made a hiring mistake. It's okay to invest more time than it would take me to do a task to teach someone else to do a task, knowing that they can learn and improve, and eventually that investment of time will pay off. Eventually they should be teaching me things too, and doing things without needing any help. But if someone is constantly taking more time, and it doesn't look like that investment is getting paid off, I get nervous.
Then when the team starts slowing down, management will become even more resistant to getting rid of people, because you need to "go faster" which in their minds is simply some matter of headcount.
A 100x engineer exists in the context of a global company like Netflix. Because if a developer makes something just 1% better that translates into millions of dollars of savings or increased revenue because on the margins just 0.001% increase of new subscribers is thousands of customers.
Generally, the idea of an Nx programmer is comparing programmers on their output, not their outcomes.
Otherwise you go from trying to compare levels of skill to levels of luck.
The only reason I've ever considered dropping Netflix is "why am I paying for this when there is nothing I want to watch". Fortunately, they have come through with some interesting content recently, and I'm still paying them. But give it a month or two with nothing I want to watch, and I'm pulling that plug, and no amount of 100x programmers will be able to keep me as a customer.
The point is, with a service like Netflix, it's absolutely the content that matters. People happily watch pirated cam copies of movies because they want the content so much.
Then again, the salaries of 10x developers are a lot lower than 10x creators (directors, showrunners, actors, etc)
It's not a coincidence that they happen to have stuff that you want to watch. You're aware Netflix also applies data insights to decide what to make?
Of course I give something thumbs up or down depending on if I liked it - why would you assume I don't know what they do with that?
But they've still made some barely watchable crap, too, in spite of themselves, so I do have to question if rating things even matters.
> they've still made some barely watchable crap, too
To you. That crap was undoubtedly entertaining to someone. Not to mention a 100% hit rate is nearly impossible in the creative biz.
Netflix's "Another Life" was so bad that people wonder if it was made bad on purpose. It was absolutely awful, and anyone that thinks it was good loses any credibility about what's good or bad sci-fi.
And I've been developing webpages for many decades, and even worked quite a long time at a precursor to what Netflix is today - yes, an online movie streaming service. So please don't talk down to me like I don't know what any of this is about. You're seriously wasting your time explaining any of that to me.
> I've been developing webpages for many decades
It can't have been that many decades, the WWW has only existed for 3 decades.[1] Even I've written at least one webpage in every single one of those decades. :-P
Do you realize how absurd that sounds? Content is King. If Netflix had crap content, it wouldn't matter how good their programmers are, because the content would still be crap. I can tell you from experience that if Netflix ever folded, their contracts with studios would be worth 100x more than whatever code they developed is worth.
> I've been developing webpages for many decades
>>It can't have been that many decades,
The "WWW" was created in August 1991, and I was on it in 1992, so yeah, practically 3 decades. I was wishing for Javascript in a web browser years before it ever existed, back when I was using lynx to browse the web. And I was coding long before that. Yeah, I'm old. I've been around. I don't need you explaining anything to me.
I don't think I ever once said "content doesn't matter". If they only had dynamite content and a shitty user experience people would simply pirate the content and not pay for it.
> Yeah, I'm old. I've been around. I don't need you explaining anything to me.
I try every day to not become like that.
Most people have no clue how to pirate anything. Out of 100 people in your life, including all your relatives, honestly, how many of them are willing and capable of pirating content? If you think it's over 25% you will have me ROFLOL. And all of those people will be just fine with a less flashy UI than Netflix has to watch content they want to watch. I mean, they've been using cable boxes for years and those absolutely SUCK for finding content - but they still watched, because there is content they want to watch, or not, so they don't watch.
You're really making some very weak arguments.
Laugh it up then: https://www.theverge.com/2019/4/17/18412159/game-of-thrones-...
Even if you're right, you're admitting a good UX gets at least 25% of the people to pay money instead of pirating.
https://www.forbes.com/sites/steveolenski/2017/06/21/why-con...
>All the content in the world won't help them if you spend your time staring at the home screen while bad algorithms recommend the wrong things.
Their algorithms only optimize for the least profitable use case. It doesn't matter what the algorithm wants to suggest if they don't have the content I want to watch, or I've already watched anything worth watching.
Know what their algorithm suggests to me now? Sci-fi in foreign languages that I'm just not interested in because of its low production value and bad writing. But it's all they have left to suggest to me. That and everything I've already watched.
"Content is King".
What? I can read about quality shows to watch on any number of websites or recommendations from people I know, and just search for the title of the show.
On the other hand, if you fill up your inventory with 99% garbage, like Netflix has, it doesn’t matter how good your algorithm is, since it’s going to come back with garbage.
I don’t notice any performance difference between HBO Max, Apple TV+, Netflix, or Amazon Prime. I press play, and it plays. What I do notice is most of the content is garbage, so I just wait to hear about good shows, and then once a sufficient number of people claim it’s worth watching, I go and play specifically that.
This dumb developer multiplier has really taken on a whole bunch of different convenient meanings.
The original idea had absolutely nothing to do with company success. It's not even useful now and it was questionable before.
The starts at Netflix are the procurement people that ensnare good movies while drinking fine wine on Manhattan or whatever. I would not say it is an engineering company like say, IBM or Oracle.
That may be true of good developers. On the other hand, in my experience "10x developers" are the ones causing the slide.
If they're causing code quality slide, they're not a "10x developer."
If a 10x developer does not deliver 10x productivity or value of the median developer, they do not meet the definition of a 10x developer.
If we say green field is 10x, and someone is doing good things, I think that should go up over time. Getting things like builds, documentation, tests, make people more productive.
Whereas on the other hand, people who make code worse eventually start drowning in their own filth, and eventually slow down to nearly nothing. Filth also compounds.
The lead developers on each selected different frameworks, used different data architectures, and set up different workflows. One project became hugely convoluted, with bugs that were very difficult to trace due to race conditions, the way the navigation worked, and choices that let to more complex code. The other team had a much simpler architecture, and was literally 95% less code. That team was able to add new features with ease, and without complex bugs cropping up out of nowhere.
In fact, that project went into "maintenance mode" because there was nothing else to add, and the lead developer could just add one or two minor things when they cropped up, and instead spent most of his time on a new unrelated project. I'd say the lead developer with the better architecture was not only 100X, but the other team's lead developer would probably lead to the downfall of that company -- both morale and development speed would plummet to 0.
It’s not about the 12’o clock shoot-from-the hip duel - the one who shoots more codepoints in the general direction leaves winner.
A piece of code - if it ends up in production - has so many potential ways to waste work hours that avoiding just a fraction of them is a huge win.
On a lighter note your username definitely checks out :)
EDIT: On the other hand, there is no limit in the other direction and that is where companies end up in big time trouble with a 0.01x codebase.
I'm also going to go out on a limb and say there's such a thing as a negative codebase. For example, let's say I have to work in a codebase for a particular political reason, and I can't rewrite something. But if that takes me 100x the time it would to do it correctly, then really the codebase is actually a net negative. One example of this is places that use an in-house framework for something (when there isn't a good alternative), but then a good open source alternative comes around. Of course you don't want to rewrite things all the time either, so I do agree there is a limit, but really I think that comes down to the code doing exactly what it should in the least complex way possible (with no bugs). Once you get there, there's nowhere to go?
I'd also argue that a lot of people over-architect solutions and they miss out capturing markets, which leads to real life economics for a business. YMMV
Good code builds and compounds on itself. It makes every developer on the team more productive. Its not just about the output of the single "10x" developer. Just having them on your team increases your whole team's output, even after they've left. Sometimes other "10x" developers build on top of that work.
Bad code also builds and compounds on itself. Same argument but in reverse. At some point the codebase becomes so unwieldy, someone will have to convince the manager, that a complete rewrite is arguably a better option.
Example of >> 10x phase change: Jeff Dean and Sanjay Ghemawat with MapReduce and BigTable.
For the negative, I think we all have seen the programmer who is useless and that actually requires other people to replace their work.
Wow!!! so true, never heard it said like this.
Also, there are entirely different “10x engineers” being talked about as one and the same here. The copy-paste spaghetti guy probably couldn’t even get a job at Netflix...
Unrelated to your point but I think a lot of people who write really bad code are the only choice because they are experts in another essential domain, and there aren't a whole lot of experts in both that domain and writing software. So you do what you can. There is a reason that code written by EE's is often derided as terrible.
"The thing with "10x" developers, is often times they (or a group of them) can do things that the average developer can't. Take Netflix as an example, would they have even started on the whole cloud thing if they had average engineers? Or if they did, would they have been thought leaders in the space for so many years.
> Maybe a 100x developer is really just a 5x developer who enables 20 teammates to also be 5x developers?
Or just a developer that makes the lives of 2000 engineers a little bit easier.
In that sense a 1x developer is infinitely more efficient than someone who is a net loss to the team and 100x is nothing.
I do agree that it would be very difficult to be 100x better than someone who has decent technical skills and generally displays common sense and stays focused on useful paths.
To those who couldn't scale out Graphite and got crushed under gruesome oncall alarms, the Netflix folks were 100x engineers.
10x developers exist. 100x developers exist. These developers don't program 10x as fast or have 1/100th of the code. They bring 10x or 100x more value as compared to other developers.
People in HN seem to forget: Code doesn't live in a vacuum. Code has purpose. Code fixes problems. 100x developers are the ones that bring true value. That value may come from a 300 LOC data structure that improves efficiency by 50% or a 30-page code architecture that improves scalability. The means to produce value are irrelevant. What matters is how much value you bring to the table.
10x is 100 times bigger than 0.1x FWIW.
> but I argue that it is at least partly due to the prevailing code-base.
Its almost exclusively because of the prevailing code-base. We can't forget that the prevailing code base was built by developers of varying skills. You can have "100x" developers build it or you can have "0.1x" developers build it.
> One of my least favorite people to work with is also a "high throughput" developer who is a prolific creator of software, but everything created by this person is an un-maintainable, un-documented, un-tested, brittle block of procedural copy-pasta that ends up in the critical business path. And yes, this developer "snapped" about a year ago and it has been a 3 person project ever since to scramble to fix this stuff.
Was this person the aforementioned "Rick" from this article?
And in my CS class I was in the top quarter percentile, he was in the top 1%. The difference is big. They type code as fast as I'm typing this comment, while having a sane architecture.
The secret: they programmed a lot more as a kid.
Real world "10x" developers are almost always in that class because they can solve the same problem with 1/10th the code of a 1x developer.
Ability to solve problems with less code will always outpace faster typing.
Because the people who shorten code at the cost of clarity are some of my least favorite people. I once saw “half = num >> 1” instead of, say, “half = floor(num / 2)”. The latter is 100% more clear to more people and doesn’t gate-keep on engineers who haven’t memorized bitwise operators. (Also, this wasn’t a context where the bitwise operator would be optimized by the compiler in case they wanted to throw that hogwash out there.)
But personally, short, standard, and sweet is preferable to crazy newfangled mental model. I've seen way too many real-world examples of the idiom "it takes a lot of skill to write Java in every language."
half = num >> 1
Was standard practice and understandable by most engineers, as well as far and away much faster than a divide.
Now-a-days, using a compiled language they are going to be translated into the same machine code supporting your point. However, it might still be a good idea in a scripting language doing heavy math lifting.
> I once saw “half = num >> 1” instead of, say, “half = floor(num / 2)”.
Again, that's just stuff that's getting you a small constant factor less code, a few characters here and there. To get closer to an order of magnitude smaller program solving the same problem requires a deeper understanding of the problem and different strategies for solving it.
To me, the gold standard example for the 10x to 100x coder is always Peter Norvig.
https://norvig.com/spell-correct.html https://norvig.com/sudoku.html
Notice the clear comments and detailed explanations and reasonable identifier names. But do you think the median developer would solve these problems with a similar amount of actual code?
Also, research shows the number of bugs per line of code is pretty much constant across programming languages and kinds of programs. So reducing the number of lines of code will almost certainly reduce the number of bugs, statistically speaking.
Nobody I've met thinks that there are a set of people that believe there are "developers that write code 100x faster than other developers" but when people write comments on HN they act like this is a really common belief and only they are able to spot that it's not sane...
Everybody that I've met considers technical prowess more along the lines of: the ability to write complicated code which others would find difficult to do, the ability to simplify a problem in order that it can be solved without complexity, the ability to optimize the performance of something in order that it uses less resources, the ability to come up with an innovative design that others wouldn't have thought of, the ability to explain technical ideas to their colleagues in a way that enables others to achieve more, the ability to balance short-term goals against a long-term plan, etc.
It’s apparently not unheard of to have C programmers who don’t know function pointers or even structs work, or who don’t know what a build system is (only ever used an IDE).
There are many people who will just plug stuff together until it works somehow, without understanding why or how it works in the end.
That's the antithesis of HN of course. Most commenters here probably work for tech companies.
There is some literature on it. For example, this blog post [0] contains some references.
I have only read Peopleware. It says 10x is the difference from worst to best in terms of time and number of defects across a few hundred programmers. Also interesting: Within the same organization, there was only a difference of 30%. This means the environment is much more important than the skill, experience, or personality of a programmer.
I cannot find any studies after 2000. Most of the data is even older. The Peopleware data is from Cobol, Fortran, Pascal, and C.
[0] https://www.construx.com/blog/productivity-variations-among-...
Technically great? Great leaders? Great thinkers/architects/high level people? All of the above?
Sometimes this meant being an expert on a certain technology to better leverage it (especially important on teams that need to go deep such as video encoding, CDNs, television hardware, etc). Or looking at needs and pain points across teams and building high level solutions that raised productivity across the board. A willingness to question things and push for better ideas and really seeing them through. This could be at a technical or human level. Some people were really good at improving team cohesion and empathy, causing teammates to work more effectively. Others pushed hard for internal education and sharing learnings to help raise everyone's game. The culture of the company helped enable all of this. Some people excelled at improving culture, which has a leveraging effect as well.
I have seen the above at just about every company I've worked at. But I would say that at Netflix people took it further and were more successful than I've seen elsewhere.
That's just my experience, I've only worked at a handful of companies. I have no doubt many companies have employees that do all of this.
Like Jeff Dean or Sanjay Ghemawat?
As for the culture. It's not nearly as cutthroat as people assume it is. But it's true that Netflix wants you to perform well. This gets balanced out with good communication from management and your peers. Netflix emphasizes candid feedback, so you pretty much always know where you stand. At least, in my experience. It's a big company, so mileage may vary.
I assume the broad buckets of continuous effort are "get the right content to the right users", "add more content" (which may involve some engineering support via e.g. analytics), and "scale it up to effectively reach more users". It seems like Netflix has fully shifted from a chaotic "zero-to-one" innovation state to a more mature "continuously aggregate marginal gains on top of a solid foundation". Is that a fair characterization?
The only conceivable "problem" with the above from the engineer's POV is that (1) individual contributions might feel less exciting and (2) it becomes progressively harder to find ways to move the needle. Though I would assume this is a problem at virtually any mature technology company. On the bright side, a marginal gain applied at a massive scale probably feels pretty rewarding.
My first 3 years were on the consumer side, working on the TV client. I'm a bit more out of touch here. But I'd still say interesting engineering is happening here. I agree sometimes it is "marginal gain at massive scale", but that can be really satisfying and challenging in its own right. There are many different teams focusing on a lot of different things here. The consumer side is pretty much entirely driven by A/B tests. So teams might take on a big idea, but it can be hard for those to beat out the established norm sometimes. That may be a factor in why you feel the product is "static". Also the wide range of devices and internet connections can segment engineering. Many efforts apply across the board, but other projects might only apply to say high end game consoles for example.
Regarding "get the right content to the right users", I don't have much experience with that. That's more in the domain of backend teams. I do know they also do A/B tests to guide innovation, but that's about all I can confidently say there.
For better or for worse, this lead to discussions about salary, negotiating practices, and to people looking elsewhere.
I sometimes speak with people that work in other fields and many of them have zero clue about these topics, whereas in most IT-related discussion boards (whether it's HN, reddit or whatever) there's a related thread in an almost periodic cadence. We in IT are kinda obsessed with these topics (we're discussing this on a VC-owned discussion board after all).
On a different topic: is there any data for salaries in other fields for the same companies (FAANG and similar) ? It'd be interesting to see how much earns, for example, a lawyer in such companies.
It's true that some market forces and potential value of what is created are factors else nobody would pay for the premium, but he generally scarcity rules here.
For a contrived example, why is caviar astronomically more expensive than bread? It's not the cost of production. It's not the fact that people like it more than bread.
It's just scarce.
If caviar was scarce, and the only people interested in buying it had no money, then it would simply be unavailable. Or maybe whatever little supply there is would sell for as much as the buyers could afford.
> It's true that some market forces and potential value of what is created are factors else nobody would pay for the premium
Although, amazingly demand can be manufactured to some extent (where potential demand has to exist of course). De Beers managed it with 'A Diamond Is Forever' where they managed to become the de facto engagement ring stone. Scarcity + good marketing does seem to be a magnet for the wealthy.
Like...I had foie gras for the first time a few years ago, and while I thought it was pretty good, it definitely wasn't mindblowly good, and definitely wasn't worth the price.
(Later, I looked up what foie gras actually was and decided I'd never eat it again)
Yes, but it's an acquired taste.
My buddy is a nurse in Bay Area with a CRNA, it’s pretty much understood you make 225k plus any overtime so there’s not much more to discuss.
https://www.thestar.com/business/personal_finance/2020/09/21...
In no world are SWEs "relatively speaking" little people compared to lawyers.
However, in our field you end up with people who have sat around in their same SWE job at DuPont/Lockheed or some other boomer company for 10 years and are making $80k while new grads are hitting $150k+ TC going into Google and 7 years experienced engineers can hit $450k TC at the big tech companies.
A tech company with a good moat can easily extract millions in value out of the work of SWEs building more crap for them. That's why they are willing to compete for competent engineers. If they didn't bring in that kind of cash, the companies just wouldn't pay for it, period.
Employees talking money with each other has zero bearing on what a company is willing to offer. I worked at a hotel in high school and everyone knew the hourly pay of every position in the hotel. It didn't get us raises.
The skyrocketing wages for engineers are because until recently, tech companies were illegally conspiring to not compete for competent engineers.
In my opinion a huge role in the raise of tech salaries is simply constrained real-estate in the bay area. Just looking at rents and homeprices, I wonder if cost-of-living adjusted salaries have actually gone up much in the bay area.
However...it does set the bar for the country overall, which is good for everyone.
Secondly, i'm not sure about brag but I think tech companies have realized that skin-in-the-game has resulted in shared success. This is also great for everyone -- companies, and workers.
The government requires that companies publicly report salary data for H1Bs. You can google for that data. Here's one site https://h1bsalary.online/
On my LG tv their app is the best, by far. I wish all the other services just served their content through Netflix. All new content has 4K HDR with Dolby vision/atmos and streaming is quite fast on my 200 Mbps fiber connection.
HBO Go is pure garbage. The app is clunky and has way worse UX than Netflix. The streaming quality is absolute crap. There's banding everywhere and the image seems to pause for a frame or two every second or so. This is extremely annoying when the camera pans. Game of Thrones doesn't even have 5.1 sound. No English subs (for those shows where sound is not so great). Last time I checked there was no 4K HDR.
The Amazon Prime app has better UX than HBO Go and has much better streaming quality, but the experience is still quite mediocre. The whole UI seems from 10 years ago. When you're binging a show they always insert ads in between episodes and the app forces you to skip recaps and the show intro every time. The quality of the streaming degrades quite often for a couple of seconds. Also, no English subs. They also have an HBO channel but it suffers from the same quality issues as HBO Go.
I haven't tried Apple+ and Disney is not available yet.
Netflix works great with a slow or intermittent connection, they've clearly optimized it.
My rank for engineering quality (not UX) are:
(1) Netflix, (2) Amazon Prime, (3) Disney+, (4) HBO Go (I get a stop-the-world spinning icon every minute at times)
HBO Go is so bad that I have to get out a mobile device and "save offline" and cast it to the TV just to watch something.
(I don't use Hulu.)
Apple TV app on macOS Catalina is a disaster zone. iTunes was pretty bad but the new app manages to be just as confusing, with fewer features, and worse of all it crashes immediately and reliably if you do something totally unexpected, like plugging your laptop into a TV via HDMI. Ridiculous.
I never owned an Apple TV but my 1st gen Nvidia Shield TV was super solid. I only stopped using it because it didn't support Dolby Vision and the apps I use are on my LG tv anyway.
A silly strawman. I'd firmly put someone like this in the bucket of "not that effective."
It's arguments like these that make me very skeptical of the claims that 10x developers don't exist, as I've yet to hear such an argument that doesn't fail at basic critical thinking.
That being said, I fully agree with the article's framing of this view as simply saying that talented developers need a healthy working environment in order to reach their potential.
The flip side being, a talented developer might not want to join a company where an engineer like that has been the top dog (and the people below haven’t been around enough to have an idea what being a senior engineer is about). It just ends in tears and frustration for the ”talented developer.”
There have been a couple of teams I've been in a position of technical leadership and/or been better than the rest of the team on all or some relevant technical axes. In all of these cases, even if I was being 100% selfish, I would still _want_ to grow the people under me, since the stuff they grow into is the stuff I want to grow out of. As a concrete example, I'm currently the TL of a team, with a primary personal focus on ML, and it's been a huge win-win to hand off ML system maintenance tasks to non-ML engineers. These tasks provide them valuable exposure to the way ML production systems work, familiarity with ML workflows/tooling, and practice reasoning about ML systems. But they also free my time up of tedious, straightforward little tasks, to work on things that challenge me more. It's win-win-win, as the company is getting a more efficient and productive allocation of resources too.
Early in my career I had someone that kept telling me "we don't write documentation because nobody will read it". I'll never put up with that again. You can take 30mins to write a confluence page describing the context, the solution, and comparison to other solutions and why this one was picked. It will save the company many hours later when someone else has to pick up your stuff.
You don't have to always write docs saying "here's how this system works".
You just write a document as a proposal saying "here is how I want to build this system".
It takes 30mins. It helps everyone. If you want to change the system significantly, you just write another design doc.
Also, if you do this you probably don't have to redo things all the time.
If a company fires you for outlining how you're going to solve a big problem - they aren't going to do well anyway so you don't miss out on much.
Based on my experience from a fast growing billion dollar company, and a company that you would call "fast moving" but will never be anywhere near as successful because they can't focus, let alone sit down for 30mins and write a document.
At the same time while youtube offline video watching always works for me on my iPad Pro, Netflix often ,,forgets'' the downloaded content.
If I look at the storytelling/direction itself though, I find HBO better than Netflix (especially with politics ruining the stories). Can somebody tell me a new Netflix serie that comes close to House of Cards?
As for designated survivor it was a nice copy of house of cards, but lacked the level of storytelling that went into house of cards.
Had I written what OP said, I would be clarifying that I mean "pushing personal politics via messaging in the show." HoC is remarkably a-political in that respect. They portray the power struggles and corruption fairly equally across the board regardless of party affiliation. More so than party though is simply they show how hollow the beliefs really are. It's about power and manipulation, not so much about policy. Of course such wide statements are nearly guaranteed to be wrong applied to some politicians, but as someone who has been all over the map politically throughout my life, they absolutely nail the main themes that I've noticed nearly everywhere.
If you get into it, Netflix also carries a bunch of good Korean dramas, which tend to have a lot of episodes and honestly just seem to have much more effort put into them than most American TV. Signal and Itaewon Class are two of my current favorites.
I enjoyed HOC, especially the earlier seasons. A few shows (none of them new though) available on Netflix that I found equivalently good, each got better as they went:
Bloodline[0] - starts slow & builds, I didn't expect to like it as much as I did. Very under the radar, very good.
The OA[1] - similar to bloodline, in that I didn't expect to like it & it got better with each episode/season as the story progressed.
Colony[2] - got cancelled so ends on on cliff-hanger (an exhilarating one), but if you like sci-fi/aliens it'll deliver.
[0] https://www.imdb.com/title/tt3520702/
I have an essay I wrote a while ago lying around that talks about the Intermediate Programmer - Rick sounds like a perfect example. The IP is the one that has the gumption to try out various inventions and experiments, usually focusing on the trying to solve a problem with a perfect Beautiful Machine, but that doesn't yet have the perspective to know how code needs will change in the future, and how to design code to make it easy to change.
I've had people on my teams that can code circles around me in various ways, and whose gorgeous intricate multi-level generics-heavy code was also regularly deleted a few weeks/months later in favor of something literal, boilerplate, small, and easy to understand and change. (Don't get me wrong, multi-level generics-heavy code is GOOD in some cases, but you have to know when.)
The good IPs learn from these lessons without letting their ego get in the way, and eventually become advanced programmers. The bad ones claim they are advanced and cause problems. Sounds like Rick was a 0.5x developer or less.
I do think, though, that you can spot them fairly easy. Even in college. I had a very skilled classmate that wrote code only he could understand, without any comments. Of course, we could eventually understand it, but it would cost us hours.
Some teachers actually refused to grade his exercises if he didn't start commenting his code. I still believe they did this to instill in him this habit, but I'm sure it was hugely helpful to them as well.
Very little on social media is organic if it pertains to a large corporation.
[0] https://www.cnbc.com/id/100436754
[1] https://www.investopedia.com/terms/f/fang-stocks-fb-amzn.asp
In addition to their stock price, these companies also pay very well. In fact, if you are lucky to get an offer from Netflix, their aim is to pay you and keep you at "top of personal market". That is, they do not believe anyone will pay you more in total comp. Netflix does mostly, if not all, base salary as opposed to equity grants.
From all my friend in FAANG, this has seemed to be true, Netflix employees make more than anyone else I know in tech.
We pay enough that your compensation is not a reason you want to leave (or stay — we don’t pay more than the best you could possibly get elsewhere.) because our philosophy on compensation is such, it has a few ripple effects - there aren’t limited budgets for raises, instead we ask for each person did the market move for your role, or did you substantially change roles? This avoids the common shenanigans / pitfalls of comp elsewhere.
I personally believe that our early move to the cloud, early adoption of micro services and our open source contributions also help our “tech brand”.
It’s the best place I have worked.
How is this structured in the UK where US companies have difficulty offering tax efficient employee share schemes.
Not looking for a Search Director are you :-) my senior band 7-6 opportunity with the uk civl service seems to have disappeared with covid.
Trading firms can beat Netflix, but the variance in pay is much higher and in my experience they tend to be more selective (and there are fewer roles available). I wouldn't say the typical engineer at DE Shaw is earning "way more" than the typical engineer at Netflix.
Source: I have friends at Netflix, Citadel and DE Shaw, including a director at Netflix and a VP at DESCO.
Hours can vary widely between teams/projects but I generally don't have an issue with the hours- like all companies we have our crunch times, but the general day to day is pretty much 9-6.
Sure a skilled software developer with an interest in networks or media platforms would have no trouble finding a job there. But what about other types of engineers like product, kernel, and embedded engineers? The companies I mentioned have divisions like Oculus, Alexa, and Chromebooks for those engineers. The comparison to Netflix in areas like those is where my confusion comes from.
Every show about dating, cooking, design, fashion, plastic surgery you could imagine.
These are just some Netflix Originals that showed up when I searched The Circle
This matters because a repeating theme seems to be that the only people who can build competent tech teams are engineers. A generic media executive will find it much harder going because they don't have any intuition for the skill gap being discussed by Hastings here. Disney+ seems to have managed it but only by buying buy theirs from a sports streaming firm that had already proven themselves effective, if I recall correctly. Obviously there's a limited number of opportunities like that.
So I guess it's a question of what's harder - for an engineer to build a great content operation, or a media guy to build a great tech operation. So far it seems like maybe neither are possible, although Netflix has had some great content perhaps that's more luck than anything else? If so then it'd make sense for eventually these firms to form a truce, with Netflix focused on the retail/online store aspects and other firms creating the shows.
There's like 5 or 6 different ways to identify my position: programmer, coder, developer, engineer, hacker..."technologist" isn't that big of a reach from them I guess.
https://en.wikipedia.org/wiki/Software_engineer#United_State...
edit I may have been mistaken and the word engineer itself may be non-protected, but the term software engineer specifically is protected in Florida:
http://www.leg.state.fl.us/Statutes/index.cfm?App_mode=Displ...
That said, in my experience all manner of technical professionals (and even not so professionals) in Texas do routinely call themselves engineers whether they're supposed to or not.
Also, if they are Canadian they might get their goose feathers extra ruffled. https://en.wikipedia.org/wiki/Software_engineer#Canada
Of course, in reality it's a rather fuzzy term.
I'm not trying to make their work sound less-than, just describing how I've heard the term used. Total anecdata.
"Tecnology" in conventional parlance has regrettably come to equate to "information technology" much as "engineer" once referred principally to a locomotive operator.
I'll skip the "ssofftware engineer" debate, though note its existence.
OP's Dice link is blogspam.
Of course, since "productivity" in software is completely subjective, every claim of higher productivity attributable to whatever cause is by definition correct.
This is why we use story points and velocity, not time.
> and never leave technical debt behind for later cleanup (they do)
What does this have to do with anything? We do this all the time and capture this sort of thing for our backlog.
> or at least leave behind the exact same amounts of debt regardless of the implementation path chosen (they don't).
So? tech debt is tech debt and it's a bear regardless.
I don't know why you're being so aggressive with the gotchas, but if you think it's impossible to objectively measure engineer quality I don't know what to tell you and I wish you good luck in your hiring and career growth.
I love that the article treats that source as valuable insight and revelations of the arguments in play.
I feel like an objective analysis of me as a software engineer is that I'm the opposite of this. Maybe because I've not been doing it long, maybe because I'm a bootcamp kid, who knows. I'd like to be that kind of engineer, though. The one that whacks out some mind-boggling fix to problems. I work with a woman like that. She just... figures it out. I don't know how to explain it. Like one time we had to build an SQL AST represented by the DOM, and she put down this recursive series of components that to this day I have trouble explaining to new people on the project.
I want that skill. If it's talent, fine, but I've yet to find things I can't learn through sheer brute force if necessary. This one, though, I haven't found the brute force solution to.
Sounds like the kind of thing you might pick up in a computer science class. Maybe read up on parsers and compilers?
If managing great employees is easier / less work, then shouldn't each manager be able to manage more people?
What are they doing with all the 100x programmers?
500k as a programmer in a tech company that's doing well sounds like justified compensation. They do write the product after all. I does make me question if there are any juniors present in that company and what kind of salary it is they have. Having a colleague that earns 5x as much with maybe 10x the experience is still... quite bizarre to me. Would that kind of a progression even be possible from within the company?
But at companies which do, progression usually goes up by around 100k per level: https://www.levels.fyi/?compare=Netflix,Google&track=Softwar...
Base salaries at the other FAANG companies is lower because stocks and bonuses are a significant fraction of the total compensation. But total compensation is similar for all of them.
I thought this was common knowledge? Reference: https://www.levels.fyi/?compare=Amazon,Apple,Netflix,Google,...
Oh and to top it off, the company is mostly Hollywood production people by sheer number nowadays. The focus of the company has veered so far from technology I doubt its a great engineering culture anymore. Internally they boasted they would become HBO before HBO could become them, but who the hell wants to be HBO? Quite the turn off. There were many of these.
Several people from my work have come over from Amazon, and we constantly interview people who either take Amazon over us (citing more $), or are trying to get away from Amazon but they end up getting a big counter offer from Amazon and staying with them.
if honestly be making less than half my current total comp if i’d accepted any of them
Ill give you an example I did a RAD (agile) project with one other developer back in the early web days two of us flew up to Edinburgh and given a clean room and with a co located team produced some thing that another group had quoted two years.
Netflix are not paying some one 500k to half arse JIRA tickets here.
* Netflix’s Reed Hastings Deems Remote Work ‘a Pure Negative’ (https://www.wsj.com/articles/netflixs-reed-hastings-deems-re...)
* Netflix CEO Reed Hastings on Working From Home: ‘I Don’t See Any Positives’ (https://finance.yahoo.com/video/netflix-ceo-no-positives-wor...)
His opinions are in stark contract with those of other CEOs in charge of the health and lives of their employees across the country.
I assume they're spending money on testing and whatever protocols they need to enforce to ensure they don't kill / incapacitate their golden legion of software engineers. And when you're making that much money, it becomes much easier to (for example) have someone else do your grocery shopping.
If it's anything like my experience and anecdotal experiences from my friends, then they're just giving you the illusion of safety and not actually providing a safe working space.
It's expensive to actually implement useful COVID measures (but not impossible and not necessarily illusory), but if you already have such huge employee expenses and are serious about in person work, I can't imagine you wouldn't spend the money and put the work in.
I agree with you that shops with less luxurious budgets would have a difficult time doing anything that meaningfully reduces the risk to their employees and should probably stay home.
I'm guessing it's less the quality of the code they produce and more the quantity. Their rockstar programmers can work 10x more efficiently than other programmers, thus the CEO can hire 10x fewer programmers.
So instead of paying $260k per year for 10 engineers (2.6M), they might pay 451k for 3 "10x" engineers (1.3M). Costs are 50% lower overall, and if the engineers are even 2x more productive than the average you "break even".
Smaller staff means you need fewer managers.
I'm not saying this is actually how it works in real life (can a developer really be 10x more productive? who know). This is just their operating theory.
Source: https://www.levels.fyi/?compare=Netflix,Google,Facebook,Micr...
https://variety.com/2020/digital/news/netflix-degrading-hd-v...
Even if they are bandwidth constrained, I wouldn't be surprised if some shows looked better at 480i/.5Mbps than 1080p/.5Mbps.
How does that even work? The fastest system RAM you can get that I know of is DDR4-5000, which transfers at 40 GB/s (320 Gb/s). How can you encrypt and send data faster than your memory can even transfer it to the CPU? Or is there something I'm misunderstanding?