A software engineer mentor for the work in front of you.
I offer one-to-one mentoring for software engineers working through architecture decisions, technical feedback, and career questions. We start with the work in front of you: a proposal that has stalled, a review you disagree with, or feedback you do not know how to act on.
Principal Engineer, former Staff Engineer and CTO. Online sessions. Updated .
What would we actually discuss?
Suppose your team wants to move notification delivery out of a checkout service. The proposal says: “Use a queue so notifications can scale independently.” That names a mechanism. It leaves the most consequential decisions open.
Illustrative example, not a client case study. The questions below show how we can examine a proposal; the right design depends on your constraints.
1. What is the user waiting for?
Does checkout need confirmation that the order was accepted, or that the notification was delivered? What delay is acceptable? If notifications are already asynchronous, adding a queue may not address the reason checkout is slow.
2. What happens between saving the order and publishing the event?
If the order is saved but event publication fails, can a notification be lost? If publication is retried, can the customer receive two? We would compare ways to recover from that gap, including a transactional outbox where appropriate, and decide where duplicate handling belongs.
3. Who owns a notification that never arrives?
A queue can move the failure into another team’s on-call shift. Who watches delivery delay, investigates failed messages, and decides whether to replay them? Those responsibilities belong in the proposal alongside the components.
4. How do we introduce the change safely?
Choose a limited rollout, define what you will observe, and agree when to stop. If the old and new paths both send notifications, the rollout itself can create duplicates. A rollback plan also needs to account for messages already waiting to be processed.
The revised proposal might say: “Checkout completes when the order is accepted. Notification delivery runs asynchronously. Before rollout, we need an agreed delivery-delay target, a way to recover from publication failures, duplicate handling, and an owner for replaying failed messages.”
That is still an unfinished design. But now the team can review concrete decisions and missing requirements. You have a useful next step even if the final answer is to keep the existing service.
Read how I think about service boundaries and coordinationHow to prepare for a session
Choose one question that matters now. A rough draft is useful because we can see the reasoning while there is still time to change it.
- Give the context: what the system or team does and what needs to change.
- State the decision, constraints, and deadline.
- Show the options you considered, including leaving things as they are.
- Include the review comment or disagreement you are struggling with.
Use a simplified example if the original work is confidential. Do not share employer material without permission.
What you take back to work
We finish by separating decisions you can make now from questions that need evidence or another person’s input. The output might be a rewritten requirement, a smaller set of options, or a question for the team that will operate the system.
Try that next step at work. If we meet again, bring what happened: a reviewer’s objection, a measurement, or a new constraint. I can help you examine the decision, but your team owns its design review and production approval.
More on preparing a design document for reviewCareer feedback deserves the same care.
“You need to be more strategic” is hard to act on. We can look at the feedback alongside your recent work: which decisions did you own, who used the result, and what did your manager expect you to do differently? Then you can ask for the missing specifics.
Rewriting a project summary may make your contribution clearer. It cannot create experience you have not had. If the gap is broader responsibility, the next step is to find an opportunity with your manager and agree how it will be evaluated.
For that work, see Staff Engineer mentoring and the Staff promotion planning guide. For a broader role decision, start with career coaching.
Decide whether my approach fits yours.
I’m Aleksandr Perederei. My engineering background includes Delivery Hero, Tesla, and CTO and Engineering Manager roles. My background page gives the details. You can also read my webinar-based article on Go architecture and delivery to see how I reason about a design that became too complicated.
Look for a mentor whose questions help you see your own problem more clearly. A senior title alone does not tell you whether someone understands the kind of work you need help with. Use this mentor evaluation checklist when comparing options.
Practical questions
What does a software engineer mentor do in a session?
We review one problem and the reasoning behind it. For a design document, that means checking the requirements, alternatives, ownership, failure modes, and rollout. For career feedback, it means comparing your recent work with the expectations you have been given. We finish by identifying what you can change or investigate next.
Can I bring code or documents from work?
Only if you have permission to share them. Remove credentials, customer information, internal links, and confidential business details. A simplified diagram, pseudocode, or a short description of the decision is often enough. Follow your employer’s confidentiality rules.
Is this useful if I am already a Senior Engineer?
Yes, if you have a specific decision or responsibility you want to work through. Senior engineers can bring architecture reviews, cross-team disagreements, delegation questions, or promotion feedback. The conversation starts with the work you are doing and the part that is difficult.
What if I have no design document to bring?
Describe a recent situation, what you tried, and where you got stuck. For career questions, a project summary and the feedback you received can be enough. You do not need to create a polished document just to have a first conversation.
Is mentoring the same as a mock system design interview?
No. A mock interview rehearses explaining a design under interview constraints. Mentoring can follow a real decision through review, implementation, and feedback at work. If an interview is your immediate goal, start with system design interview coaching.
Preparing for interviews? See system design interview coaching. For other goals, compare the engineering mentoring starting points or browse the resource library.
You do not need a polished proposal to start.
Bring the question, the options you have considered, and the part you are unsure about.