Backend Engineer: Maintenir L'Héritage Code (Et La Patience)

À Propos

On cherche un Backend Engineer senior pour maintenir et improve notre backend legacy.

On a 4 ans de code. Pas mal de technical debt. Mais ça fonctionne (mostly).

Responsabilités

• Maintain existing backend (fix bugs, improve performance)
• Debug production issues (we get about 2-3 per week)
• Refactor legacy code (slowly, carefully)
• Implement new features (when they fit the architecture)
• Code review (mentor junior engineers)
• Architecture decisions (you have influence)

Profil Recherché

• 5+ ans backend experience
• Strong systems design knowledge
• Experience with legacy code (you won't hate it)
• Patient (you'll need it)
• Pragmatic (sometimes "good enough" is OK)

Ce Qu'On Veut

"We need someone to help us modernize our stack!"

Reality:
- We can't do a full rewrite (takes too long)
- We need to work within the constraints
- You'll spend 70% of time maintaining, 30% improving

La Comp

Salaire: 50k€ (senior, so decent)
Equity: 0.15%
Benefits: Standard startup stuff

Le Jour Typique

• 9h-10h: Check overnight alerts (usually 1-2 issues)
• 10h-12h: Fix a production bug (database is slow)
• 12h-13h: Lunch (eaten at desk, debugging continues)
• 13h-15h: Code review for new features
• 15h-17h: Work on refactoring task (slowly improving)
• 17h-18h: Respond to questions from other engineers

The Technical Reality

Code is:
- Written by 3 different developers over 4 years
- Multiple language generations (Python 2 → 3 migration in progress)
- Architecture that made sense 4 years ago but not now
- Some good patterns, some... very questionable

Your job:
- Understand it
- Make it better incrementally
- Don't break anything

Common Scenarios

Scenario 1: The Mystery Bug
- User reports: "My account doesn't show all my data"
- You investigate for 3 hours
- Find: A race condition in our database update logic
- Fix takes 2 hours
- Deployment takes 1 hour
- Total: 6 hours to fix a 1-hour problem

Scenario 2: The Performance Issue
- Database query is slow
- You optimize indexes
- Shaves off 200ms
- Users: "Still feels slow"
- Problem: It's not the database, it's the frontend
- But the question came in as a backend issue

Scenario 3: The Architectural Decision
- New feature requested
- You realize: Current architecture doesn't support this well
- Options:
- Implement it "wrong" (works but ugly)
- Refactor architecture (takes 3 weeks)
- CEO: "How long for the feature?"
- You: "2 days if we do it wrong, 3 weeks if we do it right"
- CEO: "2 days"

The Trap

You know the right way to do things.

But the business doesn't care.

So you do it the "wrong" way.

Which makes the codebase worse.

Which makes the next developer's job harder.

Which is you.

So you're making your own job harder.

After 18 Months

Best Case:
- You've improved performance 30%
- You've refactored 40% of the codebase
- Architecture is better
- Junior engineers are learning

Realistic Case:
- You've maintained stability
- You've fixed bugs
- You've refactored some parts
- Code is maybe 10% better
- It's slow progress

Worst Case:
- You're just firefighting
- No time to improve
- Code stays the same
- You get frustrated
- You leave

Why It's Hard

Legacy code requires:
- Patience (can't move fast)
- Pragmatism (sometimes "good enough" is the goal)
- Humility (someone wrote this code, maybe they had reasons)

Startups want speed. Not patience.

So there's a mismatch.

The Advice

If you like: Technical challenges, understanding systems, mentoring:
Maybe yes.

If you want: To always write new, clean code:
No.

Backend engineering in established startups is maintenance + improvement.

Not exciting. But necessary.

And honestly? Kind of underrated.