Sett Software Engineer Interview: Questions, Experience & Prep (2026)

Sett currently has 11 open software engineering roles, as tracked by knok jobradar in July 2026. Candidates report a process that typically includes an initial screening call, one or two technical rounds covering coding and system design, and a final round focused on culture and past experience. The company appears to value pragmatic engineering and collaborative problem-solving, though interview formats can vary by team and role.

If you are looking at the broader software engineering market, knok jobradar tracked 5,395 active SE roles across India as of July 2026, with Bangalore leading at 776 openings, followed by Hyderabad (157), Delhi (154), Pune (140), and Mumbai (72).

Candidates who have interviewed at Sett or similar product-focused companies typically report questions across three categories: technical depth, system thinking, and behavioural fit.

Technical and coding questions

1. Write a function to find the longest substring without repeating characters. Explain your time and space complexity.
2. Given a stream of transactions, how would you detect and deduplicate entries in real time?
3. How would you design a rate-limiting system for an API used by a large number of concurrent clients?
4. Walk me through how you would debug a service that is throwing intermittent server errors in production.
5. Explain the difference between eventual consistency and strong consistency. When would you choose each?

System design questions

1. Design a payment ledger system that must be accurate, fault-tolerant, and auditable.
2. How would you architect a notification service that sends alerts across email, SMS, and in-app channels?
3. Your service is experiencing high latency during peak hours. Walk me through how you would investigate and resolve this.

Behavioural questions

1. Tell me about a time you caught a critical bug just before it went to production. What did you do?
2. Describe a situation where you disagreed with a technical decision your team made. How did you handle it?
3. Tell me about a project where you had to learn a new technology quickly to deliver on time.
4. How do you balance shipping fast versus writing clean, maintainable code?

Use the STAR method (Situation, Task, Action, Result) to structure your answers. Here are three examples tailored to the kinds of questions Sett candidates typically face.

Q: Tell me about a time you caught a critical bug just before production.

*Situation:* At my previous company, we were about to deploy a new billing module on a Friday evening. I was doing a final sanity check on the pull request.

*Task:* My job was to review the diff and sign off before the release window closed.

*Action:* I noticed that a currency conversion function was dividing instead of multiplying when converting from USD to INR. I flagged it immediately, wrote a unit test that reproduced the failure, and shared it in the team chat. We rolled back the release plan and patched the function.

*Result:* The fix took a couple of hours and we deployed on Monday with no issues. My team lead later added a mandatory currency-conversion test suite to our CI pipeline, so this class of error could not slip through again.

---

Q: Describe a situation where you disagreed with a technical decision.

*Situation:* My team decided to use a shared monolithic database for a new microservice rather than giving it its own data store, citing speed of delivery.

*Task:* I believed this would create tight coupling and make the service harder to scale independently, but I was the newest engineer on the team.

*Action:* Instead of just objecting, I wrote a short document comparing the two approaches, covering the risk of schema conflicts and the operational overhead of a shared database. I presented it in our next architecture sync and proposed a compromise: start with the shared database behind a clear data-access layer so we could migrate later with minimal rework.

*Result:* The team agreed to the compromise. Six months later, when we did need to migrate, the data-access layer made it a straightforward task rather than a large refactor.

---

Q: Tell me about a project where you had to learn a new technology quickly.

*Situation:* Our team was asked to build a real-time dashboard for operations, and the frontend lead suggested we use WebSockets. I had never worked with WebSockets before.

*Task:* I was responsible for the backend service that would push live data to the browser.

*Action:* I spent the first two days reading the official docs and building a small prototype. I then paired with a senior engineer for a code review session and rewrote parts of the prototype based on their feedback. I also studied how our existing services handled connection pooling so I could apply the same patterns.

*Result:* I delivered the WebSocket service on schedule. The dashboard went live without issues, and I later wrote an internal guide for the team on setting up WebSocket servers in our stack.

For system design questions, open with clarifying questions before jumping to a solution. Candidates report that interviewers at product companies like Sett want to see structured thinking, not just a correct answer. A useful sequence: clarify scope and scale, list functional and non-functional requirements, sketch a high-level architecture, then drill into one or two components the interviewer asks about.

For behavioural questions, STAR (Situation, Task, Action, Result) is the standard framework. Keep the Situation and Task brief, two to three sentences combined, and spend most of your time on Action and Result. Make sure your Result is concrete: what changed, what was avoided, or what the team learned.

For coding questions, think out loud from the start. State your approach before you write a single line. Mention the brute-force solution first, then explain why you are optimising. Walk through edge cases at the end even if the interviewer does not ask. It shows thoroughness.

For 'disagree and commit' questions, show that you raised your concern clearly, listened to the counter-argument, and then committed once a decision was made. Interviewers at collaborative product companies want engineers who can disagree professionally, not ones who either stay silent or hold grudges.

Candidates who have gone through product-company interviews in fintech and SaaS roles typically report that interviewers are looking for a few specific signals.

Ownership over tasks. Can you describe a project as 'I did X' rather than 'we did X'? Interviewers want to understand your specific contribution, not your team's collective effort.

Correctness under pressure. Can you write working code in an interview setting, not just talk about it? Even if your first approach is not optimal, getting to a working solution matters more than elegance.

Communication during problem-solving. Do you explain your reasoning as you go, or do you go silent and produce an answer? Product companies value engineers who can collaborate in real time.

Awareness of trade-offs. For system design, candidates who say 'it depends, and here is what each choice costs you' consistently score higher than those who give a single answer with no nuance.

Cultural fit and humility. Sett, like most early-to-mid-stage product companies, typically looks for people who can give direct feedback, receive criticism without getting defensive, and ask for help when they are stuck.

Week 1: Coding fundamentals.

Focus on arrays, strings, hashmaps, and trees. These topics cover the majority of coding interview questions at most product companies. Solve problems in the language you are most comfortable in, and practise explaining your solution out loud, not just writing it.

Week 2: System design.

Study two or three core design problems relevant to Sett's likely domain: payment systems, ledgers, notification services, and API gateways. For each, practise the full flow: requirements, high-level design, component deep-dive, trade-offs. Read publicly available engineering blogs from fintech companies to understand common architectural patterns.

Week 3: Behavioural preparation.

Write down four to six projects from your career where you made a meaningful contribution. For each, prepare a STAR answer covering at least one of: a technical challenge, a conflict or disagreement, a time you learned something new, or a time you failed and what you did about it. Practise saying these out loud, ideally with a friend or peer who can give you feedback.

Before the interview.

Research what Sett does, who their customers are, and what engineering problems they are likely solving. Candidates report that showing genuine curiosity about the product creates a positive impression even if your technical answers are not perfect. Prepare two or three thoughtful questions to ask at the end of each round.

Jumping straight into code without clarifying. Interviewers want to see how you think before you type. Skipping the clarification step makes you look reactive rather than methodical.

Giving vague STAR answers. 'We improved the system' is not an answer. 'I rewrote the caching layer, which removed a class of timeout errors we had been seeing in production' is an answer. Be specific about what you personally did.

Designing without trade-offs. Saying 'I would use Kafka for this' without explaining why, or acknowledging the downsides, signals surface-level knowledge. Always explain the trade-off.

Staying silent during coding. Interviewers cannot help you if they do not know where you are stuck. Narrate your thinking so the interviewer can step in if you go down the wrong path.

Not asking questions at the end. Candidates who have no questions for the interviewer can come across as uninterested. Prepare genuine questions about the team, the tech stack, or the problems the team is currently solving.

Underselling your impact. Indian candidates in particular tend to say 'we did this' rather than 'I did this.' Be comfortable owning your contribution. That is not arrogance, it is what an interviewer needs to hear to evaluate you.