The path from staff engineer to research engineer is more realistic than many in this person's position assume, but it requires a deliberate reframing of what they already know. Their background, a math-heavy CS degree, staff-level software engineering at a top company, and coursework in modern ML areas, is not a weak foundation. It is an unusual one, and that is precisely the point. Research engineering sits at the intersection of implementation and inquiry. It rewards people who can build robust systems while also asking the right questions about model behavior, data quality, and experimental design. This person has already demonstrated the first half of that equation. The second half is learnable, but not through more coursework alone.
The concern about age is understandable, but it is also, in this context, largely misplaced. What organizations hiring for research engineer roles are looking for is not a fresh graduate with three papers and a narrow thesis. They are looking for someone who can translate research ideas into working code, and who can do so with the judgment that comes from having shipped complex systems under pressure. A staff engineer has spent years making tradeoffs, debugging under uncertainty, and designing for maintainability. Those skills are not diminished by a lack of a PhD. They are enhanced by it. The real question is not whether this person is qualified, but whether they can present their experience as a distinct advantage rather than a consolation prize. That means framing applied ML work not as something they disliked, but as a data point that clarifies what kind of research they want to do: not fine-tuning, not prompt engineering, but the deeper, messier work of building and evaluating models that solve real problems.
The willingness to invest in lower or unpaid positions is a strategic asset, but it should not be the first lever they pull. A better approach is to target roles where their engineering maturity is the entry point, and where research exposure is the on-the-job training. That could mean joining a team that does applied research but values strong software engineering as a core competency, or moving into a research-adjacent role within their current company, where the cost of transition is lower and the existing trust is high. The master's degree question is worth setting aside for now. It would provide connections and publications, but it would not provide the one thing this person actually needs: proof that they can own a research question from hypothesis to deployment. That proof comes from doing, not from enrolling.
What this person should do next is pick a specific, narrow problem they find genuinely interesting, and build a small body of work around it. A public repository, a technical blog post, a reproducible experiment. Not to impress anyone with novelty, but to demonstrate that they can take an idea, design an evaluation, run the experiment, and communicate the results clearly. That is what research engineers do. They do not need to reinvent the field. They need to show that they can navigate it with the same rigor they brought to their engineering work. The age concern will dissolve the moment they stop acting like it is the story. The story is that they have spent years learning how to build things that work, and now they want to apply that discipline to questions that are harder to answer. That is not a step back. It is a step sideways, and it is a step worth taking.