Managerial round interview questions, with sample answers

"I'd tell my lead straight away, with facts: what's done, what's left, and how long the rest will take. Then I'd suggest options — delivering the core part tomorrow and the rest in a follow-up, getting another developer to help, or moving the date if the remaining part is essential. I'd put in the extra hours myself, but I wouldn't hide the gap and hope. Afterwards I'd look at why it happened — usually an estimate that missed something — and break my tasks into smaller pieces, so a slip shows up days earlier next time."

"I'd ask to discuss it one to one and bring evidence rather than opinion — for example, 'this query will scan the whole table once the data grows; here's the execution plan.' I'd listen to their reasons too, because they may know about constraints I don't. If they still decide the other way, I'd follow the decision and do it well, and suggest we note the risk in the ticket. I wouldn't argue in front of the client or keep reopening it."

"I'd talk to them first, privately, and ask how things are going — sometimes there's a reason, like being stuck on something or being overloaded. I'd offer help with whatever is blocking them, and agree on what each of us will deliver by when. If it continues and the deadline is at risk, I'd raise it with the lead, focusing on the work — 'these two tasks are behind' — rather than blaming the person."

"I'd look at the impact and the deadline of each: which one blocks a release, a client or other people. If it isn't clear, I'd ask my lead rather than guess, because they see the bigger picture. Then I'd tell whoever is waiting on the second task when they can expect it. If one of them is a five-minute fix, I'd often finish that first so it doesn't hang around."

"I'd own it immediately — tell my lead what happened and how many users or records are affected. Then I'd focus on fixing it or rolling it back, and check whether any data needs correcting. Once things are stable, I'd write a short note on the cause and add something that catches it next time: a test, a review checklist item or a validation. Hiding it, or blaming the tester, only makes the client trust us less."

"Changes are part of the job, so I wouldn't push back on the client myself. I'd make sure every change is written down — in the ticket or an email — along with what it affects, and tell my lead how it changes the timeline. My lead or the manager can then agree with the client whether it goes into this release or the next. In the code, I'd keep the parts that are likely to change flexible, for example using configuration instead of hard-coded rules."

"Yes. In college I learned [React] on my own in two weeks for a project, mostly from the official docs and small practice builds. On a new project I'd do the same: learn the basics quickly, read how the existing code uses it, and ask a teammate to review my first few changes. I'd also be honest about what I'm still learning, so my estimates stay realistic."

"I read the official documentation and release notes for the tools I use, solve a few problems a week on coding practice sites, and build small projects to try new things — recently [a small API with FastAPI]. I also read the engineering blogs of companies whose products I use. I try to learn by building rather than only watching videos."

"I'd skip the jargon and explain the effect and the fix. For example: 'The report is slow because it reads every order ever placed each time you open it. We're adding an index — like the index at the back of a book — so it can jump straight to this month's orders. It should load in two seconds instead of thirty.' Then I'd check they understood by asking what they need from it."

"I wouldn't make that call alone. I'd tell my lead early what can be done well by the deadline and what can't, so we can cut scope rather than quality — shipping fewer features that work is usually better than more features that break. If something has to ship with a known issue, it should be written down and fixed in the next release, not quietly left in."

"Understand before changing anything. I'd set up the project locally, read the documentation and follow the main flows through the code, then pick up small tasks or bug fixes to learn how things fit together. I'd save my questions and ask them in batches, so I'm not interrupting people every ten minutes, and keep notes so I never ask the same thing twice. By the end of the month I'd want to be delivering small changes on my own."

"I'd ask for specifics — which part, and what good looks like — and then fix it. During my internship, my first pull request came back with fifteen comments about naming and error handling. I went through each one, asked about the two I didn't understand, and my later pull requests needed far fewer changes. I treat review comments as free training."

"Yes, when the project needs it. I'd just try to make it the exception rather than the rule — flag risks early and not leave testing to the last day."

"Two days before our final-year project review, we didn't know whether the college server would allow a database connection from outside the campus. I couldn't get an answer in time, so I decided to run the database on the demo laptop and kept the cloud version as a backup. The demo worked. What I learned is to make a decision you can reverse quickly, note the risk, and tell the team why you chose it."

"Because I'm reliable with commitments and I raise problems early. In my internship I [finished every task I picked up in the sprint, and flagged an estimate that was too low on day two rather than day nine]. I write clearly, which matters with clients, and I learn quickly. Give me a well-defined first task and you'll see how I handle it."