There's a common adage:
You can have 10 years of experience, or 1 year of experience repeated 10 times.
--
I don't know the author, and it's possible that Shopify used this as an excuse because the authors talents did not meet expectations or claims: but "years of work experience" is a very poor marker for ability and experience, since years are not equal between people or roles.
No. You've drifted into believing your opinions are facts. Reasonable people can disagree.
Having hired many people, I understand that everything in the hiring process, no matter how well calibrated and tightly looped, are rough heuristics for how well a person will do in a role.
So years of experience in the relevant activity gets at least equal weight to responses to relevant technical questions, coding challenges, etc. Yes, FAANG experience carries extra weight in opening the door because FAANGs are known to set high bars and have (overly) intense filtering. Etc. Etc.
Fair enough.
I've also hired "many" people (many in my case being about 12, so that may not be "many" by other definitions).
I think it's fine to disagree, maybe my overall sentiment was much too strict, but let me just say that in my experience years != years, even people in the same roles at the same company can have wildly different experience levels from the same years of being there.
This isn't really accidental either, a good example was.. me.. actually, I had a colleague who had the same number of years experience and for all intents and purposes we actually matched super well in our abilities and mentalities.
However, we worked together for 7 years, on the same projects, same deadlines, same tech, same responsibility.
That man knows far more about influxdb than I possibly can: despite both of us having "7 years influxdb" on our resumes.
I know more about postgresql than he likely ever will, but we both have "7 years postgresql" on our resumes.
Aptitude is one thing, attitude is another, and at the end of the day: the only thing that works is to set your standard and see if people hit it.
For me, senior means that you're able to teach, are self motivated, can speak at a high level to leads or directors and understand business need, regardless of technical competence in specific technologies or years experience.
If you hit that bar, you get the title, if you don't, you don't.
Down-leveling after the fact is a punitive act. My guess is the years of experience thing was just an excuse for some business initiative to cut costs or was a personal attack on the OP.
He got interviewed for a senior position, got offered a mid-level position. Seems to fit exactly the case that you find reasonable.
This is a good adage for why 'time served' is not a particularly useful way to judge someone's level of experience, but you can't invert it and say it means time served isn't important at all. Someone with 1 year of experience might have the same experience level of someone with 10 * 1 year, but they obviously don't have the same experience as someone with 10 years of real experience.
"You can have 10 years of experience, or 1 year of experience repeated 10 times." is only useful as a way of differentiating between two candidates with 10 years experience; it can't be used to suggest someone with 1 year of experience is as experienced as someone with 10 years. They're only as experienced as the bad 10 years experience.
I'm not saying experience doesn't matter at all, just saying that it's a poor marker for seniority.
FWIW when hiring I tend to avoid thinking about years of experience; else I allow some implicit ageism into my assessment; my definition of senior has very little to do with actual technologies and is more to do with how you use those technologies and if you have experience being self-motivated to deliver something with business value.
In many contexts seniority is literally defined as years of service. I take your point to mean that experience isn't everything, and that there are many people with less experience than others but with more talent or skill, but I think there is a reasonable expectation that a senior developer (in terms of years served) ought to have certain qualities that one cannot expect in someone with far fewer years of experience, regardless of how intelligent/skilled/talented they might be.
Wisdom is one quality that takes years to arrive at. In a developer, wisdom is the quality that leads to questions like, "Yes, we could do that...but should we?" It's the lived experience of writing enough code that never got used to be able to call YAGNI. It's knowing when to be cautious about adopting new technology, because of all those times someone picked the wrong new thing that they still had to maintain five years later.
I think experience is vastly overused in hiring; it's a classic example of picking the easy thing to measure over something meaningful. But experience really does matter. Living with a code base for an extended period teaches you about consequences that just aren't obvious.
Sometimes the handful of words that filter through on the internet don't do justice to the reasoning behind them.
My questions are usually: “tell me about a time you x”
“Who helped you, what did you like about them”
Or “nobody helped you? Was that by choice, how did that feel”.
You get the gist.
Reading between the lines, and having been involved in tech hiring for junior - low-level senior roles, my guess is that they were open to his being at the level of a more senior role than his experience suggested, but his interview performance suggested he really was a more mid-level candidate, like you'd expect from his experience.
It is exceedingly rare that recruiting will give feedback on anything at all subjective; if the true reasoning is "your interviewing reflected your observed years of experience which puts you at mid-level" then the feedback to the candidate is going to be about their years of experience, not the interview performance.
> it wasn't based on my answers to soft questions
It seems that he didn't consider erb frontend or he dislikes it, he was expecting to work on js/react or whatever other framework he knows/likes. That demostrates that he doesn't fully understand what a frontend developer job is.
My current team has a senior that has been at the company for 20 years as an Analyst, she can't write a line of code without assistance. But she's just buying her time. And we've got a few juniors/midlevels that could out code almost anyone of the team. But because they lack those years on their resume they're stuck in their positions for some time.
I think it's an odd situation to be in though; most companies seem to look at either years of experience or make you do leetcode/Fizzbuzz challenges to determine your level. Which how practical is LeetCode challenges in your actual day-to-day work environment?
When pressed just a little bit turns out they installed Debian or such back in 2001 then used Linux on and off/now and then over the years. Often not even going beyond the live install environment.
Same thing with programming languages. 20+ years of C++ experience doesn’t mean anything by itself. I’ve worked people with one year experience that are far more experienced in actually using the language and delivering high quality code.
It’s just bullshit gatekeeping and laziness mostly by HR or non-technical managers.
IMHO blindly asking for N+ years experience is a waste of time and puts a lot of people off applying for the position that may be a great fit but feel they are not experienced enough.
Or maybe they were just really mediocre? I can compare myself to myself - I simply know that I'm a better Rubyist than I was 7 years ago. Not just a better Rubyist, a better software developer in general. But sure I can see that maybe some people don't have a passion for the craft and then they kinda stop learning and just get by with what they know. You can continue being mediocre for quite a long time if you can bullshit people - but I don't think that's a typical type in our industry. So I do think your experience is anecdotal. The really great Rubyists I know all have lots of experience - at least 5 years and usually it's well over a decade (I'm thinking of Tenderlove/Jeremy Evans/Sam Saffron etc etc). Btw they're not just great Rubyists they also understand software, the web and even low level stuff quite well, so they're great overall engineers. Sure some bright people can get to that level faster - but that's very rare for mere mortals. It takes a lot of hard work and a lot of time usually, like any skill.
I will say though that for many routine tasks you don't have to really be senior - e.g implement some new end point that talks to a model where you pretty much copy paste from the existing code base, for these types of tasks there won't be much of a discernable difference between a junior-mid and a senior. Senior make a difference in the more complex stuff.
I mean, there's much more to Analyst and Engineering jobs than coding, especially as you advance up the levels.
Kind of? It's worth remember that this would not have happened if he'd been a senior engineer at a FAANG company (where people have gone from new grad to senior in 2 years). But big tech hiring is conservative and they don't have great insight to small or non-tech company engineering ladders (though they tend to be less strict for a variety of reasons). The cost of a mid-level promoted too soon is dangerous and so they tend to err on the side of caution, which they can because they pay so much.
I'm not surprised that a large corp uses reductive and rigid leveling methods to, it happens at scale.
On the happy path, most of your benefit is from your experience in the defined position, yes. But things don't stay happy for long, unless you're really good at denial.
I started up with a volunteer group about 7, 8 years back, and quickly found myself leading initiatives because my work experience translated to cat herding (for very small herds). A few years later I caught myself trying to apply wisdom going the other direction. And once I started noticing that, I became aware of all the times I borrow from a very well-run hobby group I belonged to in high school. On reflection, that used to be a conscious act that had faded from my notice.
A substantial amount of the intractable problems you have to tackle anyway are people problems, not technical problems, and any experiences in retail, QA, getting a PhD, organized sports or hobbies, or even chronic illness, give you a lot of experience that you can and should use.
There are technical problems are a battle between you and 'nature'. There's a tenacity I haven't always applied to all things in life, but I refined it by being an endurance athlete. I will fix some tech problems if nobody else will, even if it's the last thing I do. And if a production issue goes unsolved for long enough, I'm one of the last three people in the room who haven't tapped out. And it's not uncommon for one the other two to be an athlete, or former military.
I think we should be aware of the fact that we're reading an accounting of the story from one viewpoint, and hiring/levelling decisions are usually not shared in depth with people who don't need to know. And most people are bad at judging how well they did on interviews.
Saying they didn't have enough years of experience may have been the way the recruiter decided to share interviewers' feedback that they seemed inexperienced.
Or maybe it was a negotiating tactic, and the company expected the candidate to push back.
Or maybe it's a simplistic metric the company put in place to cope with their rapid growth over the past 2 years.
We can only speculate.
Let's think about it this way. I apply to Xibalba Corp. for a Senior Dev position. You're a recruiter at Xibalba Corp. and you use YoE to rank candidates (as a shortcut for critical thinking which is much too hard). Why would you move past the screening stage knowing how many YoE I have? It would be dishonest of you to move past that stage with my candidacy knowing that you would later downlevel me.
(I am not claiming Shopify did this, merely an example.)
"I will always optimize career decisions based on a position's potential to improve my ability as a developer. I will optimize for this over title, benefits, and pay."
If this truly was a position they were taking that was below their level of seniority I don't think they'd necessarily feel so optimistic about growth potential.
I thought that was incredibly reasonable. For what it's worth, I do not use "senior" on my résumé and if I'm ever asked why I got downgraded after multiple senior positions I'll happily tell this story.
The mid-career midwestern enterprise line of business developer working for companies no one's ever heard of should cling to the Senior title for dear life. Losing it would signal a spectacular flame out.
I'm confused by this. Isn't this a pretty sensible reason to be downleveled. I don't think a company would care about your years of experience as, say, a lawn mower. In terms of experience, wouldn't years spent front end coding received almost all the weight?
Sure, your years mowing lawns may have been rewarding and may have helped you build good communication skills or something, but surely we don't expect companies to bump you to senior on that basis?