Model names change every few months, so the skill that lasts is building software around a model you don't control. Learn to call a model, feed it the right context and measure what comes back. Fine-tuning and fancy agent frameworks can wait until someone is paying you to need them.
| Certificate | Best for | Effort | Worth it? |
|---|---|---|---|
| Microsoft Certified: Azure AI Engineer Associate | Engineers at companies that run on Azure and use Azure OpenAI or AI Search | a few weekends if you already build on Azure | The closest match to this job title of any certificate. Worth it on an Azure shop, ignored almost everywhere else. |
| Google Cloud Professional Machine Learning Engineer | Engineers building on Vertex AI who want proof of cloud ML depth | several weeks of study around a full-time job | Respected, but it leans toward classic model training. Take it if your team lives on Google Cloud. |
| AWS Certified AI Practitioner | Software engineers new to AI who work in an AWS company and want a first credential | a couple of weekends | Entry level and quick. It helps you get past a keyword filter, but it won't convince a technical interviewer on its own. |
Exam content and names change often in this field, so check the current outline directly with Microsoft, Google Cloud or AWS before you book an exam.
Experienced with LLMs, RAG and prompt engineering.
Added hybrid BM25 plus vector search and a 400-case eval suite to an internal policy assistant, lifting grounded-answer rate from 72% to 91% and cutting cost per query by 38% with prompt caching.
Enough to explain attention, tokens and context windows in plain words, yes. You won't derive gradients on the job. Interviewers care more that you can say why a long context gets slow and expensive than that you can write the equations.
Learn to build a small retrieval app with plain API calls and a vector store first. Then pick up one framework so you can read other people's code. Plenty of teams rip frameworks out once the product matures, and interviewers like hearing that you know what's under the hood.
It's real, but it's a small slice of the job. Writing clear instructions and examples matters. What gets you hired is proving a prompt change helped, with an eval run, instead of eyeballing a few answers.
Run a small open model locally with Ollama, use free API tiers for experiments, and store embeddings in Postgres with pgvector. Build one tool that answers questions over documents you know well, then write the eval set before you tune anything.