Say you have two very different phone calls coming: one from an IT services company hiring GenAI engineers for client projects, one from a product company building its own AI features. People will tell you the first is "easier" and the second is "all system design." Both claims are mostly folklore. This post gives you a hedged comparison of how the loops may differ, a way to find out what your loop looks like, and a prep plan that works for either.
First, what I could and could not verify. On 2026-10-09 I tried to read hiring-process pages from several large employers. TCS and Infosys career pages returned HTTP 403 to my fetch tool, Wipro's careers page redirected and held no process description, and the Google "how we hire" pages I could reach listed links without describing the interview format. I could read one primary source: Anthropic's candidate guidance on AI use, quoted below. So nothing here describes a named company's actual loop. I include no leaked questions and no hiring statistics, because I have none I can cite. What follows is a framework, labelled as such, built from role differences that are logical consequences of the business model.
What actually differs between service and product company GenAI loops?
Treat this table as hypotheses to test with your recruiter, not facts about any firm. Individual teams at either type vary widely.
| Dimension | Service company (typical hypothesis) | Product company (typical hypothesis) |
|---|---|---|
| What the work is | Delivering GenAI solutions to client requirements, often across varied domains | Building and maintaining one product's AI features over years |
| Likely emphasis | Breadth, quick prototyping, delivery, client communication | Depth in one area, system ownership, quality over time |
| Questions that follow from this | "How would you scope this for a client?", "What do you do when requirements change?" | "How do you know it works?", "What breaks at scale?" |
| Project discussion | Your role, tools you used, what you delivered, how you handled a stakeholder | Your design decisions, evaluation, a failure and the fix |
| System design | May be lighter or scenario-based | More likely to be a dedicated design round |
| Coding | Common, with varying depth | Common, with varying depth |
| Evaluation thinking | Valued, often when asked about delivery risk | Often probed hard because the team owns quality long-term |
The reasoning behind these guesses: a services business sells delivery across many clients, so a candidate who can adapt, communicate and ship matters. A product business lives with its own system, so how it is evaluated, monitored and debugged matters. Plausible, not proven. Some service-company teams run deep technical rounds, and some product teams hire for narrow roles with little design content.
For how the largest Indian IT services firms are positioning AI platforms internally, which gives context on the kind of work, see TCS, Infosys and Wipro AI internal tools. That post covers the tools, not the interviews.
How do I find out what my loop will be?
Ask. Recruiters will often share the structure even when they will not share questions, though some won't. Send this after your first call (adapt the wording):
Thanks for the update. To prepare well, could you share:
1. How many rounds there are and the format of each (coding, project
discussion, design, managerial, HR)?
2. How long each round is?
3. Whether the technical rounds are about a specific domain (for
example retrieval and evaluation, or agents) or general?
4. Whether I may use any tools or reference material in each round,
including AI assistants?
5. Whether there is a take-home or live coding component?
6. What the role's day-to-day work looks like in the first six months?
Question 4 matters. As one published example, Anthropic's candidate AI guidance (read 2026-10-09 via a summarising fetch, so check the page for exact wording) says (the page shows "last updated Jul 10, 2025") candidates may use AI for preparation, should write application drafts themselves before refining with Claude, should not use AI on take-home assessments unless the task permits it, and should not use AI in live interviews unless told otherwise. That is one employer's policy and says nothing about service or product companies in general. The point is that policies are explicit, differ by round, and are yours to ask about. Do not assume.
Prep plan for a service-style loop
If the recruiter's answers suggest a delivery-focused role (client projects, mixed domains), weight your time like this. The split is a suggestion, not a measured optimum.
- Breadth of the basics. Be able to explain prompting, RAG, function calling, structured outputs and evaluation at a practical level. The AI engineer question list covers the ground.
- A project told as delivery. Problem, constraints, what you scoped out, how you handled a change request, what you handed over. If you have no client experience, use an internal or personal project and describe it as if for a client.
- Scoping answers. Practise turning a vague ask into questions and a phased plan. Prompt for practice (untested template):
You are a client who runs a [type of business] and wants "an AI
chatbot for our customers". Answer my questions briefly and vaguely,
as a real client would. After 10 questions, ask me for a one-page
plan with phases, risks and what you will NOT build in phase 1.
Then tell me which assumptions in my plan I never confirmed with you.
- Communication under change. Prepare a sentence for "the client now wants it in Hindi and Tamil" or "legal says we can't send this data to a cloud API". The translation quality checklist and tokenizer cost across Indian languages give you real material for the first.
- Risk language. Know how to say what could go wrong: hallucination, data leakage, cost. See what not to paste into ChatGPT.
Prep plan for a product-style loop
If the answers suggest a design round, a deep project discussion or an evaluation focus:
- One system, known to the bone. Chunk size, eval results, a failure. Use how to explain a RAG project.
- A design round. Practise the 45-minute structure in the LLM system design walkthrough.
- Evaluation fluency. Be ready to separate retrieval from generation errors, justify a metric and describe regression gating.
- Cost and latency numbers. Use the method in cost per 1000 requests.
- Run a full mock. The score sheet script has a design block and a technical probe block.
What both loops probably test
Whatever the company type, a few things are hard to fake and reasonable to expect:
- Clarity about what you personally built versus what the team did.
- Honest handling of what you do not know.
- Awareness that LLM output is variable and must be checked.
- Basic coding and data handling competence, in whatever language the role uses.
- Reasoning about safety and data handling when the data is not yours.
If your project reads well on all five, you are covered for most variants. Back it with a repo whose README matches your story; the README template shows how.
Decision table: where to spend the next three days
| Your situation | Spend most time on |
|---|---|
| No work project, applying to services roles | A personal project told as delivery, plus basics breadth |
| Backend or QA background, applying to product roles | Evaluation and failure stories, plus a design walkthrough |
| Applying to both | One project, two tellings (delivery and engineering) |
| Recruiter said "design round" | Timed design practice, twice |
| Recruiter said "project discussion only" | Project story and follow-up drills |
| Unsure what the loop is | Send the six questions above first |
Things to avoid
- Buying or memorising a company's "actual questions". Accuracy is unverifiable, such lists go stale, and using material an employer treats as confidential can breach terms you agreed to. Practise skills.
- Choosing a loop by reputation. The role description and the recruiter's answers say more than the company's category.
- Inflating a project. Service panels and product panels both ask "what exactly did you do".
- Assuming AI use is allowed. Ask, per round.
If you are planning a path into these roles, the AI engineering roadmap for SDETs and backend developers covers skill sequencing. Salary and offer comparisons are a separate question; see prompt engineering salary in India for that, and treat any single figure as a range to verify.
