Hi, I’m Eugenie Ma 👋

I’m a technical recruiter and people leader with deep experience helping engineering teams grow thoughtfully. I’ve supported hiring across frontend, backend, mobile, machine learning, and core technical teams, partnering closely with leaders to build inclusive, high-performing organizations.

My work is rooted in a people-first, data-informed approach to recruiting. I care about creating thoughtful hiring processes, strong candidate experiences, and talent strategies that help companies meet ambitious goals while treating people with clarity, empathy, and respect.

At my core, I’m a connector and a builder. I love helping people find opportunities where they can do meaningful work, and helping teams bring in the talent they need to grow with intention.

If you’ve been in the same engineering role for a few years, interviewing can feel strange at first.

At work, you solve problems with context.

You know the codebase. You know the team. You know which systems are fragile, which constraints are real, and which decisions were made three quarters ago for reasons no one wrote down.

In an interview, none of that context comes with you.

You have to explain your work to someone who wasn’t there. You have to make your impact clear without overexplaining. You have to talk through technical decisions out loud. You have to turn years of day-to-day work into a story another person can evaluate in 30 or 45 minutes.

That takes practice.

Strong engineers can get rusty at interviewing. That doesn’t mean they’re less capable. It means interviewing asks for a different version of the skill: not just doing the work, but making the work legible.

Interviewing is a skill you can lose

Most engineers don’t spend their workdays explaining their career narrative.

They’re not regularly answering “Tell me about yourself,” summarizing complex projects in two minutes, or talking through a technical decision for someone who has no background on the system.

So if you haven’t interviewed in a while, it makes sense that the first few reps feel awkward.

You may know your work deeply and still struggle to explain it cleanly. You may have strong experience and still ramble. You may have real impact and still undersell it because, inside your company, that impact now feels obvious.

That gap is normal.

The mistake is assuming strong work automatically turns into strong interview answers. It usually doesn’t. You need to rebuild the language around your experience.

Start with why you’re looking

Before you practice coding problems or schedule a string of mock interviews, get clear on your motivation.

A lot of candidates start with: “I need a new job.”

That may be true. Maybe you’re underpaid. Maybe you’re burned out. Maybe your company feels unstable. Maybe you’ve grown past the role.

But interviewers are going to ask a more specific version of the question: Why this move? Why now? Why this kind of company? Why this role?

You need an answer that goes deeper than frustration.

Start with a few questions:

• What have you been doing in your current role?
• What kind of work have you grown into?
• What are you strongest at now?
• What do you want more of in your next role?
• What are you trying to move toward?

This becomes the foundation for recruiter screens, hiring manager conversations, behavioral interviews, and “Tell me about yourself.”

A good answer doesn’t need to cover your whole career. It needs to create a clear through-line: where you’ve been, what you’ve built, and why this next move makes sense.

Turn familiar work into interview stories

When you’ve been in one role for a long time, your work can start to feel too familiar.

Projects that were difficult at the time may now seem obvious. Decisions you made may feel too small to mention. Impact may be buried inside roadmap changes, team goals, migrations, incidents, launches, or operational improvements.

That’s why you need to inventory your work.

Look back at the last few years and pull stories in a few categories:

• A technically difficult project
• A project with measurable impact
• A time you improved reliability, performance, cost, or developer experience
• A time you worked across teams
• A disagreement or conflict
• A mistake or failure
• A decision where you made a trade-off
• A project that shows leadership or ownership

For each story, write down the basic arc.

What was happening? What made it hard? What did you do? What changed because of it?

That’s the raw material for interviews.

The goal is not to memorize a perfect script. The goal is to know your own stories well enough that you can tell them clearly when the question comes.

Practice saying the story out loud

Interview answers are not essays.

They need to work in conversation.

A useful way to think about behavioral answers is this: you’re telling someone a story. It needs a beginning, a middle, and an end.

The beginning sets the context. What was going on? Why did it matter?

The middle explains what you did. What problem did you solve? What decision did you make? What obstacle did you work through?

The end makes the impact clear. What changed? What did you learn? What would you do differently?

This sounds simple, but it’s where a lot of candidates get stuck.

Some give too much background. Some skip the setup. Some talk about what the team did but not what they personally owned. Some explain the technical work but forget to say why it mattered.

That’s why you have to practice out loud.

How an answer sounds in your head is not how it sounds when you say it to another person. Practice with a friend, a peer, a mentor, a mirror, or a mock interviewer.

You’re listening for the places where the story gets muddy.

Rebuild the skill of thinking out loud

At work, you may solve problems in your own workflow. You can read docs, search the codebase, test locally, ask a teammate, or think quietly until the answer comes together.

In an interview, the process is visible.

You need to explain what you’re doing as you do it:

• What approach are you considering first?
• What assumptions are you making?
• What edge cases do you see?
• Why are you choosing this data structure?
• What trade-off are you making?
• How would you test this?
• What would you optimize next?

This can feel unnatural if you haven’t interviewed in years. But the interviewer can’t evaluate reasoning they can’t hear.

That doesn’t mean narrating every tiny thought. It means making your process followable.

You’re showing that you can do the work and communicate through the work. Both matter, because engineering is a team sport.

Refresh the skills your target roles actually test

Not every engineering interview tests the same things.

Before you build a prep plan, look at the roles and companies you’re targeting.

A backend role at a large tech company may require deeper data structures and algorithms prep. A full-stack role at a startup may put more weight on product sense and practical execution. A senior role may emphasize system design, cross-functional work, and technical leadership.

Ask yourself:

• Do I need to brush up on data structures and algorithms?
• Do I need more system design practice?
• Do I need stronger project stories?
• Do I need to explain impact more clearly?
• Do I need to prepare for behavioral questions?
• Do I need to understand a new domain or tech stack?

That distinction matters when you’re working full time. Your prep time is limited, so it has to be focused.

Use mock interviews as a feedback loop

Mock interviews are useful, but only if you revise between reps.

If you give the same unclear answer five times, more practice won’t fix the problem. It will just make the unclear answer more familiar.

After each mock interview, write down what happened.

• Where did you get stuck?
• Did you explain your reasoning clearly?
• Did you give enough context?
• Did you talk too long?
• Did you make your impact obvious?
• What feedback did you hear more than once?

Then change something before the next rep.

Use AI without losing your voice

AI can help you rebuild interview skills faster.

It can turn rough notes into STAR stories, generate common behavioral questions, suggest follow-up questions, and help you find gaps in your answers.

That’s useful.

But AI should not replace your voice.

If an answer sounds too polished, too generic, or too far from how you actually speak, revise it. Add back the details. Use the words you’d use in a real conversation. Make sure the story is true to your experience.

Interviewers can usually tell when an answer sounds flattened by AI.

A clean answer is not always a strong answer. A strong answer has substance, specificity, and a person behind it.

The goal is to make your work legible

After years in one role, you may have more experience than you realize.

The challenge is making that experience easy for an interviewer to understand.

That means turning day-to-day work into clear stories. It means practicing technical communication. It means explaining your decisions, your impact, and your growth in a way someone outside your company can follow.

You’re not starting from scratch. You’re translating what you already know into the format interviews require.

Practice with feedback from Formation

It’s hard to know on your own whether your answers are clear, specific, and calibrated to the role you want.

That’s where feedback helps.

Formation helps engineers rebuild interview skills through targeted practice, mock interviews, and feedback from experienced interviewers. The goal is to help you explain your real experience clearly, sharpen the places where you’re rusty, and walk into interviews with a stronger sense of what you bring.

If you’ve been in one role for years, you don’t need to become a different candidate.

You need to get good at showing the work you’ve already done.