Hacker News Reader

Comment by rsynnott | Hacker News Reader

It's not a good job market, but it doesn't seem normal to spend six months applying and only get _one_ interview.

It might be worth asking friends or former colleagues, ideally people who actually are involved in recruiting (hiring managers etc) to take a look at your resume and LinkedIn profile and see if there's anything glaringly wrong with them.

Is your resume in a weird format, or is it structurally weird/overdesigned? For instance, a recent trend in resumes was to show (programming) languages known in a pie chart (do not do this; it is nonsensical). In many companies, the text from your resume is going to end up in a standard format anyway; they'll have tools for this and if their tool can't extract your text they may not bother. Unless you're a graphic designer or something, you probably want a boringly-designed resume.

Are you applying jobs for which you are dramatically underqualified? One thing to keep in mind is that some small companies (if you're coming from one) have _wild_ title inflation; a small startup might call someone with 5 and a half years experience their director of frontend engineering, say, whereas everyone else would call that person a junior engineer.

Does anything particularly unfortunate come up if people Google your name? For instance, a real-life version of that Seinfeld episode where Elaine's dating a guy who has the same name as a notorious local serial killer.

View on HN

Have you looked for a job recently?

I don't know about you personally, but people in my social circles and employed think the job market is the same as it was from 2015 to 2020. They have no data point and assume their 2+ year old experience of looking for work is relevant today.

The market is bad.

I was getting calls from recruiters in 2020. I looked and found work (contracts) twice in 2022, the first time was not easy, the second time was very difficult.

2023: I am available, contacts and links to resume, linkedin, etc... in my profile!

It's strange because economically, tech is roaring back and the job market is tight as ever.

Are employers hedging against this perpetually 6 month away recession? Is there a shift from growth mindset to value mindset?

For private VC tech, interest rate increases mean the next funding round will be much harder to get

There was also a concerted effort from major tech employers to depress wages to control costs. They don't need to directly talk to each other to plan it, they state it in their earnings calls.

The most economically efficient companies in my career always make it insanely hard to add head count to the team. They tease you with "might get a head count next quarter". Then frequently freeze the head count during your search. They are trying to squeeze as much as they can. I'm not saying this is a pleasant working environment, but it is very good for the bottom line. Also, it is sometimes more efficient for them to give modest pay rises to best performers off-cycle to motivate them to work even harder.

In the past, I would have also found it strange to see tech blowing up in a tight job market. After a decade on the team-building side, though, I feel different.

Interviewing and onboarding are a huge distraction. Interviewing and onboarding done well require hours of attention from the more senior folks on your team.

When a company is hiring, the senior folks involved might be spending 6 hours a week interviewing. For example, I might have 4 45-minute interviews, another 15 minutes prepping for each interview, 15 minutes writing up feedback for every interview, 30 minutes in hire/no-hire discussions for candidates who are close, and another 30 minutes in hiring or interview meta-discussions.

Onboarding takes even more time. If I'm a new hire's onboarding mentor, I'm likely spending their first couple of days close by to answer any and all questions. After that, my work is frequently interrupted for a few weeks as I help them through issues (totally legitimate issues, BTW). We'll be spending extra time pairing with the new hire during the feature development process. Code review for new hires' code takes a lot longer, too.

When you factor all that in, a hiring freeze can realistically free up 10 or more hours of experienced employees' time every week. These are some of the most productive employees on the team.

In that context, it's not especially surprising to me that giving the most productive engineers 33% more productive time would lead to rapid improvements for tech companies, in the short term anyway.

Of course, in the medium-to-long term, a company that's not hiring is building up a huge "personnel debt" that is going to come due eventually. The product improvements will lead to new business, more clients will require more support, the new business will lead to more feature requests, and some employees will move on. The company will find itself without enough personnel to make headway on their product. Then they will have a hiring blitz where they wreck everyone's productive time and the team culture. The new, bigger team will make some headway, but they will still look less productive than the team was during the hiring freeze. The business will stagnate. The company will enact a hiring freeze, or perhaps even lay off team members. And then we're back at step 1.

Perfect explanation of the problem - and if I may suggest the solution is to carve some of those experienced people off as military do into a "training role" - where experienced people rotate off projects onto R&R and then onto training - creating a mini bootcamp that also has knock on benefits of building standards, tech stacks and tooling that "we have always been meaning to build".

Someone recently pointed out that we should learn more from how militaries grow and survive over the years - this is probably the biggest lesson.

It is pretty funny. During Covid I heard all sorts of doom about inflation and the economy, while I was chugging along great.

Now, no one will shut up about how there are so many jobs and how the economy is doing great, but I’m fucked.

We're into the next election cycle and PACs on both sides are engaged in viral marketing. You can no longer trust that any news is sincere and hasn't been sourced from people with a political agenda.

From my experience in two small-medium businesses - they're both running leaner than possible. I figured both were trying to sell, maybe they are?, but neither has.

By leaner than possible, I mean, things are running unmaintained, and it's only a matter of time before some of it starts crashing down.

What does it mean? I don't know. They're either going to have to hire, get bought out, or close up shop. I'm -hoping- it leads to more hiring in q4 or q1/24.

Yeah its tough. But something like 3 interviews a month (and tough to pass) is more what I’ve seen. With less experience. 1 in 6 months could be bad luck but Id wager he just isn’t applying to enough places.

He and I both, apparently!

Yes, the market is pretty bad right now, and Indeed's data shows it quite well: https://www.hiringlab.org/data (go to Sectors and choose Software Development)

We are currently at -64% from the 2022 peak job market and even -20% compared to pre-covid number of job openings.

Love it when people share a point with data. Thanks!

I am likely not revealing anything new to you (nor I know much about hiring), but:

Taking a look at your CV, I notice that you have a lot of very short work stints, averaging at about a position per year.

This is probably just the nature of contracting, but I can see this putting off most companies that are looking for someone to dive deeply in the business domain and work on supporting a project long-term.

I also feel a lot of those "we need someone with experience on X technology to onboard us or fix some urgent problem" jobs are on a downtrend, given the rise of XaaS solutions, convergence of development stacks, more documentation, stuff like ChatGPT, etc.

Thank you for taking the time to look at it and commenting.

It is indeed the nature of contracting and project work. Note that there are 3 times where I have done contracts back to back for 4 or 5 years for the same company, which should show that I don't just jump ship all the time and am able to commit for a long time.

It made more sense to highlight each project individually in an economy with a lot of need for contractors for short stints, but point taken, I'll see if I can highlight the fact that 2, or 3, or 4 consequent contracts are for the same company. Maybe even just bold the company names.

Appreciated, I wish I could help more. There's for sure a way to highlight that you can work on long stints, as well as quickly jump into diverse projects across the full stack.

Unfortunately I can't help much on it, as on my short career I always chained jobs on the good times and never had to work much on my CV or marketing myself.

Best of luck.

I reviewed your CV as well. I am a former programmer/analyst/architect, now an IT director. I have reviewed a lot of CVs as a hiring manager. I agree with the feedback you have already received. Here are some additional thoughts.

You have listed a lot of experience, mainly focusing on technical skills. When I review a CV I focus more on the last 5 or 10 years than roles from 30 years ago (unless I'm looking for someone to do COBOL maintenance). I suggest providing more information about experience in the last 5 or 10 years. I wouldn't worry too much about listing specific projects/assignments before that.

Your CV emphasizes your technical skills, but doesn't provide much insight into other skills. Perhaps for some of your recent projects you could highlight other ways in which you contributed to a successful outcome. Were you the lead developer? Did you interact with users - maybe in an agile process? What aspects of the software development life cycle were you responsible for?

So, based on your current CV, I might suggest a some entries like these:

Subtlety Communications, April 2022 - December 2022

- Vulnerability Mitigation Project

  Lead developer responsible for analyzing vulnerability reports, identifying appropriate mitigation, implementing and testing mitigation. Reported to CISO.  Javascript, React.

- Live Chat Application

  Senior member of agile application development team responsible for front-end development. Automated generation of Docker config files to improve CI/CD processes. Docker, Typescript, React.

Thank you.

Formatting it with the company as the top-level item would make clear at a glance that you’ve been at places for a lot longer.

> I have done contracts back to back for 4 or 5 years for the same company, which should show that I don't just jump ship all the time and am able to commit for a long time.

The harsh reality is right now, there are a lot of applicants were for many recent years hiring meant active recruiting so resumes aren't getting the attention that they once did. People aren't going deep dive your history unless you seem like the perfect candidate.

So short stints even mixed with a few long stints aren't going to balance out as you are suggesting in many situations.

What I can recommend to try and soften this, is be more generic, don't list ever single job, but something along the lines of "Various contract based projects from yyyy to yyyy" and bullet point detail the more juicier bits of the contacts.

but admittedly I base this solely on my own experience, so take it with a grain of salt.

What stands out to me is short work stints. You don’t tell a good story and why do you have your work experience dating back to the 80s?

I personally have been working professionally since the mid 90s. But I realize that no one cares about the fact that I did C on DEC VAX and Stratus VOS mainframes in the 90s, VB6 in the early 2000s along with C, C++/MFC/DCOM or C# for ruggedized Windows mobile devices in the late 200x. I’ve cut out everything on my resume before 2012.

Your resume is full of responsibilities. But not accomplishments. If I were to ask you why should I hire you over the dozens of other generic developers who run across my desk, what about your career sets you apart? I’m being completely hypothetical. I’m not in a hiring position and I’ve only been in one for a brief stint in my career. But put yourself in hiring manager’s shoes. Why would you hire you?

I’m not sitting on high judging you by any means. I’ve had a fairly unremarkable career myself until 2018 and nothing that really stood out.

> why do you have your work experience dating back to the 80s?

I kind of disagree. It’s not like people are printing out or even reading back that far. May as well include it, but certainly don’t expect people to read it.

I’m currently hiring and reading a lot of resumes. I rarely read past the first 2-3 pages, but sometime when I’m curious go back to learn more about career path. Has someone been programming for 30 years? Or started as a dba or a support tech?

I think it depends on the risk of including it. If you worked for an embarrassing employer or maybe don’t want people to guess your age, remove old stuff. But otherwise, I suggest just spending more effort on making the first page relevant.

I'm not an expert but your implicit premise that it's OK for a cv or resume to have multiple pages surprises me.

One page! Put the most recent relevant stuff on one page and send that. I don't agree with the idea that it's OK to include more info because people don't have to read it. They do have to read it because it might contain a red flag.

Every word you type is making work for someone, and if it's not then why write it?

With digital files, I don’t think it makes more work. Different people want different things and it’s hard to know who will be reading.

For my resume, I add on new items after each position or paper or new thing or whatever. So I’m just adding on new sections every few years. If I was starting fresh I probably wouldn’t write pages and pages.

I agree that the first page should contain all essential information. But as for the extra pages, people only read if they have some reason.

The issue what that is I have no idea what his focus is and how does it help you determine whether I would be a good hire for your company to know I did C (and FORTRAN) in the 90s?

I would like to know if you did C or FORTRAN in the 90s because it’s different than if you were building houses.

Someone who has been programming for 25 years, starting in the trenches is different from someone who changes careers in the 00s and learns programming.

And I prefer some context to know what someone means as if it was just a line for “FooCorp 1995-2000, Programmer” does that mean FORTRAN or excel macros?

How I designed systems in the early 2000s when procuring hardware had large up front costs including building an on prem server room with raised floors and non water fire suppression systems is different from how I design systems now when I can create my entire server infrastructure by using a text editor and creating a yaml file.

The considerations I take about scalability, RTO vs RPO and my entire system design and process decisions change when I have unlimited capacity and the ability to scale to zero.

My experience programming in 65C02 assembly in the 80a doesn’t make me a better developer today.

For what it is worth. I disagree completely. Your programming in assembly in the 80s made you what you are today. I am actively in a hiring role, and interviewing seemingly constantly. I want the full job history. My team and I read the complete resume.

5 years for junior for better or worse is well out of step with the industry - while you're right that you can get some massively inflated titles that are out of step with the norm, the norm is that you're an intermediate developer at a minimum and most likely a senior after 5 years.

It's dumb, but it is the standard nowadays.

Intermediate/mid for sure, but if I get a resume from someone whose first programming job was 2018 and they're calling themselves senior, I'm throwing that in the trash unless like you said they're from VC-funded startups that are going to have massive title inflation and they're applying for a realistic (mid-level) role.

Sure, I guess my point is to consider the context of the person applying. If they are coming from a place with title inflation, it's not their fault that the company they worked for inflated titles. If you're exclusively hiring seniors and they are an inflated "senior", for sure you're under no obligation to hire them, but if you're open to intermediates, I think it's worth explaining how your titles might differ from their experiences and that intermediate is a better fit.

Anyone tossing resumes because of title/time spent not matching up with their expectations is out of touch

It wouldn't be unusual to be an E5 at Facebook (err, sorry, "Meta") after 5 years, which is considered "senior" level. The point I'm making is that this title inflation has happened more broadly than just at VC-funded startups.

I was hired at L5 at Meta in 2011, they’ve done a pretty good job at keeping the bar high but it’s mathematically impossible for it to stay at 2011 levels on multi order of magnitude growth.

Back when I was even bothering in Jan/Feb it was me and 20 other L8s interviewing for the same L6 opening. It’s a coin toss at that point.

Price discovery is not functioning at the moment, there are plenty of theories why.

But high-end tech hiring is a slot machine and will be until monetary policy lets the bond market stabilize a bit.

Your comment is almost completely incomprehensible to me, as someone that doesn't work in the Meta context...

I take it being an L5 is a good thing? but just six months ago you were an L8, and competition to become an L6 was a coin toss? No idea what 'price discovery' could mean in this situation, other than a fairly weird way to say 'salary range'? And any of this having to do with 'the bond market' is just baffling!

The reason I bring it up is that I'm genuinely curious what life is like in other corners of the tech world. Any way you could translate the above into non-Meta terms?

I worked at Facebook for 4 years and also don't understand that comment. I think it's just worded confusingly.

> I worked at Facebook for 4 years and also don't understand that comment.

I have never worked for FB and I thought it was fine. None of that is FB-specific.

> I take it being an L5 is a good thing?

It's implied lower numbers are better.

>> it was me and 20 other L8s interviewing for the same L6 opening

> but just six months ago you were an L8, and competition to become an L6 was a coin toss?

Yes, due to the number of people competing for the same position.

> No idea what 'price discovery' could mean in this situation, other than a fairly weird way to say 'salary range'?

Salary range implies stability. eg What a company is willing to pay for what positions. There has been a lack of standardization in talent across tech and instability in compensation. Another way to think of it is an increased risk tolerance in wages. This has been fueled by leniency in promotion/raises/hiring when profits were higher.

> And any of this having to do with 'the bond market' is just baffling!

Monetary policy (around interest rates) is directly related to profit margins and hiring. Suffice to say, this is common knowledge for anyone who owns property (beyond a car, maybe) or tracks the job market.

Can you further elaborate on why monetary policy is directly related to profit margins? My understanding is that monetary policy / interest rates is controlled by the FED. When they raise rates then money is more expensive, therefore profit margins shrink, and the hiring bar has to increase.

I addressed at least part of this question downthread: https://news.ycombinator.com/item?id=36914919.

I was 35 years old before I had the faintest idea how money works, like even a little.

And the only way I learned even a little is because I lived in NYC for a bit and ended up hanging with a bunch of Street cats after work, who laugh their asses off about how clueless we all are (in that moment personified by yours truly).

But you get a few G&Ts into them and they’re pretty happy to teach you Econ 101.

Incredible, thank you for taking the time to knowledge share!

https://www.levels.fyi/?compare=Facebook,Amazon,Google&track... says higher numbers are better (more senior, more highly paid) at Facebook, so maybe the GGP post is talking about working at Meta, leaving, and then coming back to apply for a less senior role than they'd had previously? It confused me.

Much obliged, you answered that better than I could have.

Ah one minor critique, you didn’t tell them about the last time the same office that goes after terrorism and money laundering and stuff took time out of their day and busted all these same firms for wage fixing in the ancient days of just over ten years ago in federal court.

That’s at least tangentially germane. :)

You may have thought you understood it, but you don’t. Lower numbers in engineering levels are not better. That’s why the original post was confusing.

That is a minor nitpick that misses the point about a deeply insightful observation around bond markets and macro outcomes.

I thought it was too minor to even note.

Cool, I was in PA in 2011, MPK 2012-2017, and FBNY 2017-2018?

Did we cross paths at all?

I was on Ads for ages, Sigma for like a year, and IG ranking Ml for like 2-ish.

What did you work on? You should pop in the Ex-this/that groups from time to time if you havent, very cool crowd.

We overlapped in NY. But assuming your username is your real name, I don’t remember you. I worked mostly on iOS infra stuff (crash reporting, battery usage tracking, etc).

They were hired as a level 5 over a decade ago. They got promoted a bunch until they were level 8. At some point they left. Now they are trying to come back. The market is so bad that they have lowered their standards and are only applying for level 6 roles. Still a bunch of other level 8s are competing for that lower level job so the chance of them getting it is lower.

The bond market/interest rate comment is saying this is part of why the economy is bad.

Price discovery I am not that confident in the meaning. I think it means companies and candidates are having a hard time figuring out what each other are worth. So you have highly skilled people not getting the offer numbers they want because their skills are not being recognized.

L8 is a bit of a guess. I was an L7 five years ago and have been training hard since. Maybe I’m still a 7.

I think you and I are thinking similarly about price discovery. Markets get disrupted, it’s not unprecedented or anything, but in general there’s some price between zero and infinity that a person can make, and seeing that go from X to “no transaction” abruptly is less ideal than it going from X to X - Y because supply and/or demand changed.

Well behaved pricing curves are existential in a bunch of really key markets, to the point that institutions preserve those properties.

Whether one is a tech worker or a struc steel pro or a teacher, anything, it seems a weird exception to “we need differentiable pricing curves here”.

Can you further elaborate on "price discovery" and how monetary policy interfaces with the bond market? Also, curious to better understand how you interpret monetary policy and bond markets ultimately impacting high-end tech hiring in a more concrete example.

The second slash third questions are easier. In the US at least (and many other modern monetary systems) the money supply (it can be measured lots of ways, in the US a number called M2 is usually a good default) is (mostly) manipulated/guided by what are called “open market operations”. When lay people say “The Fed” they usually mean the “The Federal Open Market Committee”. Open market operations are give or take buying or selling US sovereign debt (a privileged kind of bond) to push the price up or down and therefore the yield (interest rates) down or up. Almost all interest rates are directly or indirectly indexed to US sovereign debt (Treasurys, etc.) and because of the way that money enters and leaves the system via lending activity (which is a whole topic), that “benchmark” interest rate “target” roughly increases the availability of money to say hire people or build a factory, or decreases it because too much money is chasing too little productivity (AKA inflation).

From roughly 2009-2022, the “benchmark” target was ~0, a policy position called ZIRP (Zero Interest Rate Policy). This might have made a little sense to like, avoid a depression in the 2009 housing-originated (ha!) financial crisis, but it turned out that running the economy in this super whacky way drove asset bubbles in a bunch of stuff which is an effective wealth transfer from people without serious estates to people with them. This was very popular with the sort of people who decide stuff. There’s this other whole can of worms called “easing” (QE) that arguably made the target rate negative, also a whole other topic.

For reasons that I haven’t heard a persuasive explanation for, beginning in roughly March of 2022 the FOMC started cranking this target up (selling a ton of bonds) and is still doing it, the most recent increase in the target was 2 days ago.

This is going to slow economic activity and on paper inflation, but the effects will usually be felt first and most in what are called “growth” sectors, basically stuff where the value is perceived to be largely in the future rather than the present. With a healthy hand-wave, “software” is a “growth” sector, which is why 500k tech people can be fired in 6 months and the Wall St. Journal can still keep sort of a straight face that labor markets are strong. There is a roaring demand for gig workers who don’t get dental.

This is already too long, so if you want my personal opinion on price discovery in elite software talent markets, reply to indicate it and I’ll write a mother micro-blog :)

Is following this kind of info a hobby of yours? I find it fascinating, but I can’t imagine how learning enough to have a truly informed opinion about these topics could be actually useful to me.

Eh, I mean I guess ultimately I’m just kind of a nerd.

I will say that understanding a modicum of finance (I’m certainly no RenTech quant!) is basically a prerequisite for understanding politics, sociology, war, energy, technology, pretty much everything.

One doesn’t need a ton, but being able to give or take eyeball whether the market believes e.g. Powell is kinda table stakes.

And it’s just insane this isn’t taught broadly. I learned even just my modicum mostly by improbable random chance.

I absolutely do want the follow up to price discovery in elite software talent markets. That said, if this is something better discussed over a beer I've gone ahead and sent you an email :+1:

That doesn't seem fair, and it doesn't seem like an effective filter, either. Titles vary wildly for a lot of different reasons, and you can't expect candidates to present themselves to you in your terms. You can't expect them to take your job descriptions at face value, either. If mismatched title expectations bother you, blame the industry, blame other companies, blame hiring managers, but don't blame an engineer who has only been working for five years. It's on you to explain how titles and compensation work at your company and work out what their position would be.

I wouldn't pigeonhole someone into a level based on their years of experience or previous job titles, either. Interviews can reveal some surprising things. I've worked with people with less than five years of experience who were senior-quality developers at all aspects of the job, and I've worked with people with ten years of experience who just wanted to sit in their cube and write code without making any decisions or talking to anyone except their boss. And these people aren't going to straightforwardly tell you what their position should be. The one who wants to sit in his cube with no responsibilities might tell you he's senior (and his resume might back that up) and the one who is ready for a senior position might tell you they're mid-level, because at their last job they worked with extraordinary people.

Along similar lines to what you are saying, I think one of the more general problems that I see with titles is that people do tend to gravitate around specific industries/sizes of companies, even within IT, and then tend to associate their own experience as "normal" when it comes to seniority.

I've moved a bit between different sizes and government vs startup vs mid-sized etc, and the titles vary wildly.

Some government jobs had people with 4 years experience be "senior" or even "tech leads" because they weren't paying enough so they simply promoted any bright spark that was going to last to senior roles so they could at least get a few more years out of them before they left, as HR wouldn't pay more money without them getting the a specific title.

Other place I've worked, your title was essentially a lottery system, others you were hard pressed to be a Senior without anything less than 10 years experience.

But each of those places, I encountered people with very specific ideas of exactly what a senior was, and they were convinced their own standards were the "accepted" ones.

There are definitely general guidelines for senior, associate etc, but they aren't normalised, just like you are saying.

So point is, in support of your post, you can't dismiss someone just based on the title they give themselves, as it might have been perfectly normal thing to call themselves in previous positions.

That's a great point, that VC-funded startups aren't the only sources of title inflation. Salary bands at bigger companies also fuel inflation. I worked for a startup that got acquired by a large bureaucratic company, and I ended up as a principle engineer -- along with two other engineers on my team. It was the only way to keep paying us what we had been making as senior engineers at the startup. It was a director-level title, so my boss technically had a lower title than me. When I decided to leave that company, I was looking at senior-level positions at startups, because that was the equivalent to the job I was doing as a director-level IC at BigCorp.

You really squandered that opportunity to get a VP role at a startup?

I don't have VP-level handsomeness or social skills, nor the desire to put in those hours.

Large multinational banks are particular offenders here. IIRC, the rough equivalent grade for a Big Tech(TM) senior in JP Morgan (or maybe Goldman? one of those) is VP. Staff is MD or something!

This is based off of how leveling in finance. They just reused the same levels for their SWEs

There are tons of Senior engineers from Google and Facebook (and other large companies) with only 5ish yeahs of experience.

great example of why hiring in tech is broken.

decision makers making blanket generalizations because candidates don't fit the mold they've invented in their own minds using only their personal experience as a baseline.

tech experience is wildly diverse. looking at candidates with a one size fits all approach is passing up plenty of qualified people, but everybody wants to hire like Google.

Might be better to just ignore job titles altogether and only look at descriptions of what they actually did.

Employees generally don't decide on the job titles used in their company.

I don’t even have titles on my resume. Everything is “software developer” or occasionally something slightly different if I think it’s relevant to the particular work I did there.

Any senior developer using in resume term "senior"?

Since 2005ish.

We just rebranded senior as staff+

Staff Pro Max

Actually I think its pretty rare to even have a junior title nowadays. You can claim anyone with less than 2 YOE is a junior or whatever but when jobs require you to “hit the ground running” AKA run migrations in prod and resolve things when shit hits the fan then you’re not really doing junior level work.

Of course, there are also junior level jobs by responsibility but not title.

I have to read a lot of cv's and the job title part is just some empty noise for me. Developer, engineer, programmer they're just terms that go in and out of fashion. At first they will become more and more pompous, Senior 10x-Ninja, or whatever, until they become so ridiculous that the actual capable people will call themselves humbly just a programmer.

> whereas everyone else would call that person [with 5 years experience] a junior engineer

I’ve met people with 3 years experience who I’d consider more senior than myself (8 years). Some folks just learn really fast and/or don’t do much else other than work.

Not sure time is relevant to your skills or title after about 2-3 years.

It's such an old-fashioned way to look at skills and experience.

Tbh there should be real ways to measure all this but there aren't.

If you can code by your own without handholding, are you a junior at that point anyways?

I've never really considered the ability to write the code without handholding to be the line between junior/senior. If anything that's more the line of being a competent developer with a particular toolset.

I may be a competent framer that can stud out the plans for a house, but I may not totally understand why the walls are positioned that way or how the roofline will work with the landscape to avoid water issues later. They're just different skill sets, I'd actually also expect the architect who can design the house wouldn't be particularly useful with a framing nailer.

Ive never actually liked drawing solid lines between skill levels because it is so contextual, but here's the closest I can get.

Any developer should be able to write code when it's already known what it needs to do. The next level for me is being able to write code with an eye towards testability, maintenance, and flexibility based on where you expect requirements to change later. I'd expect a senior to be able to go beyond that, starting from a set of product requirements and designing the code to work for those needs. Beyond that it starts to get really gray, and you likely lose more of the earlier coding skills, but that's where I'd be looking for someone who can help define what the product requirements even are, considering technical risks and limitations of how they might even build and host the product.

I see it like the most abstract up the ladder you get, the more senior you are.

Anyone can fix a button's css.

Not anyone can refactor big parts of a codebase into something better, or help them create from scratch in a cohesive, modular, future-proof way.

Every time I get into a new job I get a various degrees of this.

The more business-context you have, the better you can solve business requirements with tech, the better tech toolset you have available, the better choice you can make on what solution to use or not to use to such problems.

True seniority means understanding how all the system works, regardless of getting into the grunt work of each of the steps, but being able to do so and understand it at the lower level too if/when needed.

It's a hard act.

One caveat I have is that companies are generally terrible at recognizing senior+ level independent contributors (ICs). Many companies don't even have a career path defined for this.

I have worked with some of those individuals and they really are worth every bit as much as, if not more than, a systems-level thinker that enjoys mapping business needs to technical solutions.

Most large tech companies I've seen promote standout ICs to either architect or manager, assuming that the skillset and interest largely transfers. I've seen this blow up many times, it's painful to watch and I really hate it for everyone involved.

If I were hiring for my farm business, I would consider years of experience to have some relevance. Every year brings a new environment (e.g. drought, rainy, etc.) and, with the work being largely seasonal, it takes a whole year for a chance to try again. As each year brings new challenges, having another year of experience does strongly indicate that you faced a new challenge each time.

If I were hiring for my tech business, I agree that it doesn't mean a whole lot. One can experience a multitude of different environments before lunchtime. One can also do the exact same thing over and over. There is no seasonality to hold you back or push you forward.

Ultimately, what one is interested to know in questioning years of experience is how many scenarios someone has run through so that when something similar happens again you can believe, with reasonable confidence, that they will know how to react. This is quite measurable, but it can be hard for someone in tech to keep track of as there isn't a good frame of reference like in farming where you can simply remember each year.

All this tells me is you've never worked in agricw, and no other industry than tech at a professional level, because you think it's unique. It's not.

> All this tells me is you've never worked in agricw

Honestly, I don't even know what agricw is, so that is no doubt true. I've been working on farms for 30-some-odd years, though, and my farming operation has been going for 17 years now, so I speak from that background. We plant once a year, we harvest once a year, etc. so the lessons to learn only come around once a year. Thus years of experience starts to become a decent proxy for what you are really trying to measure. Indeed, that doesn't work in every industry.

I suspect it's a rather daft abbreviation of "agricultural work". Just guessing; I'd not heard of it either.

The idea that "experience" is an outdated concept would only make sense coming from an industry that really doesn't even really have "senior" people.

Having worked in multiple fields throughout my life, I deeply miss the presence of truly experienced coworkers.

For example one of the lessons of experience is that skill in the immediate task at hand is only a part of the overall engineering skillset. Experienced professionals (in any field) can often solve problems better with a tool they are unfamiliar with than less experienced professionals can in their area of expertise.

One trait of experienced devs I've seen, that I've not seen in even the sharpest but less experienced ones, is the ability to see problems that will arise down the road from miles away.

Likewise I also rarely see less experienced devs, no matter how smart and talented, see solutions outside of the main path massively reduce the complexity of the original problem. I fondly recall working in research orgs when I was much more junior, and asking a 30+ year industry vet how to solve a tricky problem only for them to, time and time again, that the best solution was to avoid the problem.

> One trait of experienced devs I've seen, that I've not seen in even the sharpest but less experienced ones, is the ability to see problems that will arise down the road from miles away.

This is called second (or third) order thinking btw.

I thought it was systems thinking?

> ...industry vet how to solve a tricky problem only for them to, time and time again, that the best solution was to avoid the problem...

This is a world-wide, ancient, phrase: If it ain't broke don't fix it.

Which derives from the universes oldest rule: Nothing is more permanent than a temporary fix.

Senior devs have internalized these two constants of the universe. I suggest you do as well, before the third rule of the universe takes hold of your life.

Third immutable rule of the universe: He who noticed it, broke it.

Junior is mostly related on the scale of responsibilities. Juniors take on tasks, middles on features, seniors are responsible for products, staff for a series of related products, and distinguished engineers are responsible for huge leaps in key core parts of the business.

Roughly speaking:

If you have a hard time contributing to starting on projects or resolving problems, AND you have a hard time contributing to finishing projects or resolving problems, you’re a junior X (where x is programmer, engineer, sysadmin, etc).

If you can contribute to starting on a project/problem but have a hard time finishing it, OR you have a hard time starting on a project/problem but can contribute to finishing it, you’re an X.

If you can contribute to starting on a project/problem, AND you can contribute to finishing a project/problem, you’re a Senior X.

Not sure the current term of art to being able to start and finish projects / solve problems and your work regularly being good and reliable, maybe Architect or something like that.

I like this heuristic! It captures several important aspects of "seniority" in a clever way.

A lot of the other comments are defining seniority in terms of years of experience or breadth of skills developed. Those are both important, but for me they don't capture how "well-rounded" you are. When I was a manager in consulting we used to distinguish between resources who had "5 years of experience" and resources who had "1 year of experience 5 times". Your years of experience need to be extending your capabilities, not just repetition of skills you have already mastered.

I think simple rules of thumb, like "5 years is a junior" or "5 years is a senior" aren't very helpful. When I'm hiring I may suggest a certain amount of experience as a requirement to indicate to candidates that I see the role as suitable for someone "entry-level" or someone further along in their career. But I'm not going to reject a candidate with good experience simply because they don't have the number of years experience I suggested. I'm going to look at what they've done.

One more thought on this topic. For me, years of experience can also be shorthand for variety of experience. Someone with 3 or even 5 years of experience is unlikely to have worked on a lot of big projects in different organizations. Someone with 15+ years of experience is more likely to have worked on a variety of big projects in different organizations. Some commenters here are probably going to tell me "5 years of experience at a start-up" is as good or better than 15 years of experience in a big corporate IT shop. Maybe. Depends on the role I'm trying to fill.

>Some folks just learn really fast and/or don’t do much else other than work.

Maybe it's just me, but I don't consider junior/senior to be defined by how "good" you are at programming. Obviously the hope is that senior > junior, but there are other, softer, skills involved with being a senior.

No matter how you define it, there's people that start working at a senior level much faster than others.

> Maybe it's just me, but I don't consider junior/senior to be defined by how "good" you are at programming.

What's your definition of senior?

Someone who's reached their last year of high school. Seriously though, senior just means you're older and have more years of experience. Make sure you help your kouhai when they're in trouble.

> What's your definition of senior?

I have already made the mistake you are about to make.

You've already invested a huge amount of time in learning something which became obsolete (like jQuery), then you got over it instead of giving up in frustration, and spent a huge amount of time learning something else (like Angular or React), and you've finally come to grips with the fact that it too will eventually become obsolete, and you'll be fine moving on to the next thing (like Svelte).

If you only know one system and think you're going to be able use it forever, then you're still a junior developer. If you're afraid to move on and learn something new, then you shouldn't be a developer at all.

(I'm not the parent commenter), but I believe a defining quality of a senior developer is someone who I can give any problem/project to in the business domain and they return with a solution in the technical domain.

Experience is absolutely relevant. You are vastly more likely to be competent at 10 years than 5 or 3 or 1. Sure, I have worked with incompetent people with more experience and I've been the "rock star" with 2 outperforming devs with 15, but there's still a strong correlation between experience and ability.

> Not sure time is relevant to your skills or title after about 2-3 years.

I cannot disagree with this more. In my own experience, I've never met anyone with less than 5 years of experience that I'd call "good". And I've worked at several places in SV, FAANG included.

The good old "They don't have 10 years experience, they have 2 years of experience 5 times"

There is the saying that to get 5 years of experience in 1 year you should work in a startup.

This isn't only about title inflation. It is in some ways true in the real sense also. Because in a small team you get exposed to everything and if things don't work, it's very obvious why and there are no excuses to hide behind. Whereas in an enterprise you could sleep behind the wheel, roam around in pointless meetings, wait for the other department blocking you, ride on your teammates merits, close 1 story per month and nobody would question.

This isn't to say there aren't great minds in big organizations, I've been in both contexts and learned tons and met absolutely fantastic colleagues and experiences in both.

I think you hit the nail on the head there. I’ve only worked in startups and consistently I’ve worked with “senior”-titled engineers who were absolutely brilliant. Typically with less than a decade of experience.

But yeah there’s definitely no cruising at the wheel when you’re in a small, fast-moving organization. In my experience it’s helped me level up very quickly.

I don't think it's about learning very fast. You learn the technology as you use it.

It's about having the brain to reason around problems efficiently.

I worked with someone who become senior & team lead after 2 years (and a really good one at that), after having done business PowerPoints for their entire working life.

I link IQs test (in informal channels) and all the juniors who picked up development really quickly and become very effective, all have high IQ.

If it were allowed, I would definitely use IQ tests in an interview setting.

I think leetcoding started as a proxy for IQ tests (which could totally be, if people couldn't prepare on the subject) but nowadays it's just testing people's ability to memorise different cases and being comfortable enough with coding to be able to implement (and mix and match) them.

I haven't looked for jobs in nearly 9 years now. Is a LinkedIn profile essential nowadays? I have dropped all social media and LinkedIn is one of the most invasive. I really dislike how it notifies you for everything

You can turn off any notification settings

It just bothers me that people get notified whenever I'd do anything on it. As for myself, I simply make notifications go to my spam folder

I prefer to share my information when I want and with whom I want, but LinkedIn feels like a meat market. If FB was personal marketing 101 (only sharing what makes you attractive), linkedIn feels like an advanced course on being fake. It kind if disgusts me

If you're looking for work (at least in programming, in the US), respectfully you need to get over it. This mindset is well in the minority and will actively hurt you while job searching.

Not saying you won't find stuff without it, but why make it harder than it needs to be?

What do you mean by "It just bothers me that people get notified whenever I'd do anything on it"?

You don't have to notify anyone when you update anything, it's just a setting. Most people don't.

The "fake" ones are the people trying to become linkedin-fluencers, I agree I'd never want to do that. But setting up your profile is basically a copy paste of your resume, and leads to an in-flow of recruiters you can always go back to when it's the right time.

I can't really believe I'm preaching for linkedin because I barely spend any time on it, but it's a tool, and when I've decided to move companies, it's made life far easier than it would've been manually applying to companies. That's without making public posts or sharing public updates to my role

Maybe it's because I never go on it, but every time a contact posts or visits my empty profile, I get notified. I can only imagine the notifications they would get if I started actually putting my info online. I might want to share it with a recruiter on a one-off basis, but I dislike having my cv available to everyone. I like to live a private life and not be publicly tracked, is that too much to expect nowadays? Just asking because I haven't job searched in a long time

Yep makes sense, I hate all that too, and they probably should do a better job providing sensible defaults for people like us. But it definitely can all be turned off.

Go in there and disable all that before changing anything. I’m bothered in a similar way about that stuff.

That being said, I don’t post or participate in the social media aspect. It’s a virtual resume and an index of recruiters and companies who are interested in you, and it’s good to know where your colleagues you want to work with again are at.

Don’t install the app for minimal invasiveness. And also consider that anyone who actively uses LinkedIn has probably disabled or filtered out all the notification noise themselves as well, so don’t get too caught up thinking about it.

And proactively remove yourself from any of those people lookup databases that recruiters will use to find your direct email

It's a primary tool for a recruiter. If you are in a situation where you need recruiters to help you find work I think it would be worth the effort.

Having them centralized on one platform is an asset when you want to avoid the people who will sell off you contact info and resume to unscrupulous body shops. Cut out LI and apply directly whenever possible.

I have a very bare bones LinkedIn profile. It mostly serves as an address book.

it's bad when you're not looking for a job, but It's great when you are imo.

why is it bad when you're not looking for a job?

You get lot of spam and some of the recruiters can be pretty unethical

ah, fair point

It isn't if you have good contacts. It pays to build a lot of bridges at your jobs.

A lot more seems to be through it, though other job sites do exist.

I don't really bother with notifications or the app for any social media site.

> LinkedIn is one of the most invasive

surprised to read this, I don't find it invasive in the slightest. I've turned off notifications for most things but its the only "social" app I have on my device.

I will say it's gotten a lot more content focussed lately, with everyone and their mom sharing their thoughts on jobs and employment. Personally I just use it as a profile for recruiters to hit and a way for me to talk back to them

My observations are the same. It's good for some networking and industry news articles, but anyone in an HR or managerial role is posting a story meant to farm likes, so there is more noise than usual.

If you're at the point where you're sending out online applications to jobs where you don't have a connection, I would definitely get a linkedin.

I'd turn off notification entirely or for all but messages

Funny story about how linkedin's oversharing ruined a potential date for me:

Recently I have been online dating, and while talking to a match, she dropped that she works a relatively high position in state government. So naturally I googled her name (only had her first name) and the position and clicked the first link. "Oh wow, she is, that's cool!"

A minute later she messages me "Checking out my linkedin?"

I was super confused at first, being that I never use linked in, only set it up for a job change about 4 years ago. I checked the website on my browser and I was not even logged in.

Then I pieced it together.

The first search result was her linkedin, which I clicked. Without me even noticing, it opened in the app on my phone (which I wasn't even aware I still had), which was logged in. Of course then it sent her a notification that I had looked at her page.

She stopped responding pretty much right after that. I am guessing because my totally outdated linkedin didn't at all match what I had briefly mentioned I did for work, and was much more junior.

So thanks linkedin.

Proof you need to keep your resume current. lol

The reality is that she wasn't going to be a good match if she wasn't able to communicate if she had a concern like your linkedin not matching, or even just give you the benefit of the doubt. Imagine what else she wouldn't communicate.

> The reality is that she wasn't going to be a good match if she wasn't able to communicate if she had a concern like your linkedin not matching, or even just give you the benefit of the doubt. Imagine what else she wouldn't communicate.

It's reasonable to have a default posture of not trusting people you just met online and if you give them a further reason not to trust you (online profile doesn't match what you said), even if unintentionally, it's also reasonable to cease communications before more time is wasted on someone who is potentially untrustworthy. It's a red flag. And there are hundreds of other people you can communicate with instantly online who don't have glaring red flags. I find the behavior reasonable unless they had already met/had a lot of time invested.

The “there’s hundreds of other people” mentality will continue into a relationship and marriage. One of the large issues with dating today is how people treat it disposably. Just ask a question like a normal human. It takes 5 seconds to type it out and the response is probably reassuring

There's what you want people to do and what they will actually do. Nobody who sees a big red flag and has many other options is going to do that.

Which is fine and fair, but it doesn't really refute my point that this behavior would personally make me disinterested in pursuing them as a romantic interest, and in my opinion suggests they would have compatibility issues for a long-term monogamous relationship.

A linkedin profile isn’t essential, I last moved jobs less than a year ago and discovered I had an incredibly out of date profile when somebody mentioned they had searched for me and couldn’t find me on there.

I did however have talks and interviews on podcasts and other things they could find, and a history of things I’ve worked on which I can talk about, and a previous colleague had referred me so I already had an in.

I don't think it's essential, but it's probably helpful. I also haven't looked for jobs in a long time, but interview a lot; it's unusual, through not unheard of, for a candidate not to have one (I don't think it counts against them with us, but I'm sure it does in some places).

Also, if I did find myself in need of a job, and didn't have anything particular in mind, I'd probably start replying to the recruiting messages I get on LinkedIn.

I think you can turn off the notifications; it notifies me for messages but nothing else. I assume I configured that at some point.

Use your network, not LinkedIn, to find jobs.

But set up a LinkedIn profile. LinkedIn is the lubricant of "hey, my friend X is looking - here's his linkedin" in a way that "hey ..., here's his personal website" or "here's some word doc or PDF in some random format that is annoying."

I've hired a lot of people and there is little more irritating than highly polished, curated resumes with a lot of noise and fluff on them. There may have been a time when that mattered, but honestly I just want to see your location, education, degrees, and the jobs you've had.

> whereas everyone else would call that person a junior engineer.

Does anyone have advice on what I should call myself? I was a senior in public accounting (~3 years of experience) when I switched into software development after self-teaching for 5 years on the side. I settled for an entry-level role to get my foot in the door, but after 7 months I was made the lead of one of a few teams with the rest being led by principal engineers. I think it’s fair to say im clearly not a recent college graduate and am performing like I have already been a software engineer for a few years now.

I now have 2 engineers below me. My technical skills have grown much stronger than an entry level, and my non-technical skills are on par with the other principal engineers. My team has been thriving and has received quite a bit of recognition from the company.

I’m coming up on a year and ready to ask for a raise since I believe I’m vastly outperforming an entry-level role compared to my peers, but I don’t know what to push for since these job levels are less clear than they are in accounting. Level II? Level III? Senior? It’s tough to rank the experience gained from my CPA and accounting background (that would be very valuable if I were still an accountant of course). Naturally engineers want to devalue it (fair enough), but it’s clearly paying dividends in my ability to deliver the company value.

Possibly "Engineering Manager"

Not with 2 people, and it's not even clear if they are their line managers and manage them in terms of promotions, raises, hiring and so on.

That’s a good thought, but I do want to stay on the technical side for now. Perhaps that would be to my detriment, but I find the actual developing and problem solving so exciting! The company said they needed an in-house invoicing system, and I had a blast designing it, creating it, and finally delivering it this past week.

I guess perhaps you can express your technical and leadership/management skills separately? "mid-level developer, but with prior professional experience in another industry and strong leadership skills" or something. It'll take a bit of work to explain, but I reckon it should be doable. (I have a similar issue with several years of non-professional programming experience I have prior to my first job).

Tech lead.

I’ve seen Team Lead for a technical individual who drives/scopes projects and manages SWEs.

> _wild_ title inflation

I'm wondering if it's important to put a specific title on one's resume. I assume many companies don't have any titles at all and everybody is just a "software engineers", whether they are a fresh graduate or 10 years of experience tech lead. What is more relevant is the scope of the job done which should be listed in a job description.

I think yes. While many companies have unprefixed titles, others have just plain "Software Engineer" as one step above graduate and even some otherwise decent companies will discard resumes applying for senior/lead positions when a HR drone does a first pass and decides "no senior level experience", even if your descriptions are full of business impact and leadership experience.

I think it's also important to know what you're applying to too.

If you're applying to a Frontend Engineer Position, and you're a Software Engineer who's comfortable with both parts and the full stack, you just shut up, put frontend engineer in the CV, and let them choose you, you can always tell them you also know to do backend stuff on the interview....

First passes are pretty simple, they just match their job position with the stuff recieved.

ATS filter you based on keywords before a human does

Yeah, honestly if I was coming from a startup that called everyone the Vice-President of Whatever (or indeed a large multinational bank; some of those also have silly title inflation) I'd be inclined to just put engineer.

No, no one calls someone with 5.5 years of experience a junior engineer.

That depends entirely on their skill. I’ve seen people with 10 years of experience that were still junior.

One should definitely have outgrown a junior title after say 3 years of relevant experience, as that is more than sufficient time to be trained into a normal (non-senior) status.

It could last longer if your company does not have a normal title (i.e., they consider junior == !senior), but someone with 10 years of relevant experience should have earned a seniority title of some sort.

I think you have found the issue to be honest, I think most people are expecting to be "senior" in place of "not junior" as soon as they prove they are good programmers. The senior title has been quite diluted by that.

Seniority is about experience and not skill in my opinion, we see many talented developers who don't qualify as senior because they simply haven't experienced enough situations. I expect a senior to have some war stories and a breadth of notable situations that they can walk me through, to demonstrate their ability to predict common issues and pitfalls, and to show how their experience helps their troubleshooting and informs their choices.

If I had told 20 year old me this, 20 year old me would have balked. 20 year old me was an excellent programmer, but he didn't know shit about long term software development.

I think the missing piece is the intermediate / non-qualified title. Junior implies to me someone who requires frequent hand-holding and coaching even on small scale tasks. Senior on the other hand should require cross-functional communication skills as well as technical mentorship. There's a huge swath of developers who fit between those (solid individual contributors who aren't necessarily ready to lead a project or mentor).

"journeyman"? Might be too dated, or too gendered these days, but yeah... some 'not junior' term that just indicates they're "better" (experience or skill or both) than the juniors, but without all the expectations that 'senior' should bring.

I've just always used whatever comes after junior / senior without a qualifier.

I get it, and do too sometimes.

For me, this most often comes up when acting as a reference for someone. The hiring person will ask me stuff, and often a 'senior' label question will come up. Almost invariably the person I'm acting as a reference for is beyond 'junior' connotations, and I think have to ask what the hiring person mean by 'senior'. Getting their definition helps me answer most effectively.

"Yeah, AB is pretty close to what you class as 'senior'. He's going to work well in a larger group with defined roles and a set schedule, which it sounds like you have."

"Well.. SJ is not 'junior' any more, but does need to have someone more senior to help mentor/check in on more advanced topics. If you don't have that - if this is a 'lone wolf' role, they may struggle some".

We have all the titles we need. We have junior for "that guy who can't do a fuckin' thing unless you tell him exactly what to type." We have senior for "that guy who can take a ticket and implement it." We have lead for "that guy who can take a business idea and implement it."

That should just be the title without prefix really, a Senior Developer should be providing more value than just ticket implementation.

These are just my opinions though, it differs from company to company. One place the difference between a Developer and a Senior Developer was a senior could be expected to own a feature and all the moving parts to get it deployed, eg: taking it to the board, organising all the approvals and business requirements with other teams etc. Other places senior just means "not junior" and the roles are the same, you just expect more talent from the senior.

> I expect a senior to have some war stories and a breadth of notable situations that they can walk me through, to demonstrate their ability to predict common issues and pitfalls, and to show how their experience helps their troubleshooting and informs their choices.

Yep. I've been doing this for... almost 30 years now, and... interacting with 'seniors' with 2 years of experience is really weird. My recollections from the 90s having worked inside a few places was that 'senior' had a lot more weight/heft to it. It indicated, at the very least, long experience (8-10 years or more) and some ability to at least work with other tech people (non-tech was a bonus).

Can't quite figure out when this shift started, but have definitely noticed title inflation as a regular thing over the last 10-15 years.

Have you ever taken down a database by mistake? Dealt with bad backups, "on production only" issues, rounding errors in historical data, security breaches, multibyte character set conversion issues?

"Coding" is eventually only a small part. Better coding skills up front can help prevent or mitigate some of the potential issues listed above, but only to a point. You're not always even the author of all the code in use; learning how to deal with that, maybe under pressure of "prod is slow/down", has an impact on how you consider these issues going forward.

EDIT: tangential story

I was at a meetup years ago, and one of the "senior dev/architect" folks at the company hosting the meetup was talking informally about IDEs. I jumped in a bit as I'd recently started with IntelliJ (this was... 2010, I think) and was excited to share a few bits that were new to me.

As I listened more, the guy was lecturing the meetup folks that "IDEs were really for juniors and newbs". Specific language is somewhat lost to the mists of time, but the gist was "This is your code, you've written it, you should know it inside and out; fumbling with slow IDE just burns productivity, wastes time, and just shows you don't really know the codebase."

I eventually interjected that it might be reasonable for him, personally, to know all the code in a system that he'd built up from scratch over the last 7-8 years. However, for anyone new coming in to the codebase, an IDE is invaluable because it makes the entire thing far more discoverable. Jumping around between sections helps you learn and narrow down bugs/issues much faster. "Well, you should just be asking your senior if you have questions" was the main response, and IDEs were still beneath him.

I realized a bit later he was actually giving a small pitch; as host of the meetup, they had an intro period, and they were recruiting. I'd heard about this company before - growing, funded and in a space I had some experience in. Had 0 desire to work there after talking to him. But "the senior architect" always knows best in many places. :/

> Can't quite figure out when this shift started, but have definitely noticed title inflation as a regular thing over the last 10-15 years.

I'll bet it can be tracked down by looking at job-hopping. That's how it happened to me in the early 2010s: I was never told I was promoted to senior developer, one day I was just invited to a meeting for all our senior developers to get opinions on something. I hadn't noticed before, but during the meeting I realized I technically was in the older half of all the devs in the office (in terms of time at the company, not age), just due to all the hiring that had been done in the previous year or two.

Eh, maybe an "engineer", if they have junior, null, senior grades. A lot of places wouldn't consider that sort of experience level automatically senior; they'd have to be exceptional.

Not automatic but historically a good but not exceptional developer would expect to make senior after maybe 5-8 years of experience. Someone who was still needing close supervision - which is what "junior" traditionally meant - after 5 years would be exceptional and it wouldn't reflect well on either the developer or the places they worked at the start of their career.

Of course this is about the level the employee is capable of operating at in absolute terms but hiring is relative. In an employee's market someone might be able to land a "senior" role before they're really ready for it. In an employer's market the average candidate who gets hired as a "senior" might have 10+ YOE. We've gone from one to the other recently and everyone's expectations will need to adjust accordingly.

This is why software is not a serious profession: it has no consistency in progression and recognition.

I think I would drive myself mad if I tried to live up to the crazy expectations of senior from most internet commenters.

> I think I would drive myself mad if I tried to live up to the crazy expectations of senior from most internet commenters.

And maybe that's the point of it. Senior without the title inflations is meant to be an actual high level position - not 50-100% of the company.

A lot of places have just replaced senior with staff/principal engineers instead, but senior used to be a well respected and unique title back in the days.

I agree with half of what you say. Senior should be a high-level position. It's a recognition of someone with solid skills and the ability to get things done.

But suppose a senior is someone who can work mostly autonomously under general direction from their management and tech leadership, which I'd say is a reasonable basic definition of what "senior" level has historically meant in software development. We would expect to see a lot more people reaching that level and sticking around on a tech career path now because of the rapid growth in the industry and the greater awareness that people can be a high-level IC but not have much interest in formal leadership or management roles.

Moreover there is no rule that says an employer should hire mostly juniors, some mids and only a few seniors. Good seniors are almost always disproportionately cost-effective if you can manage to hire them. The trend for rapid job-hopping has left juniors as an almost worthless hire in many cases because they probably won't be around long enough to make a good contribution in return for all the early overheads they incur.

There is definitely a longer formal tech track in large organisations now. I'd say it used to be more that you reached senior and then any other responsibilities like leading a team or dealing with large-scale software architecture issues were kind of attached. So historically you'd associate those higher responsibilities with "senior" people where today those with the skills and experience to do them probably have higher job titles like lead/staff/principal instead.

So I'm not sure senior has been deflated or replaced by staff etc. It's just that senior used to be the top of three levels for many employers but now there's more recognition that your development doesn't just stop after a few years and "senior" today mostly means "first few years as a senior" in old terminology.

> But suppose a senior is someone who can work mostly autonomously under general direction from their management and tech leadership, which I'd say is a reasonable basic definition of what "senior" level has historically meant in software development.

That's where I disagree. A senior should do a lot more than that. Seniors would mentor and train juniors. Software or not - that's how it's traditionally been.

What you describe is more like an engineer (no senior). Juniors are the 1s that can't work autonomously. When you are recognized as fully fitting the role you're just that. A senior then excels the role.

> We would expect to see a lot more people reaching that level and sticking around on a tech career path now

What does this have to do with what roles are available in an organization?

I start a company. I have 1 CTO, 1 tech lead, 2 seniors and the rest are engineers. What level someone is at should not impact what I call the titles available, but to suit the current market, instead we have 1 CTO, 1 principal engineer, 2 staff engineer, 1 tech lead, some seniors and a few engineers. Same same. No 1 actually grew additional roles.

It's all a trick to make people think they've levelled up.

Seniors would mentor and train juniors.

I agree that was typically also something that came in at senior level.

Maybe it's a regional thing? I'm in the UK. I'd say it was fairly standard here for a junior to be someone in the first couple of years on the job who was still learning the ropes and probably couldn't do much beyond very basic grunt work without the assistance of someone more senior. Losing the "junior" label came when you got beyond the near-full-time hand-holding and started doing routine stuff independently. The "senior" label came when you could do the less routine or more difficult stuff mostly independently as well.

What does this have to do with what roles are available in an organization?

It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.

> It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.

There are 2 distinctions and that's what might be confusing. 1 is your experience/level and what you're referring to. The other is the roles an organization offers.

I might have 50 years of experience but if the other roles are taken by more qualified people in THAT organization I can take a normal engineer route. Doesn't have to be senior. It doesn't make myself not qualified to even be a CTO elsewhere.

The roles are fixed. It has to do with budget, balanced, etc. Having all seniors might mean fights and everyone wanting to contribute and pull the project in different directions. A good balance is needed. A senior heavy team might not be good just because you can.

I understand (and agree with) the distinction you're making. An employee's level isn't necessarily the same thing as the level an employer needs for a specific role. The latter sets a desired minimum for the former. And realistically the former usually implies some kind of desired minimum for the latter if only because working at a much lower level than you're capable of will reduce compensation and slow career progression.

Where we perhaps disagree is your final paragraph. The roles might be fixed but there is no rule that says they have to be. Usually things like budgets and the work that needs to be done that are fixed for the team as a whole. An employer might have multiple hiring options available that fit those constraints - for example hiring a smaller team of more senior developers or a larger team with a wider range. My argument above is that if you can hire a smaller team of good senior people then this is often cost-effective.

I don't really recognise the picture you're painting of a senior-heavy team being prone to conflict. A big part of that ability to operate autonomously that I suggested characterises senior developers is learning how to communicate and collaborate effectively without needing constant intervention from above or heavy formal development processes.

What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors. The team doesn't reach consensus and get behind its choices collectively. However it also doesn't have the stronger leadership and safety rails that less experienced developers might need to be effective. I agree that situation is bad but it's not what I was advocating before.

> My argument above is that if you can hire a smaller team of good senior people then this is often cost-effective.

> I understand (and agree with) the distinction you're making.

Isn't this contradictory?

That's the trap we're stuck in. I remember Amazon HR saying their Senior titles are the equivalent of Staff Engineer titles elsewhere.

You can hire a highly experienced small team and pay each of them more. They don't all have to be "senior" in title and responsibility. They're just engineers. Fixed budget divide by the number of people (roughly) has nothing to do with titles. It only does according to some system where compensation is tied to titles.

You've said you understand the distinction but then some sentences later have just walked it all back.

> What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors.

I repeat, you're after an experienced/skilled team - not senior-heavy. E.g. you may need someone highly experienced in React and Rust with 50 years experience. It doesn't make them senior. Working autonomously doesn't make you senior.

This is really startup / tech titles as a whole. If anything engineering has avoided the rampant title inflation that has been commonplace among other departments (try finding a sales rep who isn't at least a senior / director).

In (Brazilian) Portuguese software engineers are usually graded Júnior, Pleno, or Sênior, where "Pleno" means something like "full". It is used for these intermediary situations where neither Junior or Senior applies.

I do, and quite frequently.

After more than a 2 decades in software development (rails/web/...), for me to consider a developer to be a senior it needs to:

* Communicate: For example: can explain tech concepts to non tech people, or inform on Monday that the sprint will be unlikely to be done in time.

* Can estimate and adapt to changes. Be boring and predictable.

* Can work/collaborate/teach with other devs.

I got tired of interviewing tech people that though that to be senior is the same as to be specialist (or worse even, that it was related with the number of years).

You think it takes 5+ years to acquire those skills?! Man, I would be driven insane in an environment like that. Such a long time and a relatively low bar.

I think the point is that some people don't acquire it within 5 or even more years. Think of a typical checked-out worker, without any specific ambition in professional life. There's plenty of people like that.

Some, possibly even most, never do.

I know people with 20y that can’t do that.

Not who you’re asking, but it can take almost no time, or decades. It has nothing to do with years.

I have worked with people who have 8-10 years of experience and are still mid-level in both skill and professionalism, know that they are, and are fine with it. They get their joy from other things in life and are totally fine coming into the office and doing the bare minimum to get by and going years without raises or bonuses because of it. Again, this is a conscious choice these people are making, they're not being taken advantage of or anything.

I work with a guy now who's a mid-senior level (senior is SDE4, he's a 3) nearing retirement. Happiest guy I know tbh

> Such a long time and a relatively low bar.

I've promoted juniors in months. I've also had people start, stay a few years and leave as a junior. It's all about learning and what work you take on. Also, I see this often when interviewing. 5+ years of experience looking for a junior role. Usually, it's either someone who did not learn and was not promoted, or it is someone from an company that did not let people work on important things because they were junior. So they stayed that way.

Surely there's a step between a junior and a senior?

We typically use programmer, developer, or software engineer as synonyms as a whole, but I tend to view those titles as more junior/intermediate/senior.

A programmer can program code good enough, but that doesn't mean they are good at solving the goals business requires and communicating it.

A developer can program and develop a small enhancement with good communication. Sometimes can also break things down so other developers or programmers can work on it to.

An engineer an orchestrate an entire new project and can identify multiple areas where developers and programmers can be involved. A good engineer will do so while maintaining great communication with the users to ensure they get what they want.

An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings.

"An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings."

Disagree for both cases. The building architects I know surely have to work with a given budget and in software architecture likewise.

> but that doesn't mean they are good at solving the goals business requires

I wonder if any newcomer to an organization, regardless of how senior they are, won't be in this same position. In order to solve business goals, they need to understand them properly. In order to understand them properly, they need context. The context comes from working in the organization for some time (months to years, depending on the size and the transparency of the organization).

> An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings.

This is definitely not true. I always have to balance on time/on budget/meets requirements and the skillset of the people who are using my designs.

I think in the trades, the intermediate level was called "journeyman".

Whatever about a software architect (that can mean practically anything; it's very fuzzily defined) that's rather unfair on actual architect architects, who are absolutely concerned with the practicalities.

"An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings."

Whenever I hear developers say stuff like this, they just sound junior/inexperienced.

honestly, I'm a senior developer and I don't give a fuck about collaboration.

This does not compute.

I think you made the GPs point very effectively.

So does his profile:

https://news.ycombinator.com/user?id=m00dy

    about: someone important...

Probably "senior" in the sense that you've been at the company the longest then. I've worked with a couple of these before, it's always awful.

See, again, this is what I'm talking about with the title inflation.

Couldn't agree more.

I had colleagues with 20+ years of industry experience who couldn't communicate efficiently, extending every short call to 1h+ meetings, require long and recurring discussions for the smallest details, or define tickets that always had to be reworked. The same people were often off by magnitudes with their estimates and reluctant to suggestions to improvements in their tooling (i.e. linter plugins for their IDE when necessary).

On the other hand, I had teammates with ~5 years of industry experience who outpaced the whole team, delivered optimal quality, were empathic, held workshops for other devs, and still had enough time/power to work on things like refactors.

What you're discussing has little to do with seniority - those are some personality traits that are great to have, but you either have it in you or not - people who are bad at explaining stuff will usually stay bad at it for the rest of life (but can still be fantastic in e.g. architecting things).

Being a senior dev is IMHO much simpler. It's all about being able to solve problems independently, without needing supervision, guidance or tutoring. If you can pass to a dev some business requirement, and know that they'll return with an optimal solution implementation, you've got yourself a true senior dev.

This is really off the mark.

I was horrible at communicating succinctly in both written and oral form and bad at PowerPoints and diagrams until 2016 - at the age of 42. I definitely wasn’t comfortable talking to “the business” and customers.

I got my first dev lead job and watch how my manager - the director of IT - at a mid size non tech company was able to translate my technical designs and challenges to the higher ups. I learned a little from him through osmosis.

I changed jobs in 2018 and I started proactively working with my CTO (my manager), sales and the documentation writers to become a better communicator.

By the time a chance to interview with BigTech in the cloud consulting department (yes full time job) fell into my lap in 2020, I had no problem passing a 5 round mostly behavioral interview where I had to describe technical accomplishments, business impact, scope, etc in STAR format - over video conferencing without the use of a white board.

I was still a little rough around the edges. But three years later, I consistently get great feedback from customers about my presentations and my ability to explain concepts and challenges to technical and non technical audiences at the same time. I’m not bragging just saying that it can be learned like anything else.

On another note, being able to work independently when spoonfed business requirements is considered mid level behavior according to the guidelines at every single major tech company that I’m aware of.

Can concur, the bar for senior at tech companies is usually that you are involving in scoping requirements and work, or even possibly owning the whole project.

Yes, like any skill, communication is something you can practice and get better. The key is that it’s very hard if you can’t get out of your own head. And when it comes to communication with executives and other very busy people you really need mentorship with situational context unless you really are a natural.

I got a lot of great mentorship here that very much took me to the next level when it comes to communicating with executives and CxOs.

But part of it was also me just watching people who were good at small talk and reading articles about how to be a good conversationalist since I am on client sites and go to lunch/dinner with them.

For instance, since I work remotely, I’m constantly taking notes when I’m on client calls and even with internal people when they mention something about their personal lives - families, vacations, hobbies - so I can ask then about it later.

Heck, I even have scheduled messages on Slack to ask them how was their vacation to $x when they are scheduled to return.

That's about how I think about it as well. You either need babysitting and mentoring or not.

Funny, this is how I (and I think most people I've worked with/for) describe a mid-level dev. "Doing the thing" is a pretty low bar but we don't really expect that from juniors, who typically need hand-holding. To be a mid-level you should be able to operate independently and provide optimal or near-optimal solutions most of the time, but your work is still going to be just focused around you. Most of what you're doing is individual tickets, refactoring, etc., nothing that influences or impacts the broader team. When your impact is beyond your individual work is when you start moving into the realm of senior, and it's part of why it takes time (not just skill) to get there.

> people who are bad at explaining stuff will usually stay bad at it for the rest of life (but can still be fantastic in e.g. architecting things).

How does that work? Explanation is fairly important there, I'd have thought.

> Being a senior dev is IMHO much simpler. It's all about being able to solve problems independently, without needing supervision, guidance or tutoring.

See, I think this may be the disconnect/product of title inflation.

In a system where you have junior engineer/engineer/senior engineer, what you're describing is probably engineer, not senior engineer. In a junior/senior system, it's, ah, a senior junior? :) A senior engineer should be a kind of force multiplier (though such is the level of title inflation that that maybe is now more staff in some places).

Hahah, It's the old story of the elephant and the blind men. There are so many ways to be a senior engineer, and it is, in my experience, very company dependent.

I wrote a blog post about it: https://www.mooreds.com/wordpress/archives/2812 which got some great HN discussion a few years ago: https://news.ycombinator.com/item?id=20485006

tl;dr: being a senior engineer at a startup is different than at a consulting company is different than at a large retail firm is different than at a FAANG.

And my experience outside of the large tech companies is that titles are usually meaningless and don’t give you any signal when looking at applicants.

I'd add:

* able to take responsibility

* able to transfer skills and to guide juniors to productivity

> able to take responsibility

This is the big difference - seniors will track and resolve a roadblock or issue that they could justifiably ignore, in particular where other people in the organization are being difficult or obstructive, giving incorrect guidance, etc.

A junior will just go "We were told it cant be done/will take 5 weeks" whereas a senior will know that's bullshit and escalate it to the right people.

So I'm not alone!

I'm my environment, senior developer needs a deep understanding of technology but more importantly a deep understanding of business and business processes. I'm in the ERP space so a senior Dev can talk business language - they Co develop and guide functional specifications with business analysts. In other words they understand hr or pay or financial processes of the company.

I wish I could assume all those other qualities as well, but while some here think good communication is easy to acquire early, my experience is the opposite - there are many 20 year veterans that cannot / should not be put in front of a client. They are wizards at technology but not at communication - presenting things to non experts, understanding other points of view, etc. You have to WANT to learn things other than technical proficiency, and even here, that's frequently derided / seen as uncool. "Manager" is of course a swear word insult so anybody who wants to learn communication or empathy or estimates or hard conversation is "no true techie" :-/

Completely agree!

I call it do you have 10 years of experience? or do you have 1 year of experience 10 times?

There's a step between Fiat 126p and Ford F-150 when it comes to towing capacity.

No one says everyone with 5 years of experience is a senior, but most likely is mid.

That's exactly what the parent comment says: title inflation.

I sometimes get even funnier CVs, where a person with 2-3 years of experience (usually from the Army) is already in a tech lead / architect position.

Tech is very strongly bi-modal or even tri-modal in terms of both compensation and skill. Some people with 2-3 YOE will operate better than some people with 10 YOE.

> Some people with 2-3 YOE will operate better than some people with 10 YOE.

That's true of every field, and doesn't really relate to the claim of bimodality. If ability followed a perfect normal distribution, it would still be true that some people with 2-3 years of experience are better than some other people with 10-15 years of experience.

In most fields this is extremely rare. In tech it's relatively common.

The difference is the kind of environment you're working in (E.g. high growth tech company vs non-tech company) and the learning rate in that environment, which is where the modality comes into play.

> In most fields this is extremely rare.

For example?

In pretty much any field I can think of, it is definitely not rare. The norm is that some people pick things up quickly and other people don't.

It is normal for good musicians with 3 years of experience to be better than bad musicians with 10 years of experience.

It is even more normal for good secretaries with 3 years of experience to be better than bad secretaries with 10.

My mother once partnered with a local university to offer students internships clerking in her medical office. She remarked that the students, with their zero years of experience, were more effective in this generic, unskilled role than anyone she was able to hire into it. (Those people had many years of experience.)

The partnership with the university wound down and she went back to hiring no-hopers with plenty of experience. According to her, that was the best she could hope to do for the dead-end position she was offering.

In my personal experience, devs that "cross-pollinate" in other fields are usually more competent than someone with the same YOE from a purely tech background.

I think the issue is that people sometimes incorrectly assume job titles are standard and used the same across different companies. At some companies titles are more about pay bands. I’ve worked places with a bunch of “senior” engineers, but that was mainly because the company pay bands couldn’t compete with the market for junior engineers so they’d hire them as seniors. It’s bad too because sometimes once an employee gets that title they expect it at other companies even if the experience level isn’t there yet, which limits their mobility because they refuse to take a backward step in their career, even if the pay is better

I took three backward steps since 2016

- dev lead - non tech company responsible for one “team” of two developers and a bunch of contractors on another team

- “Senior Software Engineer” - no reports and I actively refused a promotion to be a team lead. I was already the de facto “cloud architect” over the “application modernization” efforts via no more than influence and reputation.

- mid level “cloud consultant” - full time job working remotely at BigTech.

As my Dad always said, it doesn't matter what they call you, it matters what they pay you.

I worked with a person for about 3 years (and he had previous experience as well) and I wouldn't even call him a fresh-grad level or trust him more than I trust an intern. Some people are immune to learning

We have a 14 year junior engineer. She refuses to learn new tech, is difficult to work with, and makes a mean bowl of spaghetti code. She does it so quickly though and has so much institutional knowledge that it’s pretty much mandatory she stays.

When did we arrive at a point where terms like "junior" became derogatory terms similar to "idiot" or "asshole"? No, you don't have a "14 year junior engineer". You have a senior engineer who is difficult to work with and is (according to you) bad at their job.

Her official title is literally Junior Engineer with the company. Did I say that it was a derogatory term or use the title idiot or asshole or say they were bad at their job? Bro you should get that chip on your shoulder examined.

Has she been with your company for 14 years? Because if so, this really calls some of your companies practices somewhere into question.

That being said, if she got hired as a junior in the last 5 years (despite tangentially having some programming experience) and never got promoted, I guess I can understand that, but really, why even keep someone on who refuses to learn new things, is difficult to work with, and consistently writes poor code

Why? Because there are also 14 year junior managers (except they get retitled to something like "team lead")...

>but it doesn't seem normal to spend six months applying and only get _one_ interview.

At this point in time, it's completely normal for people breaking into the industry.

But someone with 5.5 years of experience isn't a person breaking into the industry.

Unless they have 6 years of 11 months experience doing the same thing.

Reply on news.ycombinator.com