Big Assets Infra Software Engineer Interview: Questions, Experience & Prep (2026)

Big Assets Infra is currently hiring for 13 Software Engineer roles, making it one of the more active recruiters to target in 2026. The company works in infrastructure and asset management, so expect interviews that test both your core coding skills and your ability to build reliable, scalable systems.

Candidates report a process that typically runs two to four rounds: an initial screening call, one or two technical rounds covering data structures and system design, and a final discussion with a senior engineer or hiring manager. The exact format can vary by team, so confirm the structure with your recruiter.

Salary bands for Software Engineers in India range from 6-12 LPA at the entry level (0-2 years) up to 40-65+ LPA for Lead or Staff engineers (10+ years), based on knok job radar data as of July 2026.

These are the types of questions candidates for a Software Engineer role at Big Assets Infra commonly encounter, based on the company domain and standard industry practice.

1. Walk me through your experience building or maintaining backend services. What stack did you use and what problems did you solve?
2. How would you design a system to track and update the status of thousands of infrastructure assets in real time?
3. Explain how you would handle database schema migrations without downtime in a production system.
4. Write a function to find the shortest path between two nodes in a weighted graph. Walk me through your approach.
5. How do you ensure the reliability and correctness of code you write? What does your testing strategy look like?
6. Describe a time you had to debug a hard-to-reproduce production issue. What was your process?
7. How would you design an API that multiple internal teams will consume? What do you prioritise?
8. What happens when a microservice goes down? How do you design the rest of the system to handle that gracefully?
9. Given a large list of transactions, how would you detect duplicate entries efficiently?
10. How do you approach performance optimisation? Walk us through a situation where you improved the speed or efficiency of a system.
11. How do you stay current with changes in your tech stack? Give a recent example of something new you learned and applied.
12. Tell me about a time you disagreed with a technical decision. How did you handle it?

Use the STAR method (Situation, Task, Action, Result) to keep your answers focused and concrete. Here are three examples tailored to the kinds of questions Big Assets Infra typically asks.

Q: Describe a time you improved the performance of a system.

*Situation:* Our team ran a nightly batch job that processed financial records. It was taking several hours to complete and occasionally timing out before it finished.

*Task:* I was asked to investigate and reduce the runtime so the job finished well within the nightly window.

*Action:* I profiled the job and found that most of the time was spent on repeated database reads inside a loop. I refactored the code to fetch all required records in a single query, used in-memory caching for reference data, and parallelised independent processing steps.

*Result:* The job runtime dropped dramatically. It now completes reliably each night and the team has not had a timeout since the change went live.

---

Q: Tell me about a hard-to-reproduce bug you fixed.

*Situation:* Users of our platform occasionally reported that their session would expire unexpectedly, but we could not reproduce it in staging.

*Task:* I was the on-call engineer when the complaints peaked, so I owned the investigation.

*Action:* I added detailed structured logging around the session validation logic and deployed it to production. After a couple of days I had enough data to spot a race condition: when two requests arrived within milliseconds of each other, one could invalidate the session token before the other finished using it. I added a short-lived distributed lock around the critical section.

*Result:* The unexpected logouts stopped. I also wrote a load test that reliably triggered the race condition, so we added it to our CI suite to prevent regressions.

---

Q: Describe a time you disagreed with a technical decision.

*Situation:* My team proposed adding a third-party analytics SDK directly into our core API service, which I felt would add risk to a latency-sensitive path.

*Task:* I needed to raise my concern without blocking the team's progress.

*Action:* I put together a short document comparing two approaches: embedding the SDK versus publishing events to a queue and processing them asynchronously. I shared it before the design meeting so everyone had time to read it, then walked through the trade-offs in the meeting itself.

*Result:* The team agreed the async approach was safer. We shipped it that way, and the core API latency was not affected. The experience also led us to adopt a lightweight RFC process for decisions that touch shared services.

STAR for behavioural questions. Every story needs a Situation (context), Task (your responsibility), Action (what you specifically did), and Result (measurable outcome). Keep the Situation and Task brief so you spend most of your time on Action and Result.

Think-aloud for coding questions. Before writing a single line, state your understanding of the problem, your initial approach, and the time and space complexity you expect. Interviewers care as much about your reasoning as your final solution. If you get stuck, say so and talk through what you know.

Structure for system design questions. A reliable order: clarify requirements, estimate scale, identify the main components, explain data flow, discuss trade-offs, and finish with how you would monitor and operate the system in production. For an infrastructure company like Big Assets Infra, reliability and observability are likely to matter more than raw throughput.

Keep answers concise for culture and opinion questions. A two-minute answer with a clear point of view is better than a five-minute answer that hedges everything. Interviewers remember candidates who have opinions and can back them up.

Big Assets Infra works in infrastructure, so interviewers are likely looking for engineers who treat reliability as a first-class concern, not an afterthought.

Solid fundamentals. Data structures, algorithms, and database design questions test whether you can build things that work correctly at scale. Brush up on graphs, trees, hash maps, and SQL query optimisation.

Systems thinking. Candidates who can explain not just 'what' but 'why' impress more. When asked to design something, talk about failure modes, consistency trade-offs, and how you would know if the system is healthy in production.

Ownership and follow-through. Stories that show you saw a problem to completion, including writing tests, monitoring, and documentation, signal that you are a low-maintenance team member.

Clear communication. Given that software engineers often work across teams, interviewers want to see that you can explain technical decisions to non-technical stakeholders and collaborate without friction.

Week 1: Coding fundamentals. Dedicate focused daily sessions to data structures and algorithms. Cover arrays, strings, trees, graphs, and dynamic programming. Pick a practice platform and aim for a mix of easy and medium problems. Time yourself so you get comfortable with interview pacing.

Week 2: System design. Study how to design systems like a URL shortener, a job queue, or a real-time status tracker (relevant to asset management). Practice drawing diagrams and explaining trade-offs out loud. Read about database indexing, caching strategies, and message queues.

Week 3: Behavioural preparation. Write out five to seven stories from your work history using the STAR format. Cover: a technical challenge, a conflict, a failure, a time you showed initiative, and a time you collaborated cross-functionally. Practice saying each one out loud until it flows naturally.

Before each round: Research what Big Assets Infra does in infrastructure and asset management. Review your resume so you can speak fluently about every project listed. Prepare two or three thoughtful questions for the interviewer about the team, the tech stack, or what success looks like in the first six months.

Knok checks 150+ job sites nightly, applies to jobs that match your resume, and messages HR on your behalf, so you can keep your applications moving while you focus on preparation.

Jumping into code without clarifying the problem. Interviewers often include ambiguity on purpose. Take a moment to ask about edge cases, input size, and expected output before you start coding.

Memorising solutions instead of understanding them. If you cannot explain why your approach works or how to adapt it, a single follow-up question will expose it. Understand the reasoning behind every pattern you study.

Vague STAR answers. Saying 'I improved performance' without saying by how much, or 'I worked with the team' without saying what you specifically did, wastes your chance to stand out. Be specific about your contribution and the outcome.

Ignoring the infrastructure angle. Big Assets Infra deals with assets and infrastructure at scale. If you only think about the happy path and never mention failure handling, retries, or monitoring, you may come across as someone who has not built systems that need to stay up.

Not asking questions. Candidates who ask zero questions often signal low interest. Prepare at least two genuine questions and ask them at the end of each round.