/faq

Tell me about yourself

I'm a senior full-stack engineer who learns and remembers through problems, not textbooks.

I don't retain theory by reading it once — I retain systems by breaking them, fixing them, and living with the consequences in production. Once I've debugged something real, I remember it permanently.

Most of my work is taking messy, manual, or fragile systems and turning them into something reliable, automated, and boring to operate. I work end-to-end, take ownership, and optimise for outcomes over how elegant something looks on paper.

How do you actually learn and retain things?

Through real problems.

I don't memorise frameworks or patterns out of context. I learn by:

• Debugging failures
• Tracing state through a system
• Fixing production issues
• Seeing what breaks under load or change

Once I've solved a real problem, I remember:

• what went wrong
• why it failed
• how it should have been designed

That kind of memory sticks far better than abstract reading ever has.

What are you best at?

• Debugging complex, messy systems
• Seeing where state, data, or assumptions go wrong
• Fixing problems others have normalised
• Designing systems that survive real usage
• Reducing manual work through automation
• Making CMS and backend systems sane to work with

I'm especially strong when things aren't clean, documented, or well understood.

How do you approach problem-solving?

I build a mental model of the system as it actually behaves:

• Inputs
• Constraints
• State
• How state changes
• Where things can fail

Once that model is clear, solutions tend to become obvious.
I don't need perfect documentation — I need enough signal to trace reality.

What's your core tech stack?

I'm not attached to tools. I'm attached to systems that work.

How do you use AI in production?

Carefully and intentionally.

I use AI where it:

• Removes manual work
• Helps with classification, retrieval, or summarisation
• Supports humans instead of replacing judgment

That usually means:

• RAG instead of free-form generation
• Clear boundaries and fallbacks
• Observable behaviour
• Costs and failure modes that are understood

If I can't explain what it's doing, it doesn't ship.

Do you build AI agents?

Sometimes — but only when they're constrained.

Most real systems work better with:

• Deterministic flows
• Explicit state
• AI used in narrow, well-defined steps

When I do build agent-like behaviour, it's:

• Interruptible
• Observable
• Scoped to a real task
• Designed to fail safely

How do you approach backend architecture?

I favour:

• Simple, boring designs
• Clear ownership
• Predictable failure modes

I don't chase novelty. I chase systems that:

• Are easy to debug
• Are hard to accidentally break
• Can be understood by the next person

If a system needs a diagram just to explain why it works, it's probably too complex.

Monoliths or microservices?

Monoliths by default.

I've seen too many teams add complexity before they have a real scaling problem. A well-structured monolith is usually faster to ship, easier to debug, and cheaper to run.

I reach for microservices only when reality forces the decision.

How do you test your work?

I test the parts that are expensive to get wrong.

That usually means:

• Core logic
• System boundaries
• Anything that's painful to debug in production

I care more about confidence than coverage percentages.

How do you handle legacy systems?

With respect.

Legacy systems usually exist because they once solved a real problem. I try to understand why before changing anything.

I prefer:

• Isolating risk
• Improving things incrementally
• Leaving systems better than I found them

How do you work day-to-day?

I work in tight feedback loops:

• Understand the real problem
• Observe how the system actually behaves
• Make the smallest change that meaningfully improves it
• Ship
• Learn from reality

I optimise for momentum and clarity, not perfection.

What does success look like in your first 30 days?

• I understand the system well enough to debug it confidently
• I've shipped at least one meaningful improvement
• I've identified risks others have learned to live with
• I'm trusted to work independently

What roles are you looking for?

• Backend-heavy or full-stack roles
• Teams shipping real products
• Environments where engineers own outcomes
• Permanent roles or long-term contracts
• Remote-first preferred

What kind of work do you avoid?

• Roles with no ownership
• AI work that exists only for demos or pitches
• Over-engineered systems without users
• Teams where production is rare or political

What motivates you?

• Solving real problems
• Debugging hard things
• Removing unnecessary complexity
• Shipping systems people rely on

I get energy from making things work properly.

Why should someone hire you?

Because I:

• Stay calm in messy systems
• Debug effectively when things go wrong
• Take ownership instead of deflecting
• Ship improvements, not just ideas
• Don't need hand-holding

I'm not the loudest engineer in the room — I'm the one you want when things break.

What's your availability?

Open to the right permanent role or long-term contract.
Not interested in short, low-ownership engagements.

What's your rate or salary range?

Shared privately once there's alignment on expectations and scope.
If price is the first conversation, we're probably not a fit.

Final note

If you value engineers who learn through reality, debug deeply, and ship systems that survive contact with users, we'll work well together.

How do I contact you?

Email: jake@nought.digital