Backend Intern

About the role

We build software that law firms and in-house legal teams rely on to do work that has real consequences if it goes wrong. That puts unusual weight on the backend: multi-tenant data that must stay isolated, document processing jobs that run for minutes rather than milliseconds, permission rules that mirror how legal teams actually share work, and audit trails that need to hold up under scrutiny.

We're looking for a third-year engineering student to join us as a Backend Developer Intern. You'll be writing code that ships — features, fixes, and improvements to the systems behind our products — alongside a small team where your work is reviewed carefully and your questions get answered properly.

This is not a shadowing role. You'll own scoped pieces of real work end to end, from understanding the problem to seeing it in production.

What you'll work on

• Product features — building API endpoints and the business logic behind them, integrating with what the frontend needs.
• Data modelling — designing schemas that represent how legal work actually happens, and evolving them safely once real data is in them.
• Background processing — long-running and scheduled jobs for document handling, notifications, and data pipelines, including the retry and failure behaviour that makes them trustworthy.
• Access control — authentication and fine-grained authorization across tenants, roles, and shared resources. Getting this wrong in legal software is not a small bug.
• Performance — finding and fixing the slow query, the N+1, the endpoint that falls over on a large document set.
• Reliability — tests that catch real regressions, and the debugging work of tracing a production error back to the line that caused it. ## What you'll do

Write and ship code

• Build features in Python and Django, exposed through our API layer (REST and GraphQL), with PostgreSQL underneath.
• Write reusable, testable code, and the tests that go with it — unit tests for logic, integration tests for the paths that matter.
• Move work that doesn't belong in a request cycle into background tasks with Celery, and reason about idempotency, retries, and what happens when a job fails halfway.
• Work through the ORM deliberately: understand the SQL your queries generate, and why the convenient version is sometimes the expensive one. Design before building
• Turn a loosely defined requirement into a concrete plan — data model, API shape, edge cases, and what could go wrong — and get feedback on it before writing the implementation.
• Write database migrations that are safe to run against a live system, and reversible when they aren't.
• Think about security and data protection as part of the design rather than a review checkbox: input validation, authorization at the right layer, and no leaking data across tenant boundaries. Collaborate
• Work in Git and GitHub the way the team does — small focused pull requests, useful descriptions, responsive to review, and green CI before merge.
• Give and take code review. Reading other people's code closely is one of the fastest ways to get better at writing your own.
• Coordinate with frontend engineers on API contracts, and with product on what the requirement actually means before you build to it. Debug and learn
• Investigate production errors and performance issues using logs, traces, and error reports, and follow them to the actual root cause rather than the first plausible one.
• Document what you built and what surprised you, so the next person doesn't rediscover it.
• Ask questions early. Two hours stuck is normal; two days silently stuck is not. ## What we're looking for

Core

• Currently in the third year of a B.E. or B.Tech programme.
• Solid Python. You're comfortable with functions, classes, modules, and error handling, and you can read code you didn't write.
• Working knowledge of relational databases and SQL — joins, indexes, and why a query might be slow.
• Understanding of how the web works: HTTP, requests and responses, status codes, and what an API actually is.
• Familiarity with Git, and at least basic experience collaborating through GitHub.
• Some experience building something that runs — a project, a college assignment taken past the deadline, a tool you wrote for yourself. What it is matters less than that you finished it.
• Clear communication. You can explain what your code does and what you're stuck on. Strong signals (not requirements)
• Experience with Django or another web framework, and with an ORM.
• Having written tests you weren't required to write.
• Exposure to background job processing, caching, or message queues.
• Understanding of authentication and authorization — sessions, tokens, roles, permissions.
• Familiarity with Docker, CI pipelines, or cloud platforms. You won't own infrastructure here, but knowing roughly how your code gets deployed helps.
• Open-source contributions, technical writing, or a project you can talk about in detail.
• Any exposure to the legal, compliance, or regulatory domain. How you work
• Self-starting and comfortable with ambiguity — requirements here are rarely fully specified up front.
• Detail-oriented. Backend bugs are quiet; they show up in someone's data weeks later.
• A team player with good time management, who communicates progress and blockers without being asked.
• Honest about what you don't know yet. We're hiring an intern, not someone pretending to be a senior engineer. ## How we'll evaluate you

Two stages. First, we send you a task — a scoped backend problem close to the kind of work you'd actually do here. Then a technical round, where we go through what you built: the choices you made, the ones you rejected, how you tested it, and how you'd extend it.

We care more about your reasoning than about whether every requirement was met. A clean, well-explained partial solution beats a complete one you can't defend.

If you have existing projects, send them along — a repository, a write-up, or a demo. Code we can read tells us more than a list of technologies.