Why structured technical interviews outperform ad-hoc questioning
The most common technical interview format in Indian companies is the "deep dive into the resume" — the interviewer picks technologies from the candidate’s resume and asks increasingly obscure questions about them. This approach tests trivia knowledge, not engineering ability. A candidate who has memorised the documentation for React hooks but cannot design a clean component architecture looks strong in this format. A candidate with deep architectural experience who has not memorised specific API signatures looks weak. Structured technical interviews fix this by asking every candidate the same questions designed to assess specific competencies — problem-solving, system design, coding fluency, debugging ability, and technology judgment — rather than random knowledge checks. The 25 questions below are organised by competency area. For each, we explain what the question assesses and what a strong answer looks like. These questions work across the Indian developer hiring landscape, from early-career to senior roles, with appropriate calibration of expected depth.
A critical principle for Indian hiring managers: evaluate the quality of thinking, not the speed of response. The Indian education system rewards fast, memorised answers (the "first to raise hand" culture). In engineering, the candidate who pauses to think, asks clarifying questions, and works through the problem methodically is often stronger than the one who immediately recites a textbook solution. Give candidates time. A 30-second silence while a candidate thinks is awkward but productive. Resist the urge to fill the silence with hints. Workro’s AI-powered interview module generates role-specific technical questions calibrated to the job description and seniority level, with scoring rubrics that focus on problem-solving approach rather than trivia recall, ensuring a consistent evaluation standard across all candidates.
Problem-solving and algorithms (Questions 1-6)
These questions assess core computer science fundamentals and analytical thinking. Question 1: "Given a large log file that does not fit in memory, how would you find the 10 most frequent IP addresses?" What it assesses: ability to handle scale constraints, knowledge of data structures (heap, hash map), and external sorting or map-reduce thinking. A strong answer describes chunking the file, counting frequencies per chunk, merging with a min-heap of size 10, and discusses the time and space complexity trade-offs. Question 2: "Design a URL shortener like bit.ly. Walk me through the data model, API design, and how you would handle 100 million writes per day." What it assesses: system design fundamentals, database choices (relational vs NoSQL), hashing vs counter-based approaches, and scalability thinking. A strong answer discusses the trade-off between auto-increment IDs (predictable, sequential) and hashed URLs (unpredictable, distributed-friendly), and covers caching, rate limiting, and analytics.
Question 3: "Explain how you would implement a rate limiter for an API that handles 10,000 requests per second. What algorithm would you use and why?" What it assesses: practical system design, algorithm selection (token bucket, sliding window, fixed window), and understanding of distributed systems challenges. Question 4: "You have two very large sorted arrays. Write code to find their intersection. Then, how would your approach change if one array is much smaller than the other?" What it assesses: coding fluency, understanding of binary search vs two-pointer techniques, and the ability to adapt solutions to data characteristics. Question 5: "Describe the most challenging bug you have debugged in production. What was your process, and what did you learn?" What it assesses: real-world debugging experience, systematic approach to troubleshooting, and intellectual honesty about mistakes. A strong answer describes a specific bug, the hypothesis-driven debugging process, the tools used (logging, monitoring, APM), and the preventative measures implemented afterward. Question 6: "Explain how garbage collection works in [language candidate uses]. How would you approach debugging a memory leak in a production application?" What it assesses: depth of understanding of language internals and production debugging skills.
System design and architecture (Questions 7-13)
Question 7: "Design a real-time chat application like WhatsApp. Focus on the backend architecture for message delivery, online/offline status, and group messaging." What it assesses: system design breadth, WebSocket vs polling decisions, message queuing, database schema design, and handling of edge cases (message ordering, delivery guarantees). A strong answer covers the full stack from client to server to database, discusses consistency vs availability trade-offs, and addresses scale considerations (sharding, CDN for media). Question 8: "How would you design a recommendation system for an e-commerce platform with 10 million products and 50 million users?" What it assesses: ML system design awareness, collaborative filtering vs content-based approaches, real-time vs batch processing, and cold start handling. The candidate need not be an ML expert — the question tests architectural thinking for data-intensive systems.
Question 9: "You need to migrate a monolithic application with 500,000 active users to a microservices architecture without downtime. How would you approach this?" What it assesses: practical migration strategy (strangler fig pattern), understanding of distributed systems challenges (data consistency, service discovery, monitoring), and risk management thinking. Question 10: "Explain eventual consistency to a product manager. When would you choose it over strong consistency?" What it assesses: ability to communicate technical concepts to non-technical stakeholders, and genuine understanding of consistency models (not just textbook definitions). Question 11: "Design the database schema for a multi-tenant SaaS application. How would you handle data isolation between tenants?" What it assesses: database design, tenant isolation strategies (separate databases vs shared database with tenant ID vs schema-per-tenant), and understanding of security and performance implications.
Question 12: "How would you implement search functionality for a product catalogue with faceted filtering (by price, brand, category, rating)? The catalogue has 5 million products." What it assesses: search architecture (Elasticsearch vs database full-text search), indexing strategy, and performance optimisation. Question 13: "Walk me through how you would handle a scenario where your primary database fails at 2 AM. The application is customer-facing and every minute of downtime costs revenue." What it assesses: disaster recovery planning, failover mechanisms, monitoring and alerting setup, and real-world operational maturity. Strong candidates describe a concrete plan including detection (how do you know it failed?), failover (automated vs manual, and the trade-offs), and post-mortem process.
Code quality and engineering practices (Questions 14-19)
Question 14: "Show me a piece of code you are proud of and walk me through why you made the design decisions you did." What it assesses: pride in craft, ability to articulate engineering decisions, and the quality standards the candidate holds themselves to. Question 15: "How do you approach code review? What do you look for, and how do you deliver feedback that might be difficult to receive?" What it assesses: collaboration skills, code review philosophy (catching bugs vs enforcing style vs knowledge sharing), and interpersonal communication ability. Question 16: "What does 'good testing' mean to you? How do you decide what to test, at what level (unit, integration, end-to-end), and what not to test?" What it assesses: testing philosophy, practical judgment (not dogmatic "100% coverage"), and understanding of the testing pyramid and its trade-offs.
Question 17: "Describe a technical decision you made that you later regretted. What would you do differently?" What it assesses: intellectual honesty, learning from mistakes, and depth of technical judgment. Question 18: "How do you stay current with technology? Give me an example of something you learned recently and applied to your work." What it assesses: continuous learning habits, practical application (not just consuming content), and intellectual curiosity. Question 19: "If you were the tech lead on a project and had to choose between building something quickly with known tech debt versus building it 'properly' with a longer timeline, how would you decide?" What it assesses: engineering pragmatism, ability to evaluate trade-offs, and communication with stakeholders about technical decisions. A strong answer does not default to "always build it properly" but describes a framework for evaluating the specific context: what is the cost of delay, what is the probability of needing to change this later, and how reversible is the decision.
Behavioural and situational (Questions 20-25)
Question 20: "Tell me about a time when you disagreed with a technical decision made by your team lead or architect. How did you handle it?" What it assesses: professional communication, constructive disagreement, and the ability to commit to decisions even when disagreeing. Question 21: "Describe a project where the requirements changed significantly after development had started. How did you adapt?" What it assesses: adaptability, communication with product managers, and ability to manage scope changes without becoming defensive. Question 22: "How do you mentor junior developers? Give me a specific example." What it assesses: leadership potential, teaching ability, and investment in team growth. Even for non-leadership roles, this reveals whether the candidate elevates their team or operates in isolation. Question 23: "Walk me through how you would estimate the effort for a complex feature you have never built before." What it assesses: estimation methodology (breaking down into smaller tasks, referencing similar past work, adding buffers for uncertainty), and honesty about the inherent inaccuracy of estimates.
Question 24: "What is the worst production incident you have been involved in? What happened, what was your role in the response, and what changed afterward?" What it assesses: crisis management, ownership and accountability, and learning from incidents. The "worst incident" question is particularly revealing because it shows how the candidate handles pressure and whether they focus on blame or improvement. Question 25: "If you joined our team, what would you want to change about our tech stack or engineering practices in the first 90 days, and how would you approach proposing those changes?" What it assesses: the candidate’s preparation (did they research the company’s tech stack?), diplomatic change management, and ability to balance improvement with respect for existing decisions. Strong candidates propose specific, reasonable changes while acknowledging that they do not have full context yet, and describe a collaborative approach to suggesting improvements. Workro’s AI interview module can generate role-specific variations of these questions and evaluate candidate responses against structured rubrics, giving hiring managers a consistent, objective basis for comparison. Conduct smarter technical interviews with Workro →