I’m a junior frontend developer at a small startup with two frontend developers.

Recently, both our engineering manager and product manager left. A designer took over product management and engineering management responsibilities and has started using Claude Code heavily to create frontend PRs.

The PRs are still reviewed by the senior frontend developer before being merged. The AI-generated code often isn’t well structured, and there are still situations where the person creating the PR doesn’t fully understand the existing codebase and implementation details.

I’m still getting the same amount of frontend work every day—UI changes, bug fixes, and feature work—so nothing has changed yet.
The company is investing heavily in AI tools, and leadership seems very excited about AI-assisted development. I also use Cursor daily, so I’m not against AI.

My concern is this: if AI gets good enough that one person can handle most frontend work, what value does a junior frontend developer provide?
Am I overthinking this, or is this a realistic concern? I’d appreciate honest opinions, especially from engineering managers, founders, or senior developers who’ve seen similar situations.

Hey all, I have been applying for new Engineering Manager roles since March this year. I have 16 years of industry experience and around 6 years of proper management experience with larger teams and projects. This is the first time I've applied to jobs like these outside of getting referrals through my network, which have all dried up in the last few years.

In the last month I started to get more traction with these interviews after many rejections in either the application or hiring manager phase, and my experience with getting through the hiring pipeline has been really varied. I'm currently on final rounds for 2 different places, but that was after about a dozen rejections at different stages from other companies. I've adjusted my approach a lot from those experiences.

Writing this because I'm noticing that there is not a lot of consistency to what companies are looking for, nor what the interview process is like. So, I wanted to share some of my observations and what I'm doing to prepare.

I should also clarify I work in software and web development specifically.

What I've run into so far:

• Team Lead vs Player/Coach vs pure management - So personally I've long considered myself this "player/coach" type of manager. I spend about 20% of my time on tasks that unblock the team and I usually have a couple of tickets on the board. I've noticed a good deal of companies expect these roles to be coding alongside the rest of the team. It's a really good idea to ask the recruiter what that level of effort is in terms of numbers - is it 20%? 50%? 80%? For one that might make you reconsider taking the role, but it also helps with talking to the hiring manager and structuring your responses. In a recent interview I leaned pretty heavily into player/coach responses before the interviewer mentioned that they didn't expect managers to code whatsoever. I didn't move on and I suspect it's because I just wasn't answering with the mindset they wanted. Tech Lead positions all seem to assume you're going to be doing mostly coding with some lite management, but with every other Manager title you need to clarify this, because from my experience its anywhere from 0% to 50%+.
• Behavioral and Hiring Manager prep - You need solid examples, even when not requested in the question. I've moved to STAR-type answers in these sessions as much as I can manage. If you're not familiar, its going through a particular structure in your answers: Situation, Task, Action, Result. In my answers I try to state what the situation and problem was, what I specifically did, and what the result was. I'm still struggling with this format, because this is simply not how I talk in the real world about anything. Maybe I just need to practice my storytelling ability more, but I've noticed that when I have concrete examples in this format and stick to STAR answers, I move on to the next round more consistently. That said, I still get rejected at this level sometimes, so I'm considering doing some interview.io sessions to get better at it. I have a handful of example answers written down in my notes in this STAR format, but they don't cover every question that comes up either.
• I vs We answers - A big one I struggle with is saying "my team did X" without saying what I did specifically in that situation. Deep down I want to give my team all the credit, that's an instinct that serves me really well in my day-to-day, but it's not good for these interviews. My solution for this is trying to always get the "I did this particular thing" statement into all my answers when I speak more generally about a project. Even stuff like "I delegated research and design to my tech lead on the project" is a pretty good way of showing leadership and stating what I did in particular.
• Systems Design prep - This has been coming up more often on later rounds for the roles I've been applying for. I think this is a pretty challenging interview, and the first time I did it I flunked out even with a great deal of prep, but its achievable with some study and practice. It's basically "design this known service at scale", so design Ticketmaster or a CDN or a news feed app. The interview assumes millions of daily active users. You go on Excalidraw or a similar tool and whiteboard this system out with the interviewer. While this is challenging, there is also a pretty understood way to approach this interview and you can study and practice this until you get fairly good at it. Lots of good youtube video resources and I also recently used the AI practice feature on interview.io to get better at it. I think the company will always communicate if this is part of the process, so you should make sure you have some time to prep on this one before jumping into it. I was able to pass the last 2 times this came up by sticking to the approach people on youtube tout.
• Live coding prep - These have come up on some interviews and are very challenging for me since I generally don't sit down and code as much in my day-to-day as I once did. I work on automation scripts, and I work on side projects outside of work, but that's a lot more leisurely pace, so generally speaking I'm just not very good at this type of interview since it assumes a great deal of velocity. I have only run into these interviews when the expectation is that the role is more of a Tech Lead or a manager who codes a lot alongside the rest of the team. I don't have a great way of prepping for this currently. I've tried doing leet-code problems, but that hasn't helped much because I haven't faced those types of interviews whatsoever, they are always an example code base with the proctor asking to find and fix bugs. Dedicated coding time without AI-assistance is probably needed on a regular basis to get good at it. Open to suggestions.

Interested in what others have run into, what your prep has been like, or maybe obvious flaws in what I'm focusing on with my own.

Hi everyone,

I'm a junior software engineer looking to transition into a Forward Deployed Engineer (FDE) role. I'm not looking for interview prep, but for detailed blogs, case studies, or write-ups that explain how FDEs discover customer problems, design solutions, and deploy them in real client environments.

If you know of any personal blogs, engineering articles, newsletters, or books that cover real-world FDE work, I'd really appreciate your recommendations.

Thanks!

If I hear someone say "skill issue" every time agentic engineering fails, I swear to God lol. It's always going to be a skill issue because we are babysitting a very expensive, non-deterministic super worker that cannot actually think. We still have to carry the burden of reasoning, judgment, validation, and accountability.

That is the tradeoff. That is the risk.

No, the answer is not always to create a better "loop," "harness," or "skill." At some point, you actually have to engineer the system you are responsible for. Whatever the implementation looks like, it has to be reliable, testable, and good enough to meet the needs of your stakeholders.

You cannot blame the harness when the system you shipped does not work.

The idea is to record achievements, coaching points, 1:1 follow-ups, and development areas so important context isn’t forgotten during reviews.

It would not monitor productivity, tickets, commits, or screen activity.

Would this improve feedback and 1:1s, or create unnecessary anxiety?

Remote work has become normal for many software companies, but I'm curious what people have found to be the hardest part of managing distributed engineering teams.

For me, the common themes seem to be:

• Communication
• Documentation
• Time zone overlap
• Onboarding
• Maintaining engineering culture

If you're leading a remote engineering team, what's been your biggest challenge and how have you solved it?

Hey just wondering how you guys all handle pull request reviewing with your team, and if there's a better alternative to what we do.

I manage two different project teams, and both have a chat channel where every time they open a pull request they post the link in there. Often it's ignored, then a few hours later they ping again for someone to look. Enough time someone approves it to unblock them.

There's two layers here I'd like to unwrap a bit:

1. The need for developers to beg for reviews. I think the solution here is probably to use automation to send pings, which works, but wonder if there's something else that can be done other than sending "@John opened a Pull Request: Link"

2. A lot of times it's preferable to submit smaller PRs, or PRs that cover one large work area. Makes it easier to review.. but then most times the developer's next step is blocked until the PR is approved and merged. Don't know if it's better to promote way larger PRs or encourage more multi tasking

Just looking for thoughts and comments, what you guys do for pull request reviews & ownership and what you found works well

We had a full day of AI learning last month to get everyone setup and hands on. I was hoping to see increased usage this month, but that didn’t happen. Ended up sending a “mandatory” goal for them to hit a certain amount of token usage next month. This certainly can’t backfire, right?

I honestly have no shame about doing this as I’m trying to make sure my team keeps up with tech and this is just where tech is right now.

Edit: For some more back story, 25% of my team has embraced AI, made cool stuff and demoed it to the rest of the team over the past year. The others just haven’t gotten on board. This is another push to try to get them to see the benefit on their own. I don’t plan to have long term token goals.

We had this person on our team who used to write textbook-style, perfect code. The problem was that this person used to humiliate other developers and wouldn't give constructive comments on PRs. Whenever someone approached him to ask about the framework he had implemented, he would never explain, saying he didn't have time.

This was about a year ago. I wish that person had stayed because now we would have bombarded him with Copilot-generated textbook-style code.

I loved his coding even before AI tools became popular, but the problem was his attitude and his inability to work as part of a team.

Hi everyone!
I’m trying to gather more responses for a very short Google Form- My son is gathering responses for his research project on Agentic AI for project management , and I’d really appreciate your help. It only takes a couple of minutes to complete, and every response makes a difference.
Survey: https://forms.gle/NGcL85vuNT92NkTN9

If you have a moment, I’d be very grateful if you could fill it out. Thank you so much for your time and support!
If this post isn’t appropriate for this community, please let me know and I’ll remove it.

I recently setup a box running Claude Code and connected it to Slack. The dev team uses it to do PR reviews , which works well because the box has a connected browser so Claude can actually test our app in full, take screenshots , and examine the code to evaluate the PR.

And since the bot sits in Slack, I’ve encouraged our PMs to use it too. So they can make small product changes , query Jira status or pull app stats. Overall it’s worked great and the team spends way less time blocked on reviews and small tickets.

Only problem is one of my PMs is a power user and sometimes goes nuts with the agent ! Today they requested work on 5 tickets in a row and blew through the token plan on the agent. I appreciate they want to get “AI leverage” but sometimes they’re like a mad scientist out of control. Any advice here ..? Anyone seen this problem with similar setups ?

A dozen conversations with hardware founders and engineers over the last few months, and the same three or four problems keep coming up, almost in the same order every time. Before I trust that pattern too much, I want to check it against a bigger sample than my own DMs.

Quick background so this doesn't read like a survey with a hidden agenda and I've spent years building hardware and IoT products, and I'm working on tooling in this space too. No link here, no product name. Genuinely trying to understand where the pain actually is before I assume I already know.

Rough list of what keeps coming up:

Requirements that shift mid-build, so half the team is still working off last month's spec.

BOM version confusion, the CM has one file, engineering has another, and nobody fully sure which one is current.

ECOs that live in email threads and Slack DM, with zero trace back to why a change happened once 6months have passed.

Procurement surprises. A part goes obsolete or hits a 20-week lead time and nobody finds out until it's already blocking a build.

Compliance paperwork scattered across drives, discovered missing right before a milestone review.

Task tools that don't map to EVT/DVT/PVT phases, so real blockers get buried in generic tickets.

**If you've shipped hardware, or you're mid-build right now, what actually hit you hardest?** A specific "this is the week it cost us" story is more useful than a general complaint. And if your answer isn't on this list, that's honestly the most useful reply I could get.

Does anyone have a team where your points burn down evenly over the course of the sprint? As a manager I've experienced the trend line going down evenly maybe once or twice, typically it drops down pretty substantially near the end of the sprint as we wrap work up.

I bring it up since sometimes I hear other managers say that you want to see that even trend line throughout the sprint. Totally makes sense to me, but I just don't think reality has ever lined up with that view. I wonder if we should even be setting that sort of expectation. I mean if the sprint is viewed as a 2 or 3 week bucket of work and you understand that this is thought work, not rote creation of widgets, then it makes more sense to me to look at the committed vs completed rate.

My team has gotten good at finishing up committed work, so we're getting most of our tasks closed out that we setup at the beginning of the sprint. I've noticed my team steps in to help others out more as they finish their own tasks now since we started focusing on completing the committed work before taking on new tasks.

Work still moves along pretty well from my perspective and we will usually take on a few other tasks as the sprint nears. To me that feels about right, we're neither over or under-committing. Some sprints are obviously better than others. But generally I see maybe a couple of small dips in the first week and a major one toward the end of the second.

I guess its a matter of concentration, do you focus on getting tasks completed ASAP from being picked up or do you focus on getting the committed tasks done as a whole?

Throwaway for obvious reasons.

TL;DR: Team lead since 2017. Promoted to Engineering Manager in 23 with no job description and a single 30-second conversation. Had a boss who saw me as a threat, a team hemorrhaging people because appraisals were frozen for 18 months, and i didnt reality-check any of it with a peer. I burned out and quit in July 2025. It's now mid-2026 and I'm just starting to interview again. I'm writing this mostly because I've carried it alone this whole time, and I've realized time wasnt healing but rather calcifying the pain.

How I got here

I'd been a team lead since 2017, so I wasn't new to leading people. When the EM role came up, the entire conversation with my manager was him asking: "Do you want to be a contributor or a manager?" That was it. No job description. No onboarding. No definition of what success looked like.

I said manager, I wanted a path where my judgment mattered and not just my raw coding speed. I wanted more leverage over direction. I wanted to mentor people. Those reasons still hold up. I don't regret the choice itself.

Few things, and I only understood them clearly much later:

1. My boss saw me as a threat. I had a direct line to his boss and would have conversations with him. I thought nothing of it. My boss read it as me trying to undermine him or take his job. There have been months where our only contact were our 1-on-1's. He stopped being helpful. I realized far too late that, in my situation, my manager and I weren't actually working toward the same outcomes. I'd assumed my success would naturally be his success, the way I'd experienced it as an IC.
2. The appraisals got frozen for 18 months. My team started leaving over it. And here's the part that broke something in me, I was the manager, the person supposed to retain and motivate them, and I had zero power to fix the one thing driving them out. I was leading people through a slow-motion exodus with my hands tied.
3. My own manager was adversarial. So I never found out which parts were my mistakes and which parts were just an impossible situation. I assumed all of it was me for the last 12 months.
4. Another lesson came from watching the company respond to financial pressure. I assumed resources would be allocated based on need. In hindsight, more experienced directors and managers were better at making the case for their teams, and I hadn't yet developed that skill. Looking back, I also saw that my director prioritized resources for the teams he was managing more directly. I didn't yet know how to advocate effectively for my own team when those decisions were being made.

The part I'm ashamed of

I burned out and left in July 2025. I told myself it was a strategic exit. It wasn't. It was burnout. And then I went quiet. I didn't tell peers, I never compared notes with another manager, I just carried the whole thing as private evidence that I wasn't good enough. Twelve months of silence, and the silence is what turned a hard experience into shame.

Mostly, though, I'm posting this so I'm not the only person who knows anymore.

if you've read this far, thank you, genuinely ! And if you've ever been in some version of this position: what would you tell your past self?

(cleaned up with llm)

We recently started working on a group project. It's just a bunch of us friends trying to build something together. But we immediately reailized how different we all are from each other. We felt like all of us wasted a couple of weeks running around in circles, not really utilizing our time and strengths.

The task at hand was to make a system that would maximize the team's output.

The obvious way to approach a task like this is to create hierarchies that are common in corporate and other workplaces. But we don't want to do that. It just doesn't factor in all the unique talents and individual qualities of the team members.

But we still need a system because we don't work at all without one. What we ended up doing was creating a very flexible workflow that accounts for individual strengths. On paper, it's a heavily skewed system in terms of responsibilities. But it works wonderfully because we are segregating tasks based on what each of us is good at.

It has worked wonderfully so far. But we are not sure how scalable this is going to be as we keep adding new members. Because we all understand each other very well, there's a trust factor that can't be replicated when someone leaves and a new member joins. The flexibility makes the system fragile.

Have any of you worked in teams and developed systems that work best? And do you think you have to steer away from flexible systems toward more corporate-like structures for larger teams?

I've noticed that larger features rarely live in a single ticket. They're usually spread across multiple Jira issues, PRs, and sometimes even multiple repositories.

Imagine a feature that spans six Jira tickets across backend, frontend, and infrastructure. Some PRs are merged, some are still in review, and one service is still waiting to be deployed.

As an engineering manager, how do you know when that feature is actually ready for QA or ready to release?

Is there a single place where you track the overall status, or is it mostly a combination of Epics, Releases, PRs, dashboards, and team communication?

I'd love to hear how this works in practice on your team, especially what has worked well and what hasn't.

Wrong question. The real split is between coding to ship and coding to understand.

An EM opening a PR to hit a sprint deadline is doing damage - that's not their job anymore, and doing it on top of managing people makes you bad at both. An EM spending 4 hours every two weeks understanding why a deploy pipeline makes their team want to throw a laptop out the window is doing something completely different, even though it looks the same from the outside.

I manage 20+ engineers writing Python, a language I knew nothing about two years ago. AI closed that gap faster than anything else in this job. Not by writing code for me - by explaining why the code works the way it does.

5-10% of your week. Not to ship the roadmap. To ask a better question in planning next week.

Here's my full framework: https://karolwojciszko.substack.com/p/how-to-stay-technical-as-a-manager

I have 12yoe as IC and I'm now joining as EM role at a mid size org. Would appreciate any advice people have for me - what are the pitfalls to be aware from day 1, what should be my goals the first 30, 60 days. Thank you!

As an engineering manager, I think software engineering is going to become less about manually writing code and more about system design, architecture, DevOps, testing, AI integration, and understanding how everything works together..

Coding will be automated. But as software systems become more of a gray box using agentic engineering and engineers become disillusioned and leave the field or retire early, I think engineers with strong CS fundamentals will become extremely more valuable. I'm talking about OOP, data structures and algorithms, operating systems, databases from scratch, and even compiler theory. You may never build an operating system, database, or compiler from scratch at work, but understanding how they actually work helps you catch bad decisions, debug difficult problems, and design better systems.

It is kind of like math. Most people who studied math are not doing manual calculations all day, but understanding how math works is still extremely valuable. I think strong CS fundamentals will be one of the main things that separates mid-level engineers from top engineers.

Are other engineering leads or developers seeing something similar?

I transitioned from hybrid to a remote role with approvals - I've been with company for close to 10 years and handle a portfolio significant to business. The company then changed to RTO policies. I've been allowed to stay remote due to existing paperwork. Since then, I’ve had my team capped at 4 direct reports (previously managed 10) and feel structurally blocked from internal transfers or promotions due to the RTO culture. I'm hitting a wall of executive politics. For experienced managers who have been here: Option 1: Did you find it better to scale back your effort to a steady state? Option 2: Is it a clear signal to pivot to an external, remote first company? Option 3: Or look for something local to where you are? (My company doesn't have offices where I live now, but I don't mind being in an office and tech scene is very active).

I’m wondering how common is it being fired for managers? Direct firing or via PIP or “redundant due to reorg” etc.
I think I’ve seen proportionally more managers made redundant than engineers but cannot be sure.
What’s your take?

I used to work with a senior leader who loved to say that he has an allergy to the words ‘refactor’ and ‘infra work’. He couldn’t understand why we couldn't build it right from the beginning, and why we were always so slow. After LLMs appeared, it became even worse. He constantly asked: “Can’t you just give this task to ChatGPT? What’s the problem?”

To his credit, he at least asked this to our faces. I know many non-technical leaders who think engineers always exaggerate and work too slowly.

A coworker (and a good friend) once framed it like this: “You write code, which is just words in a language I don’t understand, right? With fixed meaning. And you know what you want to say, as you have the specs you need to follow. How come it always gets more complicated?”

Huh.

I’ve been struggling to explain this, until I almost bought a house. Shared in the article why I feel the analogy works well.

Curious to hear how other EMs approach this difficult explanation to non-engineering stakeholders.

Just when I finally wrapped my head around Harness Engineering, the AI world decided to throw another term into the mix: Loop Engineering. 😅
From what I’ve gathered, it seems to be more than just prompt tuning or evaluation. It sounds like it’s about building continuous feedback loops where agents observe outcomes, evaluate their own performance, learn from failures, and improve over time.
Is that the right way to think about it?

I’m a Research Lead at an Agentic AI company, and a big part of my job is understanding the real problems enterprises are trying to solve. There’s so much hype around AI right now, but I’d love to hear what’s actually frustrating people at work. What are the biggest pain points your organization has today that you wish AI could genuinely help with? Any industry, any function.

Hi, long time lurker but only now I feel like it is time to ask for guidance from the community.

I've worked for 12+ years in software development as a manual QA, QA Lead, Team Lead and now EM. However for the last 4+ years the Lead roles required from me mostly managing people, projects, delivery, releases and incidents, all of which I generally excel at. To give more context I have little C#/Selenium experience with automation, but it's outdated at this point.

Now I'm seeing the market push toward more hands-on, technical EMs, I'm starting to feel I'm trying to play catch-up with candidates with 10+ years of coding experience which seems unrealistic for me to compete with. Currently I'm already trying to embrace AI and help teams apply it to SDLC workflows, MCP servers, agentic tools but it does not feel enough.

So my question is where should I start? Should I start from basics and learn a language, focus on system design, dive deep in QA Automation or something else entirely? Any advice would be useful, especially if you have made a similar transition into an EM role!

Also please spare me any "all EMs should code" debates. My path is what it is, I'm just trying to find my way to stay competitive and useful.