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?

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_!

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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

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.

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

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

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.

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.

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.

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

I am finding this whole thread very weird!

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

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

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.

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

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 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 seems anxious but I think anxious people still make valuable contributions alongside those of us who are calmer.

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.

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.

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.

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.

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'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?

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

Probably not.

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?

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.

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

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.

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.

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.

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.

Like the coding challenge. The naive expectation is that you quickly and correctly solve the problem they give you. But the actual expectation emphasizes asking about edge cases and collaborating with your interviewer. Solving the problem quickly and correctly is not actually the optimal solution. Partially because it doesn't allow you to demonstrate collaboration but also because the interviewer might think you've seen the problem before and have memorized a solution. Even though memorizing a solution and regurgitating it is basically what everyone does on these challenges.

General work experience questions are similar. You don't want to tell the truth. You want to give a STAR (situation, task, action, result) answer that shows you have whatever characteristic they're looking for. The majority of people won't have actual good stories for most of those so just hammer that grain of truth into whatever the interviewer wants.

I'd add thoughts about system design, but I really suck at those and still haven't quite figured out what everyone's looking for.

Oh, god. Sometimes it's like pulling teeth to get people to respond with concrete stories. Lie for all I care, but tell me something about what you've done in the past. Granted, I haven't interviewed anyone since I was in college hiring other college students, so hopefully people in the real job market do better here.

- whether they understand an issue when I try to "poke a hole" in their design

- whether they can quickly synthesize that problem into a possible solution (even if it isn't the best solution) and what the tradeoffs of the solution are

- how easy it is for me to understand the solution as they're explaining it

Essentially, I am testing their ability to contribute in a technical design discussion while remaining humble and open minded.

I admit it would also be nice to test their ability to actually design a good system, but rating someone on their ability to do that in a reasonable time frame seems far too fraught with biases around what "good" is or the degree of familiarity with the domain.

Especially for a company that worked on social equity issues, conflating life adversity with sundry issues faced in a corporate job seems odd. Your answer seems pretty appropriate!

But more generally, I'm now interested in completely misinterpreted interview questions, and funny stories about same.

The recruiters should explain what they mean if they are redefining terms, especially since people regularly interpret it differently.

> For the Life Story, you can expect an informal 60-minute conversation via video with a Recruiter from our team. Interviews at Shopify are two-sided conversations. We are genuinely interested in getting to know you and we want you to get to know us, too.

It seemed so out of the blue to be asked the typical questions contract recruiters ask about programming languages and years of experience in those languages.

I actually remember thinking "perhaps figuring out that the question they asked is not the question they actually want answered is the test. Figuring out that a stakeholder wants something very different than what they initially ask for is a very important skill for developers." If so, good on shopify recruiters! They're playing 3D chess.

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

https://www.linkedin.com/in/joshcsimmons doesn’t mention graduation year and seems to try to pass off the UC Irvine time as professional experience rather than academic, but other social profiles like Quora say “Graduated 2019” after doing a PhD in Music Composition & Music Technology.

I’m sorry to hear Shopify wasn’t the experience you wanted.

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

I don’t think Josh started as a Senior and then got demoted, the post explicitly says the $ was less than desired (due to the offer being made at the lower level).

I suppose it depends on your org. Where I work "senior" is the second level up, where the first level is given to new hires fresh out of college (mostly master's, some bachelor's). If someone comes in with a PhD in a related field -- though perhaps not a completely unrelated one like music composition -- I'd be surprised for them not be a senior or even a lead (the third level up). The researcher positions that require a PhD tend to be advertised as leads in my experience.

I was originally hired as a senior data scientist although I had minimal relevant work experience, but I had worked in an arguably related field (mostly ETL) for 5 years after bailing out of a PhD program (all but dissertation in economics).

Dismissing working for a university IT department, if that is the case, isn’t fair.

There's a sort of all or nothing aspect to how you handle the view layer in Rails, at least for a smaller code base. However, I'm sure Shopify is large enough that they have apps doing a little React, a little server rendered in ERB, and others that are fully React backed with an API, and probably some that don't have any JS framework at all.

Sounds to me like this person was overwhelmed by the sheer size of the codebase and how little control they had and decided it was not for them. I don't blame them. eCommerce is tough. eCommerce on such a customizable platform must be like walking through a minefield.

It's not "fun" per se in the front-end part, but it's absolutely fine, and what's required for my work. I don't mind it at all, if anything I'm happy and curious about BE/Python and how that part works.

It's 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.

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.

Is this really that unusual? I feel like most places I've worked, as long as I made it to meetings nobody cared if I stepped out for an hour to run errands or something.

Extremely.

Lets obviously ignore the large percentage of the workforce that are waiting tables, stacking shelves, have to use a punchcard and have their hours tracked to the nearest minute etc. for whom stepping out for an hour to run an errand probably means they get paid a couple of hours less at best or fired if its done without the permission of their supervisor ...

Professional 'knowledge' workers - there are workplaces where its ok, there are workplaces where you would put your career into reverse at 100mph by not being present from 7am to 8pm for your 9am-5pm job.

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.

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.

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.

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

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

the result of the changes was a half-dead demotivated engineering team that never revived. titles were fixed three years in, but it was too late. business teams had moved onto bigger and better jobs by then. good luck trying to get hyper-growth when you've screwed over all the engineers

1. check linked in. if you a dozen of kids out of undergrad in Marketing/Product/Sales/Strategy/Finance with Director+ titles a year or two out of college....and others out of industry with entry level titles, RUN. There is obvious inequity. You wont be able to motivate people to work hard with such a setup.

2. avoid companies with split executive offices. Our engineering group was 95% on the East coast while the "business" office was in SF. CEO/CFO/CPO/CRO all in SF. CTO on east coast.

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

In my opinion, "years of experience" should not be disqualified as one of multiple evaluation tools for skill. I think it signifies that you have had the opportunity to go through a variety of situations, challenges, projects etc. and you have accumulated knowledge and experience that cannot be learned by reading tutorials or working on side projects.

From personal experience and by talking to and working with other much more experienced engineers than me, I have noticed that some of the most important knowledge is obtained just by working on something for a longer amount of time.

Obviously, there are many exceptions to this rule, there are engineers with years and years of experience that are just bad at what they do. What I am trying to say is that this tool for evaluation should not be discarded.

But was shocked they consider a senior dev someone who had many jobs that made him a better developer.

WTF?

Soon we need Senior+ and Senior++ levels, if anyone can be senior.

The seniors i have seen, in my decade of programming, scare the shit out of me and make me feel like i just hello worlded into programming.

I started this after 1 month at a company and it sucks. I think it makes sense for leads/managers to do interviews quickly after joining if they were hired to build a team, but seniors are sometimes not team leads at companies.

Key reasons why this will make your new employee uncomfortable:

- They probably don't know the company very well. You're intentionally choosing someone who doesn't know the company to represent the company. That's going to make them uncomfortable and it appears to be a bad decision on the company's part

- If you hired someone primarily for coding, you're throwing interviews in along with learning the code base and company and other teams

- If you didn't tell them they'd be interviewing soon after joining (they didn't tell me), your company appears deceptive

They really appreciated this since it showed them that there was no hidden conspiracy in the process, we were giving everbody that applied the same opportunities to be accepted, and we showed then that throughout the process we were actually trying to find a fit for a person within the company instead of trying to find reasons to reject them. This also gave the new candidate the chance to aks the new hire questions related to their own interview process and first impressions in the company and eased the tension a bit.

If they wanted to carry on and participate in interviewing the next session we would let them lead the challenge, with me shadowing, to gain confidence and experience, and later on, if they still wanted to carry on, they would be fully qualified to do interviews just like other members of their team (unless of course they really weren't capable, but that never happened).

So I would say the approach really matters when discussing things like this. For us it was a positive.

In one case, I was hired as a back end services engineer and wound up working almost exclusively on a React SPA. In another case, I was also hired on as a back end services engineer and my team was asked to take over development of a native mobile app even though only one out of my four teammates had any iOS experience (I had none). It took our team two months to ship anything meaningful (a talented mobile team could've knocked it out in a sprint) and then it was immediately back to web work.

In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies).

This is something I’m dealing with in my current job. I would love to hear how people have been successful at conveying this to leadership.

Alternatives such as using a supplier to build the iOS have their own costs and outcomes. For example, cost in terms of capital dollars, a technical person still needs to invest time in finding the correct supplier, a technical person still needs to invest time into creating the specification to build upon (even if you find a supplier which can do agile and incremental delivery/iteration), and management overhead for managing the team and/or relationship with the supplier. Further, since the product is something that needs to be maintained (presumably), a maintenance plan of some sort will need to be put into place, and for the benefit of getting it done more quickly, a better product by developers interested and competent in the domain the total cost will likely be lower, and other projects will slip less. There's also the advantage that if management has to put in capital dollars then they are more likely to take the project seriously and fund its maintenance and reward those involved, especially if that's accounted for up front.

Interestingly I see this is a few ways:

* Every small 15-30 minute call knocks me out for hours. I really need at least one full day a week with minimal meetings and that includes the daily stand-up. I honestly think the daily stand-up costs companies millions per year in productivity cost

* Moving from project feature to feature is costly. So if you're working on feature X this sprint and then the PO moves to feature Y in the next sprint due to priorities it'll slow down dev. Doing this often (say every sprint) will kill velocity

* Moving from project A to project B is also a big killer for productivity

* Moving around tech stacks as you've said it happens occasionally in my experience but when it happens you're often flustered

I'd much rather give a team 3 months to ship something that I'm 99% confident will be delivered than to try it twice with two teams that have an 80% chance of delivery each.

We had a great mobile team that slowly left the company because they were being asked to prioritize web work, and when they all left and the company realized that there was mobile work to be done, they started asking us web devs to prioritize mobile. They were getting lots of complaints across the org of never-ending context switching and they didn't really care.

I'll ship stuff because it's my job, but I won't stick around for management that can't be bothered to keep their mobile and web teams happy enough to prevent these insane context switches.

> 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

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

people who practice leetcode are either unemployed or too desperate to get a job

employers who do this have bad hiring practices and bad attitude

my personal advice: get work from people you know, beggars can't be choosers

I wouldn't necessarily say this. Since it is "how things are done," these days, I strongly suspect that folks want every competitive advantage they can get, and it's perfectly understandable.

It's just that it's an extremely 1-dimensional way of evaluating people that are supposed to be creative and intelligent. It doesn't actually tell you anything about them; just that they are good at practicing rote (which, to be fair, may be exactly what a corporation is looking for).

I am very fortunate. I spent my life, living frugally, and investing carefully, so I have the ability to step back. I know that very few people have this capability.

A career is a really big deal, and worth it to prepare for.

The problem is that over thirty years of shipping software is not something that is easy to express in a few scholastic tests. It's something that can sometimes be easily demonstrated, but consuming and evaluating it is time-consuming.

I have spent a lot more time, preparing my portfolio, than lots of folks have spent at leetcode. If that's not valuable to a company, then, c'est la vie.

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

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.

I don't doubt the author, but this specific statement seems off to me in a general sense.

Sure, you can get rusty with a specific set of tools, but picking them up at a later stage should not be too much of a hassle. _Should_ is the keyword here.

Do others feel this way? Am I misinterpreting this?

I can see why someone who's trying to make a career as a React developer would see a primiarily-ERB role as a detour. And maybe in their next round of interviews, people would question how good they are at React if they spent the last X years doing mainly ERB/HTML with only sprinkles of React. "I see you don't have a lot of recent React experience..."

And yeah, I agree - a person can get rusty with some tools and pick them up again just fine. The trouble isn't whether you (the interviewee) believes that, it's more about convincing the person on the other side of the table. The perception in JS-land is that things change Very Fast™ and that skills quickly go obsolete. (Disregarding that if you zoom out, React hasn't changed majorly in 4 years and it's been the dominant choice for 6+ – the perception of fast-paced change is definitely a thing)

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

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.

It wasn't per se a large org issue, or such - or a "scandal" that is so commercialized into #movements today.

He just didn't like the work, expected more, didn't get a good offer (it was downgraded from his perspective) and in the end didn't think it was worth his time to stay.

That's a reasonable decision to make. Many people stay for the branding but hate the product.

I stayed as companies not liking the work, or the brand but just for the money and opportunity on my resume.

The people made it fun too, for a while but once the people change and the work becomes work work, it's time to go and I did.

He didn't like the backend work? Okay, that's actually quite fortunate for him, he can just quit and move on, but I'm here for Real Developers of Beverly Hills.

I posted my comment before the comment thread become full of people telling the OP they are wrong or bad, which I find very bizarre!

I did think the OP was not super clear about why they actually left, so I took a shot at summarizing what I think I got from it, to see if other readers shared my reading.

Caveat: I probably wouldn't take the switcharoo at the very beginning either...if I'm told I'll work on A but actually get B, this is likely a sign of some important things not working well at the org.

You wind up exhausting yourself trying to pick up new technologies that you wind up forgetting because you're not given enough time to deeply learn the concepts.

I've also been at a place where I was not allowed to program in C, but had to do all the code reviews for the people programming in C. The "logic" was that since I was doing the code reviews, I shouldn't program in C since no one would review my code. I sometimes wonder about how I encounter these situations a bit too often.

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

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.

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

What is WITCH?

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

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

In 5 years, I'd expect a WITCH engineer to be exposed to and deeply understand many industries and companies. I'd expect them to learn to handle stakeholders as well as code. I'd expect them to be exposed to many different vendors and tech stacks.

But mostly I'd expect them to get really good at making a big impact very quickly, with limited time and people.

When I compare that to a guy getting paid $1 million a year to run a team of 4 people who build youtube revenue dashboards or something, adding one graph a month, I know who would want working on project I cared about.

The WITCH engineer was just unwise enough to be born in India right? Probably went to the top schools there, has an MBA and a masters in compsci... Just... Indian, so worth less for some reason.

The comparison is between FAANG FTE and WITCH contractor. This isn't to do with nationality or birthplace. There are many Indian FAANG FTEs just as there are many American and European WITCH contractors.

Wipro, Infosys, TCS, Cognizant, HCL.

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.

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.

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.

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

You're not.

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

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

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

The SWE ladder however starts at L3. With extremely few or zero exceptions, no SWE is hired at L0-2.

The idea is that people at the same level in different levels are at roughly the same level of responsibility.

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.

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

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

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.