What Makes a Good Engineer Better

Every engineering team has competent developers—people who ship features, own code, and don't create chaos. The jump from competent to exceptional, however, follows a pattern that most organizations fail to recognize during hiring or in career ladders. Microsoft researchers distilled the difference into measurable traits; Gallup, McKinsey, and observational studies from mature tech teams confirm the pattern repeats. This post surfaces the research, explains why the gap matters for hiring and retention, and shows how to spot multipliers during your evaluation process before they surface in retrospectives.

The five traits that separate good from great

Microsoft's research on high-impact engineers identified five distinguishing characteristics:

• Writing good code. Not just syntactically correct—code that other engineers read and modify without friction. Clear variable names, testable logic, appropriate abstractions, and minimal surprise.
• Adjusting behaviors for future value and cost trade-offs. Great engineers resist the siren call of "get it done today." They ship fast but choose implementations that won't calcify or create onboarding debt for the next teammate.
• Making informed decisions. Exceptional engineers do the legwork: they investigate options, read design docs from adjacent teams, check incident histories, and ask why something is the way it is before rewriting it.
• Not making others' jobs harder. Competent engineers build features; great engineers build features while reducing friction for ops, design, product, and other engineering teams. This is where humility and communication compounds.
• Continuous learning. The engineer who learned React in 2018 and coasts on that knowledge will drift as frameworks evolve, business priorities shift, and adjacent skills (security, performance, systems thinking) become load-bearing.

These five overlap. They're reinforced by three psychological traits that unlock them:

• Humility. The belief that your current model is incomplete and others' perspectives matter. Without it, you cherry-pick feedback and stop investigating counter-evidence.
• Curiosity. The willingness to ask "why" and follow the thread. This is where insight lives—not in the obvious layer but in the layers underneath.
• Intellectual honesty. The capacity to hold a strongly believed position while remaining open to evidence that undermines it. This is rare and invaluable.

Technical depth vs. breadth: a false choice

A common misconception is that great engineers must be polymaths or specialists. The truth is more subtle: they understand depth in their core domain and breadth enough to see beyond the fence posts.

Depth without breadth leads to over-specialized thinking—solving a caching problem with a graph database when a cache layer is the right tool. The engineer went deep into tooling without understanding the adjacent landscape.

Breadth without depth creates architecture astronauts—people who hop between patterns without shipping or learning consequences. They talk about microservices and event sourcing but don't own the toil of actually running them.

The multiplier pattern is usually: deep competence in a critical domain (backend systems, frontend state management, infrastructure as code) paired with enough breadth to recognize when a problem isn't actually in that domain. The backend engineer who knows enough about browser caching to realize the real bottleneck isn't server-side. The frontend engineer who understands enough about databases to spot an N+1 query and push back before it ships.

This breadth often comes from reading incident postmortems, shadowing oncall rotations, or rotating through teams every few years. It's not natural; it's habitual.

Product thinking: the engineer who speaks product

In 2025, the dividing line between good and great often comes down to product sense. Great engineers understand:

• Why this feature exists. Not just the specs but the business rationale. Is this a retention lever, a competitive gap, a revenue driver, or a technical debt payoff? Different answers imply different trade-offs.
• What "done" looks like. They resist scope creep by internalizing the success metric. They know whether a 95% or 99.9% solution is being negotiated and why.
• Where the adjacent pain points are. They ask product managers clarifying questions: "What's the user flow before this feature? After? Where do we expect friction?" These questions often unblock months of confusion later.
• How to push back correctly. Great engineers flag technical risks early but don't say "this is impossible." They offer options with trade-off analysis: "We can ship this in 2 weeks with SQL, or 4 weeks with the event store. Here's what each unlocks and breaks." Product teams can then decide with full information.

This skill is often missing in engineers who've worked in product-naive organizations or who treat product as an adversary instead of a partner. For a deeper look at how to assess this during hiring, see how to evaluate product development thinking in engineers. It's one of the fastest things to develop in a high-context organization and one of the slowest in low-context ones.

AI fluency as a multiplier

By 2026, every engineer has access to powerful code generation, debugging, and design assistance. The difference between a good engineer and a great one now includes how they collaborate with AI.

Great engineers know:

• What AI is good at. Boilerplate, tests, documentation, refactoring, brainstorming approaches, explaining code, generating examples. They use it for scaffolding and speed.
• What AI gets wrong. Context-dependent tradeoffs, security implications, performance under load, the business rationale for a constraint, when a pattern is over-engineered for the use case. They don't copy/paste code; they review it with skepticism.
• How to ask good questions. "Write a Postgres query that joins these tables" is fine; "Write an idempotent webhook receiver in Python that handles retries and deduplicates based on this schema" is better. Great engineers frame prompts with constraints and intent.
• When to stop using it. Some problems need human reasoning first: architecture decisions, naming conventions, security design. AI is best as a collaborator once the path is clear, not a replacement for thinking.

Teams with AI-fluent engineers ship faster and with fewer security/performance regressions than teams that either reject AI entirely or blindly trust its output. This is the fastest-moving skill in 2026 and a key differentiator in hiring—understanding how AI is reshaping technical assessments is now essential for both candidates and hiring teams.

System design and architecture thinking

Good engineers ship features. Great engineers think about how systems will behave under stress, change, and growth.

This shows up as:

• Asking the hard questions before coding. "How do we roll this back if it breaks? What's the blast radius? Do we need feature flags? Is this idempotent?" These questions prevent firestorms at 3 AM.
• Understanding failure modes. They don't just design for the happy path. They think about what happens when a dependency is slow, a database is locked, a message queue is full, or a third-party API is down. They build resilience, observability, and graceful degradation into designs.
• Recognizing technical coupling. They see when a feature decision will create debt in adjacent systems. They advocate for decoupling strategies (adapters, event buses, contract-based testing) before integration debt calcifies.
• Balancing multiple forces. Tech debt, UX, revenue, operational burden, and team velocity all exert pressure. Great engineers don't optimize for one in isolation; they surface the trade-offs and let leadership decide which to optimize for. Then they execute that choice clean.

This skill is often paired with experience: you need to have shipped something that broke to understand fragility. It can be developed faster in high-incident organizations where failure is visible and discussed openly.

Soft skills that compound

Communication, collaboration, and patience are often categorized as "soft skills" and under-weighted in hiring. They're actually force multipliers.

Communication clarity means fewer re-implementations, fewer surprises in code review, and fewer misaligned designs. An engineer who can explain a complex architecture in a 15-minute brown bag saves the team from rediscovering the same lessons. This compounds: others learn faster, ask better questions, and make fewer mistakes.

Collaboration across disciplines (design, product, ops, other engineers) creates better solutions and faster feedback loops. A backend engineer who works closely with a frontend engineer won't ship an API that's misaligned with UI constraints. A frontend engineer who understands ops concerns will add observability hooks without being asked. This is where a 10% engineer becomes a 150% engineer in impact.

Listening over broadcasting is rare and valuable. Engineers who ask "why do you think this approach won't work?" instead of assuming others are wrong often uncover blind spots. They win trust faster and get better feedback on their own work.

Mentoring ability is the leverage most overlooked in senior hiring. An engineer who can codify knowledge, unblock juniors, and raise team capability is exponentially more valuable than a solo contributor who hoards context. This compounds across years: one great mentor can create a cohort of better engineers.

Continuous learning habits and intellectual growth

The engineering landscape moves fast. Languages fall out of favor, architectural patterns shift, and new tools constantly emerge. Great engineers stay relevant not through panic-driven "must learn everything" but through disciplined habits:

• Reading code and designs. They regularly review code in unfamiliar domains, read design docs from adjacent teams, and study open-source projects. This is low-friction learning: 15 minutes of reading per day compounds.
• Incident post-mortems as curriculum. They attend retrospectives even when not directly involved. They ask questions, read the full write-up, and extract patterns. This is how you learn what others learned the hard way.
• Rotating through new tools and domains. Every few years, a great engineer will take a project in a new language, stack, or domain. They don't need to become an expert, but they break the local optimum and expand their mental model.
• Staying informed without drowning. They follow a small number of high-signal sources: a technical newsletter, a few key blogs, conference talks in their domain. They skip the noise and absorb patterns.
• Documenting learning in public. Writing a post, giving a talk, or mentoring someone else forces you to clarify half-baked knowledge. The person who writes a guide on debugging distributed systems understands it better than the person who just reads about it.

This habit is often culture-driven. Organizations that carve out time for learning, celebrate sharing, and don't punish experimentation retain and develop great engineers faster.

How to spot these traits during hiring

Most hiring processes are designed to screen out bad engineers, not to identify great ones. To see the traits above, you need to deliberately signal for them:

1) Look for evidence of continuous learning.

• Ask about the last thing they shipped that required learning something new.
• Ask what they've read, studied, or built in the past 6 months that wasn't directly part of their job.
• Strong signal: they can name a specific tool, pattern, or concept they learned and explain why it mattered.

2) Probe for product understanding.

• Ask about a feature they shipped and why it mattered to the business.
• Ask them to push back on a fictional product requirement and explain the tradeoff.
• Strong signal: they think in terms of impact and constraints, not just implementation.

3) Assess collaboration through specifics.

• Ask for a concrete example of a time they worked with design, product, or ops and how that interaction went.
• Ask what they learned from someone on their team who was different from them.
• Strong signal: they credit others, explain what they learned, and show genuine interest in diverse perspectives.

4) Evaluate communication in the interview.

• Ask them to explain something technical to a non-technical person during the interview.
• Ask them to walk you through a complex feature and notice how clearly they explain context, constraints, and tradeoffs.
• Strong signal: they naturally ask clarifying questions and adjust their explanation based on your responses.

5) Assess AI fluency directly.

• Ask them to pair-code using AI. Observe whether they direct it, validate output, or blindly accept suggestions.
• Ask when they'd not use AI and why. The answer reveals whether they understand its boundaries.
• Strong signal: they use it as a tool with agency and skepticism, not as a crutch or as magic.

6) Look for intellectual honesty.

• Ask about a technical decision they regretted or a project that failed.
• Ask what they'd do differently if they could restart it.
• Strong signal: they own the decision, explain the reasoning at the time, and show how they'd think differently with new information.

7) Probe depth and breadth without asking "how many languages do you know?"

• Ask them to design a system in their specialty, then ask how it would change if an adjacent concern changed (e.g., scaling for a backend engineer, accessibility for a frontend engineer).
• Ask them about incidents they've participated in outside their usual domain.
• Strong signal: they can reason across domains and recognize that depth in one area enriches thinking in others.

Red flags that signal a ceiling

Not all competent engineers will grow into great ones. Watch for:

• Blaming external factors for all problems. "The product team is ineffective," "The codebase is garbage," "Ops never provides the right metrics." Great engineers ask "what's my role in this?"
• Resistance to feedback. They defend their approach rather than genuinely considering alternatives. Feedback loops shrink; growth stalls.
• Incurious about adjacent domains. They're not interested in how the system behaves under load, how operations uses metrics, how product thinks about user journeys. This limits their impact.
• Solo contributor mentality past senior level. They're high-performers individually but don't mentore, don't amplify others, and don't scale through leverage.
• Learning only when forced. They skip incident retrospectives, don't read postmortems, and learn new tools only when the job forces them.

These aren't disqualifying, but they're signals that someone has chosen a terminal trajectory or needs explicit intervention to shift.

Building culture that compounds these traits

Organizations that retain and develop great engineers tend to share patterns:

• Psychological safety is default. People can fail, ask dumb questions, and admit mistakes without fear. This unlocks continuous learning and intellectual honesty.
• Context is abundant. Incident postmortems are written well and shared. Product thinking is modeled by leadership. Architecture decisions are documented with rationale. High context → faster learning.
• Rotation and cross-domain work are encouraged. Teams that rotate engineers through different domains, on-call, and mentorship roles develop broader thinking faster.
• Learning time is protected. Whether it's Fridays, quarterly rotations, or conference budgets, signal that investment in knowledge is valued.
• Great engineers are visible. People talk about why they admire certain engineers. The criteria for greatness are clear. This creates aspiration and clarity on what to develop toward.

Early warning signs in performance

Conversely, early signals that someone is stalling or about to churn:

• Code reviews become shorter and less thoughtful. Engagement drops as frustration or burnout sets in.
• They stop asking questions in design meetings. They've either checked out or feel unheard.
• Learning flat-lines. Same tools, same patterns, same comfort zone. No evidence of stretching.
• They complain more, propose less. Energy shifts from "how do we fix this" to "this is broken."
• Mentoring responsibility drops. They stop helping juniors or reviewing others' code thoroughly.

These don't always mean departure, but they're signals to engage in a real conversation about growth, fit, and what they need to stay.

Practical signals to screen for in hiring

Here's a checklist to fold into your next hiring debrief:

• [ ] Demonstrated continuous learning (new skill, domain, or tool in the past year)
• [ ] Specific, product-aware example of impact (business rationale, not just feature list)
• [ ] Evidence of cross-functional collaboration with clear learning outcome
• [ ] Clear communication of a complex concept without jargon
• [ ] Thoughtful use of AI (if tested) or articulate understanding of its tradeoffs
• [ ] Intellectual honesty (acknowledges mistakes, considers alternatives, updates views with evidence)
• [ ] Systems thinking (asks about failure modes, scaling, dependencies)
• [ ] Curiosity shown in how they ask questions during the interview
• [ ] Humility paired with confidence (knows what they don't know, doesn't assume they're right)
• [ ] Mentoring or teaching experience or genuine interest in it

Not every candidate will show all ten. But engineers who show 6+ of these across your interview loop are likely to compound in impact over time. To compare assessment platforms that help you screen for these signals at scale, see how modern tools stack up.

Bottom line

The gap between a competent engineer and an exceptional one isn't raw intelligence or technical depth alone—it's a combination of continuous learning, product thinking, collaboration, and intellectual honesty. Microsoft's five distinguishing traits, paired with humility and curiosity, create engineers who amplify their teams and compound in value. Hiring for these signals instead of puzzle performance and credential collection—because smart engineers don't focus on shiny resumes—will shift your team's trajectory faster than any single technical initiative. The great engineers in most organizations are already doing this; the job is to recognize it during hiring, codify it in career ladders, and build culture that surfaces it rather than burying it.