I disagree, if you had the work ethic, you could study for a year on leetcode.com, and have a hell of a good chance at landing a FAANG job.
Just practice those types of problems, apply to a bunch of different companies, do the phone screens, get rejected, practice some more, get through the phone screens to the onsite, get rejected, repeat until you get an offer.
Don't these companies need you to be early 20s, have similar hobbies/culture to the hiring company, and live nearby already? I find it hard to believe they'd look at an applicant who doesn't fit the standard criteria. Why bother with someone who doesn't fit the mold when there's 10,000 applicants per month who do?
Why? One "sysadmin" who can write software can manage far more machines than one who can't. Source: started my career as a Solaris Sysadmin with a CS degree.
Well, like I said, the entire subject deserves a good gothrough, but I'll try to be terse and summarize:
For one, because many sysadmins don't have the proper CS background to "program" well. We get shit done, mostly in bash/perl/python, (these days maybe in go, etc), but devs who read sysadmin code tend to gasp and sigh a lot.
Two, being a sysadmin is more than just admining the machines. A senior has to be just as comfortable in a suit in a meeting with the C-suite, writing reports, doing BCPs etc, as they are terminating cable.
Three, coding is useless if you don't know how to fix issues, or diagnose them in order to know what the issue is that needs fixing in the first place.
Four, this push to sysadmins must code seems to largely be a filter-bubble effect of companies that are software focused. Thousands of sysadmins across the world are supporting companies that don't even have a dev team, so the whole "sysadmin is dying, devops is the future" angle is naive imho.
Five, does writing config files in something like ansible yaml or hashicorp config language really count as coding? Because ok then I'm down with all sysadmins must code. But far too often I've seen some poor sysadmin tossed a mess of python and told to fix it... and then when they struggle they hear heaps of criticism. Don't even get me started on all the huge perl messes from "sysadmins who coded" I've had to clean up...
Do you see the general gist of where I am going on this? Did you evolve into a software engineer, or did you move up to more managerial position of senior or CTO/CIO? One thing to keep in mind is that many companies don't have a CTO or CIO, and sometimes don't even have IT department heads other than a senior sysadmin. Much of the pain points we are talking about are probably different in different company cultures, and are more situation specific. What I've found is that managers tend to think that if their sysadmin can code that means their sysadmin is a dev, and they can save money by having them fill both roles, and that almost never turns out well for anyone.
It's basically understood at this point that tech salaries are going to be orders of magnitude lower outside of the US, no matter the company, country, or cost of living or economic health of the country.
I absolutely agree that it's useful to have this information in general, especially so if you work at one of those companies.
However, I wanted to point out that having a big set of apples to compare to when you're looking through oranges isn't useful, and can be harmful, mentally speaking. I think it's a net positive, I just wanted to point out how it can be hard for some of us. Seeing numbers like those make me really wonder what I can do to get myself in that position, but most people (especially on somewhere like Blind) act like that is a trivial thing to accomplish.
I'd also love to see what performance is expected at what levels, and what gets you promoted to other levels. It is of course very possible to be performing the job several levels above where you are, and not get promoted there because you are in one of those underrepresented groups, or bureaucracy, or any number of any other causes.
When I last worked at companies large enough for that sort of thing to matter, the levels were actually the important part. Your boss would typically say he couldn't promote or give you a raise above a single digit percent, even though your work was amazing, because of levels and salary bands and slots he had open and so on. That was your queue to go work across the street for a couple years at the higher level, and then switch back to the original company at a much higher level. It was basically the only way to advance and increase your salary.
And you'd never know if it you didn't realize you were outperforming your level. It's also the easiest way to take advantage of an underrepresented person (keeping them at a low level, versus underpaying them within a level)
I'm curious, how often do post-IPO companies give options versus RSUs? I am used to thinking all public companies issue RSUs, but the last one I worked at didn't. My strike was at a relatively brief high point, and the value declined to about 2/3s of that before the company got acquired, but obviously those options were worthless - they wouldn't have been if they were RSUs.
I agree with what you've written, and the phrasing I used was unclear. I was mainly making a note about joining a mid to late stage pre-IPO startup (series B or later) vs joining a large, low growth public company. You can't easily invest in most pre-IPO companies today (though with secondary markets growing in popularity this might change in 5 years). In the case of choosing between two large public companies, sure, take the cash & liquidate your positions as soon as you vest so you can stick them in SPY or vanguard.
As for 1) I literally meant pre-IPO. Companies that are not publicly traded. Even very very large ones(e.g. Uber) tend to issue options instead of RSUs. When you get hired, the value of those options is a big 0 - that's where they set the strike price. You can't really compare options to RSUs. You can't assume the stock will go up 50% in value or anything in particular. So they are hard to value as anything other than 0 (I'd love to hear other ways you think about it)
Transparency is good. I'm not exactly against this information. I mostly wish it were available in a way that applies to the rest of us.
Also, I wish it didn't make me feel bad. Call it mindset but salary discussions tend to.
I worry if I'm missing out on the opportunity to get into a Tier-1 company while I'm busy going on my own. The chance of a $5-10M exit is slimmer than the chance of getting into a Tier-1 company.
- Allow me to select more than three companies on the homepage. Or if that's not possible, let me toggle a specific one in and out. Right now I try to keep my current company on the screen, but as toggling a new company in drops an old one (seemingly lifo) it's a bit of a juggle
- On comp.html the tooltip over the graphs only shows 2/3 of the values. So I can see:
* Base salary + Total
* Base salary + Stock
* Stock + Bonus
but not all 4 at the same time. It'd be a lot more useful if I could.
Google grants RSUs. So $60k is 12 RSUs for someone hired in 2014.
In 2018, RSUs are worth twice as much as 2014, so people hired for the same role in 2018 get 6 RSUs ($60k) while the people hired in 2014 are still getting [at least] 12 RSUs ($120k).
This is what I'm talking about with regards to stat inflation on this reporting.
Typically, the recruiter asks me to do a simple challenge in e.g. a google doc. I'm then strongly pressured to do it in one of their preferred languages, or if I do it in Ruby, I have to explain all of the syntax and it takes a lot of time and mental focus away from the actual task.
For instance, in a recent interview, I couldn't remember the substr() function in Javascript, which Google insisted I do the challenge in. Instead I wound up using the ruby [range] operator and explaining ranges and what that operator meant.
To Google's credit and my moderate surprise, I passed that round of the interview. But I have definitely had interviews where the result is a mash of languages that nobody can really understand. Or they let me do it in ruby and I have to explain every line of the syntax (for instance, how ruby does iteration).
There have also definitely been times where they flat out told me that they want a specific language and I should contact them again when I've gotten skill in it.
Alternately, if languages don't match, they'll focus the interview on a skill that they need for whatever position, but for which I only have limited expertise. Take SQL. I know what indexes are, I can open a console to identify long running queries, but I mostly work with it through an ORM. But if they hear I have some SQL experience they'll decide to grill me on details of how Postgres handles things like logging and persistence and maintaining multiple versions of rows in memory and what are tuples and so on.
I'm not a DBA and will do only mediocre in such interviews. I always mix up the different types of joins, because I hardly ever write join queries and usually look it up when I need it.
I'm fairly certain they'd have given me Java questions if I knew Java, but the thing I had experience in that the recruiter knew was SQL.
Hmm, I hadn't thought of it like that. Maybe you can indeed steer it for the better, but as long as the profit model is ethically questionable, I'm not sure about the good vs. bad impact of one's contribution.
In my experience, if you think that implementing from scratch a DMA solution is not hard, then you are an extraordinary talented engineer, far above the level you find at FAANG, so your opinion on this matter is not terribly relevant. It would be as if Jeff Dean came and said writing MapReduce is not a hard task. Nice, but not relevant for the 99.9999% of the talent pool.
I got a couple offers over the years for L5-L6 positions at FAANG (specifically Google and Facebook) to work on low level stuff, including system programming and kernel development, since I have a few dozens upstream Linux kernel contributions in some subsystems I dabbled with.
I also had to deal with writing a video4linux custom driver for an embedded industrial machine and a very custom acquisition card using DMA in the past, and it was significantly difficult even to just make it work playing with the well-defined kernel DMA APIs. I can easily see how the complexity required to write the entire kernel plumbing framework that makes DMA possible to leverage for normal developers like me would be a hard engineering task, definitely one that deserves an L7 architect/engineer capable of coming up with the right level of abstractions, incredibly important for a C kernel API. Just because one can explain on a whiteboard what DMA is and how it is supposed to work by remembering the OS college class (I'm not saying that's you), it doesn't make it an easy engineering task, engineering it's about making things work. I'm sure if you go back to the LKML mailing list and look at the time period where DMA support was initially introduced in the kernel, you'll be surprised at the sheer engineering complexity that was discussed when introducing such core kernel feature.
In conclusion, the fact that FB and GOOG wanted to hire me to work on stuff relatively close to what we're talking about, at a level that is considered senior, gives me some legitimacy to say that me thinking it's a hard problem isn't probably too far from the truth, otherwise we are somehow assuming that FAANG extends offers to incompetent people (multiple times), mistakenly considering them senior engineers.
I take your original comment as naive as the people who say "I could have built Instagram/Whatsapp tech in a week!", because you either are a super expert, or you simply don’t know what you’re talking about.
Perhaps you should consider getting an offer for $1M/y (or more! Since L7 tasks are easy for you maybe you can shoot for an L9 and ask $2M/y, I have a close friend at GOOG at that level who gets paid that much) there then, if you're not already in that elite band of compensation?
Perhaps we’ve understood the original comment differently.
I took it to mean writing a driver that uses an existing DMA API to talk to a controller.
But yes, I agree: implementing such a DMA interface from scratch — even with an existing controller — is not a trivial problem. Testing and verifying said implementation would also be difficult.
Well, I hope that one day I can make 1M/yr! For now, 3 months into my first job, I’m fairly satisfied with where I’m at :)
I’m considering shifting into kernel development next. Given your experience, would you advise going down that career route? Any tips for a career in low-level development?
In my opinion (which is not shared by many these days) understanding things at a reasonably low level is critical, I firmly believe that makes you a better programmer, even if you end up doing frontend development.
My experience with the kernel has always been mostly tangential, typically a byproduct of what I do day to day, which is working at a SaaS startup at scale and wearing many hats, from backend development (Java/C++) to infrastructure management. As I find performance problems, many times I find myself digging into the kernel code and exploring parts of the networking stack (e.g. finding out the specific behavior of a socket option), virtual memory management (e.g. finding out some quirks about the page fault management system), ...
Sometimes that leads to some small kernel patches and I've done several during the years, so that's typically my limit. The v4l driver I mentioned above was 6-7 years ago when I was in college and took a part time job working on that with a very talented team.
Apparently FAANG likes those kind of background, especially if you can get into a more SRE-type role where they are actually not looking to quiz you only on dynamic programming algorithms, but also on your ability to reason with system design, low level systems and performance, at least that's my experience.
While that's true, experienced offers are influenced by tons of factors (and arent, as a rule, better than current employee offers ). There's not really enough data to draw any conclusion.
> a lot of the leveling data is subjective AFAICT and not based on cross company moves
eh? the leveling data is local to each company. within each company, of course it's subjective because ladder criteria are subjective. but AFAICT it's accurate. in general "senior" is 5 years at any company. senior means you have a 4 year degree and adequate work experience to have applied your book learning to a professional environment and so you are now adept at basic skills, advanced and current platform/framework/library/environment knowledge, know how to use many modern toolsets, have delivered software that has made it to the maintenance and maybe replacement part of the lifecycle. beyond that, some companies have more grades and some have fewer which represent larger org structures and so more people and bigger deployments, and more money.
> comp info seems a bit skewed for some companies and more senior roles
No, it's not. They explicitly try to match up levels across companies. You can see this in action if you go to the page for submitting leveling data for a company: https://www.levels.fyi/create.html.
i assume you don't actually know anyone at FAANG. There are plenty, believe me plenty, of average people. Of course there are superstars, and superstars gravitate there for the high pay as well as the chance to work with and learn from other superstars. but when you employ this many people, you also bring along many, many average joes.
Well I had the privilege of working with Paul McKenney who invented (and patented) Read-Copy-Update (RCU). He came to IBM as part of the Sequent acquisition, and was part of the Linux Technology Center, which was in the Systems and Technology group.
If you take a look at some of IBM's press releases, you'll see there are plenty of Fellows that come from the SWG and STG, and not just Research. For example:
Tell the recruiter you're a backend developer, and are interested in one of those positions instead.
The backend interview lets you choose whatever language you want. You'll be asked algorithms, distributed design, code quality, and data-structure questions.
Generally speaking, if you focus too much on a programming language / stack, it comes off as a sign that you're not a good fit, since you emphasize programmer skills, but they're looking for engineers. Except for particular roles, like front-end dev, where they're looking for programmers with experience in the technology stack itself.
52 comments
[ 3.7 ms ] story [ 118 ms ] threadJust practice those types of problems, apply to a bunch of different companies, do the phone screens, get rejected, practice some more, get through the phone screens to the onsite, get rejected, repeat until you get an offer.
For one, because many sysadmins don't have the proper CS background to "program" well. We get shit done, mostly in bash/perl/python, (these days maybe in go, etc), but devs who read sysadmin code tend to gasp and sigh a lot.
Two, being a sysadmin is more than just admining the machines. A senior has to be just as comfortable in a suit in a meeting with the C-suite, writing reports, doing BCPs etc, as they are terminating cable.
Three, coding is useless if you don't know how to fix issues, or diagnose them in order to know what the issue is that needs fixing in the first place.
Four, this push to sysadmins must code seems to largely be a filter-bubble effect of companies that are software focused. Thousands of sysadmins across the world are supporting companies that don't even have a dev team, so the whole "sysadmin is dying, devops is the future" angle is naive imho.
Five, does writing config files in something like ansible yaml or hashicorp config language really count as coding? Because ok then I'm down with all sysadmins must code. But far too often I've seen some poor sysadmin tossed a mess of python and told to fix it... and then when they struggle they hear heaps of criticism. Don't even get me started on all the huge perl messes from "sysadmins who coded" I've had to clean up...
Do you see the general gist of where I am going on this? Did you evolve into a software engineer, or did you move up to more managerial position of senior or CTO/CIO? One thing to keep in mind is that many companies don't have a CTO or CIO, and sometimes don't even have IT department heads other than a senior sysadmin. Much of the pain points we are talking about are probably different in different company cultures, and are more situation specific. What I've found is that managers tend to think that if their sysadmin can code that means their sysadmin is a dev, and they can save money by having them fill both roles, and that almost never turns out well for anyone.
However, I wanted to point out that having a big set of apples to compare to when you're looking through oranges isn't useful, and can be harmful, mentally speaking. I think it's a net positive, I just wanted to point out how it can be hard for some of us. Seeing numbers like those make me really wonder what I can do to get myself in that position, but most people (especially on somewhere like Blind) act like that is a trivial thing to accomplish.
I'd also love to see what performance is expected at what levels, and what gets you promoted to other levels. It is of course very possible to be performing the job several levels above where you are, and not get promoted there because you are in one of those underrepresented groups, or bureaucracy, or any number of any other causes.
When I last worked at companies large enough for that sort of thing to matter, the levels were actually the important part. Your boss would typically say he couldn't promote or give you a raise above a single digit percent, even though your work was amazing, because of levels and salary bands and slots he had open and so on. That was your queue to go work across the street for a couple years at the higher level, and then switch back to the original company at a much higher level. It was basically the only way to advance and increase your salary.
And you'd never know if it you didn't realize you were outperforming your level. It's also the easiest way to take advantage of an underrepresented person (keeping them at a low level, versus underpaying them within a level)
Transparency is good. I'm not exactly against this information. I mostly wish it were available in a way that applies to the rest of us.
Also, I wish it didn't make me feel bad. Call it mindset but salary discussions tend to.
- Allow me to select more than three companies on the homepage. Or if that's not possible, let me toggle a specific one in and out. Right now I try to keep my current company on the screen, but as toggling a new company in drops an old one (seemingly lifo) it's a bit of a juggle - On comp.html the tooltip over the graphs only shows 2/3 of the values. So I can see: * Base salary + Total * Base salary + Stock * Stock + Bonus but not all 4 at the same time. It'd be a lot more useful if I could.
In 2018, RSUs are worth twice as much as 2014, so people hired for the same role in 2018 get 6 RSUs ($60k) while the people hired in 2014 are still getting [at least] 12 RSUs ($120k).
This is what I'm talking about with regards to stat inflation on this reporting.
For instance, in a recent interview, I couldn't remember the substr() function in Javascript, which Google insisted I do the challenge in. Instead I wound up using the ruby [range] operator and explaining ranges and what that operator meant.
To Google's credit and my moderate surprise, I passed that round of the interview. But I have definitely had interviews where the result is a mash of languages that nobody can really understand. Or they let me do it in ruby and I have to explain every line of the syntax (for instance, how ruby does iteration).
There have also definitely been times where they flat out told me that they want a specific language and I should contact them again when I've gotten skill in it.
Alternately, if languages don't match, they'll focus the interview on a skill that they need for whatever position, but for which I only have limited expertise. Take SQL. I know what indexes are, I can open a console to identify long running queries, but I mostly work with it through an ORM. But if they hear I have some SQL experience they'll decide to grill me on details of how Postgres handles things like logging and persistence and maintaining multiple versions of rows in memory and what are tuples and so on.
I'm not a DBA and will do only mediocre in such interviews. I always mix up the different types of joins, because I hardly ever write join queries and usually look it up when I need it.
I'm fairly certain they'd have given me Java questions if I knew Java, but the thing I had experience in that the recruiter knew was SQL.
Tough decision indeed.
The fact of the matter is, were DMA indeed a hard problem, I would not have posted the comment.
So instead of posting a link to a blog post, perhaps you could try to disprove my claim?
I got a couple offers over the years for L5-L6 positions at FAANG (specifically Google and Facebook) to work on low level stuff, including system programming and kernel development, since I have a few dozens upstream Linux kernel contributions in some subsystems I dabbled with.
I also had to deal with writing a video4linux custom driver for an embedded industrial machine and a very custom acquisition card using DMA in the past, and it was significantly difficult even to just make it work playing with the well-defined kernel DMA APIs. I can easily see how the complexity required to write the entire kernel plumbing framework that makes DMA possible to leverage for normal developers like me would be a hard engineering task, definitely one that deserves an L7 architect/engineer capable of coming up with the right level of abstractions, incredibly important for a C kernel API. Just because one can explain on a whiteboard what DMA is and how it is supposed to work by remembering the OS college class (I'm not saying that's you), it doesn't make it an easy engineering task, engineering it's about making things work. I'm sure if you go back to the LKML mailing list and look at the time period where DMA support was initially introduced in the kernel, you'll be surprised at the sheer engineering complexity that was discussed when introducing such core kernel feature.
In conclusion, the fact that FB and GOOG wanted to hire me to work on stuff relatively close to what we're talking about, at a level that is considered senior, gives me some legitimacy to say that me thinking it's a hard problem isn't probably too far from the truth, otherwise we are somehow assuming that FAANG extends offers to incompetent people (multiple times), mistakenly considering them senior engineers.
I take your original comment as naive as the people who say "I could have built Instagram/Whatsapp tech in a week!", because you either are a super expert, or you simply don’t know what you’re talking about.
Perhaps you should consider getting an offer for $1M/y (or more! Since L7 tasks are easy for you maybe you can shoot for an L9 and ask $2M/y, I have a close friend at GOOG at that level who gets paid that much) there then, if you're not already in that elite band of compensation?
I took it to mean writing a driver that uses an existing DMA API to talk to a controller.
But yes, I agree: implementing such a DMA interface from scratch — even with an existing controller — is not a trivial problem. Testing and verifying said implementation would also be difficult.
Well, I hope that one day I can make 1M/yr! For now, 3 months into my first job, I’m fairly satisfied with where I’m at :)
I’m considering shifting into kernel development next. Given your experience, would you advise going down that career route? Any tips for a career in low-level development?
My experience with the kernel has always been mostly tangential, typically a byproduct of what I do day to day, which is working at a SaaS startup at scale and wearing many hats, from backend development (Java/C++) to infrastructure management. As I find performance problems, many times I find myself digging into the kernel code and exploring parts of the networking stack (e.g. finding out the specific behavior of a socket option), virtual memory management (e.g. finding out some quirks about the page fault management system), ...
Sometimes that leads to some small kernel patches and I've done several during the years, so that's typically my limit. The v4l driver I mentioned above was 6-7 years ago when I was in college and took a part time job working on that with a very talented team.
Apparently FAANG likes those kind of background, especially if you can get into a more SRE-type role where they are actually not looking to quiz you only on dynamic programming algorithms, but also on your ability to reason with system design, low level systems and performance, at least that's my experience.
eh? the leveling data is local to each company. within each company, of course it's subjective because ladder criteria are subjective. but AFAICT it's accurate. in general "senior" is 5 years at any company. senior means you have a 4 year degree and adequate work experience to have applied your book learning to a professional environment and so you are now adept at basic skills, advanced and current platform/framework/library/environment knowledge, know how to use many modern toolsets, have delivered software that has made it to the maintenance and maybe replacement part of the lifecycle. beyond that, some companies have more grades and some have fewer which represent larger org structures and so more people and bigger deployments, and more money.
> comp info seems a bit skewed for some companies and more senior roles
what do you mean, skewed?
No, it's not. They explicitly try to match up levels across companies. You can see this in action if you go to the page for submitting leveling data for a company: https://www.levels.fyi/create.html.
huh? that's not the point. It's difficult because there are zero startups or pre-IPO companies that will pay you like this.
> if for no other reason than that options are just not something you can easily stick a dollar value on
it's very easy. dollar value of options = $0.
If you take a look at some of IBM's press releases, you'll see there are plenty of Fellows that come from the SWG and STG, and not just Research. For example:
https://www-03.ibm.com/press/us/en/pressrelease/7142.wss
The backend interview lets you choose whatever language you want. You'll be asked algorithms, distributed design, code quality, and data-structure questions.
Generally speaking, if you focus too much on a programming language / stack, it comes off as a sign that you're not a good fit, since you emphasize programmer skills, but they're looking for engineers. Except for particular roles, like front-end dev, where they're looking for programmers with experience in the technology stack itself.