Tejas Kumar:
Aurora Scharff:
Lee Robinson:
Rejection is an inevitable part of the job interview process, but it doesn't have to be the end of your journey. Take each rejection as a learning opportunity and come out stronger than before.
Your job isn't to turn user stories into code. The company has a mission. Everyone at the company is hired to push that mission forward. You're not a software engineer hired to code. You're a human hired to push their mission forward. It just so happens that you are a human with coding skills and during the hiring process, they recognized that those coding skills could help them in their mission.
You may not have enough information to perform the analysis. You may need to ask the product manager questions about the features and how they tie into the mission of the company. Go into the conversation with an open mind and a desire to understand. The company hired the product manager to help prioritize work in the optimal way to push the mission forward. You should trust them to do their job well and recognize that they may have context that you're missing. So long as you effectively expressed all the information you can about the long-term benefit-to-effort ratio of your ideas then you've done all you can there.
If you join a company or team and deal with constant nonsense and a broken culture? Switch. Immediately. Do not delay. And if the new team is nonsense again? Switch again. Don't let these people waste your time or tax your peace.
You will do your best work when you are supported and included. You will make up more career time working 6 months at the right place, than in the previous 6 years of daily hell.
An inclusive team will not judge you for switching multiple times finding the right fit. And hiring managers, have more confidence in your ability to create an environment that people want to stay at. The past at other teams and other situations doesn’t predict the future at your team and this situation. I have seen so many “jumpy” people find their “home” after so many jumps. Sometimes it’s the first decent manager they have, sometimes the first company they can grow with and so on...
Don't ask people why they left their last position. They often can't tell you, and it's not relevant. Instead, ask what they are looking for in their next role. You can even ask how long they intend to stay, or what would entice them to spend N years on the same team or role.
The divide between frontend and backend engineers is increasingly less useful:
Product Engineers consider the frontend, backend, design, and everything in between to create a great user experience. They don't need to understand every part deeply, a common misconception of "fullstack". Instead, they have a broad understanding of the available tools and deep experience applying those tools to build products. At Vercel, we updated our job descriptions to change references from Fullstack to Product Engineers.
While Product Engineers focus on building and enhancing features that solve end user problems, Platform Engineers focus on the infrastructure that supports the product.
Bad engineers measure their worth by the complexity of their solutions. They build elaborate architectures for simple problems, write clever code that requires a PhD to understand, and mistake motion for progress. Good engineers reach for simple solutions first, write code their junior colleagues can maintain, and have the confidence to choose “boring” technology that just works.
Bad engineers treat code reviews as battles to be won. They defend every line like it’s their firstborn child, taking feedback as personal attacks. Good engineers see code reviews differently — they’re opportunities to teach and learn, not contests. They’ll often review their own PR first, leaving comments like “This feels hacky, any better ideas?”
Bad engineers guard knowledge like treasure, making themselves indispensable through obscurity. Good engineers document as they go, pair with juniors, and celebrate when someone else can maintain their code. They know job security comes from impact, not from being a single point of failure.
Bad engineers chase the newest framework, the hottest language, the latest trend. They’ve rewritten the same app four times in four different frameworks. Good engineers are pragmatists. They’ll choose the tech that the team knows, the solution that can be hired for, the approach that lets them focus on the actual problem.
Bad engineers write code. Good engineers solve problems. Bad engineers focus on themselves. Good engineers focus on their team. Bad engineers optimize for looking smart. Good engineers optimize for being useful.
Early in my career, I believed great work would speak for itself. I was wrong. Code sits silently in a repository. Your manager mentions you in a meeting, or they don’t. A peer recommends you for a project, or someone else.
In large organizations, decisions get made in meetings you’re not invited to, using summaries you didn’t write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you’re not in the room, your impact is effectively optional.
This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone- including yourself.
Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. But if you do it unconsciously, it can stall your technical trajectory and burn you out. The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact.
Timebox it. Rotate it. Turn it into artifacts: docs, templates, automation. And make it legible as impact, not as personality trait.
Priceless and invisible is a dangerous combination for your career.
It rewards what’s sensationalized: things that go viral, things that make people mad, things that scare people. So naturally those are the voices that get pushed and sound the loudest.
These are the 3 culprits I see every day: