If you learn about the AI job market from videos and course ads, you end up with a particular picture of it: prompt engineering as the defining skill, fine-tuning as the serious next step, and a new agent framework to learn every month. If you learn about it by reading job descriptions on Indian hiring platforms, you get a noticeably different picture. Python everywhere. SQL far more often than anyone mentions. Docker showing up more reliably than most machine learning frameworks. And prompt engineering as one line in a list, not the point of the job.
That gap — between what gets discussed and what gets written into an actual requisition — is what this article is about.
About this article: This is a qualitative pattern analysis based on reading AI job descriptions across Indian hiring platforms, not a formal study. I haven't run a counted survey, so you won't find percentages here — I don't have numbers I could stand behind, and inventing them would defeat the purpose. What you'll find instead are patterns described in tiers, with an honest note wherever I'm less sure. The method section sets out how to run the count properly yourself, which I'd genuinely recommend for the specific roles you're targeting.
Table of Contents
- Why job postings beat advice videos
- How to read a job posting properly
- The skill tiers: what actually recurs
- Five things that surprised me
- Skills the internet overhypes
- Skills companies quietly want
- Skills by job role
- Skills by experience level
- Startup vs enterprise hiring
- City-wise hiring patterns
- What freshers should learn first
- Resume mistakes, seen from the other side
- What one ideal AI portfolio looks like
- Run the analysis yourself
- What will probably change by 2027
- Where this kind of reading falls short
- Frequently asked questions
- Final takeaways
Why Job Postings Matter More Than Advice Videos
A job description is a flawed document. It's often written by a recruiter who isn't an engineer, copied partly from the last requisition, and padded with things nobody will actually test you on. Everyone who has read a few hundred of them knows this.
But it has one property no advice video, roadmap infographic or course landing page has: somebody at the company had to approve it before money was allocated to the role. It's an imperfect record of a real budget decision. When a company writes "experience deploying models to production," it's usually because they have models that aren't in production and it's costing them something.
Compare the incentives elsewhere. A course platform benefits from you believing the skill it teaches is essential. A creator benefits from covering whatever is trending this month, because that's what gets watched. Neither is necessarily dishonest — but neither is measuring anything about employer demand.
There's a second reason postings are useful, and it's subtler. What a company chooses not to mention is informative too. When generative AI postings ask for vector search but decline to name a specific database, that tells you those companies don't consider the choice important enough to filter candidates on. Absence is data.
Key insight: Advice tells you what's exciting. Job postings tell you what's budgeted. When the two disagree, follow the budget.
How to Read a Job Posting Properly
Most people skim the bullet list at the bottom and stop. That's where the least reliable information lives, because bullet lists are the part most often copied forward from an old requisition.
The responsibilities paragraph is more honest. It's usually written closer to the hiring manager and describes what the person will actually spend their days doing. When a posting's bullets mention six frameworks but the responsibilities paragraph talks only about data pipelines and stakeholder reports, believe the paragraph.
A few reading habits that make this much more productive:
- Separate "required" from "good to have." Many postings blur these deliberately. The required block is the filter; the rest is a wish list, and treating a wish list as a barrier is how good candidates talk themselves out of applying.
- Notice unnamed capabilities. "Experience with modern deep learning frameworks" and "familiarity with retrieval-based architectures" are requirements without brand names. They're often the most honest lines in the document.
- Watch for oddly specific negatives. Phrases like "beyond notebook experimentation" or "not just tutorial projects" aren't filler. Somebody wrote those after a bad hiring round.
- Check the aggregator against the careers page. LinkedIn, Naukri, Indeed and Wellfound all truncate long requirement sections. The company's own posting is frequently fuller and occasionally quite different.
- Discount stale reposts. The same role reposted for months usually means either an unrealistic requirement list or a role nobody is urgently filling.
The Skill Tiers: What Actually Recurs
Rather than fake precision, here's how the landscape sorts into tiers. "Near-universal" means I'd be surprised to see a relevant posting without it. "Rare" means I've seen it, but infrequently enough that I wouldn't plan around it.
| Tier | Skills | What it means for you |
|---|---|---|
| Near-universal | Python, SQL, machine learning fundamentals, Git | Entry conditions, not differentiators. Missing any one is a hard filter. |
| Very common | REST APIs, Docker, a cloud platform, PyTorch, deep learning, pandas/NumPy, communication | The band most candidates underweight, especially the infrastructure half. |
| Common, role-dependent | LLM APIs, RAG, MLOps, statistics, scikit-learn, NLP, CI/CD, DSA | Heavily concentrated by title. Match these to the role, not the field. |
| Occasional | LangChain/LlamaIndex, vector databases, Kubernetes, TensorFlow, Hugging Face, FastAPI, prompt engineering, fine-tuning, computer vision | Worth knowing, rarely worth specialising in early. |
| Emerging | Model evaluation, guardrails, agent frameworks, inference cost awareness | Small today, described in unusually precise language. Watch this band. |
| Rare | Full-parameter fine-tuning, AutoML platforms, blockchain + AI | Don't build a preparation plan around these. |
A few of these placements deserve explanation.
Python being near-universal is a confirmation rather than a finding, but the exceptions are interesting. They tend to be C++ research roles, or analytics-adjacent positions built around SQL and a BI tool where "AI" is in the title more for recruiting reasons than technical ones.
SQL is the placement I'd most want people to notice. It's easy to assume it's a data science concern. It isn't — it recurs in machine learning engineering and in generative AI work too, because the documents and records you're building a retrieval system over usually live in a database that someone has to query properly.
Communication sits in the "very common" tier and I nearly demoted it as boilerplate. What kept it there is how specific the phrasing often is. "Ability to explain model limitations to business stakeholders" is not a generic sentence.
MLOps sits in a lower tier than its importance warrants, because when it appears it's usually a hard requirement rather than a preference. Smaller slice of postings, non-negotiable within that slice.
Five Things That Surprised Me
1. Prompt engineering is a technique, not a job
Standalone prompt engineer roles exist, but they're uncommon and cluster at companies whose product is itself an AI writing or content tool. Everywhere else, prompting sits inside a list that also requires Python, API design and deployment. The implicit message across a lot of postings is: of course you can prompt a model, that's not what we're paying for.
2. Traditional software engineering hasn't gone anywhere
Put REST APIs, Docker, Git and CI/CD together and a picture emerges that looks a lot like a backend engineering job with models attached. Startup postings in particular often spend more words on service reliability and API design than on modelling. This is probably the most actionable pattern here, and the one least reflected in AI course curricula.
3. Cloud is table stakes, not a bonus
A couple of years ago I'd have expected cloud experience to sit under "preferred." It now frequently appears in the required block, and enterprise postings increasingly name specific managed services rather than just the platform.
4. Nobody agrees on vector databases
Postings that want vector search name a scattered set of products between them, and a substantial share name none at all — just "experience with vector stores." That's an unusually clear signal that the category matters and the specific tool doesn't.
5. Evaluation is quietly becoming its own skill
Still a small band, but the phrasing is strikingly consistent and detailed: building eval sets, measuring hallucination rates, regression testing prompts, setting up guardrails. Low frequency combined with precise language usually indicates an emerging requirement rather than a fading one.
Surprising finding: Docker shows up more reliably across AI postings than TensorFlow, LangChain or prompt engineering do. The unglamorous infrastructure skill outranks all three of the things people build course playlists around.
Skills the Internet Overhypes
"Overhyped" here doesn't mean useless. It means the attention a skill gets online is disproportionate to how often employers ask for it. Some are genuinely valuable and simply early.
| Skill / topic | How often it appears | Why it appears less than expected |
|---|---|---|
| Prompt libraries and templates | Rare | Treated as a working habit, not a hireable competency |
| Multi-agent frameworks | Occasional, exploratory | Few teams run them in production yet |
| Specific exotic vector DBs | Fragmented | Companies expect you to learn theirs on the job |
| Full fine-tuning of large models | Rare | Expensive; retrieval solves most problems more cheaply |
| Blockchain + AI | Effectively absent | Not part of mainstream hiring |
| Building AI "wrappers" | Not a stated skill | Employers describe the product problem, not the pattern |
| AutoML platforms | Rare | Used internally, seldom a hiring criterion |
Agent frameworks are the entry most likely to move. Where they appear, the language is noticeably forward-looking — "explore," "prototype," "evaluate feasibility." That's what a skill looks like a year or two before it becomes a requirement. If the area interests you, work on it. Just don't build your entire preparation around it while skipping Docker.
Fine-tuning is the one that surprised me most in this group. Online it's discussed as the serious engineer's alternative to prompting. In postings, it's comparatively uncommon, and where the technique is specified it's usually a parameter-efficient approach mentioned as one option alongside retrieval. Companies are choosing the cheaper, more reversible path, which is what companies do.
Skills Companies Quietly Want
Some of the most consistently useful things aren't in bullet lists at all. They're embedded in responsibilities paragraphs, where nobody thinks to look.
Linux and the command line. Named outright less often than you'd think, but implied by nearly every posting that mentions deployment, containers or cloud instances. If you've only ever worked in a notebook, this is a real gap and a cheap one to close.
Debugging. Rarely a bullet point, but phrases like "troubleshoot model performance issues in production" recur. Debugging a model that's technically running but producing worse outputs than last month is a distinct skill from debugging a crash, and almost nothing in a typical course prepares you for it.
API integration. Not just building APIs — consuming other people's, handling rate limits, retries, timeouts and partial failures. Any role involving a hosted model provider requires this and very few spell it out.
Documentation. Appears far more often in enterprise postings than startup ones. Someone in those organisations has clearly inherited an undocumented pipeline and hasn't recovered.
Reading papers. Confined to research and applied-research roles, and worth noting the phrasing: many ask for the ability to "implement techniques from recent literature," which is a much higher bar than reading. It means going from a paper to working code.
Testing. Mentioned less often than I'd expect, which I find concerning rather than reassuring. It suggests testing culture around ML code is still thin in a lot of places — which also makes it an easy way to stand out.
Career tip: The skills nobody puts in the bullet list are the ones you can differentiate on. Everyone applying has Python. Very few can show a tested, containerised, documented service running on a Linux box.
Skills by Job Role
Aggregate impressions flatten real differences. Broken down by title, the landscape looks like this.
| Role | Core skills | Distinctive requirement | Rarely asked |
|---|---|---|---|
| AI / ML Intern | Python, basic ML, Git, one project | Evidence of building something end to end | Cloud, MLOps, production experience |
| ML Engineer | Python, SQL, PyTorch/TF, Docker, cloud | Getting models into production and keeping them there | Paper implementation, research depth |
| GenAI / LLM Engineer | Python, LLM APIs, RAG, vector search, APIs | Retrieval quality and evaluation | Classical ML, statistics |
| Data Scientist | Python, SQL, statistics, scikit-learn, communication | Turning analysis into a business decision | Kubernetes, low-level deployment |
| Applied AI Engineer | Python, APIs, cloud, product sense | Shipping user-facing AI features | Novel model development |
| AI Research Engineer | PyTorch, transformers, mathematics, papers | Implementing and extending published methods | Business communication, dashboards |
| Prompt Engineer | LLM behaviour, evaluation, domain writing | Systematic testing of prompt variations | Deep programming, infrastructure |
The clearest divide runs between data scientist and GenAI engineer. Data science postings are built on statistics, experimentation and stakeholder communication. GenAI postings barely mention statistics and instead read like backend engineering with a retrieval layer. These are two genuinely different careers grouped under one hype cycle, and a lot of confused preparation comes from not noticing that.
The prompt engineer row is the least reliable in the table, simply because there are so few such postings to read.
Skills by Experience Level
| Level | What's actually required | What's listed as "good to have" | What decides the outcome |
|---|---|---|---|
| Internship | Python, ML fundamentals, willingness to learn | Frameworks, cloud, LLM exposure | One finished project you can explain |
| Fresher (0–1 yr) | Python, SQL, Git, ML basics, a deployed project | Docker, a cloud platform, LLM tooling | Whether the project is real or a tutorial |
| 1–3 years | The above plus APIs, Docker, cloud, one deep area | Kubernetes, MLOps tooling, domain knowledge | Evidence you shipped something people used |
| Senior (4+ yrs) | System design, MLOps, cost and latency awareness, mentoring | Specific vendor certifications | Judgement about what not to build |
Reading across the levels, the technology list barely grows after the two-year mark — but the framing changes completely. Junior postings list tools. Senior postings list outcomes: "reduce inference cost," "own the model lifecycle," "define evaluation standards." Nobody asks a senior candidate whether they know pandas.
Worth naming separately: the 1–3 year band is where the most postings sit, and it's also where postings are most demanding relative to the experience asked for. Plenty want two years of experience alongside production deployment, cloud, and LLM work — a combination that barely existed two years ago. That mismatch is real, and it isn't your fault if you feel unqualified reading them.
Startup vs Enterprise Hiring
| Dimension | Startups | Enterprises & MNCs |
|---|---|---|
| Ideal candidate | Generalist who ships | Specialist who fits a defined slot |
| Skill list length | Shorter, broader | Longer, more specific |
| LLM frameworks | Common (LangChain, LlamaIndex) | Less common; often internal platforms |
| Serving stack | FastAPI mentioned frequently | Rarely named; internal standards apply |
| Cloud | "Cloud experience," platform-agnostic | Named platform, often Azure or AWS |
| MLOps & CI/CD | Implied, rarely formalised | Explicit, frequently required |
| Governance & compliance | Almost never mentioned | Regularly mentioned |
| Documentation & testing | Occasional | Common |
| Degree requirements | Loose | Stricter, sometimes non-negotiable |
Startup postings tend to be shorter and more honest about ambiguity. A representative one asks for "someone comfortable owning a feature from idea to production, including the parts that aren't AI." That's an accurate description of the job and it filters well.
Enterprise postings run longer and more procedural, and a meaningful share mention governance, model risk, audit trails or data privacy — things startup postings essentially never raise. If that work interests you, and some people genuinely prefer it, it's a less crowded lane than the GenAI startup track where every fresher is currently pointed. I've written more about how the entry-level end of this market has shifted in this piece on what changed for entry-level AI jobs.
City-wise Hiring Patterns
| City | Relative volume | Dominant character | Over-indexed skills |
|---|---|---|---|
| Bangalore | Highest by a wide margin | Startups + product companies | LLMs, RAG, FastAPI, AWS |
| Hyderabad | High | Global capability centres | Azure, MLOps, data platforms |
| Delhi NCR | High | Mixed; services + product | NLP, analytics, SQL |
| Pune | Moderate | Enterprise engineering | Kubernetes, CI/CD |
| Chennai | Moderate | Services + manufacturing | Computer vision, classical ML |
| Mumbai | Moderate | BFSI-heavy | Statistics, governance, SQL |
| Ahmedabad / other | Lower | Small product firms | Generalist full-stack AI |
Two patterns stand out. Bangalore isn't just bigger — it's differently shaped, with the most LLM tooling and the least governance language. And cities with strong banking or manufacturing sectors produce noticeably more traditional postings: statistics, computer vision, classical models. If you're targeting Chennai or Mumbai specifically, an all-GenAI preparation plan may fit worse than national commentary would suggest.
What Freshers Should Actually Learn First
This sequence isn't ordered by what's interesting. It's ordered by how consistently each thing appears in entry-level postings, and by how much later material depends on it.
| # | Learn | Why here | Rough time |
|---|---|---|---|
| 1 | Python (properly) | Near-universal; everything else assumes it | 2–3 months |
| 2 | Git | Near-universal, and a weekend's work | 1 week |
| 3 | SQL | The most underrated common requirement | 3–4 weeks |
| 4 | Machine learning fundamentals | Needed to reason about any model | 2–3 months |
| 5 | Deep learning + PyTorch | Opens NLP and vision roles | 2 months |
| 6 | LLM basics and APIs | The growth area | 3–4 weeks |
| 7 | RAG and embeddings | Default architecture in GenAI roles | 1 month |
| 8 | APIs + Docker | Where most freshers stop short | 1 month |
| 9 | One cloud platform | Now closer to required than preferred | 1 month |
| 10 | Two or three real projects | What every level of posting implies | Ongoing |
The sequence matters more than the timings, which vary enormously by starting point and available hours. Git sits at number two despite being unglamorous because it costs a week and appears nearly everywhere — nothing else on the list has that ratio.
Deployment sits at eight rather than last because the gap between candidates who have deployed something and candidates who haven't is the most consistently implied filter at every experience level. A model in a notebook is coursework. A model behind an endpoint is a job.
Resume Mistakes Seen From the Other Side
Reading job descriptions closely does something odd: you start to see the resumes they were written in response to. The oddly specific lines are scar tissue.
Listing forty tools. Postings that ask for "depth in at least one area" or "strong fundamentals over broad tool familiarity" exist because people send resumes listing every library they've ever imported. Breadth without depth reads as unverifiable.
No deployed work. The recurrence of deployment, Docker and API requirements is the loudest pattern in this whole area, and it's the one most missing from typical fresher resumes. If nothing you've built runs anywhere, you're missing the thing employers ask for most.
Buzzword density. Postings asking candidates to describe a project's "measurable impact" or "your specific contribution" indicate someone receiving a lot of resumes full of nouns and no verbs.
Weak or absent GitHub. Requests for a portfolio link are more common than requirements for a specific degree class. That ratio should tell you where to spend your next weekend.
Certificates as the main evidence. Course certificates almost never appear as a requirement. They aren't harmful, but they occupy resume space a project description would use better.
Recruiter observation: When a job description contains an unusually specific negative — "not just tutorial projects," "beyond notebook experimentation" — it isn't filler. Somebody wrote that sentence after a bad hiring round.
What One Ideal AI Portfolio Looks Like
Reverse-engineered purely from what postings ask for, an ideal portfolio contains three projects and nothing else.
Project one: a retrieval system over real documents. Not a demo over three PDFs — something with enough content that retrieval quality actually varies, with a written evaluation of how you measured it and what failed. This single project touches Python, embeddings, vector search, RAG, an API layer and evaluation: most of the fastest-rising items in the landscape.
Project two: a classical ML model in production. A real dataset, honest feature engineering, a documented metric choice, and an endpoint someone can call. Boring on purpose. It proves you understand the part of the job that predates the current cycle, which most enterprise roles are still built on.
Project three: something small you actually use. A script, a bot, a scheduled job. Its purpose is to prove the habit of finishing and shipping, and it gives you something genuine to talk about.
Around all three: a Dockerfile, a README that states the problem and the limitations, a handful of tests, and a live link with credentials so nobody has to clone anything. That wrapper is the difference between a project and evidence. I've gone deeper into the distinction in this analysis of portfolio projects that got interviews.
Run the Analysis Yourself
Everything above is pattern recognition across a lot of casual reading. If you want actual numbers for the specific roles you're targeting — which will serve you better than anyone's general article — the count is very doable in a weekend. Here's a method that holds up.
1. Fix your sample before you start. Decide on a number (fifty is plenty), the titles you'll include, and the cities. Deciding as you go lets you unconsciously pick postings that confirm what you already believe.
2. Spread across titles deliberately. If you take whatever appears first on one platform, your results mostly describe whichever title happened to be hiring that fortnight.
3. Pull from several sources. LinkedIn, Naukri, Indeed and Wellfound surface different companies, and careers pages carry the fullest text. Check the careers page whenever an aggregator listing looks truncated.
4. De-duplicate. The same role appears across platforms constantly. Keep the version with the fullest requirements text and drop the rest, or your counts will double-weight whoever posts most widely.
5. Write your coding rules down first. Does "containerisation" count as Docker? Does a posting describing retrieval pipelines without the acronym count as RAG? There's no single right answer, but you must apply the same answer to posting fifty as to posting one.
6. Count once per posting, and track required vs preferred separately. Counting mentions rather than postings lets one verbose description dominate. And a skill in the "good to have" block is a different fact from one in the required block — collapsing them inflates everything.
7. Report your sample size next to every number. "Eight of fifty" is honest. "16%" implies a precision fifty postings can't support.
If you do run it, the results are worth charting. A horizontal bar chart of skill frequency, sorted descending and colour-coded by category (language, framework, infrastructure, cloud, LLM tooling, soft skill), makes the infrastructure-versus-framework story visible immediately. A heatmap of skills against roles shows the data-science-versus-GenAI split as dark diagonal blocks. And a slope chart connecting each skill's "required" share to its "preferred" share separates the real filters from the wish list.
What Will Probably Change by 2027
Forecasts, not predictions I'd bet money on. Job posting language is a lagging indicator of what teams are already doing.
Evaluation becomes a named requirement. Currently a small band described in unusually precise language — the classic profile of a skill on its way up. Companies that shipped LLM features in 2025 and 2026 now have to prove those features work.
Governance moves down-market. Currently concentrated in enterprises. As regulation and procurement requirements tighten, mid-sized companies will likely start naming it too.
Cost and latency awareness enters senior descriptions. Some senior postings already mention inference cost. Once AI features run at scale, the person who can halve the token bill becomes very valuable.
Agent frameworks graduate from "explore" to "build." The exploratory language will probably firm up. Whether today's specific frameworks survive is another question entirely.
"AI engineer" and "backend engineer" converge further. Already visible, and I expect it to continue — good news for anyone with software fundamentals, mildly bad news for anyone who skipped them.
Security appears more often. Prompt injection, data leakage and access control barely register today. Given how these systems are being deployed, that seems unlikely to hold.
Where This Kind of Reading Falls Short
Being clear about this matters more to me than the analysis looking authoritative.
This is pattern recognition, not measurement. I've described tiers rather than percentages because tiers are what unstructured reading honestly supports. Anyone quoting precise figures for a market this fragmented should be asked how they counted.
Hiring is seasonal and cyclical. The picture during campus season differs from the picture after a funding wave or a round of layoffs.
Postings describe wishes, not tests. A skill in a description doesn't guarantee it'll be assessed, and plenty of interviews test things nobody wrote down.
My reading is skewed by what I look at. I read more product and startup postings than services ones. That almost certainly colours the impressions above.
This is about hiring in India, which is not the same as hiring in AI generally.
Use this to prioritise your learning. Don't use it to argue with a recruiter.
Frequently Asked Questions
Which AI skill appears most often in Indian job postings?
Python, and it's not close. It's named in very nearly every AI, machine learning and data science posting in the Indian market, across every seniority level. The rare exceptions tend to be C++ research roles or analytics positions written entirely around SQL and a BI tool. The practical implication is that Python isn't a differentiator on a resume, it's the entry condition, and the things that actually separate candidates sit on top of it.
Is Prompt Engineering enough to get an AI job in India?
On its own, no. Prompt engineering does appear in job descriptions, but it's almost always one line inside a much longer list that also demands Python, API development and deployment experience. Standalone prompt engineer roles exist but are rare, and tend to be at companies whose product is itself an AI writing or content tool. Prompting is generally treated as a working technique any engineer on an LLM team will pick up, not as a job description of its own.
Should I learn LangChain for AI jobs?
It's worth knowing but not worth specialising in. LangChain and LlamaIndex show up regularly in generative AI and LLM engineer postings, and are noticeably more common in startup listings than enterprise ones. Learn enough to build and debug a retrieval pipeline, then move on. Plenty of postings describe the underlying capability — chunking, retrieval, orchestration — without naming any framework at all, which suggests employers care more about the concept than the specific library.
Do companies actually require RAG skills?
In generative AI roles, increasingly yes. Retrieval-augmented generation has become the default architecture for putting a language model on top of company data, so it appears in a large share of GenAI and LLM engineer postings even when it isn't named with that acronym. Understanding chunking strategy, embeddings, retrieval quality and evaluation matters considerably more than knowing any single vector database product.
How important is SQL for AI jobs in India?
More important than most candidates expect, and it's usually the second most requested skill after Python. It's near-universal in data science roles, but it also appears in a large share of machine learning engineer postings and in plenty of generative AI ones, because the data being fed to models generally lives in a relational database that someone has to query properly. It's one of the cheapest skills to reach a useful level in and one of the most consistently requested.
Is TensorFlow still relevant in 2026 hiring?
It's still requested, but it's clearly the second choice. PyTorch appears more often and, where both are named, is usually listed first. TensorFlow retains a stronger presence in large enterprises and in roles maintaining existing production systems, which makes sense because those systems were built years ago. If you're starting now and have to pick one, PyTorch is the safer bet, though the underlying concepts transfer either way.
Do startups care about AWS, Azure or GCP experience?
They care about deployment more than they care about a specific cloud. Most AI postings in India name at least one cloud platform. AWS leads overall, Azure has a strong bias towards large enterprises and global capability centres, and GCP appears third. Startup postings are more likely to use loose phrasing like "experience deploying to cloud infrastructure," while enterprise postings tend to name a specific platform and sometimes specific managed services.
Should I learn Docker for an AI role?
Yes, and it's one of the highest return-per-hour skills available. Docker appears in a large share of AI postings, often more consistently than individual machine learning frameworks do. It's also unusually cheap to learn relative to its weight in hiring, because a working understanding of containerising a Python service takes days rather than months. Kubernetes appears far less often and is concentrated in senior and platform-facing roles, so it can wait.
How much mathematics is expected for AI jobs in India?
Less than a research career requires and more than the tooling-first crowd suggests. Explicit references to statistics, probability or linear algebra cluster heavily in data science and research titles. Applied and generative AI roles rarely demand formal mathematics. However, many postings ask for evaluation and experimentation skills such as A/B testing, metric design and error analysis, which are statistics under a different name — so the requirement is often present even when the word isn't.
Do I need a vector database on my resume?
Knowing the concept matters, knowing a specific product matters much less. Vector search appears regularly in generative AI postings, but the named products are scattered across many different tools with no clear market winner, and a good share of postings name no product at all. That fragmentation is itself the signal. Employers want someone who understands embeddings, similarity search and index tradeoffs, and expect that person to learn whichever database the team already runs within a week.
What AI skills do freshers need for entry-level jobs in India?
The consistent core across entry-level postings is Python, SQL, Git, foundational machine learning, and at least one finished project that runs somewhere other than a laptop. Deep learning frameworks and LLM tooling appear but are more often listed as good to have than as hard requirements. The clearest pattern is that entry-level postings ask for evidence of building and finishing something rather than a long list of technologies.
Is Git really necessary for AI and machine learning roles?
It's named in a majority of postings and safely assumed in the rest. Version control appears in descriptions for interns, engineers and data scientists alike, often bundled with phrases about collaborative development or code review. It's the clearest example of a skill that carries no glamour, takes a weekend to learn properly, and quietly disqualifies candidates who have never used it beyond pushing to a personal repository.
Are MLOps skills in demand in India?
Yes, and the demand is skewed towards experience. MLOps — and the responsibilities that make it up: model deployment, monitoring, retraining pipelines, CI/CD for models — appears regularly but almost entirely in roles asking for two or more years of experience. For a fresher it isn't a realistic starting point. For someone with a couple of years of software or data experience, it's one of the strongest differentiators available in this market.
Do AI job postings ask for communication skills?
Far more often than candidates assume, and in data science roles it's close to standard. Requirements around explaining results to non-technical stakeholders, writing documentation and presenting findings appear throughout. This is easy to dismiss as boilerplate, but the phrasing is often too specific for that — lines about translating model outputs into business decisions, or explaining model limitations to stakeholders. Sentences that precise usually reflect a real and repeatedly disappointed expectation.
Should I learn fine-tuning of large language models?
It's worth understanding, but it's requested less often than online discussion implies. Where fine-tuning does appear it's usually a parameter-efficient method mentioned alongside retrieval as an alternative approach, rather than full-parameter training. Most companies are solving their problems with retrieval and prompting first because those are cheaper, faster to iterate on and easier to reverse when requirements change.
Which Indian city has the most AI job openings?
Bangalore leads by a wide margin, followed by Hyderabad and Delhi NCR including Noida and Gurgaon, then Pune, Chennai and Mumbai. The composition matters as much as the volume. Bangalore skews heavily towards startups and generative AI work, Hyderabad and Pune lean towards enterprise and platform roles with more emphasis on cloud and MLOps, and cities with strong banking or manufacturing sectors produce more classical machine learning and computer vision roles.
Is a master's degree required for AI jobs in India?
Not in most postings. A postgraduate degree appears as a hard requirement mainly in research engineer roles and some enterprise data science positions. The far more common phrasing is a bachelor's degree in a related field with a preference for advanced qualifications. Requests for demonstrable project and deployment experience are more frequent than strict degree requirements — a question I looked at separately in this piece on whether a master's is worth it for AI jobs in India.
How often do postings mention data structures and algorithms?
Often enough to matter, and much more in postings from large companies with structured interview processes than in startup listings. DSA in this market is less a description of the daily work and more a description of the screening round you'll have to pass to reach the daily work. Prepare for it as an interview skill rather than a job skill, and don't let it crowd out building things.
Final Takeaways
Compressed into a few sentences:
The base is boring and non-negotiable. Python, SQL, Git. Three skills, in nearly every posting, none exciting enough to make a thumbnail. Get these genuinely solid before anything else and you'll clear a filter that eliminates a surprising number of applicants.
Deployment is the real dividing line. Docker, APIs and cloud together recur more reliably than any modelling framework. The candidate who can put something behind an endpoint competes in a much smaller pool than the candidate who can train a model in a notebook.
The hype is directionally right and specifically wrong. LLMs, RAG and vector search are genuinely growing. But they're growing as one layer on top of ordinary software engineering, not as a replacement for it. Postings are unambiguous about this and the internet mostly isn't.
Match your preparation to the role, not the field. Data science and GenAI engineering share a hype cycle and almost nothing else. Preparing for both simultaneously is how people end up shallow in each.
Do your own reading. Twenty postings for the specific roles you want, read properly, will tell you more about your target than any general article — including this one. It takes an evening.
The thing that strikes me most, having read a lot of these, is how ordinary the picture is. You'd expect the documents to describe a strange new profession. Mostly they describe software engineering with a new and rapidly improving set of tools bolted on, and companies looking for people who can use those tools without breaking everything else.
The fastest way to prepare for an AI career isn't by chasing every new framework. It's by paying attention to what employers consistently ask for, and building practical skills that show you can solve real problems.