Hire AI Engineers in India
You can hire AI engineers in India for retrieval systems, agent workflows, model training or the serving stack underneath all of it. The hard part is not sourcing. It is that four unrelated jobs now share one title, and the market is full of people who have completed a course rather than shipped something a customer complained about.
One Title, Four Unrelated Jobs
Nothing in the phrase AI engineer tells you what the person does on a Tuesday. Four distinct roles now answer to it, they are screened differently, and hiring the wrong one is the most expensive mistake available in this field.
The LLM application engineer
This is the role most teams mean when they open a requisition, whether or not they say so. The work is building a product feature on top of a model somebody else trained: writing and versioning prompts, assembling retrieval over your own documents, wiring tool calls so the model can act, catching the output when it comes back malformed, and running an evaluation suite that says whether last week's change helped. There is almost no mathematics in it and a great deal of software engineering.
The skill that separates good from adequate here is scepticism. A model will answer anything you ask, at length, with total confidence. The engineer's job is to build the machinery that finds out whether the answer was right, before a customer does. That machinery is unglamorous: a set of graded examples, a script that reruns them, a diff of what changed. It is also the thing that almost nobody has built when they say they have shipped an AI feature.
The classical machine learning engineer
Still very much a job, and still the right hire for a large class of problems. Fraud scoring, churn prediction, demand forecasting, ranking, propensity, pricing: none of these are language problems, and a gradient boosted tree over decent features will outperform anything conversational on them. People who want to hire machine learning engineers in India usually have exactly this shape of work, even when the brief has been rewritten in the vocabulary of the moment.
Screening for this role is closer to screening a scientist than a developer. You want to hear about label definitions, about the split that leaked because rows from the same customer landed on both sides of it, about the difference between a model that scores well offline and one that changes a decision. Ask what their baseline was. If there was no baseline, there was no way to know whether the model earned its keep.
The ML platform engineer
The person who makes any of the above survivable in production. Packaging a model as a versioned artefact, serving it behind an interface with timeouts and back pressure, watching input distributions for drift, deciding when a retrain is triggered and who approves the result, keeping a rollback path that has actually been tested. Half infrastructure engineer, half sceptic.
Teams reach for this hire far too late, usually after a model has been sitting in a notebook for a quarter with everyone waiting for somebody to deploy it. If your problem is that a working model cannot get to users, no amount of modelling talent will help. That is platform work, and our MLOps services in India page sets out what it involves when you would rather buy it as an outcome than staff it.
The research-leaning scientist
Publications, novel architectures, training from scratch, methods that do not yet have a library. A genuine specialism and a real category of person, and almost never what a product team needs. Hiring a researcher to build a support assistant produces a frustrated researcher and a late feature. Hiring one to solve a problem where the method really does not exist yet is money well spent, and you will know which situation you are in because your engineers will already have failed at it with the standard tools.
Why the mismatch takes two months to become obvious
All four profiles look identical on a CV. They all list Python, PyTorch, some vector database, some orchestration framework, some cloud. They all demo well, because a demo is precisely the artefact every one of them can produce. The divergence appears only when the system meets real inputs: the researcher who cannot get a service under a latency budget, the application engineer asked to explain why the classifier degraded and reaching for a prompt, the platform engineer handed a modelling question and reasonably answering it with more monitoring.
By the time this is visible you have spent a couple of months and the ramp-up is sunk. The cheap fix costs an afternoon: write down the first three tickets in plain language, decide which of the four profiles those tickets belong to, and build the shortlist against that instead of against a title.
Which AI Hire Do You Actually Need?
Start from the complaint, not from the technology. Six symptoms account for most of the briefs that arrive here, and each one points at a different profile once you read it properly.
Your assistant answers confidently and wrongly
This is a retrieval problem far more often than it is a model problem, and the fix is nowhere near the model. Documents chunked at a fixed character count that severs tables from their headers, an embedding model doing all the work with no keyword search beside it, no reranking step, and no measurement of whether the right passage was even retrieved before generation started. You want an LLM application engineer with real retrieval experience, and you want them to instrument recall before they touch a prompt. What that work involves is laid out on our RAG development services in India page.
Something works in a notebook and cannot reach users
Do not hire a modeller. The modelling is done. What is missing is packaging, a serving interface, monitoring and a retraining path, and those are platform skills. This mismatch is common enough that it deserves naming directly: hiring a data scientist to solve a deployment problem is how a two-week job becomes a two-quarter one.
You want a workflow to run without a human in the middle
Agent territory, and the part worth being careful about. The interesting engineering is not the model choosing a tool. It is deciding when the loop stops, what happens on the third failed attempt, which actions are allowed to write to a real system, and how you reconstruct afterwards what the thing actually did. Anyone who describes this work as prompting has not run one in front of customers. Our agentic AI services in India page covers the engagement shape.
You have labelled data and a decision to improve
A classical modelling hire, and probably a scoped one. Set the baseline first: what does the current rule or the current human get right, and what does being wrong cost in each direction. Half the projects in this category should end at the baseline, and the engineers worth hiring will tell you so in week two rather than presenting a model in week ten.
Costs jumped and nobody can say why
Neither a modelling nor a research problem. Somebody needs to instrument token usage per request path, find the retrieval step that stuffs twenty passages into the context when four would do, find the retry loop that silently doubles calls on timeout, and decide which requests genuinely need the expensive model. This is engineering with a spreadsheet next to it, and it is one of the highest-return pieces of work available on a live AI product.
You are not sure the idea is viable
Then the first work is a two-week question, not a hire. Can the signal be found in your data at all, do your documents actually contain the answers people ask for, would a fixed rule get you most of the way. Buying a hire to answer that question means paying a salary while somebody does exploratory work, and then feeling obliged to build something because you have the person. If the wider question is which stacks and roles to staff at all, our hire developers in India page takes that from the top.
How Do You Tell Someone Who Has Shipped From Someone Who Has Done a Course?
This is the whole interview. Everything else on this page matters less. The field is young enough that a confident vocabulary can be acquired in a fortnight, and the only reliable separator is whether a real user has ever been hurt by something the candidate built.
What broke in production, and what did you change?
Open with this and let it run. Someone who has shipped answers immediately, with an unflattering specific: a retrieval index that quietly stopped updating and served four-month-old policy documents for weeks, a JSON response that started arriving wrapped in a code fence after a model version changed, a background job that reprocessed the entire corpus every night and nobody noticed until the invoice arrived. The story has a date in it, a diagnosis, and something they would do differently.
Someone who has followed tutorials describes the architecture instead. The answer is clean, ordered and slightly generic, moving from ingestion to chunking to embedding to retrieval to generation, and it contains no surprises because nothing has ever surprised them. That is not dishonesty. It is a person describing the only thing they have, which is a system that worked on the first try because it was designed to.
Follow up once: what did you try that did not fix it? The dead end is the tell. Real debugging is a sequence of wrong guesses ending in one right one, and people who have lived it remember the wrong guesses vividly.
How did you know the model was getting worse?
The best question on this list, because degradation is invisible by default.
Nothing throws an exception when quality drops. The service returns two hundred, the response is fluent, and the only signal is a support ticket six weeks later.
Strong answers describe a mechanism. A held-out set rerun on every deploy with the results posted where the team sees them. Sampled production traffic graded weekly against a rubric. A thumbs-down rate tracked per feature and per document source rather than as one site-wide number. Retrieval hit rate monitored separately from answer quality, so that a drop can be attributed instead of guessed at. Somebody watching the distribution of input lengths and languages, because a change there moves everything downstream.
Weak answers use the passive voice. Users would report issues. We monitored quality. Ask who looked, how often, and what they looked at, and the answer either becomes concrete or evaporates.
What did your eval set look like, and who wrote it?
Ask both halves. The size matters less than the provenance. An eval set assembled by the engineer from cases the engineer found interesting will pass forever, because it encodes the same assumptions as the system. An eval set built from real user questions, with expected answers written or at least approved by whoever actually knows the domain, catches things the engineer would never have thought to test.
The follow-ups do the real work. How did the set grow? The correct answer is that every incident added a case, so the suite is a scar record. Did two reviewers ever disagree about an expected answer, and what did you do about it? People who have built these sets have absolutely had this argument, and the resolution is usually that the question was ambiguous and the specification was wrong rather than the model. Were there cases where the right behaviour was to refuse? A set with no refusals in it is a set that has never tested the boundary.
The model was right and the product still failed. Then what?
This question filters hard, and it is the one that identifies an engineer rather than a technologist. There are many ways to be correct and useless. An answer that is accurate but arrives after the user has given up. A summary that is faithful and four hundred words long when the person needed one line. A support assistant that resolves the question perfectly and never offers the escalation path the customer was hunting for. A classifier that is right and produces an action nobody downstream is empowered to take.
The answer you want involves a change outside the model. They shortened the response and moved detail behind an expander. They streamed the first token so the wait felt different. They added a route to a human at the second failed clarification. They discovered in session recordings that people were pasting a screenshot into a text box and the whole input assumption was wrong. Candidates who only reach for prompt changes and model swaps have been working on the model rather than the product, which is a different job and often not the one you are hiring for.
A customer saw a hallucination. Walk me through the next hour.
You are testing composure and process, not blame. A person who has been through it moves in a recognisable order. Contain first: turn the feature off for that path, or fall back to search results with no generated summary, because the priority is to stop producing more of them. Reproduce second, with the exact input, because a large share of the time the fault turns out to be a retrieved document that genuinely says the wrong thing and the model reported it faithfully.
Then attribution. Was the source wrong, was the right source not retrieved, or was the source right and the generation unfaithful to it? Those three have completely different fixes and conflating them is the most common mistake in incident response here. Then the case goes into the eval set permanently, so the same failure cannot return unnoticed. Then, and this is the part that distinguishes senior people, somebody tells the customer what happened.
Listen for whether they mention prompt injection unprompted. If your system retrieves documents that users or third parties can influence, the instruction to ignore previous rules can arrive inside a retrieved passage rather than from the person typing. An engineer who has thought about the OWASP guidance for LLM applications will raise this without being asked.
Show me something you decided not to build
Restraint is the rarest quality in this field and the most valuable.
Every AI engineer with real experience has talked a stakeholder out of something: the chatbot for a form with six fields, the summariser for documents nobody was reading anyway, the fine-tune to fix a problem that turned out to be four bad rows in a lookup table. If the candidate has never said no to anything, they have either never been asked or never been listened to, and both are worth knowing.
The tells in a portfolio
Look at what surrounds the interesting code. A repository from someone who has shipped contains dull artefacts: a directory of evaluation cases, a script that reruns them, pinned versions, a prompt file with a change history, a README that mentions what the thing cannot do. A repository from someone who has studied contains a well-organised pipeline, a notebook that runs top to bottom, and a README describing what the system will do rather than what it did.
Two more signals. First, if every project in the portfolio uses a different framework and none is finished, you are looking at enthusiasm rather than delivery. Second, ask which parts of an orchestration framework they eventually removed. Nearly everyone who has run one of these systems for a year has torn out an abstraction that made debugging harder than the problem it solved, and they will name it happily.
Evaluation Is the Senior Skill
If you take one screening rule from this page, take this one. A candidate who cannot describe how they measured quality has not shipped, whatever else is on the CV. Everything in a language-model system is easy except knowing whether it is working.
What an eval set actually is
A collection of inputs with expected outcomes, graded automatically where possible and by a person where not, run on a schedule and before every change that could affect behaviour. It does not need to be large to be useful. A few dozen well-chosen cases covering the awkward inputs will catch more regressions than a thousand cases sampled uniformly from easy traffic.
What belongs in it: the questions users actually ask, including the badly worded ones. The cases where the correct answer is that the system does not know. The inputs that caused an incident. The formats that broke parsing. The adversarial ones, if your system is public. Ask a candidate which categories they deliberately included and you will hear straight away whether they built it or inherited it.
Offline scores, online behaviour, and the gap between them
Offline evaluation is fast, cheap and repeatable, and it measures a proxy. Online measurement is slow, noisy and expensive, and it measures the thing you care about. Systems that look better offline and worse in production are ordinary, not anomalous, and an engineer who has never seen that happen has not run one long enough.
The useful habit is holding both and knowing which to trust. Offline score for gating a deploy and catching regressions. Online signals for whether the feature earns its place: resolution rate, escalation rate, edit distance between generated draft and what the human eventually sent, abandonment part way through a stream. That last family of metrics is where the honest answers live, and it is where product-minded engineers separate from model-minded ones.
Using a model to grade a model, and how that goes wrong
Grading output with another model is now standard practice, and it is genuinely useful for scale. It is also a measurement instrument with known biases, and candidates should be able to name them. Judges favour longer answers. They favour text that resembles their own generation style, which makes a model a poor judge of itself. They drift when the grading prompt changes, so the prompt has to be versioned like any other code. They score inconsistently on borderline cases unless the rubric is specific enough to be boring.
The practices that make it work are unexciting. Calibrate against human labels on a sample before trusting the judge at all. Use pairwise comparison rather than an absolute score, because models are considerably better at saying which of two is better than at assigning a number. Randomise position, since order affects the verdict. Keep a held-out slice that a human still grades, permanently, as the check on the check.
Regression suites and the prompt change nobody measured
Prompts are code with none of the safety of code. A one-line addition to fix a formatting complaint can change refusal behaviour on an entirely different category of question, and nothing in the tooling will tell you. This is the single most common quality incident in production language-model systems, and it is why the eval suite has to run in CI on prompt changes exactly as tests run on code changes.
Ask a candidate what their pull request looks like when they change a prompt. The answer you want includes the diff, the eval run attached to it, and a note about which cases moved and why that is acceptable. The answer you do not want is that prompts live in a configuration screen and get edited by whoever is nearest. That arrangement is fine for a prototype and indefensible once customers depend on it.
Metrics that mean something for retrieval
Where a system retrieves before it generates, evaluate the retrieval independently. Otherwise every failure looks like a model failure and you will spend months tuning generation to compensate for a search problem. Recall at k answers whether the necessary passage was in the candidate set at all, which is the ceiling on everything after it. Ranking measures such as mean reciprocal rank and normalised discounted cumulative gain tell you whether it was near the top, which decides how much context you can afford to send. Faithfulness scoring, checking whether each claim in the answer is supported by a retrieved passage, catches the fluent invention that keyword tests miss.
An engineer who reports these separately has debugged a retrieval system. One who reports a single quality percentage has been guessing, politely.
Cost and Latency Are Engineering Constraints, Not Afterthoughts
Two things reliably kill AI features after launch, and neither is quality. The bill nobody modelled, and the wait nobody designed for. Both are engineering problems with engineering answers, and both should come up in the interview.
Where the money actually goes
Usage is charged by volume of text in and out, and the input side is where the surprises live. A retrieval step that sends fifteen passages instead of five multiplies the input on every single call. A conversation that replays its entire history each turn grows quadratically and nobody notices until sessions get long. An agent loop that reasons before each tool call can spend more on deliberation than on the work. A retry on timeout that does not check whether the first call actually completed pays twice for one result.
Provider pricing moves too often to quote and differs by model, so ignore the numbers and check the discipline. Ask a candidate whether they have ever instrumented usage per request path rather than as one monthly total. Ask what their most expensive endpoint turned out to be, and whether the answer surprised them. It usually does, and the honest ones say so.
The techniques that reduce spend are not exotic. Cache the stable prefix of a prompt where the provider supports it, since a long fixed instruction block resent on every call is pure waste. Cache whole responses for repeated identical questions, which in support workloads is a substantial share of traffic. Route by difficulty, sending straightforward requests to a smaller model and reserving the capable one for cases that need it. Retrieve fewer passages and rerank better, which usually improves quality and cost together. Distil a narrow task down to a small fine-tuned model once you have enough traffic to justify the work.
Latency is a product decision before it is a technical one
Generation is sequential, so a longer answer takes longer, and no amount of infrastructure changes that. What you can change is when the user sees the first word. Time to first token and total completion time are separate numbers with separate fixes, and a candidate who conflates them has not optimised one of these systems.
Streaming is the highest-value change available in most products, because a response that begins in a few hundred milliseconds feels immediate even when it takes several seconds to finish. Retrieval and generation can overlap where the design allows. A cheap classifier can decide up front whether a request needs the full pipeline at all. Speculative approaches and batching help on self-hosted serving. What almost never helps is the thing teams try first, which is switching to whichever model currently looks fastest on a public comparison.
Measure at the high percentiles or do not bother. Mean latency on a language model is close to meaningless, because the tail is where the abandonment happens and the tail is long. Ask what their ninety-fifth percentile looked like and whether they knew what caused it.
Self-hosting, and when it is the wrong answer
Running open-weight models on your own hardware makes sense for three reasons: data that cannot leave your environment, volume high enough that fixed capacity beats per-call charges, or a fine-tuned model you cannot host elsewhere. It does not make sense as a cost saving at low volume, because idle accelerators cost the same as busy ones and utilisation is the entire economics.
An engineer who has done it will talk about the real constraints without prompting: memory taken by the attention cache as concurrency rises, continuous batching to keep the hardware busy, quantisation and the quality trade it involves, and the fact that a second replica for availability doubles fixed cost. Someone who describes self-hosting as simply cheaper has run it on one machine for one user.
Should You Be Hiring for AI at All?
A section that argues against the page it sits on. We would rather say this plainly than have you find out after two quarters, and the willingness to say it is itself a hiring criterion.
A rule, a lookup or a query beats a model more often than anyone admits
Plenty of briefs that arrive here describe deterministic problems. Routing a message to a department when the department is already implied by the form the customer used. Extracting fields from a document produced by one system in one fixed layout. Deciding eligibility from four values in your own database. Detecting a keyword. Each of these can be done with a model, and each will be slower, more expensive, harder to test and occasionally wrong in ways nobody can explain to a regulator.
The reasonable design is a fixed rule where the logic is knowable and a model only where the input is genuinely open. Many production systems that look impressive are mostly rules with a model at one uncertain step. That is good engineering, not a failure of ambition.
The data problem in a model costume
This is the more common version and the harder one to say out loud. A retrieval assistant cannot answer questions your documentation does not answer. If the procedure exists only in somebody's head, or three pages contradict each other, or the current version sits in a spreadsheet attachment on an old email, no retrieval architecture will rescue it. The system will confidently surface whichever contradictory page ranked highest, and everyone will blame the model.
The same applies to prediction. If your labels were produced by an inconsistent manual process, the model learns the inconsistency faithfully. Cleaning the labels is dull, it is nobody's favourite quarter, and it is frequently the entire project. An engineer who tells you the first six weeks are data work rather than modelling is giving you the correct answer, and it is the answer least likely to win a pitch.
Good hires say this out loud
So make it safe for them to. Put a question in the interview that gives explicit permission: here is a thing we are considering building, tell us why we should not. A candidate who takes that opening and gives you a specific structural objection is showing you exactly what they will be like in a planning meeting. One who compliments the idea and describes an architecture for it will build whatever you ask for, correctly, including the things you should not have asked for.
Worth saying: this cuts against our commercial interest and we mean it anyway. Work that should not have been built gets abandoned, and abandoned work is a bad outcome for everybody attached to it.
The Adjacent Skills That Decide Whether the Hire Works
Model knowledge is the smallest part of the job and the only part most interviews test. These four are what separate an engineer whose work reaches production from one whose work stays in a branch.
Python, and specifically the unglamorous parts
Nearly all of this work is Python, so the ordinary engineering standards apply and are frequently absent. Can they structure a package rather than a script? Do they pin dependencies, in an ecosystem where a minor version bump to a client library changes response shapes? Do they write a test that runs without hitting a paid endpoint, which means they understand where to put the boundary? Concurrency matters more here than in most backend work, because these systems are dominated by waiting on slow network calls, and a blocking call in the wrong place stalls everything sharing that worker. If you want more depth on assessing that, our hire Python developers in India page goes through it properly.
Data handling that survives contact with your data
Before anything reaches a model, something has to read a PDF whose columns interleave when extracted, a spreadsheet with merged cells, a scanned document that needs recognition, an export where dates arrive in three formats. This is where the weeks go, and it is entirely absent from tutorials. Ask what the worst input format they have handled was, and how they knew the extraction was correct. Someone who has done it will describe a validation step and a sample they checked by hand.
API design, because these interfaces are unusual
Language-model features break several assumptions ordinary endpoints rely on. Responses stream, so the contract is a sequence of events rather than one payload, and the error case can arrive halfway through a successful-looking response. Calls take seconds, so timeouts, cancellation when the user navigates away, and idempotency on retry all have to be designed rather than inherited. Output is probabilistic, so the client needs a defined behaviour for a response that fails schema validation. Ask how they handled a partial failure mid-stream, and whether the user ever saw half an answer.
Observability, or you are debugging by anecdote
When a user reports a bad answer, you need the whole trace: the input, the retrieved passages with their scores, the assembled prompt, the model and version, the tool calls, the raw output before parsing, and the timings of each stage. Without that, every investigation is guesswork and every fix is superstition. Ask what they logged and, more revealingly, what they redacted, because the answer tells you whether anyone thought about the personal data flowing through those logs.
Two of these four cause more failed AI hires in our experience than anything model-related. A brilliant modeller who cannot design an interface will produce something that works and cannot be integrated. A capable application engineer with no observability instinct will produce something that works until it does not, at which point nobody can say why.
The Seniority Ladder for This Skill
Years of experience is an especially weak signal here, because most of the current toolset is only a few years old and nobody has a decade in it. What separates the bands is the size of the uncertainty a person can be left alone with.
Early: builds inside a shape someone else defined
Can implement a retrieval pipeline from a clear specification, write prompts that work, wire a tool call, and add cases to an evaluation suite somebody else designed. Needs review on anything involving cost, failure handling or what to do when the output is plausible and wrong. Genuinely productive on a team with an established harness. A poor choice as the only AI person on a project, however quick they are, because the judgement calls arrive before the code does.
Mid: owns a feature and its failures
Has been on the receiving end of a complaint about something they built. Designs the eval set rather than filling one in, attributes a quality drop to retrieval or generation without guessing, notices the cost line moving before finance does, and knows which requests deserve the expensive model. Most teams are hiring for this band whether the job title says so or not, and it resists interviewing, because what separates it from the band below only becomes visible on a day when something fails in public.
Senior: decides what not to build, and can prove it
Judgement rather than throughput. Argues a stakeholder out of a feature with evidence rather than opinion, chooses a rule over a model when the rule is correct, designs the measurement before the system, and sets the boundary between what the model may decide and what a human must approve. Expect a clear and well-argued opinion about your architecture within the first fortnight, phrased as a question.
The specialist, at any level
Deep in one area: retrieval quality, serving performance, safety and adversarial testing, or a domain where the vocabulary is the hard part. Worth hiring when that area is your bottleneck and worth avoiding when it is not, because a retrieval specialist on a serving problem is an expensive generalist. Ask what they would refuse to take on. Specialists who know their edges are the useful kind.
Four Hiring Situations and What We Would Staff
Composite patterns drawn from the shapes of brief that reach us, not accounts of particular clients. They are here because the reasoning transfers even when the details do not match yours.
A support assistant that is quietly making things worse
The pattern: a company launches an assistant over its help centre. Deflection looks good for a month, then escalations start arriving from customers who followed the assistant's advice and were wrong. The team assumes the model is the problem and starts comparing providers.
What is usually true: the help centre contains three generations of policy, nothing is dated, and superseded articles rank as well as current ones. The retrieval is doing exactly what it was told. The first fortnight of real work is measuring whether the correct article was retrieved at all, separately from whether the answer was good, and that measurement typically reallocates the blame entirely.
What we would staff: one LLM application engineer with retrieval depth, working alongside somebody on the client side who has authority to retire documents. The second person is not optional. An engineer who cannot get contradictory content removed is being asked to fix an editorial problem with software.
A fraud model that works and has never been deployed
The pattern: a data scientist has spent two quarters producing a model with a good offline score. It lives in a notebook. Every attempt to deploy it stalls because the features it relies on are computed by a script on the scientist's machine, and nobody can reproduce them at request time.
What is usually true: this is train and serve skew, and it is a platform problem, not a modelling one. The features need a definition that runs identically in batch and at request time, the model needs versioning and a serving interface, and somebody has to decide what happens when a feature is missing for a live request. Hiring another modeller adds a second notebook.
What we would staff: one ML platform engineer, with the original scientist kept close for the first month to settle feature definitions. The likely first deliverable is a shadow deployment, scoring live traffic without acting on it, so the offline claim can be tested before anybody's payment is declined by a model nobody has watched yet.
An agent with permission to touch a live system
The pattern: an operations team wants a workflow automated end to end. The agent reads a request, checks three internal systems, and updates a record. The prototype is convincing. The team is now nervous, correctly, about giving it write access.
What is usually true: the interesting engineering has nothing to do with the model. It is the permission boundary, the loop that must terminate, the behaviour on partial failure when two of three systems have been updated, and the audit trail that lets someone reconstruct a decision three months later during a dispute. A prototype that never fails has not told you anything about any of these.
What we would staff: an application engineer who has run an agent in production, and an explicit design phase before more building. In most cases the correct first version writes a proposed change for a human to approve, with the approval rate itself becoming the measurement that decides whether full automation is ever justified.
A cost line that tripled after a successful launch
The pattern: a feature ships, adoption is better than forecast, and the monthly bill outgrows the revenue attached to it. Leadership asks whether to switch to a cheaper model. Nobody can say which part of the product is responsible for the spend.
What is usually true: a small number of paths dominate. A retrieval step returning far more context than the answer needs. A conversation replaying full history on every turn. A background summarisation job running over everything nightly whether or not anyone reads it. Retries that do not check for completion. Instrumenting usage by path before changing anything usually finds enough to fix without touching the model.
What we would staff: one engineer for a short scoped piece of work, not a hire. This is a two to four week job with a clear end state, and the deliverable is a cost dashboard by request path plus the three changes the dashboard justifies. Turning it into a permanent role would be paying a salary for a problem that stops existing.
Working With an AI Team in India: The Day, Honestly
Offshore engagements rarely disappoint on ability. They disappoint because nobody did the clock arithmetic in advance and nobody agreed what a finished piece of work looks like. Both are fixable in the first week and expensive in the third month.
Start with the clock, because it does not negotiate
A single zone covers everything from Kerala to Assam, running five hours thirty minutes ahead of UTC, and it never shifts for summer. The consequence is worth spelling out: an Indian office day is anchored while yours moves twice a year, so the overlap you measure in December is not the overlap you get in July. A day of 09:30 to 18:30 in India occupies 04:00 to 13:00 UTC permanently.
Rather than converting your own hours into UTC and squinting at them, look at where that fixed Indian block lands on your own wall clock. That is the number that decides whether this arrangement works for you.
| Your city | When the Indian day begins and ends on your clock | Usable overlap if you work 09:00 to 17:00 |
|---|---|---|
| London, winter (UTC+0) | 04:00 until 13:00 | 4 hours, entirely before your lunch |
| London, summer (UTC+1) | 05:00 until 14:00 | 5 hours |
| Berlin, summer (UTC+2) | 06:00 until 15:00 | 6 hours, the largest window any Western market gets |
| Dubai (UTC+4) | 08:00 until 17:00 | 8 hours, near enough a shared day |
| Sydney, winter (UTC+10) | 14:00 until 23:00 | 3 hours, arriving after your lunch |
| Auckland, winter (UTC+12) | 16:00 until 01:00 | 1 hour, and nothing once daylight saving moves you to UTC+13 |
| New York and Toronto, standard time (UTC-5) | 23:00 until 08:00 | None |
| San Francisco, standard time (UTC-8) | 20:00 until 05:00 | None |
The bottom two rows are the ones this industry prefers not to print. An Indian office day finishes at eight in the morning on the East Coast and at five in the morning on the West Coast. There is no thin sliver to work with. There is nothing. If a supplier has implied otherwise to you, they are either counting a shifted roster they have not mentioned or they have not run the subtraction.
North America can have overlap, but somebody pays for it with an evening. Pull the Indian start back to 13:30 and finish at 22:30 and the block moves to 08:00 through 17:00 UTC, which puts roughly three hours inside a normal New York afternoon. Reaching California means later again, around 17:30 to 02:30 India time, and that is a night rota rather than a flexible finish. Arrangements like these hold up when they are named, priced and rostered. They collapse when a client assumes them and an engineer quietly wears them until they leave.
One thing works in your favour on this particular kind of work. A lot of AI engineering is naturally batch: sweeping an evaluation set across two prompt versions, rebuilding an index, profiling a serving configuration under load, running a labelling pass. Those jobs happen while you are asleep and the results are sitting there when you open your laptop, which makes a four-hour window more productive here than it would be on interactive interface work. It is a genuine advantage. It is not a substitute for an overlap of zero, and nothing is.
Coverage around the clock has to be staffed and paid for
If you want somebody awake at every hour, that means several people, a rota written down, a handover note designed to be read cold by whoever picks it up, and an agreed threshold for what justifies waking a colleague. All of that is additional people and additional coordination, and asking for it is perfectly sensible. What is not sensible is treating it as a free side effect of hiring abroad. We would rather scope it with you and let you look at the cost before you decide it is worth having.
How a good week runs
The default is writing rather than talking. Before your morning there is a short note in your channel covering what shipped, what is next and where somebody is stuck, so you begin the day already informed. Branches go up in small pieces early enough that your review happens while both sides are awake, instead of one enormous pull request landing on a Friday evening. Whatever gets settled on a call goes back into the ticket afterwards, because nobody can search a conversation that happened three weeks ago.
Two arrangements matter more than any of the general process advice, and both are peculiar to AI work. The first is one evaluation harness that your side and ours can both run, so an argument about whether last week's change was an improvement gets settled by rerunning it rather than by whoever speaks with more confidence on the call. The second is a development model account with its own spending limit. An engineer who has to request approval before every experiment runs fewer experiments, and running experiments is most of the job.
Data, model access and what to settle in the first conversation
Development happens in your repositories, on infrastructure you control, behind your own access management, and the commit log is the audit trail. The thing to resolve early rather than late is which data is permitted to leave your environment and which vendor is allowed to see it, because that answer shapes the architecture and not merely the contract. Regulated information may push you towards inference you host yourself, redaction before anything is sent, or limits on where the work may physically run. Terms covering confidentiality and ownership get written down before work starts, and their content belongs in that document rather than on a page like this one.
If you sit in a jurisdiction that is writing new rules about automated decision-making, get your lawyers into the design discussion rather than the review at the end. We can build against a constraint you give us. We cannot tell you what your obligations are, and any supplier who offers you that certainty from a marketing page deserves a second look.
The four things that actually go wrong
Only one of them is technical. A brief with no detail in it, where a ticket reading make the assistant better gets interpreted, and distance turns a poor interpretation into weeks of wasted output. Slow reviews, where a branch sits for two days and the engineer either idles or opens a second front and ends up with three unreviewed pieces of work in flight. Nobody with authority to answer a question, so something that would take half a minute across a desk costs a full working day. And the failure unique to this field: no shared definition of a good answer, so the engineer optimises towards a target the client never held, and neither party notices until a demo.
That last one is why we push to build an evaluation set in week one, ahead of feature work. It is the nearest thing this discipline has to a written specification, and producing it forces the argument about what counts as correct while the argument is still cheap.
Where Can You Hire AI Engineers, and What Does Each Route Miss?
Four routes, each with a real strength and a specific blind spot. We have an interest in one of them and will still describe the others fairly.
Direct hiring into your own team
The best long-term answer when the work is permanent and you have somebody who can interview for it. The blind spot is that last clause. Screening for this skill requires having done the work, and a team hiring its first AI engineer has nobody qualified to run the conversation described earlier on this page. The common outcome is a hire made on enthusiasm and vocabulary, discovered to be a mismatch a quarter later. If you go this route, borrow a technical interviewer from outside for one session. It is the cheapest insurance available.
Freelance marketplaces
Fine for a bounded piece of work with a clear end state and a specification you can write yourself. Genuinely bad for anything open-ended, because the incentive is throughput and the artefact that suffers first is the evaluation harness, which is invisible to a client and takes days to build. You will get a working demo quickly and inherit a system nobody can measure. Check whether the deliverable includes a way to tell if it is still working next month.
General staffing firms
Volume and speed, with technical screening that is usually keyword matching. A recruiter checking for retrieval frameworks and a vector database on a CV cannot distinguish someone who has run one in production from someone who completed a weekend project with the same libraries. That distinction is the entire point. If you use this route, insist on doing the technical round yourself and treat the shortlist as sourcing rather than screening.
An engineering partner, which is what we are
The advantage is that the screening has already happened and it was done by people who have shipped these systems. The engineer arrives with the habits described above rather than acquiring them on your project. Because we do not start a search when you ask, we can usually put matched profiles in front of you within forty-eight hours and have someone working inside seven days, which is the part of the hiring cycle that normally costs a quarter.
The honest disadvantage: a partner has a commercial interest in the answer being a person. We try to counter that by saying when a scoped project or no project at all is the better answer, and you should judge any partner on whether they ever do. If the first conversation does not include at least one thing they think you should not build, you are talking to a sales process.
Engagement Models
Which of these fits depends on two questions: how clearly you can describe the finished state, and whether you have somebody able to set technical direction week to week. Working hours, contract terms and the overlap window get settled with you before a name is put forward, so none of them appears here as a number. One number we will give up front: get the match wrong and a different AI engineer is in front of you within 48 hours, picked from several candidates rather than handed to you as the only name.
One Piece of Work, With an End
Suits a target you can describe in a sentence: an evaluation harness assembled from your real traffic, a retrieval layer rebuilt and measured, a spend investigation that names its three fixes, a model moved out of a notebook and into shadow scoring. What you receive is a result plus a handover, and then it stops.
One Engineer, Inside Your Team
The arrangement most people are picturing. Someone works your queue from inside your repository and your standup, taking direction from you. It needs a roadmap that already exists and a reviewer with capacity, and without those two things it underperforms regardless of who you pick.
Cover for More Than One Role
Where the work runs across application, modelling and platform at the same time and any single person would be strong in one quadrant and improvising in the others. A lead comes with it to split the work and keep the measurement standard steady, so the coordination is not yours to do.
The most useful thing we can say about money is what you will not find here, which is a published figure per role. A price detached from scope, seniority and working hours is speculation formatted as a quotation, and comparing two of them teaches you nothing. What deserves a line in your own budget, whoever you end up hiring: the weeks before anyone is productive, the review time it consumes on your side, the premium attached to any shifted roster, and model usage during development. That last one catches people out repeatedly, because forecasts get built around production traffic and an engineer running evaluation sweeps all day can consume more than the live product does.
Questions Buyers Ask Us Before Hiring
What is the difference between an AI engineer and a machine learning engineer?
In current usage, AI engineer usually means someone building on top of a hosted model: prompts, retrieval, tool calls, evaluation, cost. Machine learning engineer usually means someone who trains a model against your labelled data and owns whether it generalises. The daily work barely overlaps. One person tunes a retrieval pipeline; the other argues about label quality and validation splits. Write down which unit of work you have before you write the job description.
How do I know a candidate has actually shipped an AI feature?
Ask what broke after launch and what they changed in response. Someone who has shipped has a story about a bad retrieval result reaching a customer, a prompt edit that silently regressed something else, or a cost line that tripled in a week. Someone who has followed tutorials describes the architecture instead, cleanly and in order, with no scars in it. The scars are the signal.
Do we need someone who can train models, or someone who can call one?
Most teams need the second and advertise for the first. If your difficulty is that answers are wrong, slow or expensive, that is retrieval, prompting, evaluation and serving work, and a strong engineer will beat a research profile at it. Training is the right answer when you hold labelled data nobody else has and the task is genuinely specific to your domain.
How much overlap will we get with an AI team in India?
India holds one timezone at UTC plus five thirty and never moves it, so an office day of 09:30 to 18:30 is fixed while yours drifts twice a year. On your own clock that block runs 04:00 to 13:00 in London during winter, 08:00 to 17:00 in Dubai, and 14:00 to 23:00 in Sydney. In New York it ends at 08:00 and in San Francisco at 05:00, which means no overlap at all with normal American hours unless the Indian roster is shifted, and that shift gets agreed with you up front.
What should an AI engineer be able to tell me about evaluation?
How big their eval set was, who wrote the expected answers, and what disagreement between reviewers looked like. Then which cases they added after each incident, and what score movement they treated as noise. A candidate who describes evaluation as vibes, or who says the model just seemed better, has not owned a system where a prompt change could quietly break paying customers.
Can we hire dedicated AI engineers in India rather than buying a project?
Yes, and it suits teams that already know what they want built and have someone to review it. The engineer works in your repository, your tracker and your evaluation harness, and you keep the technical direction. Where the first six weeks would be discovery about your documents, your users and whether the idea works at all, a scoped engagement usually gets you there faster.
Who owns the prompts, the eval set and the fine-tuned weights?
Everything is produced in your repository and your accounts, so ownership follows the same path as any other code. The part worth deciding early is where inference runs and which provider sees your data, because that is a contractual and regulatory question rather than a technical one. Bring your counsel into the first conversation if you handle regulated data, since it changes the design and not just the paperwork.
What if the honest answer is that we do not need AI?
Then we will say so. A good proportion of the briefs that reach us describe a routing problem, a search problem or a data quality problem wearing a model costume, and a lookup table or a fixed rule solves it more cheaply and more predictably. An engineer who tells you that before you spend the budget is worth more than one who builds whatever was asked for.