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.

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!

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

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.

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.

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.

  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.

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.

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.

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

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.

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

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

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.

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.

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.

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?

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.

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?

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.

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

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

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.

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.

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.

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 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.

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.

That’s at least tangentially germane. :)

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.

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.

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”.

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 :)

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.

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.

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

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.

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.

What's your definition of senior?

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

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 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.

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?

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.

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.

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

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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 really bother with notifications or the app for any social media site.

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

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

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.

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

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.

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.

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

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).

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.

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.

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.

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.

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.

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).

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.

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

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

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).

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'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" :-/

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.

* able to take responsibility

* able to transfer skills and to guide juniors to productivity

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.

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

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

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

    about: someone important...

- 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.

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.

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.

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".

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.

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. :/

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.

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.

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.

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.

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.

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.

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.

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.

> 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.

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

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.

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.

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.

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.

Find a recruiter on LinkedIn. This is what it has come to. There are thousands of resumes being sent at my company, yet the recruiter can't find anyone. Why? Because no one is applying through her link. The regular resume channel is reserved for bots at this point. Contact a person and you have more chances.

1. We are only allowed to hire through either an approved recruiter or the company job portal. The company job portal gets so many applications for each job it's absurd, and we have to sift these ourselves to some degree (HR are meant to confirm we only see qualified candidates, but they're idiots) so rather than sifting the portal applications we mostly use 2-5 known recruiters who only give us candidates who can do the job. They do the first screenings, if they give us shit candidates we never use them again, so we rarely get a bad candidate through them.

2. Perks. We often meet directly with recruiters in person, and they have expense accounts and take us for lunch/drinks we don't have to pay for. This makes us want to keep using them over direct applications (yes recruiters, this 100% works, we won't use you if you're shit regardless but we'll 100% entertain looking at your candidates if you take us for lunch or drinks - check compliance limits before suggesting a venue though).

Maybe 99%. This doesn't work on me. Any swag I am sent from a recruiter gets handed to someone else. I turn down dinner and drinks because I feel like I'm being manipulated. The harder a vendor or recruiter pushes here, the more uneasy I feel about using them. I don't want to hang out with people who only want to be around me so I can give them something.

Edit: Sadly, I think this doesn't help me from the perspective of being recruited, but I can't help not being comfortable playing this game.

How badly are you paid?

Don't really get it myself, I think typically such people are drastically undervaluing their time.

Source: finally realized that half the reason I went to technical talks that bored me was for free pizza and beer that were bad for me anyway

Me: I'm not doing DIY, I'd rather pay someone competent than waste my time and energy.

Also Me: I'm getting 100% of the value from this perk goddammit it's free stuff who turns down free stuff.

Your opinion is wide spread, but it erks me. "There's no such thing as a free lunch" is an adage millennia old, and true.

The rule is, nothing is free. Nothing. There are exceptions the rule, but that is exceedingly rare, and if you think you're onto one, it's probably a scam.

"strings attached" is another adage, and often you get "free", by having the strings attached to you.

E.g. I was at an 'all-inclusive' resort for work and some of my colleages seemed to think it was their duty to get as much value out of the meals as possible, even trying to calculate the actual cost of different dishes.

Of course it isn't "free" in the sense it is a result of work, but it is free in the sense it has no additional cost.

The brief stint I was at the company, the recruiter gave me tickets to the local professional baseball team that included access to premium suites and tickets to the local professional football team.

But yeah I get it, having a free meal wouldn’t mean much to me.

We weren’t going to hire contractors outside of that agency.

Heck, my manager asked me did I know someone with the same skillset I had, I had a friend who was looking for work and asked for a rate of $80/hour. They wouldn’t hire them directly. I had to negotiate with the recruiter and my manager until we also settled on paying the agency $120/hour to hire my friend so he could get $80.

No my manager also wasn’t responsible for choosing the agency. That was chosen on higher levels.

My last job tried to address this by having a small technical test of skill that could be thrown at anyone as a first pass before getting any technical people involved. We got virtually no senior role "spam", so we didn't have to worry about making a challenging technical test, we just needed to weed out junior applicants who basically didn't know how to do anything other than apply for the job.

It worked pretty well for us but we were a relatively small company. I don't remember the exact stats, but I'm pretty sure we hired less than 50 people a year (across a couple offices in the US) for the technical roles we used that test for.