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

Keka HR is one of India's fastest-growing HR and payroll SaaS platforms, used daily by thousands of mid-market companies across the country. Their engineering team builds core modules like payroll processing, attendance tracking, leave management, and employee self-service, all on a multi-tenant cloud platform. As of July 2026, there are 3 Software Engineer openings at Keka HR on knok's radar.

The interview process typically runs across 2-4 rounds, candidates report. Expect a coding or take-home assignment, a deep-dive technical discussion on your past projects, and a system design conversation for mid and senior candidates. A final culture or HR round is common. Timelines vary, but most candidates complete the process within 2-3 weeks.

Salary ranges for Software Engineers align with broader India market bands:

These figures reflect publicly reported industry bands and may vary based on your specific skills and negotiation.

Questions below are drawn from candidate reports and reflect Keka's focus on SaaS product engineering, data integrity, and scalable systems.

1. How would you design a multi-tenant payroll processing system that handles different pay structures across thousands of companies?
2. Walk us through a time you optimised a slow database query. What was the bottleneck, and what did you do?
3. Keka processes sensitive employee data including salaries and personal details. How do you think about data security in your code?
4. How would you build a leave management module that supports complex, company-specific leave policies?
5. Describe your experience with REST API design. How do you handle versioning when both mobile and web clients consume the same API?
6. How would you debug a production bug where payroll calculations are returning incorrect results for certain employees?
7. Tell us about a time you worked on a feature with incomplete or changing requirements. How did you manage it?
8. How do you write code that is easy to test and maintain over time?
9. What is your approach to handling concurrency, for example when multiple managers update the same employee record at the same time?
10. Tell us about a time you disagreed with a teammate or manager on a technical decision. What happened?
11. How would you design a notification system to alert employees about payslip releases, leave approvals, and policy changes?
12. What do you know about Keka as a product? If you were joining the team tomorrow, which area would you focus on improving and why?

Three sample answers in STAR format. Adapt each with your own real experience.

Q: Walk us through a time you optimised a slow database query.

*Situation:* At my previous company, the employee attendance summary dashboard was taking several seconds to load for clients with large workforces.

*Task:* I was asked to fix the performance issue without changing the API contract, since several client integrations depended on it.

*Action:* I ran EXPLAIN ANALYZE on the query and found it was doing a full table scan due to a missing composite index on (company_id, date). I added the index, rewrote an N+1 subquery as a JOIN, and added a cache layer for the most frequently requested date ranges.

*Result:* Load time dropped to under a second for the same dataset. The fix went live without downtime, and the client team noticed the improvement before we announced it.

---

Q: Tell us about a time you disagreed with a technical decision.

*Situation:* During sprint planning, my team lead proposed storing all audit logs directly in the main production database. I felt this would bloat the primary DB and slow down writes over time.

*Task:* I needed to raise my concern without derailing the sprint or coming across as just being critical.

*Action:* I prepared a short doc comparing three options: same DB with partitioning, a separate audit DB, and a message queue with async writes to object storage. I shared it in our design review, laid out the trade-offs honestly, and proposed starting with the partitioned approach since it was lowest effort and easy to migrate later.

*Result:* The team appreciated having the options laid out clearly. We went with the partitioned approach and, several months later, migrated to async storage with minimal disruption because we had planned for it from the start.

---

Q: Describe how you handled debugging a production issue under pressure.

*Situation:* On a Friday afternoon, the payslip download feature stopped working for a subset of users at one of our largest client companies.

*Task:* I was the on-call engineer and needed to find the root cause and restore service quickly.

*Action:* I checked error logs first and found a NullPointerException tied to specific employee records. Tracing it back, I found a data migration script had left some records with a null bank account type field that our new validation logic did not handle gracefully. I deployed a hotfix to default to a safe fallback value, then created a follow-up ticket to backfill the bad records and add a stricter migration checklist.

*Result:* Service was restored within the hour. The post-mortem led to a new practice of running data integrity checks after every migration script.

Use these three frameworks to structure your answers clearly without rambling.

STAR (for behavioural questions): Start with the Situation (brief context), then your Task (your specific responsibility), describe your Action in detail (this is where you spend most of your time), and close with the Result. Interviewers at product companies like Keka care most about what YOU specifically did, not what 'the team' did. Own your actions clearly.

Problem, Approach, Trade-off (for system design questions): State the problem constraints first: scale requirements, consistency needs, and latency targets. Walk through your chosen approach step by step. Always name at least one trade-off or alternative you considered and explain why you rejected it. This signals engineering maturity, not just pattern recall.

Diagnose, Isolate, Fix (for debugging questions): Start by describing how you gather information (logs, metrics, reproduction steps). Explain how you narrow down the probable cause. Describe the fix and, importantly, any preventive measure you added so the same issue does not recur. Interviewers look for the preventive step as a sign of ownership.

Keka is a product-first engineering team building software that HR managers and employees rely on every day. Interviewers typically look for a combination of technical depth and product mindset.

Product thinking: Can you connect your technical choices to real user impact? Candidates who frame solutions around the HR manager's or employee's actual experience stand out from those who talk only about infrastructure choices.

Ownership: Keka is a growing company with a lean team. Interviewers want to see that you take end-to-end responsibility, from writing the code to making sure it works correctly in production, including after deployment.

Clear communication: Can you explain a complex system or a past decision simply? This matters in a collaborative product team where engineers work closely with product managers and designers who are not always technical.

Hands-on engineering depth: Strong fundamentals in data structures, SQL, and system design are expected across all levels. For mid and senior roles, familiarity with multi-tenant architecture, background job processing, or SaaS scaling patterns is a clear plus.

Genuine product interest: Candidates who have actually used Keka HR or researched its core modules (payroll, attendance, leave, performance) make a noticeably better impression. Interviewers often ask what you would improve, so having a real, reasoned opinion matters more than flattery.

A focused 2-3 week plan covering both technical and product preparation.

Week 1: Strengthen the fundamentals. Revise core data structures (arrays, hashmaps, trees, graphs) and common algorithm patterns. Practice SQL query optimisation: indexing strategies, JOIN vs. subquery trade-offs, and reading EXPLAIN plans. Review REST API design principles including resource naming, status codes, versioning strategies, and token-based authentication.

Week 2: SaaS and system design. Study multi-tenancy patterns (row-level isolation vs. schema-per-tenant), JWT and OAuth flows, background job queues, and notification system design. Practice designing a payroll or leave management system end-to-end on paper, covering the data model, API layer, and how you handle edge cases like mid-month salary revisions or overlapping leave requests.

Week 3: Keka-specific preparation. Sign up for a Keka HR free trial or watch their product demo videos to understand the actual user experience. Prepare 3-4 strong STAR stories from your past work covering performance optimisation, ownership under pressure, handling conflict, and cross-functional collaboration. For each story, be ready to state the measurable outcome.

Do at least 2-3 mock technical interviews out loud before the actual rounds. Talking through your thinking while coding is a skill that needs practice, and it matters a lot in Keka's technical discussions.

Jumping straight to code without clarifying. Interviewers at Keka want to see how you think before you type. Ask about scale, edge cases, and constraints first. Silence while thinking is fine; starting to code on the wrong problem is not.

Generic system design with no trade-off discussion. Saying 'I would use Kafka' without explaining why, or what the downside is, signals memorised patterns rather than genuine understanding. Always name the alternative you considered and explain why you rejected it.

Not connecting past work to the product domain. If you have worked on any SaaS product, billing system, or multi-user application, draw that parallel to Keka's context explicitly. Do not leave the interviewer to make the connection for you.

Passive STAR answers. Starting every answer with 'we did this' instead of 'I specifically did this' makes it hard for interviewers to assess your individual contribution. Own your role in the outcome clearly.

Showing up without product knowledge. Candidates who have not looked at Keka's product miss easy points. Knowing their core modules (payroll, attendance, leaves, performance) lets you ask sharper questions and give more relevant design answers during the interview.

Bringing up compensation too early. Do not raise salary in the first round unless the interviewer asks. Wait until you have an offer or are explicitly invited to discuss it.