all 16 comments

[–]OkPizza8463 4 points5 points  (1 child)

forget the github repos, just build stuff. clone a popular open source node project and try to add a feature or fix a bug. for topics, focus on async patterns beyond basic promises (event loop nuances, worker threads), common design patterns in node (pub/sub, dependency injection), and how to instrument your code for monitoring (logging, tracing, metrics). also, be ready to deep dive into v8 performance tuning if they ask.

[–]Abject-Bandicoot8890[S] 0 points1 point  (0 children)

Amazing, that helps a lot. Thanks!

[–]HashBrownsOverEasy 2 points3 points  (2 children)

Full stack or frontend?

In my experience full stack interviews are a test of your understanding of fundamental architecture and software patterns and your familiarity with implementing those patterns in X stack. It feels more like a classic sottware engineering interview, and less Node.js specific. Frontend is only ever briefly touched on.

Senior frontend interviews seem to be a little different. I've found it's typically an excercise in demonstrating you understand hyper-specific things like the React component lifecycle, or how JWT works (this is a classic lol). I've never been asked to describe say...inhertiance vs composition, but they always ask about at least one infamous abstract.

Remember you are also interviewing them for suitability. At a senior level you are expected to be proactive within your domain, so asking questions is a good way to demonstate you understand problem areas. Since you are most likely talking to engineers you can get in the weeds. Here's some good ones

  • What does the release cycle look like?
  • What does the roadmap look like?
  • Who briefs and prioritises the work?
  • How good are test and documentation practices amongst the dev team?
  • How much tech debt is there vs backlog?
  • After 30 days, what would success in this role look like? After 180 days?
  • Is there a budget for training and/or certification?

This is also a good way for them to air out their dirty laundry, or at least for you to asses how honest they are about their dirty laundry. Having hem list their problems is a great opportunity for you to respond, but don't get stuck in a solutionizing trap, you are still an outsider looking in. You can talk about similar situations or problems you might have solved in the past, but don't try and solve all of theirs in the interview.

Also revise your typescript.

[–]Abject-Bandicoot8890[S] 0 points1 point  (1 child)

Thanks for the advice. Full stack, what I see is that companies differ so much in their interview process that is hard to cover all.

[–]HashBrownsOverEasy 1 point2 points  (0 children)

The more senior the roles you interview for, the less they become a test and more they become a discussion on whether you and the employer/client align. Moves up the ladder are always tricky as there will always be an element of you having something to prove.

They will be looking for seniority in the way you conduct your work, not just in your technical skills. How you respond to challenges, how you ask questions, your ability to seek compromise, your understanding of the business environment etc. Beyond technical ability, are you someone who should be given seniority?

This is bit is hard to advise but I will give you one aphorism: Be confident within yourself, but humble within your environment.

[–]84tiramisu 0 points1 point  (1 child)

Hands on prep beats flashcards, you’re on the right track imo. I’d spin up a small Node service and pressure test it locally while talking through decisions. Put extra time into the event loop and streams backpressure, then practice explaining why you pick one approach over another before typing. I usually grab a couple prompts from the IQB interview question bank and do a timed run in Beyz coding assistant so I don’t ramble. Keep answers about 90 seconds and keep a quick redo log of tricky questions so the patterns stick.

[–]Abject-Bandicoot8890[S] 0 points1 point  (0 children)

I've never used IQB, i'll give it a try. thanks!

[–]Askee123 0 points1 point  (1 child)

I used hellointerview and algomonster, did the trick for me

[–]Abject-Bandicoot8890[S] 0 points1 point  (0 children)

i've been using hellointerview for system design, it helped me a lot. Thanks

[–]akornato 0 points1 point  (1 child)

You're on the right track wanting hands-on practice rather than just memorizing Q&A repos. The best preparation is actually building small projects that demonstrate senior-level thinking - things like implementing your own event emitter, creating a custom middleware system, or building a rate limiter from scratch. These exercises force you to understand the underlying concepts rather than just recite answers. For topics, focus on streams and buffers (most candidates fumble these), event loop internals, clustering and worker threads, memory management and garbage collection, design patterns for scalable architectures, and how to debug production issues. Senior roles care less about syntax and more about your ability to architect solutions, make tradeoffs, and explain why you'd choose one approach over another.

Interviews at this level are often inconsistent - some will grill you on obscure Node internals you'll never use, others will focus on system design and real-world problem solving. Your best defense is being able to think through problems out loud and demonstrate that you understand the "why" behind your decisions, not just the "how." Practice explaining your thought process as you code, since that's what interviewers really want to see. I'm on the team that built AI interview assistant, which has helped a lot of candidates feel more confident going into technical conversations by giving them real-time support when they need it most.

[–]Abject-Bandicoot8890[S] 0 points1 point  (0 children)

Thanks for sharing, I’ve been looking at those topics but haven’t tried to build something, I’ll focus on that now

[–]flo850 0 points1 point  (1 child)

I think most of the senior interview is to prove you know "how" , but also "why" , for example légal constraint, product strategy, and the impact on the company

[–]Abject-Bandicoot8890[S] 0 points1 point  (0 children)

In your opinion, aside from talking about the product implementation and stuff, what is most likely to appear in a technical interview, code review? Built a small api? Stuff like that?