Want to move into FDE work? Take on a problem nobody has specced at your current job

You read an FDE job description: work directly with customers, take on problems with no spec, decide for yourself what to build. Then you look at your CV: three years of writing APIs from tickets a PM had already broken down. The gap is real, but closing it does not require quitting first.

According to fde.academy, an ambiguous problem with no clear spec is exactly what an FDE works on. That means experience handling ambiguity counts wherever it happens, including at the company you work for now.

The accompanying advice is specific: before you apply, volunteer for a loosely scoped initiative at your current job. What follows covers how to choose the work, how to do it, and how to turn the result into something an interviewer can see.

Why ambiguity is what you should go looking for

Most engineers are trained to avoid ambiguity: if the requirement is unclear, go back to the PM; if there are no acceptance criteria, don’t start. In a product team, that is a good habit.

FDEs are paid to do the opposite: step into territory nobody has defined, work out the real problem, and keep going until users have something they can use.

The path from backend engineer to FDE that Scaler describes starts inside your current company: look for FDE or deployment-adjacent work there first. MindStudio points to where FDE judgement comes from: getting close enough to customers and real workflows to understand why a missing data field matters.

Both point to the same place. FDE experience lives where code meets users, and every company has such a place.

An example: the missing field in the import file

Imagine you are a backend engineer at a company that sells warehouse management software to businesses. Every week the support team forwards a few tickets that say only one thing: “the customer’s file import failed”. No team owns the problem, so each time someone patches it by hand and moves on.

MindStudio advises starting with exactly this kind of work: a specific problem that keeps recurring in your current job. The failed-import tickets fit almost perfectly. They are ambiguous, because nobody knows what “failed” actually means; small, because they revolve around a single flow; and they touch real users.

The first step is not opening the code but sitting next to someone in support. Here is an interview script you can use almost word for word:

You: The last time a customer reported a failed import, what was the first thing you did?

Support: Opened the customer’s file, compared it with the template, looked for the wrong column.

You: Which column is wrong most often?

Support: The warehouse code column. Customers export from their old system, which doesn’t have that column, so the whole file gets rejected.

You: When it’s rejected, what does the customer do next?

Support: They call us, or type each row in by hand.

Those three questions turn “import failed” into a concrete problem: a required field that the customer’s real data does not have. This is precisely the understanding of a missing data field described above, and you cannot get it from reading tickets.

Now comes the technical decision. You could allow the field to be empty and assign a default warehouse, or build a screen where customers map the columns themselves. Rather than choosing on your own, you take both options to the head of operations and put them in their language:

“Option one is fixed in two days, but stock may end up in the wrong warehouse. Option two takes two weeks; customers pick the warehouse themselves and no longer need to call support. Which risk are you more willing to accept?”

Not a single mention of “nullable” or “schema”. The listener chooses between two consequences they understand, and you practise the very skill Scaler lists among those to build now: explaining technical decisions to non-technical people.

Do it yourself: six steps, from ticket to CV

Step one is to go looking rather than wait to be assigned. The support queue, the operations team’s chat channel, the spreadsheets the sales team maintains on its own: wherever people repeat a manual task because the software falls short, there is a problem worth taking on.

Step two is to get close to users, as in the session beside support above. Step three is to write the spec yourself: one sentence describing the problem and the expected outcome, taken to your manager to ask to own the work for a fixed period. You are writing a spec for something that has none, and that is the exercise.

Step four is to present the options to a non-technical decision-maker. Step five is to ship the chosen option, measure one number before and after, such as the number of tickets of that type per week, and package it all into an artifact. Step six is to rewrite your CV around what you have just done.

Turning work into evidence

The artifact is what proves you can do FDE work rather than just talk about it. In the example above, it could be a one-page document: how ambiguous the original problem was, whom you asked, what you found, which option you chose and why, and the measured result.

Add screenshots or a short demo, with sensitive data removed. A number you measured yourself will be the backbone of the story in an interview.

For the CV, Scaler’s advice is to highlight every time you faced genuine ambiguity and spoke directly with non-engineers. The difference is clear when the two versions sit side by side:

The right-hand column does not say you are better. It describes the same body of work but puts ambiguity and non-engineers first, exactly the two things the CV advice above tells you to highlight.

Common traps

The most common trap is choosing work that is too big. “Redesign the entire customer onboarding flow” sounds impressive but easily drags on, gets caught in internal politics and leaves you without a tidy result to talk about. A recurring problem confined to one flow is enough.

The second trap is solving an ambiguous problem without meeting anyone. If you read the logs, guess the cause and fix it, you have practised debugging, not FDE skills. The most valuable part of the example above is the three questions put to support, not the code.

The third trap is finishing without leaving a trace. Six months later, in an interview, you will not remember the number or who said what. Write the one-page document in the week you finish, while every detail is fresh.

The last trap is subtler: stepping into another team’s territory without telling them. Volunteering for ambiguous work is different from changing someone else’s system on your own. A short message to the team that owns the code, with an invitation to review, brings them onto your side, and that is also the stakeholder management an FDE needs every day.

Exercise for this week

Pick exactly one problem you have seen reported at least twice in the past month. Write one sentence describing the problem as you understand it today, then rewrite that sentence after your first conversation with someone who runs into it.

The more the two sentences differ, the more clearly you see what an FDE does every day: turning what people complain about into a problem that can be solved.