I Quit Shopify After Five Months | Hacker News Reader

I Quit Shopify After Five Months

joshcsimmons.com

297 pointsjoshcsimmons325 comments

After reading this, and downvote me because maybe I'm old or something, but I read this and it sounded like someone who thought very highly of themselves, has limited work experience, has limited experience in technology but expects the company to work around their needs. Naively this individual decided (rightly or wrongly) that after 5 months he couldn't possibly learn anything from working at a company like this and bounced.

Point they said this: "This practice suggests that perhaps the company is scaling faster than resources safely allow."

If you do any research at all about Shopify their growth over the last two years has been unreal - their whole operation has been scaling rapidly - infrastructure, people and HR. Of course some of their systems are overly stressed. What does scaling faster than resources "safely" allow even mean?

I read it as “they said they were hiring for X and I wanted to do X, but actually all the work was Y”.

(Which is not incompatible with your read, except perhaps in emphasis)

Also, what suggested they were scaling "unsafely" was that he was asked to interview folks within a few months.

Generally, if you're hired, and you're working out, and your coworkers like you, why wouldn't you immediately be trusted to vet new hires? This is more or less startup scaling 101 - strange the author didn't just say "hey, mind if I skip the interviews?". That usually works for me for _years_!

Two immediate thoughts:

1) Interviewing is a minefield of legal stuff that can easily blow up into he said/she said lawsuits. At a minimum (well, assuming $Company is past a certain size), you'd probably want baseline training vetted by Legal to train new interviewers to avoid those sort of issues.

2) Interviewing is a skill, or really, multiple skills. Reasonable questions, learning how to explore the space around the question, knowing when to lead the candidate and when to shut up and when to drop the question and move on. Spend some time on training the interviewers. Spend some time on internal reflections on good questions, pooling potential questions and giving guidelines on good and not-so-good answers...

Is interviewing a skill for tech questions given how most companies do it?

As everywhere I have worked (and virtually all of my technical interviews), the interviewer gets a packet, runs the candidate through the packet, writes down the answers, and then moves on to the next one.

I have heard "I have no idea, so I will let you assume that" or some variation of that so many times whenever I ask a question outside the clarifying ones available in the packet.

Tech interviews just seem like exam proctors.

This is true, except we're usually not given a packet. :)

I've been an interviewer in Google for quite a few years now. I know my favourite question inside-out, implemented it in a couple languages, know the theory behind the advanced follow-ups for theorists, know the realities of running this down to the wire level for applied folk... I always answer "sure, let's assume that" when the interviewee suggests a clarification. Just makes for a smoother interview flow. If what they suggested is out of bounds of reason (say, round trip time to the moon in 10ms), I'll just note that in the report.

Impressive. I have far more often encountered an interviewer also seeing the question for the first time.

> Interviewing is a minefield of legal stuff that can easily blow up into he said/she said lawsuits.

As someone with experience in the EU but mostly Canada, organizations with 150 employees and 150k employees, can someone put this into perspective for me please? It's this mostly an American thing? I've never had any issues like this or even any exposure to things like that happening around me.

Discriminating hiring based on certain things is illegal (for example, martial and/or parental status). If you ask about these things during an interview, even casually, and then do not hire the person, they have basis to claim you did it because of what they learned about that status.

Also, I believe in some places, it's illegal to ask what they were making at a previous job. This might be something that an interviewer discusses if they don't know about the rule.

There's just a lot of little landmines like that.

Employers should have training for interviewers that includes discussion of protected classes but it's not that hard.

Don't ask questions that are irrelevant to the interview. If you need to make pleasantries, stick to very broad questions, eg "how's your day going so far?", "How about this weather?". There's no legitimate reason most of the protected classes should come up in an interview.

Sometimes people will ask "where are you from?" or similar during an interview, and that's in the off-limits category.

At my work we go through interview training because if an employee is not hired, and believes they were treated unfairly or turned down for reasons that could be human rights violations and files a grievance, they can request copies of all documentation and notes from the company's side as part of their interview process.

That's mostly why we are told "write down things that were said, not your opinions", but I've definitely seen interview notes that include things that would not be appropriate to share back with the candidate.

This. We were asked to always write down questions the candidate got right as well as questions they got wrong so there was a documented, objective reason why they were not hired.

So much of what you write down is necessarily opinion, because even your interpretation of what words the candidate said can color the interview a lot. Unless you have a stenography background, you are not going to keep up with the pace of both your and the candidates words and conduct an interview at the same time. You could use audio recording to have a direct transcript (or just submit the audio), but that would waste a lot of time.

If you ask a candidate, "How would you approach problem X", and the candidate says "I believe X is Y because A is B, so I'll approach it from this angle", you'll likely need to paraphrase. And even in that one sentence, you can paraphrase many different ways: "Candidate believes X is Y", "Candidate says A is B", "X is Y" "Candidate approached from angle Y"... All are color. Your bias seeps in in many ways. Paradoxically z the less attention you pay to it the more other people will be able to work around it, because they'll understand how you work.

I've been interviewing for multiple companies at all scales for over a decade in the US. Hiring lawsuits just haven't been a factor.

It was years ago, but I think I might have taken a half hour interview training session at a large company that was along the lines of "Don't ask about age, marital status, kids, etc, but it's fine if the candidate brings it up first. Use your best judgment." That was about it. I could also be mis-remembering and that could just have been something my manager at the time told me before throwing me into the interview rotation.

So I think calling it a legal minefield is stretching reality by quite a lot.

If you know what protected classes are, and understand that you shouldn't bring them up in any way, and only discuss them with candidates if they bring them up first and within that context (e.g. if they mention their "spouse" you can talk about that but best to not ask anything about kids until/unless they bring it up first again), you've successfully avoided 99.9999% of all pre-hire lawsuits.

Here is an example from a coworker from a previous job:

A candidate came in for an interview. It was quickly apparent he slipped by the phone screen, as he brought code examples in MS Word documents. During the interview, he claimed to be the second coming of Christ. The interviewers (my coworker and his boss) wisely said nothing in response and moved on to a different topic.

A few weeks later, he initiated a lawsuit claiming we did not hire him due to religious discrimination. It was a nuisance suit and dismissed as such, but a good reminder that interviews are business transactions, not chats between friends.

A very short list of questions that would potentially be cause for a lawsuit:

- religion

- family (i.e. do you have kids)

- culture (aside from work behaviors)

- personal background

- race

- health (nothing at all can be said short of stating that accomodations can be provided if necessary, assuming the job does not have physical requirements such as lifting or driving).

There are more, but I think this should give you a decent idea. The point is not that everyone is litigious, but rather that there are people who are, and you must act as a representative of the company during an interview.

Personally, I would not expect someone to take an active role in interviewing unless they had some training or I knew they were already experienced- partly for these reasons, but more so because it is not an easy skill. I have suffered through bad interviews at companies, and wouldnt want a company I work for to make those mistakes.

Perhaps it is that I spent my entire career in start ups (and in post exit companies that aren't quite startups anymore) but, I would disagree with both of your thoughts.

I have never taken an "how to give an interview class" although I think I got handed a packet once. Also I'm glad I didn't have to go to some interview training class, it would be written by some HR person that doesn't have a clue. The legal stuff is already well-handed by the standard HR (don't be an asshole or racist, or sexist, etc) training.

In every team I have ever been in, the interview responsibilities rotates through each team member, even newer ones unless they are maybe recent college grad super greens, then they would still go but maybe have somebody else sit in. In the small shops places, everybody interviewed each candidate.

This actually makes a lot of sense as the candidate is potentially going to be their new teammate and member of the work community and it makes sense to give the people that will be day to day with this person input on the hiring decision.

> 2) Interviewing is a skill, or really, multiple skills. Reasonable questions, learning how to explore the space around the question, knowing when to lead the candidate and when to shut up and when to drop the question and move on. Spend some time on training the interviewers. Spend some time on internal reflections on good questions, pooling potential questions and giving guidelines on good and not-so-good answers...

I would agree with this so much. I really, really wish companies would spend more money/time on training or preparing interviewers.

I've been pushed into being an interviewer for almost a decade, across 4 or 5 companies. Not a single one of them has provided any kind of training. I was a terrible interviewer when I started, and to be blunt, I still don't think I'm a great interviewer; probably mediocre at best.

Other random thoughts on things I would like as an interviewer:

1) A small upper limit on the number of interviews conducted per week. 3 a week is too much to sustain. I start resenting doing interviews, and it shows in the scores I assign.

2) Recruiting should sent interview invites that block out the whole hour before the interview. I need time to prepare, and to come down off whatever's going on at work that week, be it good or bad.

3) Scores should be multivariate, and should have some kind of "I like them as a person" score. Even if those scores are going to get discarded, it would ease my mind when I get people who are a little under the technical bar, but who I like as people. It really sucks to give someone you liked a bad score.

Especially if your employer is hiring for a similar role or for someone who will be working closely with the team/department you're in. It makes sense to ensure a good interpersonal/intrateam fit.

A "domain expert" is far more useful in a hiring team than another HR rep or someone from an entirely different scope.

The key thing for me is that he seemed to specialize as a frontend but ended up as a full stack with a slight backend bias. If you want to be a frontend, ending up full stack with a bias for backend is not optimal.

Most companies I have worked at have many more backend devs than they do frontend devs. There may be an issue with the number of jobs and number of applicants not being equal for both roles.

Well yes, but I would not be happy as a frontend dev scammed into working backend due to recruiters not finding enough other people.

ERB templates ARE frontend,he just lacks the knowledge and experience to know that. Shows why he wasn't hired as a senior engineer.

I want to disagree with you, he seemed to specialize in JS, in his post he mentioned that almost 50% of the time he worked in erb that's the rails template to produce html, or the "new fancy" term that JS developers call server side rendering.

So frontend is focused on whatever produces something visible to the user, most of the time html, others can be jsx or whatever the frontend template is being used.

I think this shows why he was not hired as senior, he's lack of experience/knowledge in the area.

> Point they said this: "This practice suggests that perhaps the company is scaling faster than resources safely allow."

I haven't read through the full post myself yet, but that point is specifically around recruiting and hiring, where the following two statements supports what they are saying:

> The recruiters seemed frazzled and disorganized. Shopify scaled their engineering department pretty aggressively in 2021 and I wonder if the recruiting department was understaffed to meet this need. It wasn't uncommon to ask a question and to wait two weeks for a response.

> Engineers can become interviewers inside of their first six months at the company.

In my experience, people who only have 6 months of experience of a company doesn't really (yet) have the culture down 100% or have the "insides" of the company internalized, especially if joining a company during the time it's increasing headcount a lot, really fast. Seems a bit weird to ask those folks with small amount of inside experience to interview others to join it.

> Naively this individual decided (rightly or wrongly) that after 5 months he couldn't possibly learn anything from working at a company like this and bounced.

It seems, from my understanding, that the author left Shopify because they learned they don't really care about eCommerce in reality, in addition to not learning new frontend stuff.

>In my experience, people who only have 6 months of experience of a company doesn't really (yet) have the culture down 100% or have the "insides" of the company internalized, especially if joining a company during the time it's increasing headcount a lot, really fast. Seems a bit weird to ask those folks with small amount of inside experience to interview others to join it.

Why? If it's a structured technical interview then the goal isn't cultural vetting aside from the a-hole factor. There's separate behavioral interviews for that at most companies. Given some training a senior engineer should be able to run technical interviews pretty quickly.

I read your comment before the article, went in ready to shake my fist at the clouds and exclaim "kids these days!", but....it's not? He was hired into a role ostensibly to do front-end, which he wanted to do, but he was coding mainly in Ruby instead.

Now, I love Ruby, and I got excited seeing his code "time spent" metric that Ruby was at the top, but I can understand why he would want to focus on his area of comfort. I also have mistakenly hired and dealt with many whiny, entitled, head-in-the-clouds/reddit-roleplay programmers who certainly need a good kick in the pants and a right sacking, but if I had hired someone to do X and instead deployed them to do Y, I can't be surprised if they want to leave to actually do X somewhere else.

He probably could have definitely "learned something" as you say, but he himself admits he doesn't care about e-commerce, so in this case nothing was really lost. Yes, "safely scaling" is a silly comment to make, but otherwise it comes across as fairly positive towards Shopify.

Editing erb files isn't exactly doing Ruby and pretty firmly within the realm of a front end dev. The author sounds like they want to specifically be a React dev.

I'd agree that maybe the fit wasn't right (from both sides) - I would argue that there is a lack of experience that is coming through his post on how to resolve and read the situation.

To me it reads as someone who has limited experience in working for large companies and expects that company to work around their wants or alternatively they don't yet know how to advocate for themselves in a company.

5 months at a large organization ... you are barely done on-boarding let alone diving into a real project.

Yeah, while I'm not a particular fan of the mindset of moving on the moment something happens that annoys you, in this case it really does make sense. If you show up at a job and the work really isn't what you expected for some reason or another, it's not unreasonable to just cut your losses and move on. You don't have appreciable investment at that point and there's not a lot of incentive to change the environment to make it a better fit.

Editing HTML templates is front end development...

The other side of it is that if someone is really attached to being an expert at front end and feels skill atrophying then maybe it really isn't a fit. I can relate to that because I've moved from full stack to more or less back end because keeping up with front end while only touching it every few months is just not very enjoyable.

That said, if that's the central issue definitely a lot of the points raised are overblown.

I don't think the author's skills were atrophying, but they may have been stuck at a certain level. I have Thoughts about that.

On the one side: I get it. As a developer you want to - and the industry expect you to - keep learning, always be on the increase, etc.

But on the other hand, when you think about it, once the main architecture is put down and the main issues are solved, most software engineering jobs are just repeating the same trick over and over again, copy / paste / edit some names, done.

The last part is where you want to end up at as a company, basically; build features end to end in a reasonable time. But it's not what most developers want, they want new challenges, they want to stay in the problem solving domain.

I think as a developer you need to accept that a big chunk of your job, and what your employer wants you to do, is kinda boring. It's not solving new problems, it's extending the functionality of an application using existing solutions.

And if you're hired as a front-end developer or whatever, the hiring company may not want you for what you can become, but what you already are.

And honestly, just trying to find decent developers that don't need to learn your stack is already difficult enough.

> But on the other hand, when you think about it, once the main architecture is put down and the main issues are solved, most software engineering jobs are just repeating the same trick over and over again, copy / paste / edit some names, done.

I don't know. I think it gets less and less true as you get away from web development. The fundamentals stay the same but how they intersect with what you are doing can vary widely. If you want to, you can encounter domain knowledge intersecting with the problems you are trying to solve, different architectures for complexe systems coming with their own set of constraints, different project structures, different ways to deal with end users requirements.

I think they are plenty of opportunities to do boring things and plenty to do interesting things.

Another problem is that developers will start pushing for solutions in their current job not because it makes sense but because they know they're going to need those skills in their resume in a year or two. The company is left with a React-sized hole (or k8s, or Vue, or whatever) when the developer moves on that they need to fill ASAP, and the cycle continues.

Funny enough, he was a little bitter about being down-leveled, but it looks like that was the right call.

My reading is that OP was disappointed that they weren't leveled as senior, yet, they left the company because they were working on the tech they want to be an expert of.

It strikes me as a misunderstanding on how career evolution works in these companies (and, I believe, most tech companies). A senior eng will focus less on the pure technical aspects (language, framework, etc), but rather will have the soft skills allowing them to carry larger projects/impact.

For instance, with experience, a senior can identify design mistakes early, can weight the value of different solutions based on aspects like time/eng-cost, tech debt, complexity, risk.

In a company of the size of Shopify, shifting away from "Rails ERB templates" to a more modern solution definitely require these skills (and also probably way more than 6 months of tenure). They could have proposed this project, tried to get some buy-in and learn new "frontend skills".

IMHO there's some red flags here. Shopify is well known and well known as being the biggest Rails company still all in on Rails. It shouldn't have been a surprise that they'd be editing ERB templates. The interviewing process being Rails heavy should have been a giant hint. If they wanted to be all in on React then they should have found a company that's all in on React.

I don't really see them as straying too far from their desired focus. Things and technologies change at big companies and developers need to have some flexibility. Learning basics of ERB templating isn't a big ask and it's conceptually similar to all sorts of different templating engines.

It also sounds like more front projects were coming and things were going to get better. 5 months is nothing in the grand scheme of things and it's an awfully quick bail. Especially considering the quality of Shopify as a company. If the FAANGs are the Kings of the programming world, Shopify is a Duke or Baron. Eyebrow raising to leave a company like that unless they ended up in a clearly better spot.

I don't even know how we're arguing about whether the job was "really" a "good fit" for the OP or not. They decided it wasn't a good fit, we really want to tell a stranger on the internet that we know better than they that a job they spent 5 months in was a good fit for them after all?

I am finding this whole thread very weird!

Exactly... They could have just been patient and stuck it out a bit longer. Companies who go through such quick growth don't have time to update their methods as quickly.

I don't think this an issue of ego so much as wildly overestimating the difference in quality in code and practices between big name companies and smaller or lesser well known companies.

I find this is a misunderstanding that many people (myself included at one point) have, especially if they come from a non-traditional path and have only worked as smaller companies.

In the post he mentions that he took a lower pay and level than he expected in order to increase his skills. He was willing to learn, but made the naive mistake in thinking that big names are where the big skills are.

One thing I always found interesting is if you list off all of the developers you respect the most, and then look where they work it's a pretty good mix of FAANG and small companies you've never heard of.

The thing is you never really know. I was pretty far into my career before I realized for instance that the concept of a 'mutual breakup' can apply to a work relationship as well. I describe one former employer as doing me the favor of laying me off. I was miserable and we both knew it. We had achieved a compromise in coding philosophy that left both of us frustrated and I should have left a year earlier.

There are places you will never fit in, no matter how much you learn or push them to 'improve'. I would say "I no longer treat a job as a 'project'" but I'm actively slipping into that right now because I finally found a wedge I could shove into our Gordion Knot. This will probably be my mic drop because it's definitely time for me to move on.

My first job after I moved away from my parents when I was 21 was at a convention company, ostensibly as a "Jr Java Developer".

This turned out to be flatly untrue; I could count on one hand the number of lines of Java code I actually touched at that company, and when there was code to be written, it was in ColdFusion of all languages. Most of my time was spent being stuck designing nametags, and I cannot put into words the level of hatred I had for that job, but I was afraid to quit because I had just gotten an apartment and didn't have the direct parental support that I had previously.

They ended up firing me after my manager ended up overhearing me calling them a "moron who didn't know anything" [1], and I was sad at first, but the next morning I was happy, maybe even elated, because it was the first weekday that I didn't have to back to that awful job.

They had done me a favor firing me, I'm honestly grateful they did. I would never have quit because of fear of being homeless, but I managed to bounce back fairly quick into a better (and luckily higher-paying job.

TL;DR, I completely agree that a firing can be a "mutual breakup".

[1] To be fair to me a little, while my choice of words in hindsight was bad, I honestly did not know she heard me until after I said it. I felt like an asshole immediately after, but I also didn't apologize because it wasn't like I didn't mean it.

> I also didn't apologize because it wasn't like I didn't mean it.

Oof. What does "meaning it" have to do with an apology being warranted? If I feel bad enough about calling someone a moron within earshot that I feel like an asshole, I'm going to apologize. This only wouldn't apply if I felt such animosity that I wanted them to feel bad. I can't imagine not apologizing in the situation you described.

I was a cranky little asshole when I was 21 who thought being a douchebag was just "edgy" and if people didn't get it then that's on them. Looking back, I cringe every time I think about, because that just is shorthand for saying "I was that toxic worker no one liked". I absolutely did mean it, I still think she was a moron who didn't understand anything about computers, but you're right, an apology for the verbiage would probably be in order.

I've thought about finding her on LinkedIn and apologizing, but almost a decade has passed since then, and I don't really think she wants to talk to me anyway. Somehow I think she's probably over it by now. What's life without a few regrets eating away at you?

True enough. I've got plenty of regrets of my own, no argument there.

I can see that, but he also said he was told this was a front end position, and it seemed like majority of his work was not.

What I didn’t see him touch on was how much did he talk with his manager about this? If the role isn’t what he signed up for, that’s definitely worth a discussion for both sides to try to better align the fit.

I would argue that erb is frontend, but is server side rendered, isn't what he expected, he seems to expected to work purely in javascript, this seems that he things that frontend is only javascript/react, that demonstrates why he was not hired as senior, he lacks of knowledge/experience.

The post does come off as a touch arrogant, but I believe the core issue was that the role was misadvertised:

> I was hired as a frontend developer, which turned out to be misleading. [...] In order to triage this, I worked on a number of frontend projects in my spare time at a pace that was admittedly draining.

The author thought they were going to be doing frontend, but a significant portion of their work was not. So they quit. That seems extremely reasonable.

He was still doing frontend. He didn't think of it that way because modern view perverted the meaning beyond all recognition

Exactly. FTA:

> Most of the "frontend work" I saw was via Rails ERB templates [puke emoji].

Okay, so ridiculous stack/language bias aside, he's doing frontend, but it's not the frontend he wants. He wants to be writing JavaScript. Which is fine, but he's implying Shopify messed up when it seems he just didn't have a clear understanding of what the role entailed and what the tech was he'd be working with.

> he's implying Shopify messed up when it seems he just didn't have a clear understanding of what the role entailed and what the tech was he'd be working with.

It seems extremely improbable to me that at no point in the hiring process, starting from the job advertisement on down, was this ever stated.

This can happen (speaking from personal experience). For a big/growing company you're interviewing for a position that's open in several teams which all can have different stacks. Which team you end up with depends on some internal priority.

The puke emoji was especially unwarranted. Templating engines are templating engines.

Oh but you don't understand. This wasn't released within the last 30 days, therefore it's legacy and bad.

I don't know why but honestly I'd expect something a little more reasonable from someone coming from academia, but in the broader context of the piece as a whole it makes perfect sense.

He wanted to write a SPA. Instead he was writing Rails.

This is the quote that is especially telling:

> I asked myself the question, "Am I becoming a better frontend developer through this experience?" and the answer was of course no.

He didn't think he was getting better by learning different approaches to solving the same problem? He doesn't think that more server-side code would make him understand the context of frontend development better?

Funny enough, I'd buy "I don't enjoy the work" or "Rails is outdated" (this is debatable) over his complaints.

I don't know the job posting that the author had read, or what guided their expectations, but here is a current Shopify Senior Frontend Engineer job posting:

https://webcache.googleusercontent.com/search?q=cache:wxk6Q4...

This job posting sounds like it lines up with author's experience at the company, and knowing Shopify is a Rails-heavy company, I would safely assume most Shopify postings look similar to this. I don't think author was bait-and-switched, author just didn't get what they _wanted_.

Note: providing a google cache link since I don't know when the posting will expire

> You’ll use the latest web standards in HTML, CSS, and JavaScript, and modern technologies and frameworks like Typescript, React, GraphQL, Apollo and Ruby on Rails, to develop large front-end web applications and websites that scale and perform well on all devices.

If I read this, I'd think that I'm going to be doing "modern front-end", which is usually a React SPA connected to a back-end API via REST or GraphQL. The inclusion of GraphQL and Apollo on this list does mean that I'd be surprised if my work was primarily server rendered ERB templates.

I think there's a bit of a bias here because many people on HN don't like modern front-end. Yes, yes, ERB templates are just fine. But they're not the same as a modern JS stack and if you're looking to gain expertise in a JS stack, they're clearly not helpful.

Unfortunately, this is also my take. I would also note that ERB hacking is still front end work. I also note that startups don't really have the kind of fixed & linear work paths that more mature companies have.

I'm kinda bummed for the guy, it sounds like he really needs an industry mentor to talk things over with to help manage reality expectations.

That was my take too. With 40+ years experience in software development and system administration, I don't know what to make of someone with obviously limited experience expecting to get a "senior" title or to pick and choose what they will or will not work on -- based on the programming language involved. That the author tracked time spent in each language, worried about the meaningless job title, but then decided that maybe they aren't interested in e-commerce (Shopify's core business) shows a junior-level attitude.

When I studied photography I wanted to use new lenses, cameras, flashes, light meters, film. My teacher, a professional photographer, told me one day that amateur photographers obsess about equipment. Professionals think about lighting and composition. That stuck with me. Junior programmers obsess over languages and tools. Senior programmers think about architecture, data structures, team cohesion, requirements, business value.

I'm sympathetic to younger programmers who enter the job market faced with the stupid algorithm-oriented interviews, which are a kind of hazing ritual performed by people with such poor people skills and confidence in their own judgment that they fall back on pointless whiteboard tests that give the interview process the veneer of rational objectivity. Instead that kind of process just insures that everyone who gets hired has the same personality (or lack of).

A lesson to take away from this experience: The interview and hiring process may look like a serious attempt to find the one perfect candidate for an amazing job. Actually larger companies tend to hire lots of people who look promising, ignoring their work experience and desired career path, and just sift out the people who don't fit or can't produce. That's not new either. I started my career as a junior, hired along with more than 50 other juniors, assigned two mentors and allowed to sink or swim. Three months later only 15 of that group were left. Later in my career I mostly got hired through word-of-mouth and referrals, sometimes I was the only candidate for a job that wasn't even advertised, and usually I didn't go through HR at all. If you're still going through a funnel to get a job you are almost by definition not senior.

Note to the author: Almost every place I have worked in four decades, with a couple of horrible exceptions, let me run errands, take care of my kids, take as much PTO I needed, asked me to take time off if I was sick, and generally showed a lot of flexibility with what's called work-life balance. Only badly-managed groups and companies don't do that, and it's not a new thing. Given the ever-increasing demand for skilled programmers companies are forced to bend over backwards to attract and keep good people, so a manager who wants to keep their team will accommodate.

> Junior programmers obsess over languages and tools. Senior programmer think about architecture, data structures, team cohesion, requirements, business value.

Well said. One of the big focus areas for me as a lead engineer is to get everyone to realize that planning (discussion, design, diagramming) are part of the engineering process.

Writing the code is a lot easier when you've already planned out how it's going to work.

Not just part of the process, but almost always the most important parts of the process. Programming languages are almost incidental. I get that everyone has preferences and strengths, but deciding you will only work with React or Python or whatever is self-limiting. Stay in this business long enough and you will see everything come and go, you have to stay open to learning new things, and working with new people.

Measure twice, cut once applies to programming too. Without a plan you're just thrashing, which gets frustrating pretty fast.

> but I felt the months ticking by and my frontend skills degrading.

Like it or not, he isn't wrong about this, though.

Web frontend stuff is like phone app coding ... it's a treadmill. And if you fall off for 18 months, it takes a LOT of effort to get back up to speed.

I do front- and back-end web development, I have done that almost exclusively for years. It's not that skills degrade, it's that the tools evolve and change quickly, and teams move from one shiny thing to the next much faster in the front-end domain than in other areas.

Without meaning to come off as condescending or rude, if you call yourself a professional programmer and you need to put in a lot of effort to adapt to the next version of React, you aren't senior. Adapting to rapid change is part of the career, and the only difference with front-end work is the mostly self-inflicted churn. HTML, CSS, Javascript are not changing month-to-month. Web sites I wrote in PHP and jQuery ten years ago still work.

The key to keeping up with change in the software business (and it's the same, maybe worse, in the system admin domain) is to understand the core technologies and principles, which haven't changed dramatically in decades. It's far more important to understand HTTP (relatively unchanged for more than two decades) and how web browsers render (which changes very slowly) than it is to memorize every detail of how React hooks work this month. Excessive focus on languages and tools and always adopting the latest new thing is a sign of poor management and lack of focus -- and especially not focusing on delivering a product and adding business value. That can happen anywhere from the CEO on down but in my experience it mainly happens at the programmer team level, because playing with the latest dot release of Ruby or React is more fun than addressing business requirements.

As I'm by now fond of saying, no company ever had the requirement "We need 2,000 more lines of Javascript code by next month." Nor does any company have the requirement "We need to move to the version of React released last week." If that's what you're concentrating on you don't understand business requirements.

> Adapting to rapid change is part of the career, and the only difference with front-end work is the mostly self-inflicted churn. HTML, CSS, Javascript are not changing month-to-month.

True, but if you are at an early stage of your career, keeping up with that churn is important as that's what your next FAANG job interviews for.

Being stuck handling backend or infrastructure when the job was supposed to be "front end development" is not acceptable in a company the size of Spotify.

If this were a startup, then the discussion would be very different.

I agree with everything you wrote. The author expected the "senior" title but the complaints in the article don't come across as experienced senior developer.

It's a shame that FAANG companies, and those that emulate FAANG hiring practices, put so much emphasis on specific languages and algorithms, since those actually have very little to do with success as a developer, or adding value to the business. I understand the gatekeeping function of those hiring practices but I think it just reinforces a monoculture and tunnel vision focus on details.

If Shopify told the author one thing then assigned something else that's a problem. One person might see an opportunity, another might interpret that as deception or poor management. I don't know what the author did about it. I would have discussed with my manager and tried to sort out the difference between my expectations (according to the job description and hiring process) and what actually happened. Some of my luckiest career breaks came from getting hired for A and ending up doing X. I even got sent to the wrong interviews once (by a FAANG company HR rep) and got a much better job than the one I was originally picked to interview for.

> Being stuck handling backend or infrastructure when the job was supposed to be "front end development" is not acceptable

Except...editing HTML templates is front end development. This guy is a React superfan and can't get his mind around anything else.

When you write React code and edit ERB templates, isn't that full stack? ;-)

If you are early in your career I would advise that person to stick around shopify and they might learn something.

Shopify asked the person to do frontend work and the person thought they were doing backend work because they weren't use to editing html templates with react.

We learn that this person might be a senior react developer but this person isn't a senior frontend developer.

Shopify identified this and made the person an intermediate developer.

Agree with this - and I think you said it right the attitude of the blogpost comes off as very junior but expecting much more. What's more is that they right a blog post about their experience after the fact and post it to HN to leverage publicity (either so they can get a new gig or cast shade on their prior employer).

Agree I hate the whiteboard interviews that seem archaic at this point. Seems better to do a take home if you want to see work product and how they think instead of programming in an acutely stressful situation.

I won't speculate on the author's motives for writing that post. I haven't worked at Shopify so I don't know what that environment is like. I have been hired to do A and then found out the work was B. One can interpret that as either deception and disappointment or an opportunity to grow, it depends on the situation. At a fast-moving place like Shopify I would expect an all-hands environment where senior developers are expected to apply themselves where the business needs them.

The whiteboard interviews conducted by "engineers" who need HR to tell them they can't ask where a candidate is from or if they're married is maybe a sincere attempt to discern technical skills. I think it's actually a gatekeeping process to maintain a homogenous workforce. In the US at least it's not hard to let someone go if they aren't performing, so big companies tend to funnel a lot of people in and see how they work out, separating the wheat from the chaff. The tests and whiteboard problems and all that are intended to eliminate people who can't put in the effort and demonstrate their willingness to play along. They're also intended to protect the company from discrimination lawsuits because the employer can point to what looks like an objective and scientific screening process, when we all know that people actually make hiring decisions mainly on personality and appearance.

it's the classic tale of junior eng thinking of themselves as senior :P

I welcome the challenge to be forced into learning new things that are outside of my expertise.

I'm a backend dev and a few years ago the company pivoted and put almost all the engineering team on building a new React app. I'd never done React. It took me some time to learn it, and I'm still bad at making things look pretty. The skill will be valuable when I look for another job. Now I can apply for Full Stack positions and not just the backend positions.

While I enjoy learning stuff that's out of my expertise, I do worry about whether or not being a generalist is more of a hindrance as both the backend and frontend have a LOT of ways one could expand their mastery. There is a bit of zero-sum in this as the hours I spent outside of work learning Go/Rust/Postgres for more understanding of the backend could've been spent on diving deeper into frontend things like performance optimization and web accessibility.

I would have to agree.

It even starts with "I have answered this many times since announcing my departure. The reactions have ranged from shock to immediate understanding."

Ah, wait, so in the author's head there is some huge crowd of people (other than maybe family?) who feel the most burning question in the universe is why the Author decided to leave?

I have been at my company for 8 years. From a startup through a successful acquisition. I know every executive and senior engineer on a personal basis and am friends with most. If I left, I might get a pizza party and card wishing me well. There would be no scuttlebutt on why I'm leaving.

I'm not sure that's quite fair. When I left my job of 3.5 years I did field a lot of questions about why I was leaving and where I was going, but I wouldn't have described that as people "feel[ing] the most burning question in the universe is why [I] decided to leave".

(Also, when I came back two months later I faced a lot of questions as to what the hell happened to bring me back so fast. But that's a different story!)

I legitimately laughed out loud at this:

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

This guy worked there for FIVE FRIGGIN MONTHS! OMG! If your coding skills are degrading so quickly maybe you aren't actually a senior engineer?

For reference, during the economic crash of 2008-2009 I was out of (software) work for six months. I didn't write a line of code during that time. I was a Jr engineer at the time. My coding skills were absolutely fine.

I wonder what sort of interview questions one can ask to filter out people like this?

My current company has strict minimum experience requirements for hired senior engineers (not promoted ones). I don't think that's unusual...

> If your coding skills are degrading so quickly maybe you aren't actually a senior engineer?

I dunno, people are different. I tend to forget what I had for lunch that day, let alone skills that I haven't touched in six months. I just tried to play piano last night for the first time in a year and I was just a mess of hands not knowing what the hell to do.

> I wonder what sort of interview questions one can ask to filter out people like this?

I specifically ask what people's technology preferences are and what they don't want to work with, then follow up with why. If they into these technologies for hype based reasons- or seem overly negative or dismissive of other technologies without solid reasoning, I gather that they are the equivalent of a fashion victim or a superfan of some pop group. These people can be extremely annoying to have around, as they try to steer every discussion into one about why their preferred technology is not being used to solve every problem.

This guy is so far gone he doesn't consider HTML templates to be front end development. A complete zombie for his chosen religion.

He's probably trying to outperform what you were capable of in 2008 and also remain in a position to advise on the latest tooling.

He seems anxious but I think anxious people still make valuable contributions alongside those of us who are calmer.

I think because he entered the field by doing a crash course, he must have some fears about losing his efficiency. This is why, perhaps the # of years in a tech role has some relevance, which he does not understand.

In fact you aren't getting downvoted -- this is a very popular opinion in this thread and you are currently the top comment with most of the discussion being on this point.

I think it was just someone sharing their experience. Which I find super useful, and people rarely do. While it can be nit-picked, I didn't think they said anything off the wall. Pointing out there might be some consequences for work experience of how quickly they have scaled is not off the wall -- you maybe even agree you just don't think it's worth critisizing or even mentioning, but what is worth mentioning is something reasonable people can disagree on.

The downside of lots of criticism of someone who shares their experience like this... is it discourages it. People do it so infrequently that I'd rather support people who do and encourage it, by making sure any feedback is constructive and supportive and charitable.

Instead, I suspect at this point the OP is thinking "Well, THAT was a mistake, next time I won't share my experience."

Thanks for putting this in perspective - a lot of very dramatic takes in the comments.

I am imperfect and finding my way, just like we all are. Glad you found it useful!

>but I read this and it sounded like someone who thought very highly of themselves, has limited work experience, has limited experience in technology but expects the company to work around their needs.

This was also my takeaway. I think, in general, younger people feel more entitled and have no idea how things really work. They want you to cater to them, rarely want to put in the effort, and want big money for it and think they are an expert that knows more than anyone that's been doing a given job for any worthwhile amount of time. Just a quick glance at /r/antiwork and /r/overemployed are a good cursory look at this sort of mentality.

Similarly go look at YouTube videos of 'day in the life' type content for data analysts/data scientists, you get a lot of "I wake up, check emails, go ride my bike for an hour, look at emails, cook a fancy breakfast, look at emails, go CrossFit/shower/cook lunch/take my kid to the wherever for 2 hours, I then hop on a meeting for an hour, then I run a python script, then I cook dinner for my partner and eat it, play some video games, and go to bed. I enjoy my 6-figure income".

I feel like that shopify is in something like a bubble.. Everyone! Can open a shop and be profitable! Now everyone aby his dog is opening a shopify.. It's like the thinking that everyone can be an influencer.. At least Youtube and Instagram are basically free..

So, i feel like this bubble will burst in a few years when they all realise, that they don't even make 20 dollars in profits..

I'm confused - did you read the article? If so I think you misunderstood my reason for leaving. Yes I was unhappy with the FE/BE split of work but ultimately I left because I don't think I want to work in eCommerce anymore.

And yes, of course I think highly of myself, I'm a confident person, I've accomplished a lot and I intend to accomplish a lot more.

I did - and there are some pretty constructive comments on here (and some less so). I noticed this was your first post on HN so I hope the attention hasn't been to overwhelming and you are able to pull some constructive value from it (I hope you like candor).

Lions share of comments are that your attitude that comes through in your post is more junior than senior for a megacap tech company, 5 months is very short at a large company to get situated and don't underestimate working with good people. Also the role interviewed isn't always the role delivered - especially at fast growing organizations but, if you are capable of navigating a large company there are typically roles more suitable. It takes experience and confidence to probably navigate large companies effectively.

At the end of the day if the fit isn't the right fit then make a move. I wish you the best of luck on your journey - given your confidence and strive to learn it sounds like you will land somewhere quickly and hopefully more fitted.

Personally I think quitting something that is amazing in so many ways but doesn't fulfil your front end needs after only 5m is something you may come to regret.

Did you ask for a change of team / change of work focus? Did you bring up your issues with a manager? If you were on my team and an attrition risk due to not working in the tech you were hired for I'd have made sure that was changed.

Five months is just about enough time to find your feet in a large org's codebase, I think having exposure to the Rails side is to your benefit, and given a bit more time you could have worked to resolve the other gripes. Shopify is a huge, profitable organization, with many, many, many opportunities for developers to do their best work. I find it hard to believe there isn't something fascinating there for anyone who likes writing code.

Good luck in whatever you are doing now though, sounds like you have the talent for doing whatever you wish which is a great place to be in.

FWIW I do not work for Shopify.

Agree with this - first job I had one of the senior members of the organization came over and said something along the lines of it will take 6 months to be a contribute just from understanding all the intricacies of the business/code etc.

> Personally I think quitting something that is amazing in so many ways but doesn't fulfil your front end needs after only 5m is something you may come to regret.

> Did you ask for a change of team / change of work focus? Did you bring up your issues with a manager? If you were on my team and an attrition risk due to not working in the tech you were hired for I'd have made sure that was changed.

I'm not sure if I misunderstand the blogpost, or if you do, but I gather the author quit because they realize they didn't like eCommerce after all. At least that's the impression I get from this passage:

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

So changing team or work focus probably wouldn't help the author, as the core theme of the company wasn't attractive.

I still think that Shopify is such a huge org you can find so much opportunity that does not feel like ecommerce. If the author is morally opposed to ecommerce then good for them sticking to principles, but other than that I don't feel like they gave the job a fair shake. People are different though, but I'd love a job with as much time off as I like and I'd be willing to work in an industry I didn't love if the people, benefits, compensation, technology, and culture were all great fits. I mean, I switch off at 5pm so maybe I am different.

> I still think that Shopify is such a huge org you can find so much opportunity that does not feel like ecommerce

Yeah, I thought about that too at first, maybe he could build internal tooling supporting the developer teams for example. But I think if I didn't believe in what the company overall did, I wouldn't have any motivation to help their developer teams being more efficient either.

> maybe I am different

Yeah, I do think that's the answer in the end, we're all different and value different things :) I for example would trade all the things you listed for just working on something I personally believe in, as I see those other things as changeable over time, but the mission of a company tends to stay mostly within the same radius, so unless that resonates, I'm over it quickly. Shopify is just consumerism at scale, something I don't care about, even though the pay would be nice and I got "unlimited" time off, I wouldn't work there.

One of the things I have seen many times with junior engineers is that, when things aren't going exactly as they desire, instead of having conversations with their managers: "Hey, can you give me a timeline of when I'll be able to focus more on frontend dev, i.e. React", instead they bail (or, mention it in the slightest of passing, and then if stuff doesn't change they feel their concerns weren't addressed and leave).

To be clear, I do NOT blame junior devs at all for this. It takes experience and growth to build the confidence to know how to be direct with managers in a way that is constructive to all parties. I'd just highlight with eng managers to be extra aware that, for junior engineers, that you'll likely need to "pull" more and dig out if there is something more that the engineer wants. Of course, you may not always be able to accommodate them, but if they do leave you will know it wasn't for lack of communication.

Earlier in my career, which is not too long ago, I behaved exactly as you've described. It was not worth the risk of seeming "difficult" or "demanding" as someone with little experience, to be asking for (ostensibly selfish) changes from my manager. It seemed much less confrontational, and often more lucrative, to simply find work elsewhere.

If the candidate was misled in the hiring process, and the organization (which is the sum of its people) is dysfunctional enough to result in that outcome, it's not unreasonable to think asking for it to be fixed may be taken negatively by the folks who put you in that situation.

> may be taken negatively by the folks who put you in that situation

From the author's account they seem to have extremely supportive managers. Not only that, the business spent a lot of time and care helping the hire figure out if they are a good fit and with all that invested I am sure they'd prefer a shot at fixing the problem. I'd be a little upset if as a manager my report resigned cited any of the issues the author reported without at least allowing me a chance to work with them on it.

Also worth noting, the author is a senior dev.

> From the author's account they seem to have extremely supportive managers.

Would you shit talk your previous company/managers with your name attached to it? Especially if you were early in your career?

Probably not.

On the flipside, there's nothing stopping a manager from diving into knowing their subordinates and assessing their mood and figuring how to make them happier if they happen to be unhappy.

In my previous role, I had two managers: one who made it a point to ask me how I was doing and if there was something he could do and another who never had a one-on-one with me until I handed over my code when I left the company.

"To be clear, I do NOT blame junior devs at all for this. It takes experience and growth..."

Also, as software engineers right now we have a very weird experience where the job market is better for us as employees than almost anyone else ever anywhere. Like this is as good as it gets.

So it gives the illusion you can find the perfect job, if you don't like a place, why not leave for something else, you can easily do that!

So while generally I'm partial to your point of view, job hopping so quickly is unlikely to lead to the job satisfaction you hope it will. But... in that environment... if you wanted to mostly work on JS and that's not what the job was, why not leave for something that is what you wanted all along?

Maybe Imposter Syndrome got to this one?

I think the lesson here is to be very clear about what you are looking for in terms of role, scope, and development opportunities during the hiring process; negotiate and come to a clear understanding with your direct and skip level managers; and then hold them accountable in your one-on-ones.

If they are not delivering on their end, put them on a PIP. (1) Remind them of what they agreed to, (2) inform them where / how they are not delivering, and (3) work out a plan and timeline to get things on track. If things do not improve then quit. This isn’t being difficult or demanding, it is managing upward.

This also does not mean refuse to do things outside of your scope when needed — on a temporary basis.

At first my reaction to your comment was "wait, what was so amazing in so many ways? If it's not a good fit it's not a good fit".

But thinking another minute... "The people were phenomenal" -- okay that is actually HUGE. It's much rarer than you might think, in my experience, to find a place to work where where most everyone is good at their jobs, motivated, friendly, and just generally great to work with. Giving that up is actually a pretty big risk.

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

I made the same mistake in the Life Story interview. I thought it was about why I became a dev. Except I only realized that about 15 minutes in.

Sounds like it's ripe for (creating the perception of) discrimination.

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.

The worst thing about this (apart from the obviously misleading name) is if you correctly interpret it, it implies your work is your life.

That would scare me at any other company, but Shopify has an excellent reputation for WLB, so at least at the time that thought did not occur.

this is just a cutesy title for a work history interview.

If a company thinks that life=work, then that's a red flag.

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.

The author comsidered that the low arsehole ratio might be a result of this process.

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.

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.

Yeah looking at OP linkedin it seems that he might be more of "regular dev" or "midlevel dev" than a senior.

Bad part was they interviewed and hired him as a senior and then downgraded.

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

PhD really depends on the lab/advisor. Some would let you have experience that directly translates, some won't

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

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.

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

A lot of it depends on how much you are willing to extract it from the company.

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.

It need not be micromanage, but could rather just be stuffing your day so full that you have no choice but to work continuously.

Go try Amazon and many companies aren’t “Tech” companies.

Sounds like table stakes to me in 2022. If any company tried to micro-manage me, I would be out in a second

That would majority of company in the Fortune 500 and dependent on your job function in IT.

Relative to the average office job, yes. In a tech-centric job, this is pretty common.

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

> Is this really that unusual?

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.

> Is this really that unusual?

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'd say that's more or less a standard thing in EU, for desk jobs.

Quite standard in Western Europe

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.

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.

Yes - would like to see some stats on attrition among down leveled hires. I suspect you’re right.

Posting anon for obvious reasons.

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.

What sort of CTO would allow this?

two lessons learned

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.

Holy hell, red flags abound

Lemme guess the CEO/CFO/CPO/CRO all come from wealthy backgrounds and post inspiring tweets/linkedins whilst the company piledrives into the ground?

> Me and all my peer engineering directors got down-leveled to entry-level titles within a month.

Wow, they demoted you post-hire!? Yeah, I'd immediately start interviewing elsewhere.

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.

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

This is exactly it. This guy is just ignorant. He wanted this job, hoping it would „make him a better developer“.

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.

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

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.

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

the funniest and saddest of all is this though:

> 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

Sounds like you're bringing in a bit of your personal gripes there as the OP didn't say the other companies wouldn't accept him...

yes, this part speaks to me on personal level

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.

> Being stuck handling backend or infrastructure when the job was supposed to be "front end development" is not acceptable

Editing HTML templates (ERB) is front end development.

> 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 feel you Chris, you have actual case studies, projects to show, so much you could talk about

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

> or too desperate to get a job

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.

Yip pretty much the same for me.

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.

Hah yeah that line was pure gold and probably just made my day

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

> I received bittersweet news in late August that I did get an offer but I'd be downleveled from senior to mid. The reasoning for this wasn't my performance in the technical interviews, it wasn't based on my answers to soft questions, and it wasn't that I had a bunch of non-CS experience, it was because I didn't have enough years of experience in tech-specific jobs.

Looking at the Shopify Jobs page[0], I see they pretty much only list openings for Senior level positions.

I think people are missing the tactic here (which a lot of companies seem to do) of only listing experienced positions to keep people with no experience from applying, but not necessarily only hiring for Senior positions.

[0]https://www.shopify.com/careers/search

Shopify dev here.

One thing I didn't see mentioned much of this was discussed with their lead? Shopify is very open to people moving around to find challenging work. And Shopify as an org has done a great job (from my vantage point) creating a culture where people give and receive feedback. So hopefully their lead would be open to that convo.

I will also say though that some of what the author says rings true. Shopify gets you excited about the product problem, and less on the tech stack (is front end). The job becomes “how do I solve X for merchants” not “where can I find a cool React problem”. Sometimes solving X just requires Ruby work. And sometimes you’re excited to help merchants do X and care less about the tech it takes to do X.

The downside to this decision is there’s somewhat of a bias towards being generalists over tech stack specialists. Not completely but it’s there.

I personally have found lots of growth at Shopify. It maximizes mission, career growth and work life balance really aggressively. Shopify, honestly isn’t the place to maximize comp. It is a fun place to do great work and feeling like you’re having an impact.

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.

That’s how I read it. It just wasn’t the work he expected / wanted.

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 don't think it's bad!

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.

That was my take away too. Seemed like it was beating around the bush until the end where it turned out there was no bush.

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.

That sounds very strange. Your code would be reviewed by the other people writing C code. Were those other people much less experienced than you?

I was 26 at the time, so I would guess not, but some of the code was problematic. It was very strange.

The big takeaway in this post is this section

> 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. I believed that working at Shopify would make me a better frontend developer.

Having spent the early part of my career working at small startups, I once took a job at a big, well known but not FAANG company with similar expectations of improving my skills and was similarly disappointed in a major way.

Shopify is (or at least was) going through a massive hiring boom. Companies experiencing this kind of rapid growth are rarely a good place to hone your skills. Funnily enough some of my coworkers from that same disappointing BigCo ended up there.

If you want to enhance your skills it's better to work on smaller team, ideally in a less rapid growth environment, where all the members of the team have some serious dev experience (look for teams that have a few people that are active in OSS). Good software/problem solving simply doesn't happen in a rapid growth environment where you are rushing to meet some quarterly KPI and recruiting is working to bring in as many devs as possible as fast as possible.

Software is always messy so people that only work on small teams tend to think "this code is a mess, I bet it's not like this at a real company!" only to find that most larger companies are even worse, use more legacy tools, and have byzantine systems that are perpetually feel ready to collapse, and on average have less talented developers (it is incredibly easy to hide in a larger company).

Why the vomit emoji after mentioning ERB templates? It's just HTML with ruby sprinkled throughout. If that's the best solution for the job, why use React or whatever flavor of the month JS framework instead?

That really stood out to me as something that suggests this is a person I would not enjoy working with at all. The dislike for HTML templates is just a sign this author has a blind spot in their understanding of their role in the world. Rather than provide value, they are more interested in moral judgements of which technology is superior. React and Virtual DOM in general is just a workaround for browser limitations. To have bought into the hype and fandom around a technology like that is quite annoying. It's why I never hire anyone that is purely "front end" or "back end". While expertise in a particular technology is useful, understanding more of the stack is making him more valuable.

Years of experience may not be a direct indicator of how you work as an individual contributor, but it is a very good indicator of softer skills such as handling workplace conflicts and mentoring junior devs.

As a senior dev it's on you to communicate and voice what you want out of the job. 6 month is the perfect time to pull aside your manager and ask/talk about your path of success.

Of course, leaving isn't a bad solution, but you should also realize there are other solutions. And being a senior dev means being able to weigh the tradeoffs and figure out the best path forward. However, the author failed to mention or reflect on the alternative solutions in the post.

This may have felt very uncommon to the author, but most of the things I read seems absolutely normal. Title inflation is real at smaller companies. You maybe a “executive staff engineering fellow” at a smaller shop but at the larger companies that’s equivalent to a mid level dev.

I’d be curious to hear what the manager and team members thought of this move. Overall, the writing strikes me as someone who may have put the cart before the horse.

I hope it works out for the author

>Does a year of experience at FANG == a year of experience at WITCH?

What is WITCH?

https://www.which.co.uk/

edit: fixed url

even with the "fixed" URL, this is not what the author meant.

Wipro, Infosys, TCS, Cognizant, HCL.

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.

I had to look this up: https://news.ycombinator.com/item?id=27571707

W- Wipro I- Infosys T- TCS C- Cognizant H- HCL A- Accenture India.

Disappointing. I was hoping it referred to working with someone like this [0].

[0] https://aphyr.com/posts/341-hexing-the-technical-interview

Might be wrong, but I think it's referring to Indian consulting companies (Wipro, Infosys, TCS, Cognizant and HCL)

Wipro Infosys TCS Cognizant HCL

The great part was all the spooky results when I googled "fang witch" to try to figure that out.

Come for the ragequit blog post, stay for the fang witch images.

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.

That was the purpose of the parent article's assertion, to illustrate that same point.

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 don't mean to be rude, but this post sounds pretty immature to me.

How come when people get rejected or down-levelled for jobs, it's always the company that's wrong?

I applied to Amazon with 4 YoE + PhD in CS and got offered a mid level position. I was pissed as well but accepted anyway. Oh boy was that the right decision.

The first time I pushed a change to prod and broke our service for hundreds of thousands of customers, it dawned on me that I wasn't the hotshot I thought. That humbled me and made me less arrogant.

Yes, I also had to do menial and dull tasks for a while. But this allowed me to learn, improve, and build my reputation. Now I'm leading a large and complex green field project in my team and I love it. I don't think it's unreasonable to not hand over the most critical or sexy projects to newcomers before they proved they can handle them.

In retrospect this was the right career move for me, and I can honestly say I am a better engineer now than I was back then.

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?

Yeah given how high it made it I was expecting a more interesting conclusion than "Eh, not as much js as I'd thought there'd be."

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

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.

> I accepted. Despite the downlevelling, despite the fact that compensation was well below market, Shopify was a big step for me. 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.

Why is Shopify offering well below-market compensation?

Also, this makes it sound like the author is "optimizing" for an internship, not a job. In a successful job role, you don't need to optimize for one of those factors over the others, you get most/all of them.

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.

The logic etc that you're writing in the templates is in the backend language though? And it's all run on the backend.

> And it's all run on the backend.

It's run server-side. That doesn't mean it's not front-end.

It is produced on the backend, consumed on the client.

Perhaps I'm just old (31), but when I started web developed this was frontend development.

> Perhaps I'm just old (31)

You're not.

Over the course of the last 2 or 4 years I've had to reflect on what actually motivates me, and what my actual level of experience is, having been in and out of short sints numerous times over 10 years. I had to accept that I am probably not a senior developer yet, in most companies, despite having done it quite a while and set mt expectations for difficulty and salary accordingly, while I grow into that. I think that's what you probably need to do too. Sure, you may have a spiffy degree or whatever, but if I was dropping frontend to go into game programming, I wouldn't take it as an affront that I'd be back to junior status in that discipline. I also had to accept that tbh frontend skill building isn't that interesting or valuable, and I don't need to tie my ego into that. Systems in general working well and serving a purpose are far more challenging and interesting, whereas React is basically a commodity speedbump that helps serve some other goal.

Every well-voted comment here implies you need a bit more humility, and I agree. Maybe you do have great skills, but it would probably have been worth sitting on that mid-level frontend job for a while and prove that, because if you do get a senior title at the next company, I feel like it would be basically just a lie, and represent at most what you'd have been doing anyway. Moving up from that mid-level would be much more impactful.

On the other hand, I could be missing the fact the work opportunity provided could simply be so weak as to stall growth in general. Growing react skills is a trite endeavor, but if your work is so banal to the point of absurdity, ya it's fair to bail if you just can't see how you'll advance that.

If you were hoping for a semblance of problem solving, but all you're doing is literally taking photoshop documents and writing html to show them, that's a tough thing to stick out

As a job hopping addict I guess I can sympathize. Maybe I am also too self centered as has been suggested about the author. Having worked at faangs and also with ex Shopify people, I am not thrilled with the life of a dev at these places. Get ready to churn and waste a lot of time. Get ready for multiple rewrite projects to be up in the air. Get ready for hypocrisy as older devs defend very legacy systems that were poorly written ostensibly in the name of reuse but mostly because they want their fingerprint to remain in the code. To me alot of what goes in these companies is highly inefficient if not down right pointless. But the salaried life is addicting and you can't easily come off it.

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.

I had to comment on this:

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

>This is almost certainly not the case.

Except that it reads like they had made it clear to them that it was.

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.

>L3 etc

Why this stuff always starts at some random number like 3 or 5?

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.

> Despite all of these things, my heart said it was time to do something different. That's not for hippy-dippy reasons either. Whenever I reject a gut feeling in my life, my body refuses to work properly which for me usually manifests as insomnia or weight gain. I know people that live like this, sometimes for decades, sometimes never realizing they're rejecting a part of themselves. It's not somewhere you want to end up.

Uhhh I've been like this in academia for a while and can't seem to make up my mind...

i quit after six years in a phd program... my only regret is not doing it sooner

Oh god yes. I too quit a PhD program after six years and massive student loan debt. I'd have so much more wealth right now if I'd left with a master's (1.5 years!) that it's not the slightest bit funny.

Am glad I read this post, it is somewhat relevant to me but also thoughtful enough. I chuckled seeing the vomit emoji after the author mentioned ERB templating.

"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." is a refreshing perspective to hear although I may not fully agree with it.

This might be a good strategy early in your career. Once you have some good experience on your resume, you can change priorities towards other things.

> 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 had this almost exact same experience last year. I left the company only after six months. I definitely saw my front end skills take a big hit in those six months. I think the author here definitely made the right move. No shame in quitting, if it's not a good fit move on to the next thing.

> The reactions have ranged from shock to immediate understanding.

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?

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.

Work/life balance is great at Shopify because it's a Canadian company. This is a constant around here. I'm leaving a US-based company because, among other things, people still think being a workaholic is cool in the US.

I had one job where literally the first thing I did on my first day was give an interview. I hadn’t even signed up for the 401(k) yet and I’m vetting someone (admittedly for my team).

“What’s it like working here?” “So far, this interview is going pretty well…”

This blog just seems like entry-level contrarian ramblings. Hardly HN-worthy IMO

Good luck on whatever you do. You shouldn't feel the need to explain yourself but if it made you feel better then that's ok too.

Without change, something sleeps inside us, and seldom awakens. The sleeper must awaken.

This: https://www.saastr.com/why-if-you-quit-every-year-you-wont-m...

Wow, five interviews. Is that common?

Unless it was clearly communicated from the very beginning, after the third I'd say: give me the job or put me on your do-not-contact-again list.

Yes, it's standard to have an initial screen and then a day of five interviews (e.g. 3 coding, one system design, one behavioral).

I really don't get how this has become the standard, on the team I hire for we do two interviews - one introductory conversation, and a technical interview. After that we're either going to hire you or we aren't, it really doesn't take much more than that to get an idea of whether somebody knows what they're doing or not.

The trend for running multiple multi-day interviews is a waste of the candidates time, and its even more of a waste of your teams time because for every candidate they're now having to take out hours on end to go through the motions of interviewing. I find it painful getting 20 minutes into a 90 minute interview and knowing that the candidate isn't going to be getting a job, I can't imagine having to string that along for a full day.

I think the idea is that a candidate might have a bad interview or not click with a given interviewer, and so doing a few interviews averages this effect out a bit. At least at Google, every interviewer has their history and overall calibration tracked, where the calibration is, I believe, something to do with how much your scores match the other interviewers' scores. This is probably fairer overall, albeit more expensive for the company and the candidate.

tl;dr I wanted to do more frontend work but they made me mostly write Ruby. They're nice though.

imho, they should have expected that, since Shopify is a known Ruby shop

edit: this wasn't meant to insult OP, sorry

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.

> imho, they should have expected that, since Shopify is a known Ruby shop

Why is there always the tendency to blame the person and NOT the company?

Such a tendency is not on display here. This is like accepting a job at NASA and assuming you’re going into space.

> known

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.

CP Rail anecdotally does this with a lot of its office staff in case of a strike.

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.

accurate summary.

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.

What did the author do to you to warrant such a mean-spirited reply?

My read is that doesn't sound personal, rather it sounds objective and factual.

Heh. He was the submitter. From a green account.

Totally unrelated (wink): whatever happened to the term „script-kiddie“?

Nowadays i only see ReactJS senior devs with 1+ years of experience.

I was at shopify for 5+ years and recently left.

AMA

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.

> I accepted. Despite the downlevelling, despite the fact that compensation was well below market, Shopify was a big step for me.

There are lots of good reasons to leave companies fast if they aren't a fit, but this statement was almost everything I needed to know. The author started the job feeling undervalued precisely because he didn't have negotiating skills on the comp package on the way in, and then had his feelings confirmed, possibly by presenting as someone who believes they are undervalued (which is as attractive to be around as it sounds) but also, shopify's HR reps saw the poor bargaining position and offered him even less (a downleveled position) and he still took it.

(Note to recruiters and HR people, if you make people feel either over or undervalued on the way in, they're going to act that way, and then you're going to be mystified wondering why your culture is broken - but in this case the author left so much on the table, I'll direct this to him.)

I'd posit the author left because his professional negotiating skills aren't mature, and in their current state, they're producing poor and disadvantaged deals and relationships. I'm not going to take it so far as to say that the author has that rare martyrly quirk that they seek out disadvantaged relationships because it keeps them feeling righteous and justified - but not setting and signalling boundaries on what you will personally accept, and then blaming others for offering you what you don't want is within sight of the horizon of that anti-pattern. I learned this in a much harder way, but even putting it charitably still feels like it has a hard edge. It's not intended that way.

The implied expectation was that he was "senior," and good at what he does, and independent of what he might be able to do for the company, this by itself demands some kind of consideration. Like when someone says they have a master's degree and wants an extra 30% salary for it, but the degree is in some kind of theory. I interpret that the author may have been indexed on counterfactuals about reciprocity and value going into the negotiation.

It's great to mature as a developer or a hacker, but after a point, there are also diminishing marginal returns on investing in those skills, and making big expensive sacrifices for those skills seems like a substitute for taking risks for success, and this doesn't have anywhere near the yield that reading a book on negotiations or sales wouldn't return in a few hours.

Sure, get Shopify on your CV, become the best <foo> developer you can, I'd even love to work for them, and though I know I too moralize my own blindspots, in this case, I'd posit this was a negotiations failure between the author and the Shopify recruiters.

tl;dr: 'I didn't want to work with Ruby on Rails and I realized I don't care about ecommerce.'

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

> obviously silly

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.

Except it was not "after the fact"?

He got interviewed for a senior position, got offered a mid-level position. Seems to fit exactly the case that you find reasonable.

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.

Couldn't you be fooled by someone that meticulously studied Cracking the Coding Interview but has never opened an IDE in real life?

Given that I don’t at all ask the kinds of questions in that book I think it’s unlikely.

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.

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.

I think you missed the “wasn’t” in this sentence:

> it wasn't based on my answers to soft questions

> never would have hired him for that role.

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.

If anyone wants to strip you of your "Senior" title, run.

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.

We can only speculate.

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.

It actually isn't a sensible reason to downlevel.

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

This is shocking

Reply on news.ycombinator.com