Software engineer is the highest-volume role most Indian staffing agencies fill. Candidates are abundant; qualified candidates are not. In Bangalore, Hyderabad, Pune, or Gurgaon you will receive 200 CVs for a mid-level backend opening and maybe 12 will survive a 20-minute phone screen. The rest have the same five bullets — Java, Spring Boot, AWS, Agile, microservices — and none of that tells you whether the person shipped anything real. The difference between a senior who has owned a revenue-carrying service and one in the same WITCH maintenance seat for six years is almost never visible on the CV. Both list the same frameworks. One can walk you through a 2am production incident with specific log lines and the line of code they reverted. The other says "we had some issues once and the team fixed it." Every signal below is something we have seen separate the shortlist from the reject pile in real Talpro India screens.
Has shipped and maintained code in a live production environment with real users and on-call consequences. A bootcamp capstone or final-year college submission does not count. Ask for the URL, user count, and the year they owned it.
Three or more years of focused work in one core language (Java, Python, Go, Node, C#). Depth means they can explain why they chose a LinkedList over an ArrayList, or how Go goroutines behave under backpressure. Breadth across six languages with no depth is a pass.
Daily Git including branching, rebasing, non-trivial conflicts, and code review. Should whiteboard the workflow their last team used and describe one time a rebase went wrong. Candidates who only know commit and push are junior regardless of title.
Has consumed and built REST or GraphQL APIs in production. Understands auth patterns, idempotency, retry with backoff, rate limiting, pagination. Ask about the last third-party integration they debugged — payment gateway, SMS, WhatsApp Business — and what they did when the vendor sandbox lied.
Has diagnosed a production bug where the symptom was not the cause. Real engineers spend more time reading logs and narrowing hypotheses than writing code. If they cannot describe one debugging session longer than four hours with a specific resolution, they have not owned a real system at scale.
AWS, GCP, or Azure hands-on deployment — not "I uploaded files to S3 once." Deployed a service, configured IAM, set up alerts, handled a misconfigured security group. Table-stakes for most BFSI and product clients.
Docker for local development and reading-comfort with Kubernetes manifests. Should know what a pod, service, and ingress are, even if they have not personally run kubectl apply in production.
Writes unit and integration tests as part of the normal flow. Ask what percentage of their code last quarter had test coverage and how they decided. Strong engineers cite specific risk-based choices rather than blanket coverage dogma.
Public GitHub with real commits, a technical blog with recent posts, or meaningful Stack Overflow reputation. Indian engineers often skip this because of employer IP agreements — probe personal projects instead. Self-driven learning is the strongest predictor of a good hire.
Has reviewed juniors code, given internal tech talks, or run sessions. Useful signal above 5 years — at that level, coding alone does not justify the salary band.
Walk me through the most complex bug you have debugged in production in the last year. Symptom, investigation, root cause, fix.
What to listen for
Specific technical detail — the actual error message, log line, metric that spiked. Real investigation: metrics, logs, hypothesis, test, discard, retry. Mentions wrong turns honestly. Can tell you what they changed and how they verified. "We had a database issue and I fixed it" means they were in the room when someone else fixed it.
Tell me about a feature you owned end-to-end — spec through deploy. What trade-offs did you make and what did you consciously reject?
What to listen for
Real ownership means naming stakeholders, non-technical constraints (timeline, budget, compliance), and technical options they considered and rejected. Strong candidates describe something they wanted to do but could not, and what they would revisit. Weak candidates describe the feature as if it built itself.
How do you decide when to write a test and when to ship without one? Walk me through your last three decisions.
What to listen for
Pragmatic, risk-based. "I test anything that touches money, auth, or data I cannot easily reverse. I skip tests on throwaway admin tooling." Engineers who insist on 100% coverage have not shipped under deadline. Engineers who skip all tests are juniors regardless of YOE.
Describe a time you strongly disagreed with a technical decision your team made. What did you do after the decision was finalized?
What to listen for
Disagree-and-commit. Raised concerns in writing, escalated once, then executed. Red flag: "I quit" or "I stopped caring." Worst flag: executed the plan while subtly sabotaging it to prove they were right. Senior engineers at WITCH firms learn this pattern; test for it.
How do you stay current with new technology in your stack? Name the last three things you learned and why.
What to listen for
Specific sources — Hacker News, named newsletters (Pointer, Bytes), specific podcasts, Discord or Slack communities. Generic "I read blogs" or "YouTube" without a named source is yellow flag. Bonus for Indian tech communities — Bangalore meetups, GDG events, Pragmatic Engineer subscribers.
What is the worst code you have ever shipped to production and why did you ship it?
What to listen for
Honesty with context. A strong candidate will laugh, then describe a hacky cron job they wrote at 2am to patch data corruption, and how they came back later to rewrite it. "I have never shipped bad code" is disqualifying — they have not shipped enough code.
You join a codebase on day one with no documentation. Walk me through the first three days.
What to listen for
Finding entry points (main.go, index.ts, the route file), running it locally, drawing a rough dependency graph on paper, reading the last 50 commit messages, asking specific people specific questions rather than "how does this work." Avoids the trap of reading every file.
What feedback last year changed how you work? Who gave it, what was it, what did you change.
What to listen for
Specific feedback from a specific person followed by a specific behavior change. "My manager told me my PRs were too large, so I now open draft PRs at 200 lines for early feedback" is strong. Vague "I work on my communication" means they are reciting interview prep.
Score each candidate against these weighted criteria. Total: 100%.
| Criterion | Weight | Signal |
|---|---|---|
| Production ownership depth | 30% | Multi-year ownership of a service with real users. Names specific production incidents with timestamps and resolutions. Mentions deploys, rollbacks, on-call shifts without prompting. |
| Technical communication | 25% | Explains a technical decision and its trade-offs to a non-engineer in two sentences. Writes clear commit messages and PR descriptions (ask them to show one). |
| Code quality habits | 20% | Writes tests as part of normal flow without being asked. Active in code review, both giving and receiving. Has refactored their own code after learning something. |
| Learning velocity | 15% | Specific examples of technology learned in the last 6 months. Public contributions or meaningful community activity. Can describe a tool they evaluated and rejected. |
| Collaboration | 10% | Disagree-and-commit examples. Has mentored a junior or contributed documentation. Speaks about teammates by name and contribution, not as "the team." |
Six or more years at one employer with no role, team, or project change — likely maintenance of one codebase the whole time
CV lists 12 or more frameworks with no project proving depth in any — classic WITCH bench-optimized CV
Cannot describe a single production incident in five minutes of open-ended prompting, even at 5+ YOE
Job hops every 8 to 10 months across three or more employers in the last four years — usually culture-fit or performance issues
Refuses any take-home, paired coding, or live debug exercise citing "I do not do tests" — overconfidence or hiding a real gap
Upload Software Engineer CVs and let AI score every candidate against the same 42-point evidence rubric.
Try CVPRO Free