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

Sign3 is an Indian fintech-infrastructure company building device intelligence and fraud-prevention products for banks, lending apps, and payment platforms. Their core technology assigns a unique fingerprint to mobile and web devices, helping lenders detect repeat defaulters, synthetic identities, and account takeovers without relying on cookies.

As of July 2026, Sign3 has 4 open Software Engineer roles on knok's radar. The engineering team is small and product-focused, so candidates report that interviews test both hands-on coding ability and practical product thinking. Typically, the process runs across two to three rounds covering a coding screen, a technical deep-dive, and a final culture or hiring-manager discussion. Candidates should expect questions on data structures, system design for real-time data pipelines, and how fraud signals are processed and scored at scale.

1. Walk us through how device fingerprinting works and how you would build one from scratch.
2. Design a real-time fraud-scoring system that flags suspicious loan applications as they come in.
3. How would you handle a situation where a fraud model starts producing false positives in production?
4. Explain the difference between stateless and stateful processing. When would you choose each for a fraud-detection pipeline?
5. Write a function that checks whether two device profiles are likely the same physical device, even if their identifiers differ.
6. How would you design an API that returns a device risk score with low latency for a lending partner?
7. Describe a time you improved the performance of a slow query or data pipeline.
8. How do you ensure data privacy and regulatory compliance (such as RBI guidelines) when storing and processing device signals?
9. What is eventual consistency and when is it acceptable in a financial-services context?
10. How would you structure a caching layer for device fingerprint lookups that sees very high read traffic?
11. Tell me about a production incident you owned end to end. How did you diagnose and resolve it?
12. How would you test a fraud-detection feature end to end before releasing it to production?

Q: Design a real-time fraud-scoring system that flags suspicious loan applications as they come in.

*Situation:* At a previous company, the fraud-detection pipeline was batch-based, which meant there was a significant delay between a customer submitting a loan application and a lender receiving a risk score. Lenders were either holding applications in a queue or approving them without complete fraud signals.

*Task:* I was tasked with redesigning the pipeline so that scores were available almost instantly after a customer submitted an application.

*Action:* I proposed a Kafka-based event-streaming architecture where each application submission published an event to a dedicated topic. A scoring microservice consumed these events, ran the fraud model in-process using ONNX format to keep inference fast, and published the result to a response topic. I worked with the data science team to keep the model compact enough for in-process inference without a separate model-serving hop. I also added a Redis layer to cache device fingerprint lookups for recently seen devices, reducing repeated database reads under high traffic.

*Result:* The pipeline moved from batch-based decisions to near-real-time scoring, and lenders reported a measurable improvement in their ability to make fast, accurate decisions on incoming applications rather than waiting for the next batch run.

---

Q: Tell me about a production incident you owned. How did you diagnose and resolve it?

*Situation:* Our device fingerprinting service started returning mismatched device IDs for a subset of mobile users on a specific Android version. Lending partners flagged it because the same physical user was appearing as multiple different devices in our system.

*Task:* I was the on-call engineer and took ownership of the incident from detection all the way through to resolution.

*Action:* I pulled logs for affected users and compared device attributes being collected before and after a recent OS update on that Android version. The update had changed how certain hardware identifiers were reported, and our hashing function was treating the new format as a brand-new device. I wrote a normalisation step to handle both the old and new identifier formats and deployed it behind a feature flag so we could roll it back immediately if needed.

*Result:* The mismatch rate dropped to near zero within minutes of the fix going live. I followed up with a post-incident document and added a regression test specifically for identifier format variations, so the same class of issue would be caught automatically in future deployments.

---

Q: Describe a time you improved the performance of a slow query or data pipeline.

*Situation:* A key dashboard used by our operations team was timing out regularly because the underlying SQL query was doing a full sequential scan on a large transactions table.

*Task:* I was asked to fix the performance problem without taking the table offline or interrupting live writes.

*Action:* I ran EXPLAIN ANALYZE on the query and found that the most-filtered columns had no composite index covering them together. I added that index and verified it built cleanly without impacting production writes. I also rewrote an expensive aggregation sub-query to use a materialised view refreshed on a background schedule, so the heavy computation no longer ran on every dashboard load.

*Result:* Dashboard load times improved dramatically and the operations team could use the dashboard during peak hours without timeouts. Database CPU usage also dropped noticeably during reporting cycles, and I documented the approach so the team could apply the same pattern to other slow queries.

For experience-based questions, use STAR. Open with the Situation (context and the problem), move to Task (your specific responsibility), walk through Action (exactly what you did, step by step), and close with Result (the outcome and what you learned). Keep results concrete: a reduction in errors, a faster load time, a process that no longer needed manual intervention.

For system design questions at Sign3, candidates report that interviewers want a structured walk-through rather than an immediate architecture diagram.

1. Clarify requirements and constraints first. Ask about expected traffic, acceptable latency, consistency needs, and whether the system must be auditable for regulatory purposes.
2. Sketch the high-level data flow: what comes in, how it is processed, where results are stored or forwarded.
3. Choose your core components (message queue, processing service, data store, cache) and justify each choice in one sentence.
4. Identify failure modes: what happens if the queue backs up, the scoring service is slow, or a device signal is missing entirely.
5. Discuss trade-offs honestly. Sign3 operates in a regulated space, so trade-offs between availability and consistency carry real financial consequences.

For coding questions, think aloud throughout. Candidates report that Sign3 interviewers value clear reasoning over a perfect first attempt. Write a working solution, state its time and space complexity, then offer to optimise if time allows.

Based on candidates' accounts, Sign3 interviewers are looking for a few specific qualities.

Ownership mindset. Small teams mean you are expected to own features end to end, from design through deployment and monitoring. Stories where you handed something off and never followed up do not land well. Show that you see the full lifecycle of a feature.

Real-world problem-solving. Sign3 operates in the fraud and identity space where mistakes have direct financial consequences for lenders and borrowers. Interviewers look for engineers who think about edge cases, data quality, and failure modes, not just the happy-path implementation.

Product curiosity. Candidates report that interviewers follow up with questions like 'why does this matter to the customer?' Show that you understand why low-latency fraud scoring matters to a lending partner, not just how to build the pipeline that delivers it.

Clear communication. You will work across engineering, data science, and partner-integration teams. Being honest about trade-offs and limitations is valued more than projecting false confidence. If you are unsure about something in the interview, say so and reason through it aloud.

Week 1: Foundations and domain knowledge.
Review core data structures and algorithms, with focus on hashmaps, graphs, and sliding-window techniques. Read about how device fingerprinting works and why it matters for fraud prevention in Indian fintech. Skim public RBI guidelines on digital lending to understand the regulatory context Sign3 operates in. This background will help you give more grounded answers to the product-related follow-up questions interviewers typically ask.

Week 2: System design for real-time pipelines.
Practise designing event-driven systems using message queues such as Kafka. Study patterns like fan-out, dead-letter queues, and idempotent consumers. Review how an in-memory cache like Redis is used for low-latency lookups. Sign3's product is built around real-time device signals, so streaming architecture questions are particularly common for mid-level and senior candidates.

Week 3: Mock interviews and company research.
Do timed coding sessions under interview conditions to build comfort with thinking aloud. Research Sign3's product, recent news, and the specific team you are applying to. Prepare three to four stories in STAR format covering: a technical challenge you solved, a production incident you owned, a time you collaborated across teams, and a time you improved something measurably. Review your own stories for any vague outcomes and replace them with concrete results.

Jumping straight into code. For design questions especially, candidates who skip the requirements-gathering step often build a system that solves the wrong problem. Take a moment to ask clarifying questions before writing anything.

Ignoring edge cases in fraud scenarios. A fraud system that only works when data is clean is not production-ready. Talk through what happens when a device ID is missing, when signals conflict across sources, or when the model returns a low-confidence score.

Over-engineering simple problems. Not every feature needs a distributed message queue and a dedicated caching layer. Candidates who reach for complex infrastructure on simple problems signal that they cannot match solution complexity to actual requirements.

Being vague about results. If you say something was 'much better' or 'much faster,' a good interviewer will ask for specifics. Know the actual impact of your work, even if it is qualitative, such as 'the ops team stopped escalating this issue entirely.'

Not preparing questions for the interviewer. Sign3 is a growth-stage startup, so asking about team size, tech stack, on-call expectations, and how the engineering team makes technical decisions shows that you have thought seriously about whether this role is the right fit.