Tabby Interview Process: Product and Engineering Roles

Most candidates applying to Tabby treat it like a generic Series D startup. They memorize BNPL talking points, rehearse standard behavioral frameworks, and assume the bar is "startup-casual." It isn't. Tabby is a regulated financial platform holding payment licenses in four countries and processing real consumer credit decisions at scale. The interviewers are calibrated for that.

Here's what the loop looks like, which question patterns appear consistently, and the mistakes that eliminate otherwise qualified candidates.

The Tabby interview process: what it is

The Tabby interview process for engineering and product roles typically runs four to six weeks and includes three to five stages. Engineering candidates go through a recruiter screen, a live coding round using medium-to-hard algorithmic problems, a system design round anchored in fintech scenarios such as fraud detection or payment reliability, and a behavioral panel before a final leadership call. Product candidates complete a recruiter screen, a 48-hour take-home case study, a live case walkthrough, a cross-functional panel, and a hiring manager round. Senior roles at both tracks may add a C-suite conversation. Tabby holds payment licenses in Saudi Arabia, UAE, and Kuwait, so both tracks include questions that probe regulatory awareness and the ability to operate in a high-stakes financial environment. Preparation requires domain-specific focus, not just general polish.

What Does the Tabby Interview Loop Actually Look Like?

Tabby is a Saudi-headquartered buy now, pay later (BNPL) platform regulated by SAMA in Saudi Arabia, CBUAE in UAE, and the Central Bank of Kuwait — meaning it operates under genuine financial oversight, not standard tech compliance. The interview process reflects this.

The engineering track runs: recruiter screen → live coding → system design → behavioral panel → leadership call. The recruiter screen handles logistics — compensation, visa status for international candidates, location preferences. The coding round is the first real filter. The system design round follows within a week of the coding round passing. The behavioral panel typically includes two or three interviewers and runs 60 to 90 minutes.

The product track runs: recruiter screen → take-home case study (48-hour window) → live case walkthrough → cross-functional panel → hiring manager. The cross-functional panel draws from engineering, design, and data. Senior+ product roles sometimes add a call with a C-suite stakeholder.

Timeline compression happens during headcount sprints — some candidates have moved from application to offer in under three weeks. Slowdowns typically appear around SAMA review cycles and regional public holidays.

What Types of Questions Should You Expect?

The question patterns at Tabby are consistent enough to prepare for deliberately.

Live coding runs medium-to-hard on the LeetCode scale: graph traversal, dynamic programming, and sliding window patterns are the most common. Tabby's internal engineering stack uses Go, TypeScript (Node.js), and Python. You're rarely constrained to a specific language, but fluency matters — the interviewer will push toward optimization, and "I could refactor this for space complexity" followed by actually delivering it is expected, not optional.

System design prompts are almost always anchored in the fintech domain. Design a fraud detection layer. Design a payment retry service with idempotency guarantees. Design a merchant settlement reconciliation system. According to Glassdoor reviews and candidate discussions on LinkedIn, over 65% of Tabby system design interviews involve a reliability or fraud-prevention scenario. You need to understand distributed locks, Kafka-based event streaming, and eventually-consistent data stores — not in the abstract, but well enough to choose between them with a concrete reason.

Product case studies. The take-home is typically a real Tabby scenario: improve checkout conversion by a specific percentage, scope a new merchant onboarding feature, or define a metric tree for a BNPL risk-scoring product. Reviewers flag vague prioritization — "impact vs. effort" frameworks without actual numbers score consistently lower. If your case study can't answer "what does success look like in 90 days with specific numbers," it's already at risk.

Both tracks close with behavioral questions. The recurring themes: a time you operated without clear direction, a time you failed and what changed, and a time you pushed back on a stakeholder. They want specific situations and specific outcomes — not philosophies about how you handle conflict.

What Cultural Signals Is Tabby Scoring During the Interview?

Tabby built from zero to a licensed financial platform in under five years. The culture rewards a specific set of behaviors, and the interview is designed to surface them.

Ownership versus performance of ownership. Interviewers distinguish candidates who say "I owned the checkout flow" from those who describe exactly what they decided, what they didn't delegate, and what the specific outcome was with a number attached. The difference registers immediately.

Merchant-first framing. Tabby's model depends on merchant trust. Engineers proposing a payment retry mechanism without considering merchant settlement implications get flagged. PMs scoping a checkout change without asking what it does to merchant margins get flagged. The default frame in Tabby interviews is not "what does the consumer want" but "what does the merchant need and what does the consumer expect, simultaneously."

Speed with judgment on risk. This is a fintech company. Cutting corners on payment infrastructure has regulatory and financial consequences. Interviewers are not looking for perfectionists or cowboys — they want people who know the difference between a safe shortcut and one that creates downstream liability. That distinction has to come through in how you talk about tradeoffs.

Region-first mindset. Candidates who treat MENA as a secondary or "localization" market consistently score lower. Saudi Arabia and UAE are the primary context here, not an add-on to a global product frame.

Three Things Candidates Consistently Underestimate

1. The regulatory knowledge floor. Most candidates research Tabby's product. Few research its regulatory environment. SAMA's consumer finance circulars shape what Tabby can build and how it can market installment products. CBUAE's BNPL rules govern the UAE operations. Candidates who can name even one constraint — for example, that SAMA requires specific disclosure language for installment products — signal they understand the environment they'd be working in. Candidates who can't name any signal that they don't. A fast fix: read SAMA's "Consumer Lending Regulations" document, publicly available in English on the SAMA website. Thirty minutes gives you three specific constraints you can reference naturally in both the system design and behavioral rounds.

2. Cross-functional fluency at the senior level. Senior engineers at Tabby are expected to engage with product implications of architectural decisions. Senior PMs are expected to scope with enough technical awareness to have a real conversation with an engineer. The cross-functional panel is specifically designed to test this. An engineer who can't articulate the user impact of their system design decision, and a PM who can't estimate basic technical complexity, both lose points that aren't recoverable in other rounds.

3. The take-home anchors the product score. Many product candidates assume the take-home is a filter and the verbal walkthrough is the real evaluation. The reverse is more accurate. Reviewers form a strong prior on the written submission. The walkthrough surfaces the edges — follow-up questions on tradeoffs, edge cases, stakeholder conflicts. If the written case study is vague or structurally weak, a polished walkthrough doesn't recover the deficit.

How Should You Prepare in 2, 4, or 8 Weeks?

2 weeks: Days 1–3, read SAMA's publicly available consumer finance guidelines — note two to three operational constraints relevant to a BNPL product. Then: engineers, complete 10 medium LeetCode problems in graphs and DP, plus one mock system design session on payment reliability patterns; PMs, do two teardowns of Tabby's actual checkout flow and draft one case study end-to-end. Final two days: run two full behavioral mock interviews using IntervYou, record them, and rewatch specifically to evaluate how you handled ambiguity — that's the signal Tabby weights most.

4 weeks: Add a dedicated week of LeetCode (engineers: graphs, DP, tries) or merchant-facing fintech product research (PMs). Senior candidates should spend two hours reading Tabby's publicly available terms of service — not because you'll be quizzed on it, but because it surfaces the real constraints the product operates under. Week 3: two mock interviews — a system design session for engineers or a case walkthrough for PMs — with a live practice partner or interviewer. Week 4: one full mock loop end-to-end.

8 weeks: Engineers should work through Chapters 1–9 of Designing Data-Intensive Applications for systems depth. Begin behavioral mock practice in Week 3. Build a five-story behavioral inventory by Week 5, each story tied to a specific outcome and number. Reserve the final two weeks for full loop simulations — no new material, reps only.

Which Tools and Frameworks Matter for Tech Roles?

Tabby's engineering stack is Go and TypeScript (Node.js) on the backend, Python in data and ML functions. Infrastructure relies on Kafka for event streaming, PostgreSQL as the primary relational store, and Redis for caching and rate-limiting. Knowing this specifically — rather than relying on generic distributed-systems vocabulary — lets you make precise choices in system design. Proposing Kafka for a payment event log, then noting consumer group semantics and offset management, is the kind of domain fluency that scores.

Product analytics at Tabby uses Amplitude. PMs who can discuss funnel analysis, cohort retention, and A/B test significance with named tools — rather than abstract "data-driven decision-making" phrasing — consistently score higher on reviewers' calibration. According to multiple Tabby product managers who have discussed the process on LinkedIn, every product interview at the company includes a metric-definition question: "how would you measure success for this feature?" Prepare a specific, number-backed answer before walking in.

The framework that matters most across both tracks is not STAR, not CIRCLES, not any structured method — it's the demonstrated ability to connect a decision to a specific, measurable outcome. IntervYou's fintech-specific mock library includes Tabby-style system design prompts and product case scenarios for candidates who want practice in the actual domain before the actual interview.

Most candidates who fail the Tabby interview fail early — in the take-home or the system design round — because they prepared for a general interview instead of a fintech-specific one. The regulatory context, the system design domain, the merchant-first framing: these are learnable. They just have to be learned before the interview, not improvised during it.

Start a free mock →

Related reading

• SABIC Interview Process: What Engineers Need to Know
• Al Rajhi Bank Tech Interview: What Actually Happens
• How to Prepare for an Aramco Interview in 2026