HR & Behavioural Interview
In short: Use Present → Past → Future in 60–90 seconds.
- Example: "I'm a .NET developer with 5 years' experience in C#, ASP.NET Core, SQL Server and Azure.
- Currently I build payment reconciliation APIs at ABC, where I cut the nightly batch from 3 hours to 25 minutes by moving row-by-row processing to set-based T-SQL and parallel jobs.
- Earlier at XYZ I built SSIS/SSRS reporting for a banking client and set up Azure DevOps CI/CD.
- I'm looking for a role building cloud-native, high-scale services — which is why this Azure platform role interests me." Tailor the achievements to the job description.
In short: Connect three things: the role's needs, your proof, and your attitude.
- "You need someone who can build and run .NET services on Azure and improve performance.
- I've done exactly that — for example, I reduced API p95 latency by 60% with caching and query tuning, and I set up the CI/CD pipeline my team uses today.
- I also communicate well with business users, and I'm keen to keep learning, as my recent AZ-204 certification shows.
- I can contribute from the first month."
In short: Pick two or three that matter for the role and prove each with a short example.
- "First, problem-solving under pressure — I led the fix for a production payment outage within 40 minutes by isolating a failing dependency and switching to a fallback.
- Second, ownership — I don't stop at 'code complete'; I add monitoring and documentation.
- Third, learning quickly — I picked up Angular in a month to help our frontend team meet a release."
In short: Choose a real but manageable weakness and show improvement.
- "I used to find it hard to say no to extra requests, which once put a sprint commitment at risk.
- I've learned to make trade-offs visible: when a new request comes in, I ask my lead or product owner what should move out, and I track everything in Jira.
- Over the last three sprints we met all our commitments."
In short: Show research and fit: company → role → you.
- Mention the product/domain, something specific (tech stack, engineering culture, growth, customers), and how your experience matches.
- Avoid answers about salary only or "it's a big brand".
- Example: "Your platform serves banks across Asia, and I've spent three years on banking data systems.
- This role combines .NET microservices with Azure, which is where I want to grow, and your focus on automated testing matches how I work."
Stay positive and future-focused: "I've had a great learning experience and delivered X and Y, but the project has moved into maintenance, and I'm looking for larger-scale, cloud-native work and more ownership, which this role offers." Never criticise your employer, manager or colleagues, and keep it consistent with what's on LinkedIn and your resume.
In short: Show realistic ambition aligned with the company's path: "I see myself as a senior engineer or tech lead owning a product area's architecture, mentoring developers and working closely with business stakeholders, with deeper Azure architecture expertise.
- I'd like to grow into that here." Avoid "running my own startup" or "in your job".
In short: Summarise in four points: what they do (products/services and customers), scale or market position (from public sources), recent news (launch, expansion, acquisition, results), and the tech/culture aspects relevant to you.
- Then connect: "That's why this role appeals to me…".
- Only use facts you've verified — don't guess numbers.
In short: Answer honestly with any conditions: "Yes, I'm open to relocating to Hyderabad; I'd need about a month after my notice period to move.
- Could you tell me if relocation support is provided?" For shifts: "I'm fine with occasional on-call rotations and overlap with US hours a few days a week.
- Could you share how often night shifts are needed?"
In short: State it exactly and what flexibility exists: "My notice period is 60 days.
- My company allows buyout of part of it, so I could join in about 30–45 days if needed, and I'm finishing my handover documentation early to make that possible." Don't claim an immediate joining you can't deliver — background checks will confirm dates.
In short: STAR, showing empathy and resolution — not blame.
- "S: A senior QA and I disagreed on releasing a hotfix — he wanted a full regression; I worried about the client's outage.
- T: We needed a decision within the hour.
- A: I spoke with him privately, understood his concern about a past incident, and proposed a targeted regression of affected modules plus a rollback plan, then we presented both options to the lead together.
- R: We released in 90 minutes with no new defects; since then we keep a 'hotfix test checklist' we built together, and we work well."
In short: Choose a genuine mistake with low-to-moderate impact, own it, and show learning.
- "I once deployed a database migration that locked a large table during business hours, causing 10 minutes of slow responses.
- I rolled back immediately, informed my manager and the client, and redid it off-hours in batches.
- I then added a pre-deployment checklist for migrations — size checks, off-peak scheduling and a tested rollback script — and we haven't had a repeat."
In short: Use STAR with planning and communication.
- "When a client moved a release forward by two weeks, I prioritised by risk, automated repetitive validation with scripts, split tasks with two teammates, and gave daily status updates highlighting risks early.
- We delivered three days early with zero UAT defects." Emphasise calm prioritisation, not heroic overtime.
In short: Pick a professional achievement relevant to the role, with a measurable result and your personal contribution.
- "Re-architecting our report generation: reports took up to 20 minutes and often timed out.
- I profiled the queries, introduced pre-aggregated tables refreshed by SSIS, moved generation to a background queue with email delivery, and added caching.
- Average time dropped to under 30 seconds, and support tickets on reports fell by 80%."
In short: "I treat feedback as information to improve.
- I listen without being defensive, ask for specific examples, and agree on what to change.
- For example, my lead said my PRs were too large to review; I started splitting work into smaller PRs with clear descriptions.
- Review time dropped from days to hours, and I now give feedback to others the same way."
In short: "I first clarify impact and deadlines with stakeholders, then sort by urgency and importance (production issues and blockers first, then committed sprint work, then improvements).
- I break tasks into smaller pieces, track them in Jira, communicate early if something will slip, and ask my lead to arbitrate real conflicts rather than silently missing a deadline."
In short: Be specific and genuine: "Solving real problems for users and seeing measurable impact — like a report that used to take 20 minutes running in 30 seconds.
- I'm also motivated by learning new things, such as moving our services to containers, and by working with a team where people help each other."
In short: "Both have their place.
- I enjoy deep focused work on complex problems, but I deliver best in a team: design discussions, code reviews and pairing improve quality.
- In my current team I own the reporting module end to end and also review two colleagues' PRs daily."
In short: Show respectful disagreement backed by data, then commitment.
- "My manager wanted to add a feature directly into the monolith to meet a date; I was concerned about coupling.
- I wrote a one-page comparison of effort and risks and suggested a small separate module behind an interface.
- He agreed to a middle path: we shipped on time inside the monolith but behind the interface, and we extracted it later in two days.
- Once a decision is made, I fully support it."
Give concrete, recent examples: "I follow the .NET and Azure blogs and release notes, did the AZ-204 certification last year, build small side projects to try new features — recently Minimal APIs with .NET 10 and Azure Container Apps — and share learnings in our team's monthly tech talk."
In short: "Our team kept losing time on manual deployments.
- Although DevOps wasn't my role, I wrote a YAML pipeline in Azure DevOps for build, test and deployment to dev and QA, documented it and ran a session for the team.
- Deployment time went from 2 hours to 15 minutes and failed deployments dropped sharply.
- It was later adopted by two other teams."
In short: Be honest and professional: thank the first company, express genuine interest, and ask for a reasonable timeline to decide ("Could I confirm by next Friday?").
- Inform the second company that you have an offer and a deadline to see if they can speed up.
- Compare on role, learning, team, stability, compensation and location — not just salary.
- Once you accept, honour it; reneging after accepting damages your reputation (and in India some companies share data on offer drop-outs).
In short: Raise the concern immediately with facts: explain the risk, likely impact and evidence, and propose alternatives (a safer approach, a feature flag, a staged rollout, more testing).
- Put it in writing (email/ticket) so the decision is documented.
- If the manager still decides to proceed and it isn't unethical or illegal, execute it as safely as possible with monitoring and a rollback plan.
- If it's unethical or illegal (e.g. data privacy violation), escalate through proper channels.
In short: First talk to them privately and without blame — there may be a reason (overload, personal issues, unclear tasks).
- Offer help and agree on clear ownership and deadlines.
- Make work visible on the board.
- If nothing changes and delivery is at risk, raise it factually with the lead, focusing on the impact on the work rather than on the person.
In short: "First 30 days: learn the product, architecture, codebase, deployment process and people; fix small bugs to learn the workflow.
- 60 days: own a feature end to end, contribute to code reviews and on-call.
- 90 days: deliver a meaningful improvement — for example in performance, testing or tooling — and agree on goals with my manager." Adjust to the role and ask what they expect.