AI Engineering track

AI Engineering Intern

Flocci Intelligence · product team

InternshipRemote (India)2 months~40 hrs/week1 opening
Applications close
30 September 2026
Cohort
Next cohort begins October 2026
What you get
Certificate + merit bonus
How the two months run

What is the AI Engineering Intern position on Flocci Intelligence?

A two-month remote on-job training position on Flocci Intelligence, the shared metered AI layer behind every Flocci product. You start by testing it as a black box — outputs, failure modes, metering — and after the gate you work on the provider abstraction, the response schemas and the evaluation harness that decides whether a change is an improvement.

The role

What this posting actually is

Every AI feature across the Flocci estate — resume screening in Talent, grounded answers in Chat, the analysis lenses in Donna — calls one service. Intelligence exists so that AI behaves and bills the same way everywhere instead of each app inventing its own client, its own retry logic and its own idea of what a credit is worth. It is the least visible thing in the platform and the one with the widest blast radius.

This is also the posting where the gap between a demo and a product is most obvious. A prompt that works on your machine is not a feature. A feature is: what happens when the model returns explicit nulls where you expected strings; what happens when the response is valid JSON but the wrong shape; what happens when a request times out after the credit was already metered; what happens when a user pastes text into your product that contains instructions aimed at your model. DeepSeek in particular returns explicit null for unknown fields, which is why the response schemas here have to be written to expect it rather than to hope.

Your first three weeks are testing, and here that means building an evaluation set and running the service against it until you can describe its behaviour in sentences rather than impressions. After the gate you work inside it — schemas, the provider abstraction, idempotent metering, and the harness that lets someone prove a prompt change made things better rather than merely different.

The product team

The product you would join: Flocci Intelligence

Flocci Intelligence is the shared, metered AI layer every Flocci product calls, so AI behaves and bills the same way everywhere instead of each app inventing its own.

How the two months run

Testing first. Then a gate. Then the codebase.

Nobody is handed the codebase on day one, on any track. This is the arc for this posting specifically — the phases, the gate in week four, and what you produce in each.

  1. Phase 1Weeks 1–3

    Test the AI layer as a black box

    You get access to the service through a staging product surface, the requirement notes for one AI feature, and read access to the request and metering records. You probe it: good inputs, empty inputs, enormous inputs, adversarial inputs, and the same input twice. You write down what it does, not what you assume it does.

    What you produce

    • An evaluation set for one AI feature with a scoring method a second person could apply and reach the same conclusion.
    • A failure-mode catalogue: null fields, wrong shapes, timeouts, rate limits, truncation — each with the input that produced it.
    • A metering verification note showing what a duplicate and a failed request each charged.
    • A written list of the non-functional requirements a shared AI service carries — latency budget, timeout behaviour, cost per action, graceful degradation — and how you tested them.

  2. The gate — not everyone passes

    Phase 2Week 4

    The gate — explain a metered AI call

    You walk an engineer through one AI action end to end: the product surface, the gateway’s session check, the request the service builds, the provider call, the schema validation of the response, the credit metered and the row written. Then you classify your defects and explain how you would prove a prompt change is an improvement.

    What you produce

    • An end-to-end account of one metered AI call, including where it can fail and what each failure should cost the user.
    • Your defects classified as functional or non-functional, with the requirement named.
    • A written evaluation plan for a proposed prompt or schema change.
    • The track decision for month two, told to you directly with reasons.
  3. Phase 3Weeks 5–8

    Work inside the shared layer

    On the codebase track you make small, reviewed changes in the service — a schema that now handles the nulls you found, a retry path that cannot double-meter, an evaluation harness extended so the next person ships with evidence. Changes here touch every product, so review is strict and the reasoning goes in the pull request.

    What you produce

    • Merged, reviewed commits on the Intelligence service, each with its evaluation or reasoning stated in the pull request.
    • Or, on the testing track: an owned evaluation set run before every change to the answering path.
    • A failure-mode regression list the team keeps using.
    • A written closing review of your two months.

The work

What you will actually do

  • Build an evaluation set for one AI feature — real inputs, expected properties of a good output, and a way of scoring an answer that another person would score the same way.
  • Test the failure modes nobody demos: an explicit null where a string was expected, valid JSON in the wrong shape, a truncated response, a timeout, a rate limit, an upstream error mid-stream.
  • Verify metering is idempotent — that a retried or duplicated request charges the user’s credit wallet exactly once, and that a failed call does not charge at all.
  • Probe the boundary between user content and instructions: paste hostile text into a product surface and record whether it changes what the model was told to do.
  • Compare behaviour through the provider abstraction so that a swap of the underlying model is a configuration change and not a rewrite, and document every place that assumption currently does not hold.
  • After the gate: work in the service itself — tighten a response schema so nulls are handled rather than crashing, harden a retry path, or extend the evaluation harness so prompt changes ship with evidence.

Who this is for

What you need, and what simply helps

Requirements

  • You are in your 2nd, 3rd or 4th year of an engineering degree and can commit two continuous months, full-time and remote.
  • You can read and write JavaScript or TypeScript, and you understand what an async call and a promise rejection are.
  • You have called an HTTP API and handled its response and its error, in any language.
  • You can reason about data shapes — the difference between a missing field, an empty string and an explicit null is not a subtlety to you.
  • Enough scepticism to distrust a good-looking output and ask how you would measure it.
  • You are willing to spend the first three weeks testing the service before you change a line of it.

Nice to have

  • You have used an LLM API directly — the OpenAI SDK, or any other — rather than only a chat window.
  • You have used zod or any schema validation library.
  • You have thought about a retry and realised it might do the thing twice.
  • Any statistics — enough to know that two samples is not a result.
  • You have written a script that processed a few hundred records and had to handle the bad ones.

The stack

What you would be working with

  • Node.js + TypeScript services
  • DeepSeek through the OpenAI SDK behind a provider abstraction (baseURL swapped, not the code)
  • zod schemas written to survive explicit nulls — DeepSeek returns null for unknown fields, so nullable and optional are load-bearing
  • PostgreSQL for request records and metering
  • The Flocci Gateway — the only public door into the service — and per-action credit metering
  • An evaluation harness for prompt and response quality
  • Git with conventional commits, OVHcloud VPS behind nginx and pm2

What you leave with

What you will learn that college does not teach

  • How AI features are actually judged in production: an evaluation set, a scoring method, and a before-and-after — not a screenshot of one good answer.
  • Why idempotency matters most where money is involved, and how a retry becomes a double charge.
  • How to write schemas that expect the real world — explicit nulls, missing fields, wrong shapes — instead of the happy path in the documentation.
  • What a provider abstraction buys you, and what it costs when someone leaks a provider-specific assumption through it.
  • Where prompt injection actually enters a product, and why untrusted user content is untrusted even when it is polite.

Eligibility

Before you apply, check these

  • Enrolled in a full-time engineering programme at an Indian institution (B.E./B.Tech/M.Tech or an equivalent diploma).
  • Available for two continuous months, roughly 40 hours a week.
  • Remote from anywhere in India, with a connection stable enough for daily collaboration.
  • Your own laptop.
  • If this is a college-mandated OJT, your institution must accept an unpaid, remote industrial-training placement.

Selection

How we decide

Five steps, in this order. The written answers carry more weight than the resume.

  1. Apply with your resume, a GitHub link and the two written answers below. If you have ever called an AI API from code, link that first.
  2. A 20-minute screening call about how you would measure whether something got better.
  3. A practical exercise: we give you a prompt and five real outputs and ask you to define what "good" means here and score them.
  4. A conversation with the engineer who owns the Intelligence service about your exercise and the two months.
  5. Offer and joining letter, with the college paperwork attached.

Compensation

Certificate + merit bonus

A certificate of completion for every intern who finishes the programme.

Interns whose work clears an exceptional bar are considered for a completion bonus at the end of the two months. It is earned, not scheduled.

This is an unpaid industrial-training position

The programme

What we provide, and what we expect back

Identical on every posting — this is one programme with several tracks.

What we provide

  • A real product, not a sandbox: a live Flocci surface with real customers, its requirement notes, and a staging environment of your own to break.
  • A certificate of completion for every intern who finishes the two months, on either track.
  • Code review from the engineers who own the service — on your commits, and on your defect reports before that.
  • Access to the tooling that matters: the repositories, staging environments, the issue tracker, and read access to the databases you are testing against.
  • A weekly one-to-one where you are told plainly how you are doing, including when it is not going well.
  • A written closing review, and consideration for a completion bonus if your work clears an exceptional bar.

What we expect

  • Roughly 40 hours a week on the full-time track and roughly 20 on the part-time track, on a schedule agreed in writing before you start.
  • A daily written update: what you did, what you found, what is blocking you. Three lines is enough. Silence is not.
  • Defect reports another person can follow without asking you a single question.
  • That you use the product properly before you judge it, and read the requirement before you call something a bug.
  • Confidentiality. You will see customer data structures and unreleased work; it stays inside.
  • Honesty about what you do not know. It is the single fastest thing you can do for yourself here.

The bar

  • Show up. Two months is eight weeks and eight weeks is short. If you cannot make a day, say so before it starts, not after it has passed.
  • Reproduce it before you report it. A bug you saw once and cannot make happen again is a note to yourself, not a defect report.
  • Read first, then ask. The requirement, the existing code and the error message answer most questions. Ask once you have read all three and it still does not make sense — then ask immediately, not on Friday.
  • Do not ship code you cannot explain. If you cannot say why a line is there, it does not go in. Pasting a fix you do not understand is worse than saying you are stuck.
  • Write in plain sentences. Half of this work is being understood — in a defect report, a commit message, a stand-up note. Nobody here is impressed by long words.

For colleges

If this is your college's on-job training requirement

  • We issue the paperwork colleges normally ask for: a joining letter at the start of the two months and a completion certificate at the end, stating the dates, the track, the product worked on and the weekly hours.
  • Attendance and progress are recorded weekly. A college mentor or TPO can be named on the application — they will receive the joining confirmation, a mid-programme note and the completion certificate, and can write to us directly at workshop@flocci.in. If your institution needs a periodic report or a signed logbook in its own format, tell us in the application and we will keep our records in that shape.
  • The part-time track exists for exactly this situation: if your training window runs alongside a semester, send us your college schedule and the two months are structured around it.
  • What we will not do: promise a placement, backdate a certificate, or certify hours that were not worked. These are unpaid industrial-training positions — if your college requires a paid placement for the training to count, please check that before you apply.

The company

About Flocci Technologies

Flocci Technologies is an India-based, AI-native software company founded in 2023 and built in Ranchi, Jharkhand. It publishes a connected estate of software: 20 product surfaces — audience engagement, AI support, recruiting, sales, meetings, work apps — plus 8 full ERP and POS systems for hotels, schools, garages, libraries, marts, pharmacies and restaurants. It is priced in rupees, billed through PayU, and designed around how Indian businesses actually operate rather than translated from a US product.

The idea holding it together is called One Flocci: every product runs on the same shared layer instead of reinventing it. Identity handles sign-in, organisations, teams and roles once, for everything. Payments holds a single credit wallet you top up once and spend in any product. Intelligence is the shared, metered AI layer every app calls, so AI behaves and bills the same way everywhere. Graph is the cross-app event spine, carrying counts and metadata but never your content. Notifications is one delivery pipe for transactional email and one-time codes, and Gateway is the only public door in — it resolves the app, verifies the session and strips untrusted identity headers before anything reaches a service.

Flocci was founded by MD Afsar Hussain, who spent 10+ years as a senior engineer at SAP Labs India across S/4HANA, ABAP, Fiori and BTP before building this platform. He studied at BIT Mesra (B.Tech) and BITS Pilani (M.Tech), mentors 30+ startups and runs AI and coding workshops across India. That enterprise background shows up in how the estate is built — shared services, auditable rails, systems meant to survive being depended on — and it is why an internship here is run as engineering rather than as a workshop.

What that means for you as an intern: you will touch production code and production data structures used by real customers, not a training sandbox built for interns. The product you are assigned is live while you are testing it. When your commit merges, it gets deployed and somebody uses it. That is the appeal and it is also the reason for the gate in week four — real code carries real consequences, so we make sure you understand the system before you change it.

The facts

Company
Flocci Technologies — an India-based, AI-native software company
Founded
2023
Headquarters
Ranchi, Jharkhand, India
Founder
MD Afsar Hussain, Founder & CEO — 10+ years as a senior engineer at SAP Labs India
Scale
20 product surfaces and 8 ERP/POS systems on one shared platform
Platform
One account, one credit wallet and one AI layer across every product
Contact
workshop@flocci.in

The stack, across the estate

Frontend
Vite + React + TypeScript single-page apps, Tailwind and shadcn components
Backend
Node.js and Express services, with some Python/FastAPI
Database
PostgreSQL
Realtime
Socket.io — Flocci content features are realtime by default
AI
DeepSeek through the OpenAI SDK behind a provider abstraction, or through the shared Intelligence service
Payments
PayU, metered per action against one credit wallet
Infrastructure
Self-hosted OVHcloud VPS with nginx and pm2; sibling -ui and -srv repositories per product, conventional commits

Questions

Questions about this posting

Apply for the AI Engineering Intern position on Flocci Intelligence

1 opening · Remote (India) · Next cohort begins October 2026. Applications close 30 September 2026.

Elsewhere in the cohort

Other open roles

EngineeringSoftware Engineering InternFlocci Pulse · Ranchi, Jharkhand (Hybrid)View roleEngineeringSoftware Engineering InternFlocci Talent Suite · Remote (India)View roleEngineeringSoftware Engineering InternFlocci Schools Suite · Ranchi, Jharkhand (Hybrid)View role
See all 8 postings and how the programme works

AI Engineering Intern

Flocci Intelligence · closes 30 September 2026