It's not a 3 man company, you know. If they are interviewed and hired as Frontend (React) Developer in organization of that scale, they might expect to actually do what they are qualified to do.
You make it sound like the author did something wrong. Accepting a job and finding after 5 months that, for whatever reason, it's not your thing is pretty OK is it? Better to quit quick than stick around unhappy.
If you apply for a role that is explained to you, what does it matter what the company mostly does? If I apply to a rail maintenance company as a programmer, should I expect to maintain rail? No.
I don't blame OP for leaving. You can usually get the vibe in 3 months and have a pretty good feel for what things are in your control and how it's going to shake out.
I left HashiCorp in 4 months for basically the same reason, just swap our frontend with Go.
I was interviewed in Go and I knew the team was using Ruby but all the teammates were energetic for having someone else who knew Go, wasn't all about Ruby/Rails and the team was great. But the opportunities on other teams to build out things in Go and work on the existing Go codebases, both public and private, was just teasing me every day. I tried to work on one of our open source libraries and was told I was stepping on someone else's toes and could be taking opportunities away from them.
I would return in a heartbeat on one of the Go teams working on one of the Go products. I think they are just great in the Go community and their tools are fantastic.
I sometimes read articles like, "why I left Google," or "why I left Facebook," and they're mostly a teardown of the company.
This article is generally positive. The author liked the people, had a positive sentiment of the interview process, was impressed by the tech stack, had a solid manager, etc. It just wasn't the tech stack they wanted to be working with.
I am not casting aspersions on the specific OP, but often these "why I left" stories are missing key information, like the writer got a bad review, or was on plan, or had a monster boss, or was actually fired, etc.
People don't want to hurt their employment prospects, so it's understandable if they are selective about what they reveal, but that's why I don't trust accounts like this.
Rails views are frontend code. The assumption “front end = JS” is a false equivalence, and one only relatively recently promulgated. Overall this article reads like someone who doesn’t quite understand how inexperienced they are; this mistake confirms it.
> My hunch with those companies was that it wouldn't have been a major issue if I was video-ing in from the State Penitentiary (due to murder charges) as long as I solved the algorithms correctly
the OP clearly has some skills to his name and even academic background, yet they'd like him to solve coding puzzles
i could get $100k freelance contract only after 1 meeting and bit of paperwork, but tech bros won't accept me cause i don't do puzzles
He didn't mention whether he could or could not do coding puzzles.
But if you are accepted purely on coding puzzles, then your colleagues also were. Meaning, they might be difficult to work with (such as: overconfidence, always criticising the code they didn't write, shaming people in large meetings, repeatedly overpromising, or other bad behaviours).
Sadly, Shopify's care and interest in his individuality didn't extend past the interview stage, as he was given work that shouldn't be expected from a front end focused developer.
> we <must> ask algorithm questions to ensure engineers can think properly
I thought that described today's interviewing zeitgeist, pretty well. In my experience, absolutely no one even glanced at the dozens of open-source repos (for finished, documented, tested products), or the hundreds of pages of writing I have amassed, over the years, which ahem, are actual artifacts of lots of my "proper" thinking.
I've only practiced a few Codility exercises, a few years ago, when I was still interested in working with someone else. Otherwise, I never practice leetcode. As I am quite aware that many, many people practice these types of things, for hours every day (I strongly suspect while being paid by their current employers), I just consider that a wash.
If this is a requirement, then I'll never get hired, and I might as well give up (I can actually do reasonably well, at these kinds of things -mostly-, as they are usually basic commonsense exercises, but I won't ever have the rote efficiency of a practiced leetcoder).
Since I don't actually need the work, I accepted that this is just the way things are, and withdrew from consideration.
Too bad. I suspect that some companies that I would have enjoyed working at, and that I could have been a valuable IC at, are maybe having to deal with less-than-ideal workers.
I wouldn't necessarily say this. Since it is "how things are done," these days, I strongly suspect that folks want every competitive advantage they can get, and it's perfectly understandable.
It's just that it's an extremely 1-dimensional way of evaluating people that are supposed to be creative and intelligent. It doesn't actually tell you anything about them; just that they are good at practicing rote (which, to be fair, may be exactly what a corporation is looking for).
I am very fortunate. I spent my life, living frugally, and investing carefully, so I have the ability to step back. I know that very few people have this capability.
A career is a really big deal, and worth it to prepare for.
The problem is that over thirty years of shipping software is not something that is easy to express in a few scholastic tests. It's something that can sometimes be easily demonstrated, but consuming and evaluating it is time-consuming.
I have spent a lot more time, preparing my portfolio, than lots of folks have spent at leetcode. If that's not valuable to a company, then, c'est la vie.
I done one hacker rank on my last round of interviews and it absolutely killed my confidence. It was 5 questions automatically timed to 15 minutes. So in terms of completing it you really need to have seen these types of questions before as they left no "thinking" time only time to type up the solution and a short debug.
I got 3.5 of the questions finished in that time so I'm going to be working on my speed for the next time.
Like you I think it's kinda sad given that the people who promote this style of interview say is so that they can assess how you "think" or "approach" a programming problem. The reality is that it's a hazing ritual, they are looking for you to have seen the type of question before memorise how to solve it and instantly start applying that in the interview.
I'd note that overly strict interviews often cause companies to not be able to hire efficiently and effectively which the very same companies will complain loudly about. Companies I've worked for rejected almost all candidates and still complained they couldn't hire anyone.
> i could get $100k freelance contract only after 1 meeting and bit of paperwork, but tech bros won't accept me cause i don't do puzzles
I’ve hired both contractors and employees.
Contractors almost always arrive with more of a verifiable portfolio and verifiable references.
Contractors are also much easier to cut off early if we realize they aren’t delivering. A $100K contract could end up being cheaper than the amount of money we waste on a bad hire from start to finish by a factor of 2X.
The bar for hiring full-time employees is higher than contractors.
How hard is it really to fire someone, though? When I was recently a contractor the company was paying my contracting company well over double what they would've paid for me directly. They could've hired me directly and, if I didn't work out, fired me and given me a massive severance and it still would've been cheaper.
Am I reading correctly that the reason is basically that he didn't get to enough frontend/JS work, even though being hired in a frontend role? And maybe realized he was kind of bored with ecommerce after all too.
Why is that bad? It's his blog, writing about himself for his feelings?
It wasn't per se a large org issue, or such - or a "scandal" that is so commercialized into #movements today.
He just didn't like the work, expected more, didn't get a good offer (it was downgraded from his perspective) and in the end didn't think it was worth his time to stay.
That's a reasonable decision to make. Many people stay for the branding but hate the product.
I stayed as companies not liking the work, or the brand but just for the money and opportunity on my resume.
The people made it fun too, for a while but once the people change and the work becomes work work, it's time to go and I did.
Accurately put! Not trying to portray Shopify in a negative light at all. I just learned something about myself through the experience and thought it might be helpful for other devs.
It's fine for him, I just don't get why this is on the front page of HN. If somebody submits an article titled "I quit <High Paying Thing> after <Short Period of Time>", I expect there to be drama.
He didn't like the backend work? Okay, that's actually quite fortunate for him, he can just quit and move on, but I'm here for Real Developers of Beverly Hills.
I posted my comment before the comment thread become full of people telling the OP they are wrong or bad, which I find very bizarre!
I did think the OP was not super clear about why they actually left, so I took a shot at summarizing what I think I got from it, to see if other readers shared my reading.
The insight around the "Life Story" interview round is good. It helps interviewees feel like they are being seen as whole people and, at least in the author's view, helps filter out jerks from a large org.
Seems like something other large companies could/should adopt.
Getting down-levelled through the interview process due to YOE, which is known before interviews even start, indicates some failures by the recruiters. Recruiters should've been able to set proper expectations up front.
I bet being down-levelled and leaving within a year are very strongly correlated and cost the company a lot.
I joined a Series A startup. Me and all my peer engineering directors got down-leveled to entry-level titles within a month.
Product Mangers, Sales People, others got up-leveled from Entry Level --> Manager --> Director --> Sr. Director.
The company is on a dying breath, because these shenanigans caused so much acrimony. Who the fuck cares about a company that fucks you over a month into joining the company? Half the engineers were working on side projects and the company has basically died.
1. check linked in. if you a dozen of kids out of undergrad in Marketing/Product/Sales/Strategy/Finance with Director+ titles a year or two out of college....and others out of industry with entry level titles, RUN. There is obvious inequity. You wont be able to motivate people to work hard with such a setup.
2. avoid companies with split executive offices. Our engineering group was 95% on the East coast while the "business" office was in SF. CEO/CFO/CPO/CRO all in SF. CTO on east coast.
my mistake was staying and thinking it would be fixed. It didnt get fixed for three years. By then, out-of-undergrad business team members were already Senior Directors while PhD engineers with 15yrs continued to be entry level.
the result of the changes was a half-dead demotivated engineering team that never revived. titles were fixed three years in, but it was too late. business teams had moved onto bigger and better jobs by then. good luck trying to get hyper-growth when you've screwed over all the engineers
I've had that happen to me with Coinbase, down-leveled from senior to intermediate halfway through the process (in no part due to my performance on the screen). Based on their comms, it seemed to have happened for budget reasons: they exhausted their "senior head" budget. Either that, or it was a hardball negotiation tactic (which lost them a head)
Leveling is simply a byproduct of your alternatives, not your experience or skills. I bet you that higher paying companies like Stripe/Robinhood have a more even spread, while others need to level people as senior to compete.
In my last interview bout, I've had some companies come back with senior leveling _after_ I told them I had competing offers. The blatant reality of "leveling" being tied to your negotiation prowess and not your engineering skill shocked even myself, as cynical as I am.
(Edit: I should say that I had a great experience interviewing at Coinbase, and recommend others to do the same)
It's not that easy to filter out jerks just from that interview. "Life Story" is more about cultural fit, in Shopify case they used to select mostly youngish, hipsters candidates and filter out family/middle aged candidates.
I don’t know that it was the main issue - but yes I think this is common with Shopify hires. I’ve seen a number of similar complaints on Blind’s Shopify board.
Possible. I acted on a hunch thinking that it is a typo. He talks about non-tech roles and I made the connection with the e-commers -> consummer protection.
Anyone who has worked with "WITCH" knows there is no comparison here. WITCH operates at high scale, low cost, low skill, low quality contractors. They cannot be compared to full time FAANG engineers.
I see threads elsewhere full of "I joined a FANG hoping to make amazing algorithms and push computer science forward but I'm just building dashboards and changing button colours", so I'm not 100% sure the work content is different.
In 5 years, I'd expect a WITCH engineer to be exposed to and deeply understand many industries and companies. I'd expect them to learn to handle stakeholders as well as code. I'd expect them to be exposed to many different vendors and tech stacks.
But mostly I'd expect them to get really good at making a big impact very quickly, with limited time and people.
When I compare that to a guy getting paid $1 million a year to run a team of 4 people who build youtube revenue dashboards or something, adding one graph a month, I know who would want working on project I cared about.
The WITCH engineer was just unwise enough to be born in India right? Probably went to the top schools there, has an MBA and a masters in compsci... Just... Indian, so worth less for some reason.
> "The WITCH engineer was just unwise enough to be born in India right? Probably went to the top schools there, has an MBA and a masters in compsci... Just... Indian, so worth less for some reason."
The comparison is between FAANG FTE and WITCH contractor. This isn't to do with nationality or birthplace. There are many Indian FAANG FTEs just as there are many American and European WITCH contractors.
And indeed I have worked with many outstanding FTE engineers at 3 FAAMG companies who were born in India, and are very highly paid. I also worked with some good WITCH contractors at those same companies.
..and can we talk about how it's weird the author calls it FANG and not FAANG? Seems that's been more common for a few years at least. Minor point I know but threw me off on first read
I do think its pretty weird to hire someone as a frontend dev and have them in Rails a bunch IF you were in models, controllers, and elsewhere a lot. If the majority of your work was in views, ERB or otherwise, I don't think its that strange.
There's a sort of all or nothing aspect to how you handle the view layer in Rails, at least for a smaller code base. However, I'm sure Shopify is large enough that they have apps doing a little React, a little server rendered in ERB, and others that are fully React backed with an API, and probably some that don't have any JS framework at all.
Came here to say the same. Server-side rendered front-end is still front-end. Just because someone doesn't like the stack, doesn't mean it's incorrect.
Sounds to me like this person was overwhelmed by the sheer size of the codebase and how little control they had and decided it was not for them. I don't blame them. eCommerce is tough. eCommerce on such a customizable platform must be like walking through a minefield.
Right, I'm a React dev, but currently I'm at a point in my project where I have to dip into Flask/Jinja2.
It's not "fun" per se in the front-end part, but it's absolutely fine, and what's required for my work. I don't mind it at all, if anything I'm happy and curious about BE/Python and how that part works.
If I need to call Rails services and methods from ERB, then it isn't frontend :)
It's comparative to hiring a front-end and putting them to work on .php files. It's so far back in the past, that it becomes degrading, and you start feeling regression in front-end skills.
Web dev seems to be headed in three directions imo:
1) The old style, where the server owns the routing but can cede control over html to the frontend for discreet applications. Always cedes control of JS and CSS to the frontend.
2) A fully separated frontend and backend application that talks to one another over REST or GraphQL
3) A very javascript-light frontend that uses a technology like LiveWire, LiveView, or Hotwire to render on the server but push reactively to the frontend
I think any is fine and each have their merits. I imagine that #3 is the one that is most likely to supersede #1 as it's a direct evolution. But I would think that it's a bit gatekeeping to tell someone whose whole job is HTML templates, javascript, and CSS that they are No True Frontender.
There was a major release of PHP8 2 months ago. To add to that - JavaScript was invented in 1995. PHP, "so far back in the past", was invented in 1994.
It's only regression in the exact language and framework you wanted to use. Certainly not "front-end skills".
I worked at a company where our iOS team refused to make multiple API calls for any given view. They wanted 100% of the data for _any_ given activity the user could do to be a single call, formatted how they wanted. I pushed very hard to let that team go, but failed, although I do still chuckle at the horrific reviews the app gets for general bugginess.
It's absolutely mind blowing that people getting paid 150k say "well I'll touch that code but _never_ that other code". I hate to paint with broad brush strokes, but I never once saw that attitude from a non-college graduate. Loathed to use the word "entitled", but holy cow.
> What does the unit "year of experience" represent, and is it comparable across domains?
In my opinion, "years of experience" should not be disqualified as one of multiple evaluation tools for skill.
I think it signifies that you have had the opportunity to go through a variety of situations, challenges, projects etc. and you have accumulated knowledge and experience that cannot be learned by reading tutorials or working on side projects.
From personal experience and by talking to and working with other much more experienced engineers than me, I have noticed that some of the most important knowledge is obtained just by working on something for a longer amount of time.
Obviously, there are many exceptions to this rule, there are engineers with years and years of experience that are just bad at what they do. What I am trying to say is that this tool for evaluation should not be discarded.
> downleveled from senior to mid ... because I didn't have enough years of experience in tech-specific jobs ... I was disappointed in Shopify for using such a reductive metric to determine levelling
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?
Being downleveled for "years of experience" is obviously silly.
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.
> No. You've drifted into believing your opinions are facts.
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.
I feel like it's reasonable to hire someone at a lower level due to lack of years of experience.
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.
Years of experience is relative to the company, and software type. Companies like Google, production products are likely on a totally different level than almost any other product in existence. So 10yrs at none google company is not equal to Google engineering. What plays into all of this is the complexity of the problems they solve at scale, and level of academic sophistication. Map software, search engines, Google app suite gui products are not simple or easy to build.
You contradict your own point. Even that adage accepts that the upper bound on the amount of experience you have is based on the time you spend. You can have 1 year's worth in 1 year, or 1 year's worth in 10. But you can't get 10 years' worth in 1 year.
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.
You can have 10 years of experience, or 1 year of experience repeated 10 times.
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 think that's completely fair, but are we really talking about people with 1 year of experience as if they have 10 years?
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.
> I'm not saying experience doesn't matter at all, just saying that it's a poor marker for seniority.
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.
Yes. It's reasonable to say that some people with 15 years of experience won't be qualified for some senior role and others will be. But unless there are really unusual circumstances, you're probably not hiring someone with just a couple years of experience for that role--however well their interview went.
They might have said "years of experience" because the candidate was lacking some important skills that Shopify needs in their senior engineers, and Shopify felt that the candidate was plenty smart and the only reason they hadn't learned those skills was a lack of time and opportunity, which a few more years in the industry would likely cure.
Sometimes the handful of words that filter through on the internet don't do justice to the reasoning behind them.
I think the problem is they knew his CV and were interviewing him for a senior role. It's a little manipulative to string him along as interviewing for a senior role when they knew up front they never would have hired him for that role.
It says in the quoted paragraph that they downlevelled him due to his answers in the interview, particularly soft questions. Soft skills are extremely important for a senior, much more than a mid.
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.
> Most of the "frontend work" I saw was via Rails ERB templates
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.
The way I read this is that they had tech experience (e.g. not mowing lawns) but that it wasn't related to Shopify tech, so something other than Rails, JS/TS, etc. Still, it seems to me like as good a reason to get downlevelled as any. If you join a Rails company without Rails experience, I would expect a downlevel but an articulated path to "get back" to your current level faster than normal.
> Isn't this a pretty sensible reason to be downleveled
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 think requiring "years of experience" is a relative reflection of the employeer.
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?
Agreed ‘years of experience’ is a crap measure. I’ve interviewed people that put 20+ years Linux experience on their C.V. yet knew nothing about grub or systemd (as examples).
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.
Surely on average, all else being equal - a 20+ year C++ vet would be better than a 1 year C++ programmer, no? Are you saying experience simply doesn't measure anything in programming?
I mean I'm a decent programmer but I do mostly Ruby and web stuff. I don't think I'm gonna be that great in C++ compared to most 20 year old veterans.
You would think so but in my personal experience people massively over estimate how competent they are in a language. Even more so when they haven't actually used it in a while (let's say >1 year).
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.
> people massively over estimate how competent they are in a language.
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.
> 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. [..] And we've got a few juniors/midlevels that could out code almost anyone of the team.
I mean, there's much more to Analyst and Engineering jobs than coding, especially as you advance up the levels.
Isn't it like that in most fields? Are there never any mid level accountants/lawyers/teachers/doctors who are better than their senior superiors but have to stay the course and bite their lip until they are promoted or get better pay?
I've worked with countless engineers who've had 10+ years under their belt that were outperformed and outthought by engineers with half the experience. People with low skill levels and a lot experience exist. The opposite does as well.
I'm not surprised that a large corp uses reductive and rigid leveling methods to, it happens at scale.
Counterpoint: I left a company where I was a Senior Software Engineer and among the most experienced devs of the ~25 they had and joined a company where I was clearly the least experienced dev of the ~10 they had. The CEO of the new company told me that Senior wasn't a realistic title for me in comparison to everyone else and I'd be hired as a Software Engineer—but that I should feel free to use "senior" on my résumé if I thought it'd be helpful.
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.
Perhaps in the FAANG community there's room for this kind of introspection. There are many accomplishments and accolades you can point to that carry a great deal of weight.
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 dont think it's unreasonable. Like any standard, it's imperfect, and shouldn't be followed mindlessly. But it has some basis in reality, in that most people get better at their job the longer they do it, and few people get worse.
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.
I think it's a bit silly as a rationale alone. But it's pretty clear from the rest of the article that this engineer isn't nearly as senior as they percieve themselves to be. For instance...
"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.
Someone once stated, and I kick myself for not remembering who, that becoming an adult is the process of integrating all of your life experiences (and using them).
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.
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've had two dev jobs in my career that wound up being very different than advertised, the best I can tell is that companies will say pretty much whatever you want to hear as a candidate, but when it comes time to solidify a product roadmap, you have to be flexible.
In one case, I was hired as a back end services engineer and wound up working almost exclusively on a React SPA. In another case, I was also hired on as a back end services engineer and my team was asked to take over development of a native mobile app even though only one out of my four teammates had any iOS experience (I had none). It took our team two months to ship anything meaningful (a talented mobile team could've knocked it out in a sprint) and then it was immediately back to web work.
In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies).
> In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies).
This is something I’m dealing with in my current job. I would love to hear how people have been successful at conveying this to leadership.
I started asking my boss to commit me to 6 months on a new stack if that's what they really needed me to do, making the argument that it takes at least a month to really become productive and several more to internalize the concepts. He understood and agreed that the constant context switching didn't make much sense because it slowed us down, but he couldn't make any promises. Things didn't change and I left a few months later when I got a better offer.
In the past I've explained this as a comparison of Costs and Outcomes. The total cost of the plan, and the outcomes (mostly as benefits). In the GP's example it could have been, for example, the cost in time for the existing to develop the iOS application, the opportunity cost that's being given up by causing schedule slippages, and the discretionary effort of staff based on doing unfavorable work for the benefits of reducing management complexity, upskilling existing staff, and gaining a wider variety of experience within the team.
Alternatives such as using a supplier to build the iOS have their own costs and outcomes. For example, cost in terms of capital dollars, a technical person still needs to invest time in finding the correct supplier, a technical person still needs to invest time into creating the specification to build upon (even if you find a supplier which can do agile and incremental delivery/iteration), and management overhead for managing the team and/or relationship with the supplier. Further, since the product is something that needs to be maintained (presumably), a maintenance plan of some sort will need to be put into place, and for the benefit of getting it done more quickly, a better product by developers interested and competent in the domain the total cost will likely be lower, and other projects will slip less. There's also the advantage that if management has to put in capital dollars then they are more likely to take the project seriously and fund its maintenance and reward those involved, especially if that's accounted for up front.
There's another perspective that might be worth considering - management knew your team would deliver. Specific platform skills are learnable. The ability to ship something isn't always - especially at scale.
I'd much rather give a team 3 months to ship something that I'm 99% confident will be delivered than to try it twice with two teams that have an 80% chance of delivery each.
The problem in that particular case was that the company did this so much with various teams that it caused incredible turnover.
We had a great mobile team that slowly left the company because they were being asked to prioritize web work, and when they all left and the company realized that there was mobile work to be done, they started asking us web devs to prioritize mobile. They were getting lots of complaints across the org of never-ending context switching and they didn't really care.
I'll ship stuff because it's my job, but I won't stick around for management that can't be bothered to keep their mobile and web teams happy enough to prevent these insane context switches.
> In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies).
Interestingly I see this is a few ways:
* Every small 15-30 minute call knocks me out for hours. I really need at least one full day a week with minimal meetings and that includes the daily stand-up. I honestly think the daily stand-up costs companies millions per year in productivity cost
* Moving from project feature to feature is costly. So if you're working on feature X this sprint and then the PO moves to feature Y in the next sprint due to priorities it'll slow down dev. Doing this often (say every sprint) will kill velocity
* Moving from project A to project B is also a big killer for productivity
* Moving around tech stacks as you've said it happens occasionally in my experience but when it happens you're often flustered
>Engineers can become interviewers inside of their first six months at the company
I started this after 1 month at a company and it sucks. I think it makes sense for leads/managers to do interviews quickly after joining if they were hired to build a team, but seniors are sometimes not team leads at companies.
Key reasons why this will make your new employee uncomfortable:
- They probably don't know the company very well. You're intentionally choosing someone who doesn't know the company to represent the company. That's going to make them uncomfortable and it appears to be a bad decision on the company's part
- If you hired someone primarily for coding, you're throwing interviews in along with learning the code base and company and other teams
- If you didn't tell them they'd be interviewing soon after joining (they didn't tell me), your company appears deceptive
At a previous employer I had people that we just hire be our +1 and shadow the interview process, if they wanted to of course.
They really appreciated this since it showed them that there was no hidden conspiracy in the process, we were giving everbody that applied the same opportunities to be accepted, and we showed then that throughout the process we were actually trying to find a fit for a person within the company instead of trying to find reasons to reject them. This also gave the new candidate the chance to aks the new hire questions related to their own interview process and first impressions in the company and eased the tension a bit.
If they wanted to carry on and participate in interviewing the next session we would let them lead the challenge, with me shadowing, to gain confidence and experience, and later on, if they still wanted to carry on, they would be fully qualified to do interviews just like other members of their team (unless of course they really weren't capable, but that never happened).
So I would say the approach really matters when discussing things like this. For us it was a positive.
> Work-life balance at Shopify is unparalleled. Work is synchronous-ish but it's super easy to run out for some afternoon errands or a quick workout. Shopify is pretty visionary here - turns out happy and healthy employees do better work than ones that are chained to a desk all day
Is this really that unusual? I feel like most places I've worked, as long as I made it to meetings nobody cared if I stepped out for an hour to run errands or something.
It’s not unusual at all. It would actually be more strange in 2022 if a tech company was trying to micromanage every hour of every day of each tech employee.
This is good to hear! I’ve worked positions before where this definitely wasn’t the case (had to use limited PTO for doctor’s appts). Maybe this is something that’s changed significantly since COVID
Lets obviously ignore the large percentage of the workforce that are waiting tables, stacking shelves, have to use a punchcard and have their hours tracked to the nearest minute etc. for whom stepping out for an hour to run an errand probably means they get paid a couple of hours less at best or fired if its done without the permission of their supervisor ...
Professional 'knowledge' workers - there are workplaces where its ok, there are workplaces where you would put your career into reverse at 100mph by not being present from 7am to 8pm for your 9am-5pm job.
You'd be surprised. So many places it is not the thing. Or it is made hasslesome with team calendar update plus email to manager with justification and so on.
I can only speak for myself, but it doesn't feel that uncommon. It probably depends on the kind of business you're working in. I've heard bad things about finance, for one.
Having worked for almost ten years now, I've always been able to take off an hour here and there without having to battle for it or come back with doctor's notes. When I was a contractor I'd generally have to tell someone and make up the time, but even then it was never a huge deal. Where I work now no one cares what I do at all as long as I'm reasonably productive.
Technically your work hours here have to encompass (IIRC) 11-3 I think? Or 9-3? Something like that. So no working third shift, I guess. But it's pretty flexible.
At every company I've worked at where I stayed for a bit, I eventually had to work on languages and stacks that I wasn't technically hired for/had interest in. At the very beginning I found this very hard, also wanting to quit/actually quitting. I've come to accept that this is actually pretty normal. The benefits to my career from working on a bunch of different stuff I didn't pick have been substantial.
Caveat: I probably wouldn't take the switcharoo at the very beginning either...if I'm told I'll work on A but actually get B, this is likely a sign of some important things not working well at the org.
It's fine when the context switching is managed properly. It's not OK when a company asks a team to spend a month working on a rails service, followed by a month of working on a native app, followed by a month of working on a web front end, which I have experienced.
You wind up exhausting yourself trying to pick up new technologies that you wind up forgetting because you're not given enough time to deeply learn the concepts.
I've had two companies that switched technology between recruiting me and the start of my employment. It was a bit irritating, but provided an interesting way to learn something new on someone else's dime.
I've also been at a place where I was not allowed to program in C, but had to do all the code reviews for the people programming in C. The "logic" was that since I was doing the code reviews, I shouldn't program in C since no one would review my code. I sometimes wonder about how I encounter these situations a bit too often.
> Shopify has a Life Story round. Due to developers' insistence on rebranding everything, this is just a cutesy title for a work history interview.
When I interviewed at Shopify, naïve as I was (or perhaps just overly-literal, as engineers are wont to be), I thought they actually wanted my life-story in the "Life Story" interview. I told of how I have a non-traditional background for CS, how I had children early and how it influenced my life, how I moved my family to a farm as a work-trade after being laid off from my first full time programming job. The interviewer (recruiter I think) kept steering thus: "oh wow! So then after that, what was your next job?" and "interesting! And what kind of programming languages did you use at that job?"
It took me a minute to realize she just wanted me to recite my CV. I found the Shopify folks to be very cordial and the interview was a positive experience overall even though it did not result in an offer. This was about 5 years ago.
The intent could very well be to get people to volunteer information you otherwise can’t directly ask. “Life story” is such an odd way to label it if they just want to know your career path to date.
Communication goes both ways. It is a very reasonable assumption that a life story is about your whole life, not just your education and professional career.
The recruiters should explain what they mean if they are redefining terms, especially since people regularly interpret it differently.
This is what Shopify has to say about the Life Story:
> For the Life Story, you can expect an informal 60-minute conversation via video with a Recruiter from our team. Interviews at Shopify are two-sided conversations. We are genuinely interested in getting to know you and we want you to get to know us, too.
It seemed so out of the blue to be asked the typical questions contract recruiters ask about programming languages and years of experience in those languages.
Yeah this sort of language was what threw me off. It explicitly states that they want to "get to know you" in a way that, presumably, extends beyond "how many years JavaScript experience."
I actually remember thinking "perhaps figuring out that the question they asked is not the question they actually want answered is the test. Figuring out that a stakeholder wants something very different than what they initially ask for is a very important skill for developers." If so, good on shopify recruiters! They're playing 3D chess.
Shopify has a pretty solid rep for having good work life balance, and in general. I routinely hear stories of people taking pay cuts to work there because of how well it integrates into life.
They used to say "tell me a little bit about yourself." At least for a literal-minded developer the "little bit" added some guard rails against unnecessary verbosity.
This is the kind of process you end up with when you have way, way too many people paid to do a certain job. It probably sounded great on a slide deck somewhere after months or years of iteration, but once it reaches front-line employees who do the actual work I’m guessing it’s just another arbitrary process they have to follow to do their job the corporate-approved way.
I had a similar experience at a company that made software that scanned text for social equality (i.e. it would flag something like "our guys make great bread") in corporate copy. I am pretty liberal but was still kinda nervous about not being "woke" enough, so when the interviewer asked me about times I had faced adversity I launched into a diatribe about breaking away from a conservative religious background and friction with my family etc. She was like... "ok how about adversity in your past software roles?"
That's pretty funny. I have to admit, though: "adversity" is an odd term to use when they meant challenges specifically related to your past jobs. Ask about how a candidate dealt with conflict, or dealt with being asked to meet an unreasonable timeline, sure: but adversity?
Especially for a company that worked on social equity issues, conflating life adversity with sundry issues faced in a corporate job seems odd. Your answer seems pretty appropriate!
That's hilarious! Also a bit disturbing that you felt the need to recite some political "party line" to get a job (not that I think you were wrong), but I suppose if it's an explicitly political org it could make sense.
But more generally, I'm now interested in completely misinterpreted interview questions, and funny stories about same.
My favorite was at a dying startup when Amazon interviewed anyone willing and gave us all their leadership principles to read beforehand. One person got a question wrong and when challenged thought they were testing on “disagree and commit” and so doubled down thinking that’s what they wanted to see.
It's kind of odd how much of the interview process for a developer is counter-intuitive.
Like the coding challenge. The naive expectation is that you quickly and correctly solve the problem they give you. But the actual expectation emphasizes asking about edge cases and collaborating with your interviewer. Solving the problem quickly and correctly is not actually the optimal solution. Partially because it doesn't allow you to demonstrate collaboration but also because the interviewer might think you've seen the problem before and have memorized a solution. Even though memorizing a solution and regurgitating it is basically what everyone does on these challenges.
General work experience questions are similar. You don't want to tell the truth. You want to give a STAR (situation, task, action, result) answer that shows you have whatever characteristic they're looking for. The majority of people won't have actual good stories for most of those so just hammer that grain of truth into whatever the interviewer wants.
I'd add thoughts about system design, but I really suck at those and still haven't quite figured out what everyone's looking for.
> The majority of people won't have actual good stories
Oh, god. Sometimes it's like pulling teeth to get people to respond with concrete stories. Lie for all I care, but tell me something about what you've done in the past. Granted, I haven't interviewed anyone since I was in college hiring other college students, so hopefully people in the real job market do better here.
I've given ~50 system design interviews. Personally, I'm looking for a combination of problem solving and collaboration skills. I am not particularly concerned about the quality of the system they have designed by the end of the interview, I'm more interested in:
- whether they understand an issue when I try to "poke a hole" in their design
- whether they can quickly synthesize that problem into a possible solution (even if it isn't the best solution) and what the tradeoffs of the solution are
- how easy it is for me to understand the solution as they're explaining it
Essentially, I am testing their ability to contribute in a technical design discussion while remaining humble and open minded.
I admit it would also be nice to test their ability to actually design a good system, but rating someone on their ability to do that in a reasonable time frame seems far too fraught with biases around what "good" is or the degree of familiarity with the domain.
> it was because I didn't have enough years of experience in tech-specific jobs.
This is almost certainly not the case. It was likely due to the answers given in the soft skills interview that belied a lack of experience. The author further confirmed this view (for me) by talking so much about their technical skills becoming rusty. That's actually the natural state at Senior+ levels as you should be spending a lot of your time on influence: code reviews, mentoring more junior people, figuring out requirements and so on. You may be able to get by at a purely technical person at Senior but you're going to be fighting forces pulling you away from that to some degree.
Here's the way I like to think about it based on the Google/FB levelling ladder and what you're responsible for:
- L3 (college grad): Task. You are given a task to do and need to deliver it. Example: fix an issue with Javascript timeouts on an auto-complete box;
- L4 (PhD or 1-3 years of experience): Feature. You will be responsible for delivering a feature. This requires more autonomy and self-direction and breaking down a feature into tasks. Example: add a user settings and preferences panel.
- L5 (Senior): Project. This is where you start to work more across different teams. Example: ship rewind for Live videos from backend requirements to UI.
- L6 (Team). This is where responsibility shifts. Instead of being told what to do, you should be telling your management chain what they should be doing. This also includes larger projects but often includes forecasting, risk analysis, tracking and so on.
On this scale, the author comes across to me with a very L4 mindset so it sounds like they were correctly levelled. What's more, putting them in as L5 could be setting them up for failure.
I didn't see in the post how much and what experience the author had but it does matter how much is as an engineer and even how much is in a big tech company. It matters.
Here's an example of how this matters: the author didn't like doing so much in Rails (ERB). I haven't worked at Shopify so I may off base here but it sounds like Shopify uses a similar distinction that Facebook does.
FB largely categorizes people as product (Product Generalists) or infra (Systems Generalists). There are strictly UI engineers but they're less common than product engineers. There are also specialists.
product engineers will deal with everything from the UI (HTML/JS/CSS) down to the storage layer and can include things like providing APIs. As an FB product engineer you may never touch JS. Or you may do it 80% of the time. It varies.
But the point is that this dividing line is deeper than a lot of traditional FE engineers might be used to. That's not necessarily good or bad. But it may be different.
A better way of putting it is the author has made that claim. That doesn't necessarily make it true. Likely several factors went into the levelling decision. If anything, the (assumedly) limited years of experience were a factor. It may be what was communicated to the author. It may simply be how the author took it even if it wasn't explicitly stated.
But what I do know is that (again, on the FB/Google scale) being levelled as an L4 with 5-10+ of experience does happen and it's usually (IME at least) appropriate. YMMV.
The ladders technically start from level 0. Google actually had L0s whose job, as best as I could gather, was to take things from point A to point B during, say, an equipment install.
The SWE ladder however starts at L3. With extremely few or zero exceptions, no SWE is hired at L0-2.
The idea is that people at the same level in different levels are at roughly the same level of responsibility.
The impression I get of Shopify is that they hire more than they need and churn out the less successful in the first year. This is only a second hand observation though since I don't work there.
This is mildly interesting but I'm not sure why its so high on HN, is it because people don't often write about such experiences with companies like this?
And to be honest, if you know anything about Shopify you'd know they're a famously Rails-heavy stack. Thus working on erb templates is pretty much guaranteed. Although apparently this wasn't 'interesting' enough
While I’m generally cautious that “Years of Experience” isn’t a great reason to downlevel, I also wouldn’t expect someone to be a “Senior” after graduating (even with a PhD, and even if it were in Computer Science or a closely related field) in ~2 years either.
https://www.linkedin.com/in/joshcsimmons doesn’t mention graduation year and seems to try to pass off the UC Irvine time as professional experience rather than academic, but other social profiles like Quora say “Graduated 2019” after doing a PhD in Music Composition & Music Technology.
I’m sorry to hear Shopify wasn’t the experience you wanted.
I read this as the posting was for Senior and the offer extended was at a lower level, that’s not uncommon — Amazon particularly is somewhat famous for down-levels happening in interview debriefs.
I don’t think Josh started as a Senior and then got demoted, the post explicitly says the $ was less than desired (due to the offer being made at the lower level).
> I also wouldn’t expect someone to be a “Senior” after graduating (even with a PhD, and even if it were in Computer Science or a closely related field) in ~2 years either.
I suppose it depends on your org. Where I work "senior" is the second level up, where the first level is given to new hires fresh out of college (mostly master's, some bachelor's). If someone comes in with a PhD in a related field -- though perhaps not a completely unrelated one like music composition -- I'd be surprised for them not be a senior or even a lead (the third level up). The researcher positions that require a PhD tend to be advertised as leads in my experience.
I was originally hired as a senior data scientist although I had minimal relevant work experience, but I had worked in an arguably related field (mostly ETL) for 5 years after bailing out of a PhD program (all but dissertation in economics).
> UC Irvine time as professional experience rather than academic
If I’m an employee of the school while also getting my degree, that is professional experience. I’ve done the same working for a HPC IT department for a university that supported university departments and 3rd parties customers.
Dismissing working for a university IT department, if that is the case, isn’t fair.
From my point of view SSR is still frontend, maybe not the kind of workflow the author was expecting, but still is producing HTML, CS and eventually some JS down to the browser.
> but I felt the months ticking by and my frontend skills degrading
I don't doubt the author, but this specific statement seems off to me in a general sense.
Sure, you can get rusty with a specific set of tools, but picking them up at a later stage should not be too much of a hassle. _Should_ is the keyword here.
Do others feel this way? Am I misinterpreting this?
No, that line stood out to me too. I felt like that clearly expressed the lack of experience and maturity the author has with programming. Over the short term it is definitely possible to have a skill set degrade in a particular language or framework, but over the long term, this becomes normal and you tend to apply what you learn in one place to another place, despite using different technologies. And HTML in a browser is always frontend, regardless of tech…
I felt the same. "Months ticking" is like the OP is having some kind of career angst, or maybe I am out of the Silicon Valley rat race and world-class engineers think that way.
As a React developer who can also sling Rails + ERB, they're very different skillsets, even though they're both broadly "frontend".
I can see why someone who's trying to make a career as a React developer would see a primiarily-ERB role as a detour. And maybe in their next round of interviews, people would question how good they are at React if they spent the last X years doing mainly ERB/HTML with only sprinkles of React. "I see you don't have a lot of recent React experience..."
And yeah, I agree - a person can get rusty with some tools and pick them up again just fine. The trouble isn't whether you (the interviewee) believes that, it's more about convincing the person on the other side of the table. The perception in JS-land is that things change Very Fast™ and that skills quickly go obsolete. (Disregarding that if you zoom out, React hasn't changed majorly in 4 years and it's been the dominant choice for 6+ – the perception of fast-paced change is definitely a thing)
I think the author is justified in his thinking here. It's a large time investment to build skills to a certain level. To just set aside those hard earned skills, and not know when or if you'll be able to utilize them again is demoralizing. Especially if you enjoyed working with said technologies.
I can understand that, but that's kind of the opposite problem. You invested time and practice, now you want to benefit from it, versus you are currently not investing in the same skill, which degrades it over time. The latter seems overblown to me personally. Sure, to get warm again with some specific tech takes some effort, but it doesn't get lost.
Fist bump to quitting early. I am leaving a company after only 3 months (Edit-- I also will not plan on working for several more months!). My parents (both in their 50's, who are used to the idea of working all the way from 22 to 65 years old in your life) do not like it one bit. But then again, as Americans we all have some weird hardcore norms about work. That attitude is slowly changing I think.
Funny enough, I had a bit of the opposite happen in the interview -- I was upleveled due to my performance, and the money was awesome. Just had a lot of reasons for feeling unfulfilled.
Good for you. A lot of commenters getting hung up on the mechanics of the process. There’s a lot of cultural norms about what to do in this situation but at the end of the day you’re the one the one that has to live with your decisions.
If I'm reviewing a CV I'm not going to ding someone for leaving a job a few months in, but I am going to be asking some carefully worded questions about why you left to work out whether you left of your own accord, or you were asked to leave before the probation period ended and the company were stuck with you on a three month notice period. (Its possible the US market is different in this regard, where as far as I'm aware everyone is on 2 week notice periods all the time)
I'm in the process of leaving a company after 6 months at the moment and I know I'm going to probably get this question forever now, but end of the day I have my reasons, and I think they're valid and will likely be judged as such. I think going in to any other job I'm equally as motivated as any interviewer to not have it happen again given how painful an experience this has been. In my case I wouldn't necessarily say it was bait and switch, but I wasn't made aware of something that would have led me to turn down the offer had I known about it beforehand as I knew it wouldn't be a good fit, but I also didn't think to ask because I was making assumptions based on all my pre-covid experiences. I guess I learned a lesson there.
> There is even a bit of a stigma about working while sick - if you do so, your coworkers will urge you to just take a day and rest up instead. Pretty cool and pretty rare.
I feel like it’s not acceptable anymore to go to work while being sick since the Covid-19. I would be upset if I see a sick coworker at work.
They're referring to Slack, and encouraging sick coworkers to take time off. We do this too, because a lot of people feel like "I'm sick, but I'm just sitting at home anyway, I might as well take this meeting".
I've always felt this for my entire working career which is about 20 years now (16 dev and 4 retail).
Sick workers productivity was close to 0 in almost all instances. For Retail that meant they were not on the checkouts but out on the shop floor goofing around and ignoring customers. They could also be in the toilets for hours at a time which meant that the other employees would be picking up slack for them rather than them being off and having to get someone to cover for them.
In terms of dev they would be in the office but only there in person. If you had a meeting they would make seemingly random decisions. If they are programming at their desk their code would be buggy and could take up to 10 times as long for them to write. I'd rather be able to explain that a feature was late as one of the devs was ill rather than they came in and tried to work whilst being ill and failed.
Being ill and taking time to recover is part of doing business. Companies should factor this into their plans. Not doing so is a company issue not an issue with an employee being sick.
I mean no-one wants to be ill it's not really your choice. I'm not enjoying myself being ill, it sucks. Going to work draws this process out and makes your fellow co-workers sick.
I've always taken time off when I'm ill and I will continue to do so and so should everyone else.
P.S. I include Mental illness in this as well.
If you're having a bad day / week / month mentally TAKE SOME TIME OFF!
I'm really sorry to about how this played out for you. I can see some similarity to the bumps I faced when I joined Shopify.
> I don't doubt that more frontend work was coming down the pipeline for my team - even greenfield work - but I felt the months ticking by and my frontend skills degrading. In order to triage this, I worked on a number of frontend projects in my spare time at a pace that was admittedly draining.
With me, it wasn't so much that I wasn't learning at the start, it was that I wasn't really working on meaty/challenging tasks/projects. This was several years ago. It took a while probably more than a year after having shipped a major feature from beginning to end with a team to understand what 'scale' means at Shopify. Normally when we think scale, we think users, servers, requests/sec. Shopify scale is more like shipping via ocean tanker vs 1-day delivery drone. Imagine my shock finding myself accidentally (that's another story) at Shopify coming from a series of startups and missing the pace of work. To be clear, I didn't ship anything part of a whole project in my first 5 months either. I think this got dealt with in my case, because my attempts to make faster/greater impact was conflicting with established process standards. This was fortunate as it led to discussions about mindset. It was still hard to internalize: we design, build, and ship the right thing, only when it's ready, to millions of customers. It only makes sense if you think about it in a year+ timeframe.
> I asked myself the question, "Am I becoming a better frontend developer through this experience?" and the answer was of course no. These things are complex though and I could see how maybe six months or a year from various points I might be working on some exciting frontend work. This line of self-questioning mutated into, "Do I care about eCommerce?" It was a question I never had the bravery to ask myself before. I've worked almost exclusively in eCommerce of one form or another since I started working in tech. I began to wonder if it might be time to try something different.
When I started I didn't even know what Shopify was really, only that they made web storefronts like many other website/checkout product/companies. As I worked there I realized that there's a big difference. Shopify's storefront/checkout is only the tip of the platform, the rest you can't see are the parts used by the merchants.
I did also think, is this the place for me? My asking was about the tech stack. I only had one Rails job before and it wasn't my cup of tea. I did stick it out though, for the reasons of working with great people, both peers and management. One thing I didn't take for granted was that Shopify is a good company. Perhaps I didn't start interested in Commerce (no 'e' Shopify does Retail too, the team I started on :-), but I did understand that trade, in particular international trade, and also at all levels and not just megacorps, can actually make the world better. I think getting and shipping international orders is a pretty eye-opening moment for merchants. Eventually I also got to work on very challenging technical problems, which do regardless of tech stack.
> Everything on the surface was good for me at Shopify and I want to take some space to recognize that.
I'm sorry that this didn't work out. I do agree that there are layers, but also that there are more than two layers. DM me for anything.
338 comments
[ 3.3 ms ] story [ 288 ms ] threadedit: this wasn't meant to insult OP, sorry
Why is there always the tendency to blame the person and NOT the company?
If you apply for a role that is explained to you, what does it matter what the company mostly does? If I apply to a rail maintenance company as a programmer, should I expect to maintain rail? No.
I left HashiCorp in 4 months for basically the same reason, just swap our frontend with Go.
I was interviewed in Go and I knew the team was using Ruby but all the teammates were energetic for having someone else who knew Go, wasn't all about Ruby/Rails and the team was great. But the opportunities on other teams to build out things in Go and work on the existing Go codebases, both public and private, was just teasing me every day. I tried to work on one of our open source libraries and was told I was stepping on someone else's toes and could be taking opportunities away from them.
I would return in a heartbeat on one of the Go teams working on one of the Go products. I think they are just great in the Go community and their tools are fantastic.
This article is generally positive. The author liked the people, had a positive sentiment of the interview process, was impressed by the tech stack, had a solid manager, etc. It just wasn't the tech stack they wanted to be working with.
People don't want to hurt their employment prospects, so it's understandable if they are selective about what they reveal, but that's why I don't trust accounts like this.
> My hunch with those companies was that it wouldn't have been a major issue if I was video-ing in from the State Penitentiary (due to murder charges) as long as I solved the algorithms correctly
the OP clearly has some skills to his name and even academic background, yet they'd like him to solve coding puzzles
i could get $100k freelance contract only after 1 meeting and bit of paperwork, but tech bros won't accept me cause i don't do puzzles
But if you are accepted purely on coding puzzles, then your colleagues also were. Meaning, they might be difficult to work with (such as: overconfidence, always criticising the code they didn't write, shaming people in large meetings, repeatedly overpromising, or other bad behaviours).
Sadly, Shopify's care and interest in his individuality didn't extend past the interview stage, as he was given work that shouldn't be expected from a front end focused developer.
Editing HTML templates (ERB) is front end development.
I thought that described today's interviewing zeitgeist, pretty well. In my experience, absolutely no one even glanced at the dozens of open-source repos (for finished, documented, tested products), or the hundreds of pages of writing I have amassed, over the years, which ahem, are actual artifacts of lots of my "proper" thinking.
I've only practiced a few Codility exercises, a few years ago, when I was still interested in working with someone else. Otherwise, I never practice leetcode. As I am quite aware that many, many people practice these types of things, for hours every day (I strongly suspect while being paid by their current employers), I just consider that a wash.
If this is a requirement, then I'll never get hired, and I might as well give up (I can actually do reasonably well, at these kinds of things -mostly-, as they are usually basic commonsense exercises, but I won't ever have the rote efficiency of a practiced leetcoder).
Since I don't actually need the work, I accepted that this is just the way things are, and withdrew from consideration.
Too bad. I suspect that some companies that I would have enjoyed working at, and that I could have been a valuable IC at, are maybe having to deal with less-than-ideal workers.
people who practice leetcode are either unemployed or too desperate to get a job
employers who do this have bad hiring practices and bad attitude
my personal advice: get work from people you know, beggars can't be choosers
I wouldn't necessarily say this. Since it is "how things are done," these days, I strongly suspect that folks want every competitive advantage they can get, and it's perfectly understandable.
It's just that it's an extremely 1-dimensional way of evaluating people that are supposed to be creative and intelligent. It doesn't actually tell you anything about them; just that they are good at practicing rote (which, to be fair, may be exactly what a corporation is looking for).
I am very fortunate. I spent my life, living frugally, and investing carefully, so I have the ability to step back. I know that very few people have this capability.
A career is a really big deal, and worth it to prepare for.
The problem is that over thirty years of shipping software is not something that is easy to express in a few scholastic tests. It's something that can sometimes be easily demonstrated, but consuming and evaluating it is time-consuming.
I have spent a lot more time, preparing my portfolio, than lots of folks have spent at leetcode. If that's not valuable to a company, then, c'est la vie.
I done one hacker rank on my last round of interviews and it absolutely killed my confidence. It was 5 questions automatically timed to 15 minutes. So in terms of completing it you really need to have seen these types of questions before as they left no "thinking" time only time to type up the solution and a short debug.
I got 3.5 of the questions finished in that time so I'm going to be working on my speed for the next time.
Like you I think it's kinda sad given that the people who promote this style of interview say is so that they can assess how you "think" or "approach" a programming problem. The reality is that it's a hazing ritual, they are looking for you to have seen the type of question before memorise how to solve it and instantly start applying that in the interview.
I'd note that overly strict interviews often cause companies to not be able to hire efficiently and effectively which the very same companies will complain loudly about. Companies I've worked for rejected almost all candidates and still complained they couldn't hire anyone.
I’ve hired both contractors and employees.
Contractors almost always arrive with more of a verifiable portfolio and verifiable references.
Contractors are also much easier to cut off early if we realize they aren’t delivering. A $100K contract could end up being cheaper than the amount of money we waste on a bad hire from start to finish by a factor of 2X.
The bar for hiring full-time employees is higher than contractors.
It wasn't per se a large org issue, or such - or a "scandal" that is so commercialized into #movements today.
He just didn't like the work, expected more, didn't get a good offer (it was downgraded from his perspective) and in the end didn't think it was worth his time to stay.
That's a reasonable decision to make. Many people stay for the branding but hate the product.
I stayed as companies not liking the work, or the brand but just for the money and opportunity on my resume.
The people made it fun too, for a while but once the people change and the work becomes work work, it's time to go and I did.
He didn't like the backend work? Okay, that's actually quite fortunate for him, he can just quit and move on, but I'm here for Real Developers of Beverly Hills.
I posted my comment before the comment thread become full of people telling the OP they are wrong or bad, which I find very bizarre!
I did think the OP was not super clear about why they actually left, so I took a shot at summarizing what I think I got from it, to see if other readers shared my reading.
Seems like something other large companies could/should adopt.
Getting down-levelled through the interview process due to YOE, which is known before interviews even start, indicates some failures by the recruiters. Recruiters should've been able to set proper expectations up front.
I bet being down-levelled and leaving within a year are very strongly correlated and cost the company a lot.
It can get really bad.
I joined a Series A startup. Me and all my peer engineering directors got down-leveled to entry-level titles within a month.
Product Mangers, Sales People, others got up-leveled from Entry Level --> Manager --> Director --> Sr. Director.
The company is on a dying breath, because these shenanigans caused so much acrimony. Who the fuck cares about a company that fucks you over a month into joining the company? Half the engineers were working on side projects and the company has basically died.
1. check linked in. if you a dozen of kids out of undergrad in Marketing/Product/Sales/Strategy/Finance with Director+ titles a year or two out of college....and others out of industry with entry level titles, RUN. There is obvious inequity. You wont be able to motivate people to work hard with such a setup.
2. avoid companies with split executive offices. Our engineering group was 95% on the East coast while the "business" office was in SF. CEO/CFO/CPO/CRO all in SF. CTO on east coast.
Lemme guess the CEO/CFO/CPO/CRO all come from wealthy backgrounds and post inspiring tweets/linkedins whilst the company piledrives into the ground?
Wow, they demoted you post-hire!? Yeah, I'd immediately start interviewing elsewhere.
the result of the changes was a half-dead demotivated engineering team that never revived. titles were fixed three years in, but it was too late. business teams had moved onto bigger and better jobs by then. good luck trying to get hyper-growth when you've screwed over all the engineers
Leveling is simply a byproduct of your alternatives, not your experience or skills. I bet you that higher paying companies like Stripe/Robinhood have a more even spread, while others need to level people as senior to compete.
In my last interview bout, I've had some companies come back with senior leveling _after_ I told them I had competing offers. The blatant reality of "leveling" being tied to your negotiation prowess and not your engineering skill shocked even myself, as cynical as I am.
(Edit: I should say that I had a great experience interviewing at Coinbase, and recommend others to do the same)
The shock makes some sense (you were leaving after a short period of time), but where did their "immediate understanding" come from?
It sounded like your main issue was that the work wasn't as advertised. Is that common for Shopify hires?
What is WITCH?
edit: fixed url
Wipro, Infosys, TCS, Cognizant, HCL.
W- Wipro I- Infosys T- TCS C- Cognizant H- HCL A- Accenture India.
[0] https://aphyr.com/posts/341-hexing-the-technical-interview
In 5 years, I'd expect a WITCH engineer to be exposed to and deeply understand many industries and companies. I'd expect them to learn to handle stakeholders as well as code. I'd expect them to be exposed to many different vendors and tech stacks.
But mostly I'd expect them to get really good at making a big impact very quickly, with limited time and people.
When I compare that to a guy getting paid $1 million a year to run a team of 4 people who build youtube revenue dashboards or something, adding one graph a month, I know who would want working on project I cared about.
The WITCH engineer was just unwise enough to be born in India right? Probably went to the top schools there, has an MBA and a masters in compsci... Just... Indian, so worth less for some reason.
The comparison is between FAANG FTE and WITCH contractor. This isn't to do with nationality or birthplace. There are many Indian FAANG FTEs just as there are many American and European WITCH contractors.
There's a sort of all or nothing aspect to how you handle the view layer in Rails, at least for a smaller code base. However, I'm sure Shopify is large enough that they have apps doing a little React, a little server rendered in ERB, and others that are fully React backed with an API, and probably some that don't have any JS framework at all.
Sounds to me like this person was overwhelmed by the sheer size of the codebase and how little control they had and decided it was not for them. I don't blame them. eCommerce is tough. eCommerce on such a customizable platform must be like walking through a minefield.
It's not "fun" per se in the front-end part, but it's absolutely fine, and what's required for my work. I don't mind it at all, if anything I'm happy and curious about BE/Python and how that part works.
It's comparative to hiring a front-end and putting them to work on .php files. It's so far back in the past, that it becomes degrading, and you start feeling regression in front-end skills.
1) The old style, where the server owns the routing but can cede control over html to the frontend for discreet applications. Always cedes control of JS and CSS to the frontend.
2) A fully separated frontend and backend application that talks to one another over REST or GraphQL
3) A very javascript-light frontend that uses a technology like LiveWire, LiveView, or Hotwire to render on the server but push reactively to the frontend
I think any is fine and each have their merits. I imagine that #3 is the one that is most likely to supersede #1 as it's a direct evolution. But I would think that it's a bit gatekeeping to tell someone whose whole job is HTML templates, javascript, and CSS that they are No True Frontender.
It's only regression in the exact language and framework you wanted to use. Certainly not "front-end skills".
I worked at a company where our iOS team refused to make multiple API calls for any given view. They wanted 100% of the data for _any_ given activity the user could do to be a single call, formatted how they wanted. I pushed very hard to let that team go, but failed, although I do still chuckle at the horrific reviews the app gets for general bugginess.
It's absolutely mind blowing that people getting paid 150k say "well I'll touch that code but _never_ that other code". I hate to paint with broad brush strokes, but I never once saw that attitude from a non-college graduate. Loathed to use the word "entitled", but holy cow.
In my opinion, "years of experience" should not be disqualified as one of multiple evaluation tools for skill. I think it signifies that you have had the opportunity to go through a variety of situations, challenges, projects etc. and you have accumulated knowledge and experience that cannot be learned by reading tutorials or working on side projects.
From personal experience and by talking to and working with other much more experienced engineers than me, I have noticed that some of the most important knowledge is obtained just by working on something for a longer amount of time.
Obviously, there are many exceptions to this rule, there are engineers with years and years of experience that are just bad at what they do. What I am trying to say is that this tool for evaluation should not be discarded.
But was shocked they consider a senior dev someone who had many jobs that made him a better developer.
WTF?
Soon we need Senior+ and Senior++ levels, if anyone can be senior.
The seniors i have seen, in my decade of programming, scare the shit out of me and make me feel like i just hello worlded into programming.
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?
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.
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.
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.
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.
> it wasn't based on my answers to soft questions
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 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.
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.
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.
I'm not surprised that a large corp uses reductive and rigid leveling methods to, it happens at scale.
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 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.
"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.
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.
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.)
In one case, I was hired as a back end services engineer and wound up working almost exclusively on a React SPA. In another case, I was also hired on as a back end services engineer and my team was asked to take over development of a native mobile app even though only one out of my four teammates had any iOS experience (I had none). It took our team two months to ship anything meaningful (a talented mobile team could've knocked it out in a sprint) and then it was immediately back to web work.
In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies).
This is something I’m dealing with in my current job. I would love to hear how people have been successful at conveying this to leadership.
Alternatives such as using a supplier to build the iOS have their own costs and outcomes. For example, cost in terms of capital dollars, a technical person still needs to invest time in finding the correct supplier, a technical person still needs to invest time into creating the specification to build upon (even if you find a supplier which can do agile and incremental delivery/iteration), and management overhead for managing the team and/or relationship with the supplier. Further, since the product is something that needs to be maintained (presumably), a maintenance plan of some sort will need to be put into place, and for the benefit of getting it done more quickly, a better product by developers interested and competent in the domain the total cost will likely be lower, and other projects will slip less. There's also the advantage that if management has to put in capital dollars then they are more likely to take the project seriously and fund its maintenance and reward those involved, especially if that's accounted for up front.
I'd much rather give a team 3 months to ship something that I'm 99% confident will be delivered than to try it twice with two teams that have an 80% chance of delivery each.
We had a great mobile team that slowly left the company because they were being asked to prioritize web work, and when they all left and the company realized that there was mobile work to be done, they started asking us web devs to prioritize mobile. They were getting lots of complaints across the org of never-ending context switching and they didn't really care.
I'll ship stuff because it's my job, but I won't stick around for management that can't be bothered to keep their mobile and web teams happy enough to prevent these insane context switches.
Interestingly I see this is a few ways:
* Every small 15-30 minute call knocks me out for hours. I really need at least one full day a week with minimal meetings and that includes the daily stand-up. I honestly think the daily stand-up costs companies millions per year in productivity cost
* Moving from project feature to feature is costly. So if you're working on feature X this sprint and then the PO moves to feature Y in the next sprint due to priorities it'll slow down dev. Doing this often (say every sprint) will kill velocity
* Moving from project A to project B is also a big killer for productivity
* Moving around tech stacks as you've said it happens occasionally in my experience but when it happens you're often flustered
I started this after 1 month at a company and it sucks. I think it makes sense for leads/managers to do interviews quickly after joining if they were hired to build a team, but seniors are sometimes not team leads at companies.
Key reasons why this will make your new employee uncomfortable:
- They probably don't know the company very well. You're intentionally choosing someone who doesn't know the company to represent the company. That's going to make them uncomfortable and it appears to be a bad decision on the company's part
- If you hired someone primarily for coding, you're throwing interviews in along with learning the code base and company and other teams
- If you didn't tell them they'd be interviewing soon after joining (they didn't tell me), your company appears deceptive
They really appreciated this since it showed them that there was no hidden conspiracy in the process, we were giving everbody that applied the same opportunities to be accepted, and we showed then that throughout the process we were actually trying to find a fit for a person within the company instead of trying to find reasons to reject them. This also gave the new candidate the chance to aks the new hire questions related to their own interview process and first impressions in the company and eased the tension a bit.
If they wanted to carry on and participate in interviewing the next session we would let them lead the challenge, with me shadowing, to gain confidence and experience, and later on, if they still wanted to carry on, they would be fully qualified to do interviews just like other members of their team (unless of course they really weren't capable, but that never happened).
So I would say the approach really matters when discussing things like this. For us it was a positive.
Is this really that unusual? I feel like most places I've worked, as long as I made it to meetings nobody cared if I stepped out for an hour to run errands or something.
Extremely.
Lets obviously ignore the large percentage of the workforce that are waiting tables, stacking shelves, have to use a punchcard and have their hours tracked to the nearest minute etc. for whom stepping out for an hour to run an errand probably means they get paid a couple of hours less at best or fired if its done without the permission of their supervisor ...
Professional 'knowledge' workers - there are workplaces where its ok, there are workplaces where you would put your career into reverse at 100mph by not being present from 7am to 8pm for your 9am-5pm job.
You'd be surprised. So many places it is not the thing. Or it is made hasslesome with team calendar update plus email to manager with justification and so on.
Having worked for almost ten years now, I've always been able to take off an hour here and there without having to battle for it or come back with doctor's notes. When I was a contractor I'd generally have to tell someone and make up the time, but even then it was never a huge deal. Where I work now no one cares what I do at all as long as I'm reasonably productive.
Technically your work hours here have to encompass (IIRC) 11-3 I think? Or 9-3? Something like that. So no working third shift, I guess. But it's pretty flexible.
Caveat: I probably wouldn't take the switcharoo at the very beginning either...if I'm told I'll work on A but actually get B, this is likely a sign of some important things not working well at the org.
You wind up exhausting yourself trying to pick up new technologies that you wind up forgetting because you're not given enough time to deeply learn the concepts.
I've also been at a place where I was not allowed to program in C, but had to do all the code reviews for the people programming in C. The "logic" was that since I was doing the code reviews, I shouldn't program in C since no one would review my code. I sometimes wonder about how I encounter these situations a bit too often.
When I interviewed at Shopify, naïve as I was (or perhaps just overly-literal, as engineers are wont to be), I thought they actually wanted my life-story in the "Life Story" interview. I told of how I have a non-traditional background for CS, how I had children early and how it influenced my life, how I moved my family to a farm as a work-trade after being laid off from my first full time programming job. The interviewer (recruiter I think) kept steering thus: "oh wow! So then after that, what was your next job?" and "interesting! And what kind of programming languages did you use at that job?"
It took me a minute to realize she just wanted me to recite my CV. I found the Shopify folks to be very cordial and the interview was a positive experience overall even though it did not result in an offer. This was about 5 years ago.
The recruiters should explain what they mean if they are redefining terms, especially since people regularly interpret it differently.
> For the Life Story, you can expect an informal 60-minute conversation via video with a Recruiter from our team. Interviews at Shopify are two-sided conversations. We are genuinely interested in getting to know you and we want you to get to know us, too.
It seemed so out of the blue to be asked the typical questions contract recruiters ask about programming languages and years of experience in those languages.
I actually remember thinking "perhaps figuring out that the question they asked is not the question they actually want answered is the test. Figuring out that a stakeholder wants something very different than what they initially ask for is a very important skill for developers." If so, good on shopify recruiters! They're playing 3D chess.
If a company thinks that life=work, then that's a red flag.
Especially for a company that worked on social equity issues, conflating life adversity with sundry issues faced in a corporate job seems odd. Your answer seems pretty appropriate!
But more generally, I'm now interested in completely misinterpreted interview questions, and funny stories about same.
Like the coding challenge. The naive expectation is that you quickly and correctly solve the problem they give you. But the actual expectation emphasizes asking about edge cases and collaborating with your interviewer. Solving the problem quickly and correctly is not actually the optimal solution. Partially because it doesn't allow you to demonstrate collaboration but also because the interviewer might think you've seen the problem before and have memorized a solution. Even though memorizing a solution and regurgitating it is basically what everyone does on these challenges.
General work experience questions are similar. You don't want to tell the truth. You want to give a STAR (situation, task, action, result) answer that shows you have whatever characteristic they're looking for. The majority of people won't have actual good stories for most of those so just hammer that grain of truth into whatever the interviewer wants.
I'd add thoughts about system design, but I really suck at those and still haven't quite figured out what everyone's looking for.
Oh, god. Sometimes it's like pulling teeth to get people to respond with concrete stories. Lie for all I care, but tell me something about what you've done in the past. Granted, I haven't interviewed anyone since I was in college hiring other college students, so hopefully people in the real job market do better here.
- whether they understand an issue when I try to "poke a hole" in their design
- whether they can quickly synthesize that problem into a possible solution (even if it isn't the best solution) and what the tradeoffs of the solution are
- how easy it is for me to understand the solution as they're explaining it
Essentially, I am testing their ability to contribute in a technical design discussion while remaining humble and open minded.
I admit it would also be nice to test their ability to actually design a good system, but rating someone on their ability to do that in a reasonable time frame seems far too fraught with biases around what "good" is or the degree of familiarity with the domain.
> it was because I didn't have enough years of experience in tech-specific jobs.
This is almost certainly not the case. It was likely due to the answers given in the soft skills interview that belied a lack of experience. The author further confirmed this view (for me) by talking so much about their technical skills becoming rusty. That's actually the natural state at Senior+ levels as you should be spending a lot of your time on influence: code reviews, mentoring more junior people, figuring out requirements and so on. You may be able to get by at a purely technical person at Senior but you're going to be fighting forces pulling you away from that to some degree.
Here's the way I like to think about it based on the Google/FB levelling ladder and what you're responsible for:
- L3 (college grad): Task. You are given a task to do and need to deliver it. Example: fix an issue with Javascript timeouts on an auto-complete box;
- L4 (PhD or 1-3 years of experience): Feature. You will be responsible for delivering a feature. This requires more autonomy and self-direction and breaking down a feature into tasks. Example: add a user settings and preferences panel.
- L5 (Senior): Project. This is where you start to work more across different teams. Example: ship rewind for Live videos from backend requirements to UI.
- L6 (Team). This is where responsibility shifts. Instead of being told what to do, you should be telling your management chain what they should be doing. This also includes larger projects but often includes forecasting, risk analysis, tracking and so on.
On this scale, the author comes across to me with a very L4 mindset so it sounds like they were correctly levelled. What's more, putting them in as L5 could be setting them up for failure.
I didn't see in the post how much and what experience the author had but it does matter how much is as an engineer and even how much is in a big tech company. It matters.
Here's an example of how this matters: the author didn't like doing so much in Rails (ERB). I haven't worked at Shopify so I may off base here but it sounds like Shopify uses a similar distinction that Facebook does.
FB largely categorizes people as product (Product Generalists) or infra (Systems Generalists). There are strictly UI engineers but they're less common than product engineers. There are also specialists.
product engineers will deal with everything from the UI (HTML/JS/CSS) down to the storage layer and can include things like providing APIs. As an FB product engineer you may never touch JS. Or you may do it 80% of the time. It varies.
But the point is that this dividing line is deeper than a lot of traditional FE engineers might be used to. That's not necessarily good or bad. But it may be different.
Except that it reads like they had made it clear to them that it was.
But what I do know is that (again, on the FB/Google scale) being levelled as an L4 with 5-10+ of experience does happen and it's usually (IME at least) appropriate. YMMV.
Why this stuff always starts at some random number like 3 or 5?
The SWE ladder however starts at L3. With extremely few or zero exceptions, no SWE is hired at L0-2.
The idea is that people at the same level in different levels are at roughly the same level of responsibility.
https://www.linkedin.com/in/joshcsimmons doesn’t mention graduation year and seems to try to pass off the UC Irvine time as professional experience rather than academic, but other social profiles like Quora say “Graduated 2019” after doing a PhD in Music Composition & Music Technology.
I’m sorry to hear Shopify wasn’t the experience you wanted.
Bad part was they interviewed and hired him as a senior and then downgraded.
I don’t think Josh started as a Senior and then got demoted, the post explicitly says the $ was less than desired (due to the offer being made at the lower level).
I suppose it depends on your org. Where I work "senior" is the second level up, where the first level is given to new hires fresh out of college (mostly master's, some bachelor's). If someone comes in with a PhD in a related field -- though perhaps not a completely unrelated one like music composition -- I'd be surprised for them not be a senior or even a lead (the third level up). The researcher positions that require a PhD tend to be advertised as leads in my experience.
I was originally hired as a senior data scientist although I had minimal relevant work experience, but I had worked in an arguably related field (mostly ETL) for 5 years after bailing out of a PhD program (all but dissertation in economics).
Dismissing working for a university IT department, if that is the case, isn’t fair.
It's run server-side. That doesn't mean it's not front-end.
You're not.
I don't doubt the author, but this specific statement seems off to me in a general sense.
Sure, you can get rusty with a specific set of tools, but picking them up at a later stage should not be too much of a hassle. _Should_ is the keyword here.
Do others feel this way? Am I misinterpreting this?
I can see why someone who's trying to make a career as a React developer would see a primiarily-ERB role as a detour. And maybe in their next round of interviews, people would question how good they are at React if they spent the last X years doing mainly ERB/HTML with only sprinkles of React. "I see you don't have a lot of recent React experience..."
And yeah, I agree - a person can get rusty with some tools and pick them up again just fine. The trouble isn't whether you (the interviewee) believes that, it's more about convincing the person on the other side of the table. The perception in JS-land is that things change Very Fast™ and that skills quickly go obsolete. (Disregarding that if you zoom out, React hasn't changed majorly in 4 years and it's been the dominant choice for 6+ – the perception of fast-paced change is definitely a thing)
Funny enough, I had a bit of the opposite happen in the interview -- I was upleveled due to my performance, and the money was awesome. Just had a lot of reasons for feeling unfulfilled.
I feel like it’s not acceptable anymore to go to work while being sick since the Covid-19. I would be upset if I see a sick coworker at work.
Sick workers productivity was close to 0 in almost all instances. For Retail that meant they were not on the checkouts but out on the shop floor goofing around and ignoring customers. They could also be in the toilets for hours at a time which meant that the other employees would be picking up slack for them rather than them being off and having to get someone to cover for them.
In terms of dev they would be in the office but only there in person. If you had a meeting they would make seemingly random decisions. If they are programming at their desk their code would be buggy and could take up to 10 times as long for them to write. I'd rather be able to explain that a feature was late as one of the devs was ill rather than they came in and tried to work whilst being ill and failed.
Being ill and taking time to recover is part of doing business. Companies should factor this into their plans. Not doing so is a company issue not an issue with an employee being sick.
I mean no-one wants to be ill it's not really your choice. I'm not enjoying myself being ill, it sucks. Going to work draws this process out and makes your fellow co-workers sick.
I've always taken time off when I'm ill and I will continue to do so and so should everyone else.
P.S. I include Mental illness in this as well.
If you're having a bad day / week / month mentally TAKE SOME TIME OFF!
> I don't doubt that more frontend work was coming down the pipeline for my team - even greenfield work - but I felt the months ticking by and my frontend skills degrading. In order to triage this, I worked on a number of frontend projects in my spare time at a pace that was admittedly draining.
With me, it wasn't so much that I wasn't learning at the start, it was that I wasn't really working on meaty/challenging tasks/projects. This was several years ago. It took a while probably more than a year after having shipped a major feature from beginning to end with a team to understand what 'scale' means at Shopify. Normally when we think scale, we think users, servers, requests/sec. Shopify scale is more like shipping via ocean tanker vs 1-day delivery drone. Imagine my shock finding myself accidentally (that's another story) at Shopify coming from a series of startups and missing the pace of work. To be clear, I didn't ship anything part of a whole project in my first 5 months either. I think this got dealt with in my case, because my attempts to make faster/greater impact was conflicting with established process standards. This was fortunate as it led to discussions about mindset. It was still hard to internalize: we design, build, and ship the right thing, only when it's ready, to millions of customers. It only makes sense if you think about it in a year+ timeframe.
> I asked myself the question, "Am I becoming a better frontend developer through this experience?" and the answer was of course no. These things are complex though and I could see how maybe six months or a year from various points I might be working on some exciting frontend work. This line of self-questioning mutated into, "Do I care about eCommerce?" It was a question I never had the bravery to ask myself before. I've worked almost exclusively in eCommerce of one form or another since I started working in tech. I began to wonder if it might be time to try something different.
When I started I didn't even know what Shopify was really, only that they made web storefronts like many other website/checkout product/companies. As I worked there I realized that there's a big difference. Shopify's storefront/checkout is only the tip of the platform, the rest you can't see are the parts used by the merchants.
I did also think, is this the place for me? My asking was about the tech stack. I only had one Rails job before and it wasn't my cup of tea. I did stick it out though, for the reasons of working with great people, both peers and management. One thing I didn't take for granted was that Shopify is a good company. Perhaps I didn't start interested in Commerce (no 'e' Shopify does Retail too, the team I started on :-), but I did understand that trade, in particular international trade, and also at all levels and not just megacorps, can actually make the world better. I think getting and shipping international orders is a pretty eye-opening moment for merchants. Eventually I also got to work on very challenging technical problems, which do regardless of tech stack.
> Everything on the surface was good for me at Shopify and I want to take some space to recognize that.
I'm sorry that this didn't work out. I do agree that there are layers, but also that there are more than two layers. DM me for anything.