Frontend Engineering track

Frontend Engineering Intern

Flocci Workspaces · product team

workspaces.flocci.in
InternshipRemote (India)2 months~40 hrs/week2 openings
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 Frontend Engineering Intern position on Flocci Workspaces?

A two-month remote on-job training position on the frontend of Flocci Workspaces, a drag-and-resize dashboard whose widgets update in real time. You start by testing the layout, the touch behaviour and the realtime reconciliation, and after the gate you build and fix interface work in reviewed pull requests.

The role

What this posting actually is

Workspaces is one screen that contains almost every hard problem in frontend engineering. Widgets are dragged and resized on a grid, and the layout has to persist and come back exactly as it was left. Calendar, kanban, collections, pages, notes and meetings each render their own world inside a box whose size the user controls. Everything updates in real time, so the screen has to reconcile what you just did optimistically with what the server actually confirmed. And a cross-app My Day pulls today’s work in from other Flocci products.

Your first three weeks are testing, and on a frontend surface that means something specific. Does the layout survive a browser resize, a zoom, a reload, a second tab open on the same account? What does a widget show while it is loading, when it is empty, and when its request fails — and is any of those three states a lie? Does drag work with a finger as well as a mouse, and can somebody who cannot use a mouse at all move a widget with the keyboard? Does the theme hold in light mode, which is the default here, and in dark?

After the gate you build. Small, reviewed, and held to the house standard: existing CSS-variable tokens rather than hardcoded colours, every state designed rather than assumed, and no interaction shipped that only works on your laptop with a trackpad and fast internet.

The product team

The product you would join: Flocci Workspaces

Flocci Workspaces is a composable work dashboard where calendar, kanban, collections, pages, meetings and notes live as drag-and-resize widgets that update in real time.

Read the full Flocci Workspaces page

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

    Application testing on the interface itself

    You get a staging Workspaces, the requirement notes for the dashboard and widget behaviour, and a list of the devices we care about. You test the grid, the widgets, the realtime updates and the responsive behaviour, and you file what you find with the evidence a frontend defect needs — a screenshot, a viewport size, a browser, a recording where motion matters.

    What you produce

    • A state audit of every widget covering loading, empty and error, with a screenshot of each and a verdict on whether the state tells the truth.
    • A responsive and touch report across at least one phone, one tablet and one desktop viewport.
    • Reproducible defect reports on layout persistence and realtime reconciliation, including the two-tab conflict case.
    • A written list of the non-functional requirements a dashboard carries — interaction latency, frames during drag, first meaningful render — and what you measured.

  2. The gate — not everyone passes

    Phase 2Week 4

    The gate — explain what happens when a widget moves

    You walk an engineer through a drag: the pointer events, the state that changes locally, the request that persists the layout, the socket event other clients receive, and what the screen must do if that request fails after the widget already moved. Then you classify your defects functional or non-functional and defend each call.

    What you produce

    • An end-to-end account of one drag, including the optimistic update and its rollback path.
    • Your defects classified against functional and non-functional requirements, in your words.
    • A prediction of what degrades first on a board with many widgets and a busy socket, with reasoning.
    • The track decision for month two, told to you directly with reasons.
  3. Phase 3Weeks 5–8

    Build interface people use every morning

    On the codebase track you take real frontend issues in small reviewed pull requests, working within the existing token system and component primitives. Every change must hold in light and dark, on a phone and a desktop, and with the network throttled. On the testing track you own the interface test plan and run it before every release.

    What you produce

    • Merged, reviewed frontend commits in conventional-commit form, using existing design tokens.
    • Or an owned interface test plan covering states, responsiveness and accessibility, run at every release.
    • At least one widget state you designed and built that previously lied to the user.
    • A written closing review of your two months.

The work

What you will actually do

  • Test the dashboard grid the way real users abuse it: resize the browser mid-drag, zoom to 150%, reload, open a second tab on the same account, and confirm the layout persists and reconciles instead of quietly reverting.
  • Audit every widget for its three unglamorous states — loading, empty, error — and file each one that shows a spinner forever, an empty box with no explanation, or a message that is not true.
  • Test realtime reconciliation: make a change in one tab and watch it in another, then make conflicting changes in both and record what the screen decides.
  • Test touch and keyboard, not just mouse — drag and resize on a phone and a tablet, then try to move focus through a widget with only the keyboard and record where it gets trapped.
  • Profile a heavy board in DevTools and report what is actually costing frames — a re-render on every socket event, an image nobody sized, a list rendering four hundred rows nobody can see.
  • After the gate: build and fix real interface work in reviewed pull requests — a widget state, an accessible drag handle, a layout bug on a narrow screen — using the existing design tokens rather than new colours.

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 build a small React component and explain what re-renders it. Tutorial-level is fine; understanding is not optional.
  • Working HTML and CSS — flexbox and grid should not frighten you, and you should know why a z-index sometimes does nothing.
  • Browser DevTools: you can inspect an element, read the console and look at a network request without being walked through it.
  • Git basics: clone, branch, commit, push, open a pull request.
  • You are willing to spend the first three weeks testing the interface before you build anything in it.

Nice to have

  • You have used Tailwind, or any utility CSS, on something real.
  • You have implemented drag-and-drop once and remember why it was harder than expected.
  • You have opened the Performance or Lighthouse tab in DevTools on purpose.
  • You have any exposure to accessibility — a screen reader, keyboard navigation, contrast checking.
  • You have an opinion about a UI you use daily and can defend it with more than "it looks nice".

The stack

What you would be working with

  • React 18 + TypeScript (Vite)
  • Tailwind CSS with shadcn/ui primitives and CSS-variable design tokens — light mode is the default theme
  • A drag-and-resize dashboard grid with persisted layout
  • Socket.io client for live widget updates and optimistic-state reconciliation
  • react-hook-form with zod resolvers — the house form pattern
  • Chrome DevTools performance profiling and device emulation
  • Git with conventional commits, deployed to an OVHcloud VPS behind nginx

What you leave with

What you will learn that college does not teach

  • Why optimistic UI is a distributed-systems problem wearing a friendly costume, and what to do when the server disagrees with the screen.
  • How to design all the states — loading, empty, error, partial, offline — instead of only the one in the mockup.
  • What makes an interface slow in measurable terms, and how to prove a fix with a profile rather than a feeling.
  • How a design system holds a product together: tokens over hex codes, primitives over one-off components.
  • How frontend defects are classified — the difference between a layout that is wrong and a layout that is merely different from what you expected.

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, and access to a phone you can test on.
  • 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, any deployed thing you have built however small, and the two written answers below.
  2. A 20-minute screening call where we ask you to talk through an interface you built and what you would change now.
  3. A practical exercise: we send you a screenshot of one of our screens and ask you to list what is wrong with it on a phone, and what you would fix first.
  4. A conversation with the engineer who owns Workspaces 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 Frontend Engineering Intern position on Flocci Workspaces

2 openings · 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

Frontend Engineering Intern

Flocci Workspaces · closes 30 September 2026