FDE, technical consultant or product engineer: choose by temperament

Three roles, one axis each

Job titles blur, so this article uses a simplified model. Real roles mix these.

• Forward deployed engineer: builds and adapts working software inside or alongside a specific client's environment. Success is "it runs in their world and people use it". See what a forward deployed engineer is for more.
• Technical consultant: diagnoses a client's problem and recommends or designs a solution, often delivered by others. Success is "the client made a better decision".
• Product engineer: builds and maintains a product used by many customers, usually shielded from any single one. Success is "the system is reliable and improves over time".

The main axis of difference is distance from a single customer and how long you live with your own code.

The self-assessment

Score each statement from 1 (not me) to 5 (very me). Be honest about how you actually behave, not how you would like to.

Scoring

Add up your scores in three groups:

Group C has three statements, so multiply its total by 4 and divide by 3 before comparing (a C total of 12 becomes 16). Statement 5 is not in any group; a high score on it favours FDE or consulting over product work, a low one the reverse.

The scoring is a conversation starter, not a verdict. A tie between A and B is common and simply means you should look at how hands-on each specific role is.

Reading your result

High A: close to the user, still building

You like consequences you can see. The strain in FDE work is ambiguity and interruption: a client environment you do not control, a deadline tied to their calendar, and a mix of building and talking. If statement 9 scored high too, notice the tension — FDE work has fewer quiet blocks than product work. Ask employers how their FDEs protect building time.

High B: shaping decisions

You enjoy the persuasion and structure of the work. The risk is drifting away from hands-on skill; technical consultants who stop building can lose credibility with engineers over time. Look for roles where you still prototype, or keep a side habit of building.

High C: depth and ownership

You want to live with a system long enough to make it excellent. FDE work can frustrate this because you often hand over and move on. Product roles let you own quality over years. If you still want client exposure, product teams with a "customer-facing engineer" rotation are a middle path.

Three quick checks beyond the quiz

1. 1Recall your best week at work or college. Was it a week of deep focus, a week of solving someone's urgent problem, or a week where you convinced a group to change course?
2. 2Recall your worst week. Was the cause interruption, isolation, or lack of impact?
3. 3Look at what you do voluntarily. People who explain things on forums unprompted often enjoy consulting-style work; people who refactor their own side projects for fun often enjoy product engineering.

Questions to take into interviews

Whichever group led, ask the employer:

• "What share of the week is building versus client conversations, in practice?"
• "How long does an engineer usually stay with one client or one system?"
• "Who owns the code after the engagement ends?"

The answers will tell you where the specific role sits on the axis, whatever its title says. The FDE vs ML engineer comparison covers another boundary people often confuse. If group A came out on top and you are early in your career, the FDE for Freshers programme builds the engineering and client-facing sides together from zero prerequisites.