Arcana Software Engineer Interview: Questions & Prep (2026)

Arcana currently has 19 open Software Engineer positions (as of early July 2026). Candidates report that the process typically runs across three to four rounds, mixing technical assessments with behavioural and system design discussions. The exact round structure varies by team and seniority level, so treat all process claims here as 'typically' rather than guaranteed.

For market context, knok's job radar shows 5,395 active Software Engineer openings across India as of 8 July 2026. Bangalore leads with 776 roles, followed by Hyderabad at 157, Delhi at 154, Pune at 140, Mumbai at 72, and Chennai at 48.

Salary ranges for Software Engineers in India, based on knok data:

For Arcana specifically, publicly reported offers vary by team and location, so use these bands as a market reference rather than company-specific data.

Based on what candidates report from Arcana and similar product-focused engineering companies, these questions come up most often:

1. Walk me through a recent project where you owned the architecture end to end. What trade-offs did you make?
2. How do you approach debugging a production issue you have never seen before?
3. Describe a time you disagreed with a technical decision your team made. How did you handle it?
4. Design a scalable API for a feature like user authentication or file storage.
5. How do you prioritise when you have multiple bugs and feature requests at the same time?
6. What is your approach to writing code that other engineers can maintain easily?
7. Tell me about a time a deadline was at risk. What did you do?
8. How do you stay current with new technologies and decide which ones are worth adopting?
9. Describe a situation where you had to work with unclear requirements. How did you move forward?
10. Have you ever introduced a bug to production? What happened and what did you learn?
11. How do you think about performance optimisation, and when do you decide it is 'good enough'?
12. Why Arcana, and what problem are you most excited to work on here?

Use the STAR format (Situation, Task, Action, Result) for all behavioural questions. Here are three worked examples.

Q: Tell me about a time you debugged a difficult production issue.

*Situation:* Our payment confirmation service started returning errors intermittently on a Saturday afternoon, affecting a subset of users.

*Task:* I was the on-call engineer that weekend and had to identify the root cause and restore service as quickly as possible.

*Action:* I pulled logs from our monitoring tool and narrowed the errors to a specific database connection pool that was hitting its limit under peak load. I increased the pool size temporarily to restore service, then opened a postmortem to track the root cause. I refactored the connection handling to use lazy initialisation so connections released faster, and added alerting so the team would catch the pattern early next time.

*Result:* Service was stable within the hour. The follow-up fix reduced connection pool exhaustion events to near zero in the weeks after. The alerting caught a similar issue in a different service a few months later.

---

Q: Describe a time you disagreed with a technical decision your team made.

*Situation:* My team decided to use a third-party service for all our email notifications instead of building a lightweight internal queue.

*Task:* I had concerns about vendor lock-in and long-term cost at scale, but I was the most junior person in the discussion.

*Action:* Rather than objecting without evidence, I put together a short written comparison of the vendor option versus a simple internal queue using tools we already had. I shared it with the team lead before the next planning session and asked for a brief slot to walk through it. The team appreciated the structure and we ended up choosing a hybrid approach: the vendor for immediate rollout, with an abstraction layer so we could swap it out later.

*Result:* We shipped on time, and the abstraction layer was used when we eventually migrated to an internal solution. My approach of 'write it down and ask for time' became a small team norm for handling technical disagreements.

---

Q: Tell me about a project where you improved performance significantly.

*Situation:* Our search endpoint was timing out for users with large data sets, causing significant drop-off in a key user flow.

*Task:* I was asked to investigate and fix the performance problem without changing the API contract.

*Action:* I profiled the endpoint and found it was making repeated database calls inside a loop rather than fetching all needed records in a single query. I refactored the data access layer to batch those queries, added an index on the most-queried column, and introduced a short cache for results that did not change often.

*Result:* Response times dropped from several seconds to under a second for the affected users. The fix was reviewed, merged, and deployed within a week. The pattern we documented became the standard approach for similar endpoints in the codebase.

For system design questions: Start by clarifying requirements (scale, read vs write ratio, latency needs). Sketch the high-level components first, then go deeper on the parts the interviewer is most interested in. Explicitly call out trade-offs you are making, because interviewers want to hear your reasoning, not just your conclusion.

For behavioural questions: Use STAR (Situation, Task, Action, Result) and keep each section brief. Aim for two to three sentences per section. The 'Action' part should be about what *you* did, not what 'we' did as a team. Interviewers are evaluating your individual contribution.

For coding questions: Think out loud before writing any code. State your approach, mention the time and space complexity, and ask about edge cases. Candidates report that interviewers at companies like Arcana typically value clear thinking over a rushed correct solution.

For 'why this company' questions: Be specific. Reference a product, a technical challenge, or a business problem the company is working on. Generic answers like 'I like the culture and growth' rarely land well.

For 'tell me about yourself': Keep it under two minutes. Cover where you started, what you have worked on that is most relevant to this role, and why you are looking now. Do not recite your resume chronologically.

Candidates who have interviewed at Arcana and similar product companies report that interviewers consistently look for a few things.

Clear communication. Can you explain a technical concept to someone who does not share your exact background? This matters especially in cross-functional teams where engineers work closely with product and design.

Ownership mindset. Interviewers want to hear that you have taken problems all the way to resolution, not just handed them off. Use specific examples from your own work rather than team-level stories.

Structured thinking. Whether it is a design question or a behavioural one, interviewers want to see that you break problems down before diving into solutions. Jumping straight to answers without framing the problem is a common signal of shallow preparation.

Genuine curiosity. Companies in the product and tech space typically look for engineers who ask good questions, read about the domain, and bring ideas to the table rather than waiting to be told what to build.

Pragmatism over perfection. Interviewers at growth-stage companies often value engineers who can ship working solutions and iterate, rather than holding out for an ideal architecture that takes too long to reach.

One to two weeks before: Revise core data structures and algorithms (arrays, trees, graphs, sorting, searching). Practice on a coding platform until you can talk through your approach out loud while writing. Review system design basics: load balancing, caching, databases (SQL vs NoSQL), and API design.

One week before: Write down five to eight stories from your own work covering a technical challenge you solved, a conflict you navigated, a time you led something, and a failure with what you learned. Map each story to the STAR structure. Research Arcana's product, the problems they are solving, and any recent news. Prepare two to three specific questions to ask at the end of each round.

Two to three days before: Do a mock interview with a friend or record yourself answering common behavioural questions. Watch the playback. Pay attention to filler words and whether your answers have a clear structure rather than trailing off.

Day before: Light review only. Go over your STAR stories once. Confirm the interview format (video call, in-person, take-home) and make sure your setup is ready. Get enough sleep.

During the interview: For coding, clarify before you code. For design, ask about scale and constraints first. For behavioural questions, pause briefly before answering so your response is structured, not rushed.

If you are applying to multiple companies at the same time, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so you can focus your energy on preparation rather than job hunting.

Jumping into code without clarifying. Many candidates start typing before they fully understand the problem. Ask one or two clarifying questions first. Interviewers specifically watch for this as a signal of how you will behave in real work situations.

Using 'we' instead of 'I' in behavioural answers. Saying 'we built the system' tells the interviewer nothing about your individual contribution. Describe what you personally did, decided, or drove.

Vague system design answers. Saying 'I would use a cache here' without explaining why, what type, and what the trade-off is, comes across as surface-level knowledge. Name the component, justify the choice, and acknowledge what you are giving up.

Not asking questions at the end. Candidates who have no questions often signal low interest or low preparation. Prepare at least two thoughtful questions per round before you walk in.

Ignoring edge cases in coding problems. Candidates report that interviewers notice when you test your code only against the happy path. Mention null inputs, empty arrays, and large inputs as part of your solution walkthrough.

Underselling or overselling salary expectations. Research the market range before the conversation. For Software Engineer roles in India, Glassdoor and publicly reported data show wide variation by city and experience. Use market bands as a reference point, not a ceiling.