The job postings say one thing, and the actual work says another. That gap is the source of the confusion you are feeling. When a role is labeled "AI/ML Engineer" but the interview loop is all LeetCode and FastAPI configuration, it is fair to wonder if you applied for a research position or a platform team by mistake. You are not misreading the market. The market is mislabeling itself.
The core issue is that the title has become a catch-all for everything from prompt engineering to distributed systems. The original expectation for an ML role, deep math and data processing skills, has been quietly replaced by a stack that looks suspiciously like a software engineering job with an API wrapper. This is not an accident. It is the natural result of tools that handle the modeling and the math under the hood. When the heavy lifting is abstracted away, the differentiator becomes your ability to ship code, not your ability to derive a gradient. That is a significant shift, and it is worth comparing to how other high-stakes fields are adapting. Consider the pressure documented in Neurosurgery Match Requirements Highlight Growing Pressure on Medical Students, where the bar for entry has escalated so far beyond the core practice that trainees are left wondering what the actual job will be. The same dynamic is at play here, but instead of board scores, we have DSA hazing.
The real problem is not that they ask for software skills. It is that they refuse to update the title or the interview process to reflect the job's true nature. If the role is mostly about building robust APIs, managing data pipelines, and integrating with hosted models, then call it that. Do not wrap it in the AI/ML label and then quiz candidates on the architectural details of a transformer. That is a bait and switch, and it is alienating the very people who could do the job well. The math skills are not dead, but they are concentrated in research roles that do, in fact, often require a PhD. For the rest of the market, the practical path is to treat these postings as what they are: software engineering roles with a machine learning flavor. The takeaway here is direct: if you are job hunting, read the requirements as a description of the tooling, not the science. Apply for the ones where you can demonstrate you can ship a feature, not just explain a loss function. The title is aspirational, but the work is concrete.
The path forward is to stop chasing the title and start chasing the deliverables. The confusion you feel is real, but it is also a signal. It tells you that the industry is still figuring out what an "AI engineer" actually does. As that settles, expect the job descriptions to become more honest. Until then, the question to ask in every interview is not "What AI framework do you use?" but "What does a typical week look like?" The answer will tell you more than any job posting ever will. And if the answer is "wrapping an API," then you have your answer. That is not a failure on your part. It is just the market catching up to the reality that Exploring Paragraph Structure: How LLMs Navigate Token Space shows us, the underlying mechanics matter less than the structure we build around them. The old math-heavy ML role is not gone, but it is no longer the default. The new default is a builder who understands enough to use the tools well. That is a different job, and it deserves a different title.