2025-12-18
Hiring for a Greenfield Project vs Maintaining Legacy Code
Hiring for a Greenfield Project vs Maintaining Legacy Code
The hiring landscape shifts dramatically depending on whether you're building something from scratch or keeping a 15-year-old system alive. Yet most technical recruiters approach both scenarios with the same playbook—and that's a costly mistake.
A greenfield project demands architects and innovators. A legacy system needs detectives and pragmatists. The skills gap is real, the incentives are different, and the talent pool you're drawing from operates on different assumptions about what a "good engineer" looks like.
This guide breaks down the hiring playbook for both scenarios, with specific strategies, interview approaches, and compensation frameworks that actually work.
Understanding the Two Hiring Contexts
What is a Greenfield Project?
A greenfield project is exactly what it sounds like: you're starting from nothing. No existing codebase, no technical debt, no deprecated frameworks. You're making architectural decisions, choosing tech stacks, defining standards from day one.
Common greenfield scenarios include: - A new product launch - A complete system rewrite (technically not greenfield, but often treated as one) - Expanding into a new market with a new platform - Microservices migration where you're building new services from scratch
The opportunity: Engineers get to shape technical culture. There's less constrained decision-making. You can adopt the latest frameworks, use modern CI/CD pipelines, and avoid technical debt.
The pressure: Every decision scales. You're setting precedents. There's no "how we've always done it" safety net.
What is Legacy Code Maintenance?
Legacy code is production code that nobody wrote yesterday. It's systems that have been running, making money, handling critical workflows for years. It might be written in COBOL, it might be Node.js from 2010, it might be a Python monolith that's seen 20+ engineers come and go.
Common legacy maintenance scenarios include: - Banking systems, insurance platforms, telecom infrastructure - Content management systems with millions of users - ERP systems that run entire organizations - Inherited codebases from acquisitions
The reality: Legacy code usually works. That's why it's still running. But it's also fragile, undocumented, and filled with business logic that lives nowhere except the minds of three people who've been here for eight years.
The hidden complexity: A "simple bug fix" in legacy code can unravel three systems because nobody fully understands the coupling anymore.
The Hiring Profiles You Actually Need
For Greenfield Projects: What to Look For
Technical judgment beats raw horsepower
In greenfield work, there's no existing system to learn from. An engineer's judgment about which tradeoffs to make early shapes the entire trajectory. A poor architectural decision made in month one of a greenfield project can cost 6 months of refactoring in year two.
Look for candidates who:
- Have shipped multiple complete systems. They've lived with their decisions. They understand that "microservices" sounds great but adds operational complexity. They've felt the pain of over-engineering.
- Can articulate why they chose specific technologies. Not "React is popular" but "React's component model aligns with our mental model of the UI, and the ecosystem has solved the routing and state management problems we care about."
- Have experience in similar problem domains. A candidate who's built three real-time collaboration tools understands scaling challenges that someone building their first web app won't anticipate.
- Think about operations from day one. Greenfield engineers need to care about logging, monitoring, deployment pipelines, and incident response. Not as an afterthought, but as part of the design.
The experience threshold: For greenfield projects, you're generally looking at mid-level to senior engineers (5+ years). Junior engineers can contribute, but your technical leads should have shipped complete systems before.
What to weight less heavily: Specific framework expertise. An engineer who knows React deeply might take 2 weeks to become productive with Vue if they understand component architecture. Don't hire for framework knowledge; hire for architectural thinking.
For Legacy Code: What to Look For
Debugging skill beats algorithm knowledge
Legacy systems are mysteries. The documentation is either non-existent or describes a system that no longer exists. Tests are sparse or brittle. When something breaks, there's no clean error signal pointing to the problem.
Look for candidates who:
- Have thrived in ambiguous, undocumented systems. Ask directly: "Tell me about a time you had to understand a large system with minimal documentation. How did you approach it?" Their answer tells you everything.
- Understand the business logic, not just the code. In legacy systems, a "proper" software engineering solution might violate 15 years of business rules nobody documented. Engineers who ask "why is it this way?" before refactoring are invaluable.
- Can work incrementally and safely. Big rewrites fail. They need to be comfortable making small, testable improvements. They understand the risk of touching something that works.
- Have debugged without stack traces. In some legacy systems (mainframe code, older Python, etc.), you're debugging with logging and reasoning. Modern developers expect perfect error messages.
- Respect constraints. "That framework doesn't support version X of the language" or "We can't deploy more than once a month" isn't a challenge to overcome; it's reality. Good legacy engineers work within constraints.
The experience threshold: Legacy work needs pragmatic engineers with 4+ years of experience. Senior engineers are valuable (they've seen more patterns), but a smart mid-level engineer often outperforms a brilliant but impatient senior who wants to rewrite everything.
What to weight less heavily: Trendy tech stack knowledge. A candidate who knows Kubernetes, Docker, and GraphQL might be frustrated and unproductive in a system running on Apache and connecting to Oracle via ODBC.
The Skill Comparison Table
| Skill | Greenfield Weight | Legacy Weight | Why |
|---|---|---|---|
| Architectural thinking | ⭐⭐⭐⭐⭐ | ⭐⭐ | Greenfield: you're setting it. Legacy: the architecture already exists. |
| Debugging under uncertainty | ⭐⭐ | ⭐⭐⭐⭐⭐ | Greenfield: clear error signals. Legacy: minimal visibility. |
| Shipping complete systems | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | Greenfield: need people who've shipped end-to-end. Legacy: learned experience transfers, but differently. |
| Knowledge of latest frameworks | ⭐⭐ | ⭐ | Greenfield: moderate help if you're using them. Legacy: usually irrelevant. |
| Business domain expertise | ⭐⭐ | ⭐⭐⭐⭐ | Greenfield: you learn the domain; code can be "pure." Legacy: business logic is everywhere. |
| Patience with constraints | ⭐⭐ | ⭐⭐⭐⭐⭐ | Greenfield: you can often avoid constraints. Legacy: constraints are real and non-negotiable. |
| Willingness to refactor aggressively | ⭐⭐⭐⭐ | ⭐⭐ | Greenfield: fresh code should be clean. Legacy: refactors carry risk. |
Interview Questions That Reveal Fit
For Greenfield Roles
Ask these questions and listen for specific examples, not general philosophies:
- "Tell me about a system you built from scratch. What would you do differently if you built it again?"
- Good answer: Specific technical decisions with tradeoffs explained. "I chose a monolith initially because it was simpler, but by year two we had a clearer picture of what should be separate services."
-
Bad answer: "I would've used [trendier framework]" or vague answers about "better design."
-
"Walk me through how you'd choose a database for this new project."
-
You're not looking for "PostgreSQL is best." You want to hear: operational concerns (backups, replication, monitoring), query patterns, scaling assumptions, team expertise, and willingness to re-evaluate later.
-
"How do you prevent technical debt in a new system?"
-
Strong candidates understand that zero technical debt is impossible and expensive. They talk about deliberate choices, code review discipline, and monitoring accumulation of shortcuts.
-
"Describe your experience with system design tradeoffs. What's an example where you chose worse performance for better maintainability?"
- This filters for engineers who think in tradeoffs, not absolutes.
For Legacy Code Roles
- "Tell me about the most confusing codebase you've worked in. How did you untangle it?"
- You want to see systematic approaches: reading tests first, mapping dependencies, talking to senior engineers, finding the "seams" in the code.
-
Red flag: "It was badly written, so I rewrote it."
-
"You find a bug that's been there for three years but nobody noticed. How do you decide whether to fix it?"
-
This tests business thinking. Good answer: "I'd understand why it wasn't noticed. If it's not affecting users, the risk of fixing it might outweigh the benefit. I'd ask stakeholders."
-
"Describe a time you refactored legacy code. What was your process, and what happened?"
-
You're listening for incrementalism, testing, collaboration with domain experts. Red flags: "I rewrote the whole module" or "I refactored without tests."
-
"How do you onboard to a system with minimal documentation?"
-
Candidates who talk about reading code, asking questions, running it locally, and building mental models are gold. Those who expect perfect documentation are going to struggle.
-
"What's your experience with languages/platforms older than 10 years?"
- Not a dealbreaker if they say none, but valuable if they have it and can articulate what's different.
Compensation and Benefits Strategy
Greenfield Project Compensation
Greenfield projects attract candidates for career growth and impact potential. They'll often accept slightly lower compensation if the project is genuinely interesting and they'll have architectural influence.
Salary positioning: Market rate to market rate + 5-10%. You don't need a premium if the project is compelling.
Equity matters: In startups, greenfield projects are equity plays. Equity should reflect real upside potential, not just a line item. Candidates for greenfield work are placing a bet on the company.
Bonus structure: Tied to shipping milestones and product launch. Greenfield engineers respond well to goal-oriented incentives.
Benefits that matter: - Flexibility to choose tools and technologies (within reason) - Conference attendance budget - Autonomy and decision-making authority - Clear growth path to principal engineer or tech lead roles
Legacy Code Compensation
Legacy maintenance work is the unsexy reality of most software. Compensation needs to acknowledge this.
Salary positioning: Market rate + 10-20%. You're asking engineers to work on systems that aren't prestigious, with constraints that feel like handcuffs, and with less obvious career growth. Pay reflects this.
Stability and security: Legacy systems aren't going away. Emphasize the job security and stable team (no constant reorganizations).
Bonus structure: Tied to stability, reliability, and incident prevention. Fewer bugs, fewer outages, faster MTTR.
Benefits that matter: - Professional development budget (even if it's for older tech, engineers want to learn) - Clear career path (you don't have to become a manager; principal engineers are valued) - Reasonable on-call practices (if it's a 24/7 system) - Respect for domain expertise (legacy engineers know their system better than anyone; they should have decision-making authority)
The reality: Legacy systems often have better work-life balance than greenfield projects. Use this as a recruiting advantage. "You'll work on a mature system with stable requirements, predictable hours, and real business impact" is an honest pitch.
Red Flags and Dealbreakers
Red Flags for Greenfield Candidates
- "Tell me about your last system." They describe a system that someone else built or that they only worked on for 6 months. Worry if they've never shipped something complete.
- They speak dismissively about frameworks or languages they haven't used. "Vue is for people who don't know React" suggests weak judgment.
- They can't articulate tradeoffs. "We used microservices because that's what the cool companies use" suggests they're chasing trends.
- They've never dealt with ops/deployment. A full-stack engineer for greenfield should understand the deployment pipeline.
Red Flags for Legacy Candidates
- "That code is garbage." Some criticism is fine, but engineers who start by criticizing the system (rather than understanding it) struggle with legacy work.
- They've never spent more than 1-2 years at a company. You need people who can live with long-term consequences of their changes.
- They immediately propose rewrites. "The right solution is to rewrite this in Rust" suggests they don't understand incremental improvement.
- They're unfamiliar with debugging in constrained environments. Some legacy systems don't have good logging; candidates need to be comfortable with this reality.
Building Your Team: Composition Matters
For Greenfield Projects
You typically need: - 1-2 architects (senior, shipping experience) - 3-5 builders (mid to senior, can ship complete features) - 1 ops engineer (deployment, monitoring, infrastructure)
Critical ratio: At least 30% of your team should have shipped complete systems before. Greenfield projects fail when staffed entirely with junior engineers, no matter how smart they are.
For Legacy Maintenance
You typically need: - 1 tech lead (someone who knows the system deeply or can learn it quickly) - 3-5 maintenance engineers (mixed seniority; mid-level is ideal) - 0-1 architect (only if you're planning incremental modernization)
Critical ratio: At least 50% of your team should have worked in legacy systems before. One engineer who's debugged production issues in a 20-year-old system is worth three who've only built greenfield projects.
Using Zumo to Find the Right Fit
Different hiring contexts require different sourcing approaches. GitHub activity patterns reveal whether an engineer thrives in greenfield or legacy environments.
For greenfield projects, look for engineers with: - Diverse repository contributions across multiple languages and frameworks - Regular commits indicating systems built from initial commit through maturity - Active participation in architecture discussions (evident from code review comments, architecture decision records) - Evidence of systems shipped to production
For legacy code maintenance, look for engineers with: - Deep commit history in single or few repositories (indicating long-term system knowledge) - Code review activity focused on incremental improvements - Contributions to test coverage and refactoring - Evidence of long tenure (multiple years in same codebase)
Zumo analyzes this activity data to surface candidates whose GitHub patterns match your project type, saving weeks of screening time.
FAQ
Q: Can an engineer move from greenfield work to legacy maintenance (or vice versa)?
A: Yes, but it requires deliberate onboarding. An engineer who's always built greenfield systems might struggle initially with legacy code's constraints, ambiguity, and risk-aversion. Conversely, legacy engineers can feel frustrated by greenfield work's ambiguity. Give them 4-6 weeks of adjustment time, explicit mentoring, and patience.
Q: Should I hire for the project or for the future?
A: Hire for the project, but consider growth. A greenfield engineer might become a great legacy maintainer once you launch. A legacy expert might become a great architect once your system matures. Hire for immediate fit, but position the role as part of a longer career arc.
Q: How do I attract top talent to legacy maintenance roles?
A: Be honest about what legacy work entails, but reframe it: "You'll stabilize a system that powers [specific business value], work in a stable team without constant reorganization, and develop deep domain expertise." Position it as mastery, not settling. And pay appropriately for the reality.
Q: What if my greenfield project inherits legacy code (from acquisition or migration)?
A: You now need a hybrid team: greenfield architects to design the new system, and legacy experts to understand what's worth preserving from the old one. This is harder than pure greenfield or pure legacy. Expect friction and budget accordingly.
Q: How important is domain experience for greenfield vs legacy roles?
A: For greenfield: not required, but helpful in later stages (product definition). For legacy: critical. An engineer unfamiliar with fintech or healthcare shouldn't start by refactoring a core banking system. Domain knowledge is a substantial advantage.
Next Steps: Optimize Your Sourcing Strategy
Hiring for greenfield versus legacy code requires fundamentally different approaches. The skills that make someone excellent at building new systems make them frustrated with legacy constraints—and vice versa.
The difference between a mediocre hire and a great one isn't just experience; it's alignment between the engineer's strengths and what your project actually demands.