Careers at iSpark

A note on what this page is and is not. It is a description of the ten disciplines we hire into and what the work looks like at a company that builds AI systems for clients rather than for itself. It is not a live vacancy board with a count of open seats. If one of these roles describes you, write to us with work we can look at and we will tell you honestly whether there is something open now or whether it is worth staying in touch.

The ten AI roles we hire for

These are ordered roughly by how often the discipline appears in client requirements, not by seniority or pay. The demand column cites published market signals where we have them. Treat those figures as directional: hiring indices measure job titles, and job titles in this field are notoriously inconsistent between companies.

What follows is a longer description of each role as it exists here. If you recognise yourself in the bullet points rather than the job title, that is the right reason to write to us.

AI Engineer

The broadest role on this list and the one most in demand. An AI engineer at iSpark takes a business problem and assembles a working system from models, retrieval, tooling and ordinary software. In practice this is more software engineering than research: you spend your time on context assembly, prompt and tool design, latency, cost per request, caching, fallback paths and the evaluation harness that proves the thing works.

• Building retrieval systems over client document sets, including chunking strategy, embedding choice and the reranking step most teams skip
• Designing evaluation suites that catch confident wrong answers before a client does
• Getting cost per request down by an order of magnitude without losing answer quality
• Writing the integration layer between a model and the systems a client already runs

Machine Learning Engineer

Where the problem is prediction rather than generation, this is the role. Forecasting, classification, ranking, anomaly detection, recommendation and the unfashionable tabular work that quietly produces most of the measurable value in the field. The job is feature engineering, model selection, validation design and the discipline to resist a complicated architecture when a gradient boosted tree wins.

• Building demand, churn, risk and maintenance models against real client data
• Designing validation that reflects how the model will actually be used, including time based splits and group leakage checks
• Quantifying uncertainty so a business user knows when not to trust a prediction
• Retraining strategy, drift detection and the question of when a model should be retired

MLOps and AI Infrastructure Engineer

The reason AI projects survive. You own the path from a notebook to a service that runs at three in the morning without anyone watching. Pipelines, feature stores, model registries, reproducible training, deployment, rollback, monitoring and the alerting that tells a client their model has quietly drifted. It is the least glamorous work in the field and the highest leverage.

• Standing up training and serving infrastructure on the client's cloud, not ours
• Building drift and data quality monitoring that produces an actionable alert rather than noise
• Versioning data, code and model weights together so any prediction can be reproduced months later
• Making rollback a one command operation before it is ever needed

Data Engineer for AI readiness

Almost every engagement begins here, because the data is never in the shape the model needs. You build ingestion, cleaning, joining, lineage and quality checks across systems that were never designed to talk to each other. The role suits someone who finds a badly documented legacy schema interesting rather than infuriating, and who understands that fixing inputs usually moves the number more than changing the model.

• Designing pipelines that pull from ERP, CRM, warehouse and file systems into something usable
• Building data quality tests that fail loudly at ingestion rather than silently at inference
• Entity resolution across sources where the same customer appears four times with three spellings
• Documenting lineage well enough that an auditor can trace a number back to its source

AI Solutions Architect and AI Consultant

The role that decides whether an engagement should happen at all. You sit with a client, work out what is actually going wrong, assess whether the data supports a solution, and write the recommendation. Sometimes that recommendation is to buy a product or to fix a process first. This is a senior role because saying no credibly requires enough scar tissue to know what failure looks like early.

• Running assessments that end in a written verdict, including the verdict that no build is warranted
• Translating between a finance director's language and an engineering team's constraints
• Sizing and sequencing a programme so value arrives before patience runs out
• Reviewing architectures for cost, failure modes and the integration work everyone underestimates

NLP and LLM Engineer

Language work that goes beyond calling an API. Document extraction at scale, classification over messy text, entity recognition in domain specific vocabulary, summarisation with fidelity constraints, and fine tuning where a general model genuinely is not enough. A large part of the job is measurement, because language outputs are harder to score than a number and most teams do not try.

• Building extraction pipelines over contracts, claims, clinical notes or invoices
• Fine tuning and adapter training where a general model misses domain vocabulary
• Designing rubrics and automated judges that make language quality measurable
• Handling multilingual requirements without assuming English behaviour transfers

Computer Vision Engineer

Vision systems that run in physical environments rather than on clean benchmark data. Defect detection on a production line, object tracking in a warehouse, condition monitoring from drone or satellite imagery, and medical imaging support. The engineering challenge is rarely the model architecture. It is lighting, camera placement, class imbalance, edge deployment constraints and the twenty defect types that appear twice a year.

• Training detection and segmentation models on small, imbalanced client datasets
• Deploying to edge hardware with real latency and power budgets
• Designing the annotation process, including what to do when experts disagree
• Building the feedback loop that captures new failure cases from production

AI Governance and Compliance Specialist

A role that barely existed five years ago and is now a procurement requirement in regulated sectors. You build the evidence trail: model documentation, bias testing across protected groups, evaluation records, risk classification under the EU AI Act and comparable regimes, and the audit pack a regulator will ask for. It suits someone who is technical enough to read an evaluation report and rigorous enough to write the paperwork properly.

• Running fairness and bias audits with defensible methodology rather than a single metric
• Classifying systems by risk tier and mapping the obligations that follow
• Writing model cards and system documentation that survive external review
• Building the monitoring that demonstrates ongoing compliance, not compliance on one day

Conversational AI and AI Agent Developer

Systems that hold a conversation or take a sequence of actions on a user's behalf. The hard part is not the dialogue. It is the tool layer, the state handling, the escalation path to a human, and the boundary logic that stops an agent doing something expensive and wrong. Multi step agents compound errors, so most of the craft is in constraining, verifying and knowing when to stop.

• Designing tool interfaces and permission boundaries for agents that act on live systems
• Building escalation and handover so a customer reaches a person before they are angry
• Testing adversarially, because users will find the path you did not consider
• Instrumenting conversations so failure patterns are visible rather than anecdotal

AI Product Designer and AI Product Manager

Probabilistic systems break most interface conventions. This role decides how a user is shown confidence, how they correct a wrong answer, what happens when the system abstains, and how trust is built without overselling. It combines interface design with the product judgement to choose which problems are worth pointing a model at, and it works closely with whoever is building the evaluation.

• Designing review and correction flows that people actually use rather than bypass
• Communicating uncertainty without either hiding it or paralysing the user
• Prioritising the small set of use cases where the model is genuinely reliable
• Running usability sessions on systems whose output changes between runs

What working at iSpark is like

We are a remote company based in India serving clients worldwide, which produces a specific working culture. Some of it will suit you and some of it will not, so here it is plainly.

• Client work, not a product roadmap. You will work on several different problems a year across different industries. That variety is the attraction for some engineers and exhausting for others.
• Written by default. Decisions get written down. Long form writing is a core skill here, not an optional extra, because a remote team that does not write loses context within a week.
• An agreed overlap window. Hours are flexible around a fixed daily overlap with the team and, on some engagements, with a client in another timezone. The window is agreed up front and kept.
• You will talk to clients. Every role here involves explaining technical decisions to people who are not engineers. If you would rather never do that, this is the wrong firm.
• Shipping to production matters. The satisfaction here comes from systems that survive after handover, not from benchmark scores. Monitoring, documentation and tests are part of the job, not a chore at the end of it.

We will also say what we do not offer. We are not a research lab and you will not be publishing papers on company time. We do not run an internal platform team, so infrastructure work happens inside engagements on client clouds. And because the catalogue is broad, nobody here works on a single narrow specialism all year.

How to apply

There is no application form and no tracking system to disappear into. Write to hello@ispark.biz with the role that fits, a short note on why, and something we can actually look at. Something to look at means a repository, a written technical piece, a system you built and can describe in detail, or a project writeup that explains a decision you got wrong and what you changed.

What helps: specifics about a system you took to production, what broke, and what you did about it. What does not help: a list of frameworks, a summary of a tutorial project, or a cover letter that could have been addressed to any company. We read everything that arrives and we reply, including when the answer is no.