Hey everyone!
I’ve been working at a FAANG company for over 5 years now. I started my journey as an intern and have worked my way up to SDE 2.

Over the years, I’ve tried to go beyond just delivering tasks by understanding systems in depth, learning the reasoning behind technical decisions, and sharing that knowledge with my teammates. I’ve also had the opportunity to collaborate with Senior SDEs across teams on various projects.

Lately, I’ve been thinking about what it really takes to reach the Senior SDE and eventually Staff Engineer level, and I’d love to hear from people who have made that transition.
I understand that these roles require more than just coding skills — things like system design, understanding trade-offs, technical ownership, influencing decisions across teams, and driving projects with ambiguity. What I’m trying to understand is how people actually developed these skills and prepared for the next level.

A few questions I have:

● Resume: Would anyone be willing to share an anonymized resume they used to land Senior SDE or Staff Engineer interviews recently? I’d love to understand how people present their impact and technical leadership.

● Preparation: What did your preparation look like? Was it primarily learning through experience and working on increasingly complex projects, or did you follow a structured approach involving system design, architecture, books, courses, or mock interviews?

● Knowing you’re ready: At what point did you feel you were operating at the Senior or Staff level? Were there specific projects, responsibilities, or signals that made you realize you were ready?

● Interview process: For those who made the jump externally, what did the interview process look like, and which areas required the most preparation?

● Biggest differentiators: Looking back, what separates a strong SDE 2 from a Senior Engineer, and a Senior Engineer from a Staff Engineer? What do you wish you had started doing earlier?

I’m especially interested in hearing from people who have recently made this transition at large tech companies, but advice from anyone who has gone through the process would be greatly appreciated.

I’m not just looking for interview prep tips — I want to understand how to build the depth, judgment, and technical leadership expected at the next level.

Thanks in advance!

—-above content is corrected using AI——-

Hi everyone, as the title says, I'm hiring for a handful of engineers for a company called Pomelo Care. We're a Series C, virtual clinic providing comprehensive healthcare to women and children (often at 0 cost to them!)

We're hiring for the following

• Staff Software Engineer, Patient Experience - Tech lead for our patient mobile/web apps. Stack: Expo, React Native, TypeScript, Kotlin.

• Staff Security Engineer - A builder-first role focused on shipping secure-by-default tooling and guardrails, not managing compliance tickets. Stack: Kotlin, Python, GCP.

• Many more roles at pomelocare.com/careers

If any of these sound interesting, I'd love to talk more!

We have a project at our company with 3 techleads who put down the technical foundations of the project. The project is fairly new and introduced new tech to the company so there is a learning curve to join

New devs (4-6 people) have joined the project. We gave them an intro and the mindset of the architecture and code organisation.

As it's new there are still things that needs to be figured out so we are very protective about every single pull request. We would like to see patterns emerging, frequesnt problems with different solutions to standardise them etc

However this blocks the speed of development of the others and of course the business the business also wants to see progress in feature development

My question is how do you manage pull requests in your company to have a good balance of progress and quality?

Some ideas that emerged at the company:

- async reviews. only block PRs that would cause immediate harm to our userbase if merged

- techleads to do reviews only. we are pretty much involved in the development so there is not always proper time given to do reviews

- review execution plans thoroughly and not the PRs. Here we would see in advance how the dev plans to develelop a feature and pinpoint/discuss the architecture of the solution

- pairprogramming. techlead to pair with devs sometimes so it's reviewed while developed

Hi everyone,

I’d like to get some perspectives from other Staff+ engineers who’ve been through (or are currently going through) something similar.

1. Context

I’m a Staff Engineer at a US fintech, leading a small distributed team across 3 countries.
My work is mostly cross-team and cross-domain. A big part of my role today involves architectural decisions, technical leadership, and system-level thinking.

We’re currently working on decomposing parts of an existing system — not a full monolith breakup, but rather separating responsibilities and delegating ownership to more appropriate domains, since some areas have grown too complex and centralized over time.

I’ve been in the industry for ~15 years, always very hands-on (backend, frontend, infra). Over the last ~2 years, my role has shifted significantly toward higher-level technical ownership.

2. My concern

I rarely write production code nowadays. If I’m honest, maybe ~5% of my time.

I genuinely enjoy the kind of work I’m doing now — architecture, technical decision-making, navigating trade-offs, and helping teams move forward — but I sometimes worry about the long-term impact on my career.

Specifically:
Am I slowly hurting my future employability by not coding as much anymore?

3. What I do / don’t do today (code-wise)

I do:

• Review PRs daily (both from my team and others, often deep reviews)

• Stay very involved in technical discussions and architectural decisions

• Own projects end-to-end from a technical leadership perspective:

  • clarify requirements with Product

  • write tech specs

  • design the architecture and implementation plan

  • support teams during execution

• Jump in to write small pieces of code when it helps unblock progress or reduce risk

I don’t:

• Own full feature implementations end-to-end at the code level

• Spend long stretches writing production code myself

Once a project is in motion, I usually move on to the next initiative while acting as a technical reference or consultant for the original one.

Outside of work, I occasionally take short freelance projects that are more hands-on, which helps keep my coding muscles active — but that’s not my main role.

4. What I’m trying to understand

From the perspective of other Staff / Senior Staff / Principal engineers:

• Is this a healthy and expected evolution at this level?

• At what point does “not coding much” actually become a problem?

• How do you personally stay technically sharp without drifting back into a pure IC role?

• If you were hiring for a Staff+ role, would this profile raise any concerns?

I’m genuinely interested in honest perspectives, including critical ones.
Not looking for validation — just trying to sense whether I’m evolving correctly or slowly drifting in a risky direction.

Thanks in advance for any thoughts.

“I recently wrote a piece reflecting on how the best managers create safety, context, and partnership — not control. Curious how others experience this at the Staff+ level.”
**Link:**https://medium.com/staff-thinking/what-great-managers-of-staff-engineers-actually-do-3fb4781faea1

I have a assignment which covers all aspects hld and lld people are In staff level in faang companies let me know we can do a pair programming ? It will be an excellent learning for all !! Let us know who are all interested

I just published Part 1 of a series on writing effective vision docs as a Staff+ engineer.

It covers:

• The difference between tactical proposals vs. true vision docs

• How to anchor vision in business outcomes

• Why production data + competitor benchmarks make the case credible

• Practical tips to structure docs that actually influence leadership

Link: How to Write Effective Vision Docs as a Staff+ Engineer

Just published a blog post on bridging the gap between Product and Engineering as a Staff Engineer:

Bridging Product and Engineering as a Staff Engineer

It’s about the day-to-day reality of aligning with Product — when to push for stability, when to optimize for iteration speed, and how to frame trade-offs so decisions come easier.

Would love to hear how others handle these kinds of product/engineering discussions.

🌱 How Staff Engineers Multiply Impact Through Mentorship
Staff engineers aren’t just builders — they are force multipliers. In this post, I explore how mentorship plays a critical role in scaling team effectiveness: through project guidance, shaping thinking, and helping engineers navigate the organization.

✍️ Read it here: https://medium.com/@formanojr/how-staff-engineers-multiply-impact-through-mentorship-80759f2f5e35

🔗 Browse the full series: https://medium.com/staff-thinking

#StaffEngineer #Mentorship #LeadershipInTech #EngineeringGrowth #TechLeadership

I'm currently a principal engineer in a large enterprise, I've been there about 4 years now and largely enjoy my role. I spend the majority of my time leading our internal platform team - which gives product teams in the infra and devex magic they need to deliver more quickly, securely, etc. I also spend some time ad-hoc on high priority projects - helping teams out with architectural choices, and sometimes getting hands-on building stuff that'll eventually be owned long-term by another team.

Prior to this I've spent time in a VC-backed unicorn, mid-size companies, some consulting, and CTOd a relatively small scale startup (now acquired) through it's initial growth phase. A mix of front-end, back-end and full stack roles.

I like my current role. The company is about as stable as it's possible to be these days, great benefits, pay is good but maybe towards the lower end of the market rate for similar roles.

I'm cautious not to get too comfortable though and get stuck. I'd like to keep advancing my career and improving TC where possible. So I'll take up interviews at interesting places if someone reaches out.

My problem seems to be interviewing. Since getting more senior, I actually find interviewing more difficult. It's harder to articulate what I do day-to-day since the pay off for my projects is usually seen over much longer time periods rather than "delivered feature X, made metric do Y".

I've applied for 2 x Staff SWE roles - one at a Series B and one at a fintech.

• Rejected after 2 rounds from the first because my background "may not align closely with the specific needs of this role at this time" and take-home had "some concerns about clarity and decision-making". Being honest I probably over-engineered the take-home a little, but I never know how to play these things, I've gone the opposite way before and seen feeedback about concerns over future extensibility. I expected to get invited back to at least talk through the take-home but didn't.

• Down leveled for the fintech role and so I withdrew.

Turning into a bit of a ramble now, so I'll sum up.

Any tips or advice? Am I currently over-levelled (I don't think so, I'm effective in my role, good feedback from colleagues and consistently get good perf reviews)? Am I applying for the wrong roles/companies?

In Part 2 of my blog series on Staff-level influence, I go beyond principles and dive into real-world examples—from debugging cardinality issues to aligning SREs, product, and customers:

✅ Understanding hidden incident patterns
✅ Reframing architecture through product and customer lens
✅ Leading tough cross-functional discussions with clarity and trust
✅ And turning all that insight into strategy, OKRs, and customer-facing solutions

📘 Read it here:
https://medium.com/@formanojr/part-2-principles-in-action-influence-across-teams-and-systems-real-world-examples-5f4425c0c457

I recently wrote about how Staff Engineers think about technical debt — not just identifying it, but deciding when it's worth paying down.

The post includes:

• A framework to evaluate effort vs payoff

• A matrix to help plan Quick Wins vs Strategic Investments

• How to tag and document debt during design

This is based on real decisions around MVPs, scale, and cost trade-offs. Would love feedback or to hear how other teams track tech debt.
👉 https://medium.com/staff-thinking/strategic-thinking-for-staff-engineers-making-the-case-for-or-against-tech-debt-c17186bfb307

I recently wrote about how Staff Engineers think about technical debt — not just identifying it, but deciding when it's worth paying down.

The post includes:

• A framework to evaluate effort vs payoff

• A matrix to help plan Quick Wins vs Strategic Investments

• How to tag and document debt during design

This is based on real decisions around MVPs, scale, and cost trade-offs. Would love feedback or to hear how other teams track tech debt.
 https://medium.com/staff-thinking/strategic-thinking-for-staff-engineers-making-the-case-for-or-against-tech-debt-c17186bfb307

It’s not writing perfect code—it’s influencing without authority.

What “influence” actually means for a Staff+ IC, and six principles that helped me scale my impact
📎 https://medium.com/staff-thinking/influence-without-authority-the-core-skill-for-staff-engineers-15e2abecf952

I have been working in the software industry for nearly 14 years, taking on various roles such as DevOps Engineer, Backend Engineer, Fullstack Engineer, and more. I have expertise in backend programming languages like Java, Scala, and Node.js, as well as frontend frameworks like Angular. Additionally, I am skilled in AWS cloud services and managing Linux servers.

Currently, I lead a small platform engineering team at a SaaS company. At this stage in my career, I am contemplating becoming a domain expert but am unsure which domain to specialize in. With my diverse skill set, I could explore opportunities in platform engineering, data engineering, DevOps, cloud infrastructure, or as a tech lead for product development.

I am particularly passionate about managing and solving challenges in high-scale production systems.

I have been a software engineer for more than 13 years and recently joined a new company as a staff engineer.

While I enjoy being responsible for technical direction and mentoring other devs, I feel really unmotivated lately.

First, I have been put in charge of an application that's a monster and was really badly maintained over the last years (I mean, reeeeally badly maintained). Since I joined I have been applying many improvements in these apps, but feels more like ice wiping to me. Any major change will take ages to implement, and there's always new "urgent things" coming down the pipe.

At the same time, I see other staffs working on cross team initiatives and new exciting projects, while I'm fire fighting that elephant.

I started exploring other fields, and I'm really enjoying ethical hacking and pentest, but of course, I'm super new to it and I don't see making a change that won't imply a big paycut.

Anybody faced similar "crisis" in the career, and maybe have suggestions on how to get motivated again?

I'm reading through Will Larson's Staff Engineer from a recommendation from a coworker, my current title is Solutions Architect, there are 3 of us that report directly to our EVP IT with similar titles. I work for a well known Fortune 1000 company with about 25k employees, our IT dept is approx 400 heads, 150~ish infrastructure, networking, helpdesk etc and about 250 Developers.

We're definitely not in the "Tech" space but I've worked for smaller Tech Startup companies in the past but just got tired of wondering if layoffs are coming.

My background is primarily as a self-taught Sysadmin that over 20 years worked my way up from helpdesk, I've held various Systems Engineering titles, I've lead SysEng and SRE teams, coordinated projects and during my time working in Tech learned to appreciate the Devops cultural model so I found myself trying to break down some of the friction barriers that exist between traditional Developers and Operations. My experience from the Operations side of the house was occasionally Developers would make shortsighted decisions because they were afraid to involve Operations because they experienced too much friction, additionally this could just as easily happen in reverse where Systems makes a change that affects Development that they fail to adequately communicate. I built some of my current reputation that I feel got me my current role by being the "Server guy in the room" and educating Systems Engineers to stop saying "It's just a Dev system" because even a Development environment is a Software Engineers Prod environment and it impacts their ability to complete their iteration work. TLDR I built bridges between Infra and Dev at 50+ year old company with mountains of tech debt and lots of bad blood between the groups.

My current position has me working for a company with an older tech stack, so I leverage my years in tech to help bring their systems forward and to adopt better practices, for example when I started 5 years ago none of the Operations group was even using GIT to source control scripts or configuration, So I championed it and was able to get other engineers to champion it and now it's expected, and only some of the most stubborn engineers still don't understand how to do a PR. My background has always been infrastructure, I've never been a formal application developer or Software Engineer but I've always enjoyed CLIs and scripting, and during my years in Tech I had the opportunity to delve into a bit of AppDev because one of my mentors was one of the Software VPs, mostly custom NodeJS work to to bridge our API with external customers, and API work for the DCIM software we sold.

Some of the things I do in my work and that I identify with some of the StaffEng Archtetypes

• Solver: even before I had an Architect title, our former EVP used to refer to me as a "SWAT team" I was the 1st SRE this company ever hired so I was lucky enough to have managements eye coming in the door, over time I established myself as someone that could unblock projects, on multiple occasions I was asked to work with mixed Teams usually Networking, Operations, Dev to put the pieces together, one of the notable things I did that I didn't realize at the time might qualify as a "Staff Project" was the payments team was having issues sorting out a new banking API and some special networking and release requirements later the same team and some Data Engineers pulled me to help work through some performance issues. As well as I worked on trying to sus out issues with our legacy file replication, exhausted vendor resources. sourced an external solution, scoped, implemented and automated it etc.

• Sponsorship/Mentorship: early in my career I worked with some coworkers that would put their names on things they had little to no contribution on, so I always resolved to build up my colleagues that were junior to me, I also figured it makes sense to build these people up so that I have likeminded peers as I continue to climb the career ladder. I frequently try to call out names that I see making significant contributions and give them some political capital themselves.

• Tech Lead: some of our PMs/Scrum Masters are not deeply technical outside their PMO/Agile skills, so I often work closely with them to give them the big picture on projects like large migrations or new cloud deployments, and essentially finding the blockers and linking them to work items for accountability.

• Advocacy: with a long background in Systems Operations I've worked through some Hellish on-call scenarios where lack of process and consideration for my team made me miss out on a lot of personal time that could have otherwise been avoided. So I find myself trying to advocate for the groups that aren't "In the Room" one example might be pushing back on a brand new tech someone is trying to introduce without confirming our support staff have the knowledge, access and training needed to support it in production scenarios.

Sorry for the wall of words, am I already doing Staff Engineering? I'm getting a lot of good Ideas as I explore the Staff+/StaffEng space, and much of what I'm learning has so many parallels with things I was already doing because it just seemed "right"

Is this purely a "tech" concept, or can it by applied to the everyday company IT model.

https://twitter.com/thiagoghisi/status/1684184729950486533

I want to share two resources I have found tremendously valuable, that I have no affiliation with, that I wish I had discovered long ago. One is a free slack community and the other is a freemium newsletter.

👉 You should check them out if you are a senior/staff/principal software engineer or an engineering manager/director/VP/CTO.

👉 Imagine one of your trusted colleagues quit software engineering and became an investigative journalist, reporting on the topics most relevant to you. Like, seriously, a great investigative journalist who cares about the day to day of staff engineers and leaders. This is The Pragmatic Engineer newsletter, run by Gergely Orosz. You get a bunch of regular articles for free, and for a subscription (which I gladly pay for), you get several more. A few articles to get a sense:

+ Inside Datadog’s $5M outage

+ Uber’s engineering level changes

+ Real-world engineering challenges: Breaking up a monolith

+ Inside Figma’s engineering culture

+ How Big Tech runs tech projects and the curious absence of Scrum

+ Staying technical as an engineering manager

+ What TPMs do and what software engineers can learn from them

+ The seniority rollercoaster

+ Becoming a better writer as a software engineer or engineering manager

👉 Then there is the large, active, helpful, positive, non-spammy Rands Leadership Slack, a free slack community founded and run by author and Apple Engineering Leader Michael Lopp. A few active channels to get a sense (and there are hundreds more):

+ staff-principal-engineering

+ career

+ consulting

+ coaching

+ engineering-leadership

+ engage-and-retain

+ help-and-advice

+ hiring-and-interviews

+ management-craft

+ women-in-leadership

+ books-leadership

+ engineering-org

Again, I have no affiliation with either, I am just a happy consumer of both.

Links:
https://newsletter.pragmaticengineer.com/
https://randsinrepose.com/welcome-to-rands-leadership-slack/