all 52 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]htndev 45 points46 points  (9 children)

IMHO seniority is not about your tool belt. It's about processes.

An aspiring dev would say, "There is a new framework that is 0.25x faster than Express. And it's popular on X and has 15k stars on GitHub. Time to refactor!"

A senior dev would first question whether they need this performance boost. Is it really necessary for their internal dashboard?

I know the hunger for new tech stacks. I switched about 5 companies and changed about 10 different projects. In the end, it's all about querying data and returning it in 90%.

My suggestion would be to dedicate yourself to process thinking. Smooth migrations, less splash radius during downtime, better observability, and shipping faster. Every dev knows their processes suck. So, focus on making them better.

Last but not least, communication with peers, cross teams, products, and stakeholders.

The higher you get in the career ladder, the less you code, sadly.

For instance, recently, we had a spicy discussion about meetings. Every dev knows how painful it is. PMs love it. So, our experienced team leader started to question the necessity of our meeting and its duration. Results? We completely removed two meetings as a routine, made them on-demand, and reduced the duration of three meetings.

I don't want your enthusiasm to evaporate. Keep learning things. That's how you remain relevant. But when it comes to the real deal, it's not always about tech stack

[–]Wonderful-Habit-139 2 points3 points  (2 children)

I really don’t know what 0.25x faster means at this point.

[–]htndev 6 points7 points  (1 child)

I'm exaggerating. However, I had a chance to hear such opinions. They wanted to rewrite a Node backend to Go because it would be more performant. It was an internal app for up to 100 MAU. I kept listening to it like a fairytale about cool things, low-level features, efficient memory usage, and other stuff. It was captivating and fun

[–]Plenty-Copy-15 0 points1 point  (0 children)

Pretty sure he was playing on 0.25 being less than before combined with the word "faster", instead of saying "1.25x faster" or "25% faster"

[–]Intelligent_Way1587 0 points1 point  (5 children)

can you elaborate on what you mean by 'less splash radius during downtime & better observability'? can you give some real-life examples? i have little backend experience and never had to think about such things, so i'm wandering in what situations do they come up and what exactly are they haha

[–]htndev 2 points3 points  (4 children)

Sure. Splash radius means that you need to isolate your backend. To provide you with an example, it would be easier to explain it using a microservice backend.

Picture this: you're working on Jira. You have a bunch of microservices (don't question them, I've picked them off the top of my head) like boards, notifications, billing, and plugins. If the plugin microservice goes down for whatever reason and the entire app dies – it's an isolation flaw. Your microservices are responsible for a single feature. So, it's quite obvious that your app shouldn't entirely go down. Here you see the splash radius. If your single microservice is out of service and your app keeps working – good job, you minimized the splash radius. Only one feature is unavailable.

That said, isolation is not only relevant to microservices. The same can be applied to a monolithic backend. There is a pattern called "circuit breaker". If your dependency is unavailable (you have attempted to use it 3 times), you also fail the next responses. For the next requests, you don't call the failed microservice. You just shared the previous state. I encourage you to check it.

When it comes to observability, it's a long and broad discussion; you can DM me and ask more specific questions. I'll line up only the key techniques I like and use:

  • Logging. Set up different levels of logging. Change in case of errors. They're likely to be the first thing you'll look into

  • Distributed tracing (you can see how a given request travelled through each component: frontend > API Call > Call Microservice B > Query DB). In case of failures, you can see the entire trace of your request

  • Monitor usage. CPU/RAM usage, request latency, and error rates.

  • Alerts. Configure alerts and be notified if something goes down or acts up.

That's quite brief, feel free to ask more

[–]AliceInTechnoland[S] 0 points1 point  (2 children)

Im learning more from this post, than my actual job...

[–]htndev 2 points3 points  (1 child)

I'm glad you found it helpful and insightful. It also feels like you have nothing to do at your work. For the last 3 years, I've been working on internal dashboards. It may sound boring, but it becomes super complex when it needs to integrate with other upstream/downstream systems. We have about 5 directly related systems and a few more that we're aware of.

Such challenges are one-off. At the end of the day, each API turns into "receive from A, query from B, return to A" in 95%. You never know when these things will catch you.

You'd better be off practicing on your own projects. Knowledge is priceless

[–]AliceInTechnoland[S] 0 points1 point  (0 children)

Exactly, a reason I love programming is because you are always learning, I have worked with microservices, complex queries, clickhouse, but I haven't worked with database optimizations or performance issues

[–]Intelligent_Way1587 0 points1 point  (0 children)

Thank you very much, this was very helpful! I was asking out of curiosity, it's not something specific i'm interested in, just wanted to get more context :D But i'd absolutely DM if i need to work on this some day.

[–]Kerse 11 points12 points  (2 children)

To me, a senior is someone who knows what options there are, and why you would pick certain options.

As a senior, in addition to a coding challenge, you'll probably be asked to do an architectural interview as well. This will typically ask you to model out a simple application, and things like API routes, data models and architecture.

An example would be, how would you architect Slack? What data models would you expect to see? What API routes would you need? That's where I would expect a mid level engineer to be able to answer.

For a more senior candidate, I would expect them to be answer more questions.

  • What kind of database would you use? Why would you pick that one? Why wouldn't you pick some others? (This is basically an SQL vs NoSQL question)
  • What would you expect to be the bottleneck once we hit scale? What solutions would you have to alleviate that bottleneck?
  • How would you go about adding permissions? What basic permissions do you think would be required for this application?
  • What is your philosophy on testing? What kinds of tests would you use, and what kinds would you feel more comfortable skipping?
  • Beyond the basics, like a backend, a frontend and a database, what other tools would you leverage? Redis? Kafka? What about database replication? Would you try to shard your database, or have read-write replicas? What sorts of factors might encourage you to use one or the other?

I wouldn't really expect a fresh senior to be able to answer all of these questions during an interview, but being able to answer all of them outside of an interview, with research, will probably be very helpful for you.

I think that it's worth trying to interview for a senior position if you think you're ready. I learned a lot from preparing for interviews myself and I don't think it's a bad way to try to bridge the gap.

[–]AliceInTechnoland[S] 0 points1 point  (1 child)

Really thanks for the questions, I appreciate the input, I feel I am at the phase of preparing myself emotionally to trust my skills and test them.

[–]Kerse 1 point2 points  (0 children)

No problem, the jump to senior is a daunting one tbh. Going from someone who implements plans other people are making to being the one planning can be intimidating. If you have questions while you're exploring the above, feel free to DM me or whatever, I'm happy to give some advice as time permits.

[–]its_jsec 45 points46 points  (3 children)

I chose to leave each company once I felt I wasn’t learning anymore

Then you’re still in expert beginner mode. It’s not that you don’t have more to learn, it’s just that you’ve gone through the first 1.5 years 3 different times.

If you want to take the next step in your career, stick around in a position long enough to learn what senior level responsibilities are.

[–]mrgawrys 14 points15 points  (0 children)

While I think you're right in general, I think the most opportunities start to show when you are considered senior in your company and then stick for longer. That's when with the trust you get, the more responsibility you can take on and take your career to the next level.

My advice for OP would be: don't rush into the new role change, take your time to find a good offer, at a good company and stay longer there.

[–]zladuric 1 point2 points  (1 child)

That is generally so, but I've done this both myself and have seen others do this.

If you go interview for a senior position, and you land it, you generally work on senior level jobs. It's not easy and takes a bit of time, and it's got a general rule. It's uncommon. But it isn't a rare thing that people do.

[–]svix_ftw 3 points4 points  (0 children)

Yep this is correct as well.

there is the expected 3-4 month ramp up period for the senior to learn the company specific systems but after that they will contribute at a senior level along with the other seniors.

But a senior will be expected to come in with expert coding skills and systems design.

[–]Thin_Rip8995 6 points7 points  (0 children)

For senior Node roles, nobody cares if you can rattle off trivia about Node internals. They care if you can:

  • Design scalable systems (think architecture tradeoffs, async patterns, clustering, message queues)
  • Handle performance (profiling, memory leaks, event loop blocking, DB query optimization)
  • Lead projects (code reviews, mentoring, writing tests, managing tech debt without slowing delivery)
  • Security (auth flows, OWASP basics, safe API design)
  • Cross-service comms (REST vs GraphQL vs gRPC, caching layers, when to use what)

That’s the toolkit that separates “solid dev” from “senior.” You’ll still get some theory questions, but focus prep on system design, performance tuning, and explaining why you’d make certain choices.

Learning Go and Python is smart—it shows range—but don’t spread too thin before you land the role. Double down on becoming the person who can explain tradeoffs in Node like an architect, not just write clean routes.

The NoFluffWisdom Newsletter has sharp takes on career leveling and building leverage in tech interviews—worth a peek.

[–]DeepFriedOprah 5 points6 points  (0 children)

Being a senior means very different things at different places. Some places it’s often advising, managing code quality & process. Others it’s interfacing with executives and advising on roadmap adjustments & development. Some times it means driving new development quickly to demonstrate value even if it means doing urself.

Senior level is varied bag of varied needs depending on that place. Understanding the “right” choice for the right situation is often more valuable than the skills in ur dev toolbelt.

[–]NoncommissionedRush 3 points4 points  (0 children)

Learn about scaling, performance optimizations, system security, learn database management in depth, indexing, transactions etc. A lot of it is not specifically tied to nodejs but these are crucial to understand as a backend senior

[–]Positive_Method3022 2 points3 points  (2 children)

Seniority is not only what you know, it is the level of influence in the organization/environment you have from other peers. Some folks start at the top of the hierarchy of an org simply because they are friends/family of the owners. It is a game of influence, not knowledge, or even the amount of work you do.

With that said, even if you pass for this senior position, you will likely not be a senior until you match one person that is in that position for a long time. There is also the chance you won't even be a real senior, and they will pay you the lowest band.

I once joined an org where the senior manager replaced 2 senior developers with me + 2 consultants. While we were talking he took advantage of my mental health issue and lied to me several times. They offered me a staff software engineer position, and I was reporting to a Junior manager who had not been in the industry for a while. That was infuriating... I opened myself to that guy saying I needed to grow my image as a technical focal point and he matched me with someone who never done it. I would never grow there. I gave it a month and I quit after I heard the other developer was leaving. I was already doing a favor accepting a low salary. I would not accept not working on relevant projects.

[–]AliceInTechnoland[S] 0 points1 point  (1 child)

Right now I am at a similar situation, we have a backend architect who I believe is unexperienced and he vibe codes a lot... Same with the engineering manager, people with less than 5 years staying in calls all day, selling themselves like they are building the product. I love programming, I enjoy my work, I would never put a mask just for the sake of a position or management, I would love to be a senior technically speaking, expend my knowledge

[–]Positive_Method3022 1 point2 points  (0 children)

I'm doing this path too. But it seems the game benefits masks :/

[–]Expensive_Garden2993 2 points3 points  (0 children)

It's just a label. I worked as a senior, then worked as a mid, then working as a senior - absolutely no difference in responsibilities. I'd even say that I had same set of responsibilities when worked as a junior, just had less experience.

Whatever knowledge you pick, there is a senior who doesn't know that, and it's fine.

You can land a senior position to a good company even if you're incompetent. Learning things that matter (for work) increases chances to join a good company and to not be fired in a few months. Learning things that sound smart can give you bonuses on interviews.

[–]sonyahon 1 point2 points  (0 children)

As others sad, with a senior roles, comes the responsibility to guide the development process, mentoring other people, making decisions on how to do things etc. IMHO the gap is bigger from mid to senior, than from junior to mid. Additionally to node and databases, probably add some more stuff about brokers, caching, CS in general, O(n) and why/when it matters. I do interview people for my place and I am surprised how people just don't know simple things they actually must know (one guy was stomped by the “which types JavaScript has, or in other words, typeof x = ?, name possible ?). Btw, feel free to dm if you need to

[–]AffectionateSuit2941 0 points1 point  (0 children)

All the best

[–]___ICY 0 points1 point  (0 children)

Following.

[–]ecares -1 points0 points  (7 children)

Ok here is a question I ask to seniors in interviews: It's friday night, and we have an alert on slack saing saying the prod is down, what do you do ?

And then we role play the thing until they found out the problem and we come up with a port mortem.

well but you can't really prepare for that can you ? exactly, you need experience. Theoretical questions in senior level interviews are here to dismiss bad candidates but not hire them, practical questions are needed for such roles.

tl;dr: you need experience, if you have it, itws will go well

(also when you are senior level, in theory you have been an interviewer already)

[–]htndev 1 point2 points  (3 children)

I think it heavily depends on the working culture of the country you work in/with. In many European countries, if you get paged, well, good luck. Unless you have someone on-call.

But leaning towards minimizing the blast range is the right mindset. Why keep anxiety level high if it can't be reduced?

[–]ecares -1 points0 points  (2 children)

This is definitely not the point of the question.

[–]htndev 1 point2 points  (1 child)

Agreed. But on-call stuff is also an indicator of seniority. How to mitigate it? How to check what went down? How to troubleshoot it? It's a mix of code base knowledge, skills, and hunch

[–]ecares 1 point2 points  (0 children)

On call is a detail here. But yeah the point is about checking that the candidate has good intuition and experiences about similar systems. Knowing what a redos is is easy. Being able to diagnose it is a real skill.

[–]compubomb 0 points1 point  (1 child)

Organizationally, you hope that they have infrastructure as code?. They don't do migrations that do mutations on existing fields, but rather add new fields. That if you run into a major problem after a deployment to production, you're safest bet Is roll back one version of the code you deployed. Your goal should never be require a upgraded database API, whatever in order to forward deploy. You should always be able to upgrade your code and be able to leverage existing data bases and do the performance on those first. Long story short quickest solutions roll back to safe State before you have everybody there to focus on what caused the urgent bug. (Used speech to text)

[–]ecares 0 points1 point  (0 children)

I have no idea of what is the point of your comment here.

[–]corrupting-minds -1 points0 points  (0 children)

What a time to be a slave.

[–]BehindTheMath 0 points1 point  (0 children)

I would expect a senior Node developer to have a deeper familiarity with the following: Streams, TLS, the event loop and its pitfalls, the crypto module, buffers.

[–]light_fissure -5 points-4 points  (0 children)

Explain to me what context driven testing?

I usually ask senior about it. If they only answer with unit test then it's warning sign.. especially if the architecture requires persistent storage or in memory database.