“Software Engineer” is the least specific title on Indian job boards. It can mean payment services at a product company, an insurer’s claims system on a services project, or a bit of everything at a fifteen-person startup. This guide shows how to tell which job a posting means, what each level must own, and how generalist interview loops are built, so you prepare for the rounds that decide offers.
Inside a software engineer’s week
At a product company or GCC, a software engineer works in a small team, usually with a product manager and an engineering manager, that owns one slice of a product: checkout, search ranking, a partner API, the tool finance uses to close the books. Work arrives as sprint tickets, yet reading code, reviewing, debugging and agreeing interfaces with other teams take more of the week than most candidates expect.
A realistic week, two or three years in:
- Monday: planning, then questioning a vague ticket (“let customers edit an order after placing it”) until you know what happens to payment, delivery slot and stock.
- Tuesday: a one-page design note for a new table and an API change, reviewed before much code exists.
- Wednesday and Thursday: implementation, tests, and reviews of three teammates’ pull requests.
- Friday: a release behind a feature flag, an hour watching error rates, and a fix for the flaky test failing everyone’s builds.
Two roles get confused with this one. A backend developer posting usually names a stack and expects depth in it from week one; a software engineer posting, especially at a product company or GCC, hires for fundamentals and expects you to work in whatever the team owns, a Go service this quarter and a React admin page the next. A full stack developer posting explicitly asks for browser and server work. A “Software Engineer” posting that lists only Spring Boot and Oracle is a backend role with a generic title.
Skills that interview panels test, and the ones that set you apart
Generalist loops test a small core heavily and treat the rest as evidence of range.
| Skill | Core or differentiator | Why panels care |
|---|---|---|
| One language in depth (Java, Python, C++, Go or TypeScript) | Core | Every coding round uses it, so know its collections, error handling and concurrency tools without searching. |
| Data structures and algorithms | Core | The usual first filter at product companies and GCCs. Panels want the right structure and its cost explained, not a recited solution. |
| SQL and one relational database | Core | Most services sit on a database, and slow queries are a routine source of production trouble. |
| Object-oriented and low-level design | Core from about two years | Shows whether your code will survive the next three requirements. |
| System design, caching and queues (Redis, Kafka) | Differentiator early, core later | Needed once you own services rather than tickets. |
| Cloud, Docker, Kubernetes, CI/CD | Differentiator | Teams deploying their own services value someone who can read a failing pipeline. |
| Observability (logs, metrics, traces) | Differentiator | The difference between guessing and knowing during an incident. |
Writing belongs here too: design notes, pull request descriptions and incident write-ups are how engineers beyond SDE I get noticed.
SDE levels, titles and what each one is expected to own
Titles do not transfer cleanly between Indian employers, so compare scope rather than words.
- 0–2 years (SDE I or Associate Software Engineer). You deliver well-defined tasks with review, write tests unprompted, and need less help each month. Freshers are judged on DSA, CS fundamentals (operating systems, DBMS, networks, OOP) and proof that they finish things.
- 3–5 years (SDE II, or Senior Software Engineer at some firms). You own a feature or service end to end: design note, rollout, on-call follow-ups. You review usefully and unblock interns. Interviews add low-level design and usually a first system design round.
- 6+ years (SDE III or Senior, then Staff and Principal). You own problems that span services or teams, make trade-offs explicit, and reduce work for others. Staff is a different job from senior, judged on influence across teams rather than tenure.
Employer type changes what the title means. Product companies run SDE I/II/III or Engineer, Senior, Staff ladders, usually with written expectations, and promote on evidence of next-level scope. Services companies use grade-based designations (Software Engineer, Senior Software Engineer, Technical Lead, Architect): the grade sets pay band and allocation, the client project decides your work, and bench time between projects is normal. Startups flatten or inflate titles, so panels probe whether a three-year “Senior Engineer” has more ownership than an SDE II or less depth. GCCs generally follow the parent company’s global levels, often with some overlap with colleagues’ working hours abroad.
Code review, testing and on-call: the expectations nobody lists
Postings say “ownership”; in practice it means habits that senior interviewers ask about directly.
- Reviewable pull requests. Small enough to review in one sitting, with the why in the description and refactoring kept apart from behaviour changes.
- Reviews that catch things. Comment on correctness, failure handling and naming, and let a formatter settle style. Approving everything within two minutes gets noticed, and not as a compliment.
- Tests that protect behaviour. Unit tests for logic, integration tests where code meets a database or another service, and a regression test for every bug you fix. Tests written only to lift a coverage number protect nothing.
- On-call. Product teams commonly rotate weekly. Acknowledge the alert, mitigate first (roll back, switch off the flag), find the cause second, then write a short blameless review whose follow-ups actually get scheduled.
If your job has no on-call or review culture, say so and describe the nearest equivalent, such as production support or pre-release checks for a client.
How generalist SDE interview loops are put together
Product company and GCC loops usually combine these rounds:
| Round | What it tests | Where candidates slip |
|---|---|---|
| Online assessment | Two or three timed problems, sometimes with fundamentals MCQs | Passing the sample cases, then failing hidden edge cases |
| DSA interviews (one or two) | Solving out loud, working code, complexity analysis | Coding in silence, or never testing the code |
| Low-level design or machine coding | Classes, interfaces and runnable, extensible code in a fixed time | Beautiful class diagrams and no working program |
| System design (usually from three years) | Requirements, data model, scaling and failure handling | Naming technologies before stating requirements |
| Hiring manager or behavioural | Ownership, conflict, judgement, reasons for moving | Describing the team’s work with no clear personal role |
A recruiter call comes first (notice period, current and expected CTC, location). Services companies hire most freshers through campus drives or national aptitude tests, then technical and HR interviews; off-campus candidates usually reach product companies through referrals, hiring challenges or direct applications. Services laterals usually face one or two rounds on the project’s stack, sometimes plus a client interview. Startups vary most; some replace DSA with pairing on their own codebase.
Six questions that mirror real SDE rounds
Practise by pattern (sliding window, two pointers, BFS and DFS, heaps, binary search on the answer, dynamic programming), not by problem count. Italics show what the interviewer is watching.
- Given a stream of login events, return the k users with the most logins in the last hour. A hash map plus a heap, and how you expire old events.
- Implement a rate limiter allowing N requests per user per minute, then explain what breaks when it runs on five servers. The step from data structures to shared state and clock skew.
- Low-level design for an expense-sharing app that records group bills and proposes settle-up payments. Clean entities, a pluggable split strategy, and knowing that a greedy settle-up keeps payments few but not always minimal.
- Machine coding in 90 minutes: an in-memory cinema seat booking service where held seats expire. Runnable code, separated concerns, and correct behaviour when two users hold the same seat.
- System design: a notification service sending order updates by SMS, email and push that honours user preferences and survives a failing provider. Queues, idempotency, provider fallback, and what you would monitor.
- Walk me through a production incident you were part of, minute by minute. Whether you mitigated before debugging, and what changed afterwards.
In live rounds, restate the problem, give a brute-force approach and its cost, then improve it. Before declaring victory, trace your code by hand on an empty input and one awkward case.
Writing an SDE resume that survives a quick skim
A first-pass reader looks for what you owned, how hard it was, and what changed because of you. Name technologies where they did work, not only in a skills block. These three examples use invented numbers to show the shape of a strong claim; use your own.
- Example: “Owned order editing from design note to rollout across the order service (Java, PostgreSQL) and the support dashboard (React); shipped behind a feature flag in three sprints with no rollback.”
- Example: “Cut the team’s weekly on-call pages from about 15 to 4 by fixing the five noisiest alerts, adding retries to two flaky integrations and writing runbooks for the rest.”
- Example: “Split a 40-minute CI pipeline for a monorepo shared by six teams into cached, parallel stages, bringing typical runs under 12 minutes.”
Common mistakes, with fixes:
- “Involved in development, testing and deployment of modules.” That describes anyone; name the module, your part and the result.
- A skills wall of twenty technologies. List only what survives ten minutes of probing.
- Photo, date of birth and marital status. Product companies and GCCs do not need them; spend the space on projects.
- Every bullet says “we”. Panels will ask what you did, so write that.
Getting in, and growing past SDE II
For freshers and engineers leaving services work, a realistic path takes months, not weeks:
- One language, kept for every interview.
- DSA by pattern, a few problems a day, revisiting failures a week later.
- SQL properly: joins, indexes, transactions.
- One project with real constraints, then low-level design against a timer.
- From two or three years, system design: requirements and rough capacity numbers, then data model, then scaling.
Projects that draw follow-up questions:
- A caching proxy in front of a slow public API, with per-client rate limits, metrics, and a load test at ten times normal traffic.
- A small library or command-line tool that other people actually install, with tests, CI, versioned releases and a changelog.
- A merged fix to an open-source library you use. Reviewers can read the discussion, which says more than a certificate.
To grow past SDE II, take work with visible scope: write the design note, run the incident review, fix the alert that wakes everyone at 3 a.m. To specialise instead, see the backend developer, frontend developer and full stack developer guides.
Where to find software engineer roles, and a first-week checklist
Start with the live listings for Bengaluru, Hyderabad and Pune, then widen to all of India or remote roles. The market snapshot on those uHired pages ranks skills by how many recent postings mention them: a more current revision list than any general advice.
- Sort five postings you would accept into product, services, startup or GCC, and predict each one’s rounds.
- Rewrite your top three resume bullets to show ownership, difficulty and outcome.
- Do one timed low-level design exercise and one mock DSA round, talking throughout.
- Follow the four-week technical interview preparation plan; if you are leaving a services company, read the guide to switching to a product company or GCC.