Earlier quoted context omitted.
That’s a pretty defeatist attitude
That's a funny way of spelling "realistic". These companies want The Right Stuff, and it's easy to tell if you yourself aren't it.
Compare career levels across companies
401–410 of 428 posts
Re: Compare career levels across companies
#402Earlier quoted context omitted.
Keep in mind that new hire salaries at the same level are typically higher than folks internally who have been at that level for some time. The market rate has actually gone up significantly in last 1-2 years.
I have 16 years of engineering experience and Google has made me two offers (original and revised) for a T4 position in NY that are well below the numbers reported on Levels (in fact, below the average on the site). So, either I am getting low balled like hell or there is skew in the numbers. Edit: there is skew in the numbers, not some in the numbers.
Re: Compare career levels across companies
#403Huge fan of this site, for two reasons: - It lets “outsiders” to the tech scene understand salary and levels at big companies. If you went to MIT you probably already have frat brothers/sorority sisters or an alumni network that consists of senior engineers at these big companies that know the promotion and compensation schemes well. But if you were an equally smart student who went to a non target school, many of th…
> 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 envir…
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.
Re: Compare career levels across companies
#404Earlier quoted context omitted.
Besides, DMA isn’t really a “hard” problem as far as I am aware...
https://baus.net/you-cant-impress-developers/
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?
Re: Compare career levels across companies
#405Earlier quoted context omitted.
https://baus.net/you-cant-impress-developers/
Oh, so now we need to feign being impressed so no one gets their feelings hurt? 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?
Re: Compare career levels across companies
#406Earlier quoted context omitted.
Oh, so now we need to feign being impressed so no one gets their feelings hurt? 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?
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-L…
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?
Re: Compare career levels across companies
#407Earlier quoted context omitted.
I was at the IBM LTC from 2001--2009 as an STSM, and my understanding was that DE's could absolutely get promoted to Fellows. So assuming that Fellows are "just" the highest rank of the research rank is not really accurate. Perhaps that's what you mean by "diluting the merit of the title", but that sounds like you're coming from the Research side of IBM. :-) Yes, it's rare for a DE to get promoted to be a Fellow, but…
You may be right about the DE -> Fellow promotion, although I only heard of it once, and that person was pretty spectacular. The Fellow -> DE path is unheard of. As is the RSM -> DE. All the DEs I know came from SWG and were STSM. Re: my “dilution” comment, i was not thinking about DEs. I was thinking about non-technical people (management, law, accounting, ...) that have been creeping up the Fellowship lately. Also…
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:
Re: Compare career levels across companies
#408Earlier quoted context omitted.
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-L…
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…
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.
Re: Compare career levels across companies
#409Earlier quoted context omitted.
I suspect Glassdoor mostly gets money from employers so it reflects what they like to see =)
Spot on. Glassdoor is paid by companies so it's not surprising it became very biased towards low salaries.
Re: Compare career levels across companies
#410Earlier quoted context omitted.
The front-end interviews at Google are about half algorithms and half details about how web front-ends should work, be structured, web technology problems, browser performance, etc. It's an entirely different interview track from General SWE.
How hard is it to ask them to switch me to something more backend? Is it impossible unless I know Another one of their languages?
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.