Slice Placement Papers 2026 — Complete Preparation Guide

Last Updated: March 2026

Meta Description: Prepare for Slice 2026 campus placements with our comprehensive guide featuring the hiring process, 20+ solved technical questions on fintech systems, payments, DSA, system design, and backend engineering.

---

Company Overview

Slice (now operating as a Small Finance Bank after acquiring NKG Infrastructure) is one of India's fastest-growing fintech companies, revolutionizing digital payments and credit for young Indians. Originally known for its credit card alternative — the Slice Card — the company has evolved into a full-fledged banking and payments platform.

Attribute	Details
Founded	2016 by Rajan Bajaj (IIT Kharagpur)
Headquarters	Bangalore, India
Employees	1,500+
Valuation	$1.5+ billion (unicorn since 2022)
Users	15+ million registered users
Key Products	Slice UPI, Slice Card (credit line), Savings Account, Personal Loans
Investors	Tiger Global, Insight Partners, Gunosy Capital, IIFL, Blume Ventures
Tech Stack	Java, Kotlin, Go, Python, React Native, AWS, Kafka, PostgreSQL, Redis, MongoDB
Banking License	Received Small Finance Bank license (via NKG Infrastructure acquisition)

Why Work at Slice?

• Full-stack fintech — building banking from scratch with modern tech
• Competitive packages — SDE-1 salary ranges from ₹18-35 LPA
• High-growth trajectory — from credit cards to full banking in 3 years
• Hard engineering problems — payments at scale, real-time fraud detection, regulatory compliance
• Small teams, high ownership — you own entire features end-to-end

---

Eligibility Criteria

Parameter	Requirement
Degree	B.E./B.Tech (CS/IT preferred), M.Tech
CGPA	7.0+
Backlogs	No active backlogs
Skills	Strong DSA, Backend engineering, Problem-solving mindset

---

Hiring Process

Round 1: Online Assessment (90 minutes)

• 2-3 coding problems (Medium to Hard)
• Focus on clean, optimal solutions
• Topics: Arrays, Strings, Trees, Graphs, DP, Greedy
• Platform: HackerRank

Round 2: Technical Interview 1 — DSA (60 minutes)

• 2 coding problems, live coding
• Strong emphasis on approaching the problem systematically
• Edge cases and follow-up optimizations
• Clean code matters — naming, structure

Round 3: Technical Interview 2 — System Design (60 minutes)

• Design a fintech system (payment processing, fraud detection, wallet)
• Scalability, consistency, security focus
• Database design, API design
• Understanding of financial transaction guarantees

Round 4: Technical Interview 3 — LLD or Backend Deep Dive (45-60 minutes)

• Low-Level Design problem
• SOLID principles, Design Patterns
• Concurrency, threading, database internals
• Past project deep dive

Round 5: Hiring Manager Round (30 minutes)

• Behavioral questions, culture fit
• Career goals, interest in fintech
• Why Slice? What excites you about fintech?

---

Slice Technical Interview Questions with Solutions

Data Structures & Algorithms

Question 1

Given an array of transactions (positive = credit, negative = debit), find the maximum sum subarray (maximum net balance in any contiguous period).

Answer (Kadane's Algorithm):

def max_transaction_sum(transactions):
    max_sum = transactions[0]
    current_sum = transactions[0]
    start = end = temp_start = 0
    
    for i in range(1, len(transactions)):
        if current_sum + transactions[i] < transactions[i]:
            current_sum = transactions[i]
            temp_start = i
        else:
            current_sum += transactions[i]
        
        if current_sum > max_sum:
            max_sum = current_sum
            start = temp_start
            end = i
    
    return max_sum, start, end

# Example: [-2, 1, -3, 4, -1, 2, 1, -5, 4]
# Output: (6, 3, 6) — subarray [4, -1, 2, 1]
# Time: O(n), Space: O(1)

---

Question 2

Design a data structure that supports: addTransaction(amount), getMedian() — both in efficient time.

Answer (Two Heaps):

import heapq

class TransactionMedian:
    def __init__(self):
        self.max_heap = []  # Lower half (negated for max-heap)
        self.min_heap = []  # Upper half
    
    def addTransaction(self, amount):
        heapq.heappush(self.max_heap, -amount)
        
        # Ensure max_heap top <= min_heap top
        if self.min_heap and (-self.max_heap[0] > self.min_heap[0]):
            val = -heapq.heappop(self.max_heap)
            heapq.heappush(self.min_heap, val)
        
        # Balance sizes (max_heap can have at most 1 more)
        if len(self.max_heap) > len(self.min_heap) + 1:
            val = -heapq.heappop(self.max_heap)
            heapq.heappush(self.min_heap, val)
        elif len(self.min_heap) > len(self.max_heap):
            val = heapq.heappop(self.min_heap)
            heapq.heappush(self.max_heap, -val)
    
    def getMedian(self):
        if len(self.max_heap) > len(self.min_heap):
            return -self.max_heap[0]
        return (-self.max_heap[0] + self.min_heap[0]) / 2

# addTransaction: O(log n), getMedian: O(1)

---

Question 3

Find all pairs of transactions that sum to a target amount (for reconciliation).

def find_reconciliation_pairs(transactions, target):
    seen = {}
    pairs = []
    
    for i, amount in enumerate(transactions):
        complement = target - amount
        if complement in seen:
            pairs.append((seen[complement], i))
        seen[amount] = i
    
    return pairs

# For finding ALL pairs (including duplicates):
def find_all_pairs(transactions, target):
    from collections import defaultdict
    index_map = defaultdict(list)
    pairs = []
    
    for i, amount in enumerate(transactions):
        complement = target - amount
        if complement in index_map:
            for j in index_map[complement]:
                pairs.append((j, i))
        index_map[amount].append(i)
    
    return pairs

# Time: O(n), Space: O(n)

---

Question 4

Implement a Least Recently Used (LRU) cache for caching user profiles.

class Node:
    def __init__(self, key=0, val=0):
        self.key, self.val = key, val
        self.prev = self.next = None

class LRUCache:
    def __init__(self, capacity):
        self.cap = capacity
        self.cache = {}
        self.head, self.tail = Node(), Node()
        self.head.next = self.tail
        self.tail.prev = self.head
    
    def _remove(self, node):
        node.prev.next = node.next
        node.next.prev = node.prev
    
    def _add_to_front(self, node):
        node.next = self.head.next
        node.prev = self.head
        self.head.next.prev = node
        self.head.next = node
    
    def get(self, key):
        if key not in self.cache:
            return -1
        node = self.cache[key]
        self._remove(node)
        self._add_to_front(node)
        return node.val
    
    def put(self, key, val):
        if key in self.cache:
            self._remove(self.cache[key])
        node = Node(key, val)
        self._add_to_front(node)
        self.cache[key] = node
        if len(self.cache) > self.cap:
            lru = self.tail.prev
            self._remove(lru)
            del self.cache[lru.key]

# All operations: O(1)

---

System Design — Fintech

Question 5

Design a UPI payment processing system for Slice.

Requirements:

• Process UPI payments (P2P and P2M)
• Support QR scan, UPI ID, phone number payments
• Real-time settlement
• Handle 1M+ transactions per day
• 99.99% availability

Architecture:

Slice App → API Gateway → Payment Service → NPCI (UPI Switch)
                               ↓
                    Transaction DB (PostgreSQL)
                               ↓
                    Event Bus (Kafka)
                   ↙         ↓         ↘
            Fraud          Ledger       Notification
            Engine         Service      Service

Transaction Flow:

1. User initiates payment → Payment Service creates transaction record (INITIATED)
2. Validate user, check balance/credit limit
3. Send collect/pay request to NPCI
4. NPCI routes to beneficiary bank
5. Beneficiary bank responds (success/failure)
6. NPCI sends callback to Slice
7. Update transaction status (SUCCESS/FAILED)
8. Publish event → Ledger update, Notification

Key Design Decisions:

Aspect	Decision	Rationale
Database	PostgreSQL with ACID transactions	Financial data needs strong consistency
Idempotency	Transaction ID as idempotency key	Prevent duplicate payments
Consistency	Strong consistency for balance updates	Can't allow negative balance
Retry	Exponential backoff for NPCI callbacks	Network failures are common
Audit Trail	Append-only ledger + event sourcing	Regulatory compliance
Security	End-to-end encryption, MPIN/biometric auth	RBI compliance

Fraud Detection (Real-time):

• Rule engine: velocity checks (max 10 txns/hour), amount limits
• ML model: anomaly detection on transaction patterns
• Device fingerprinting: detect device spoofing
• Geo-velocity: impossible travel detection

---

Question 6

Design a credit scoring system for Slice.

Data Sources:

1. Bureau Data: CIBIL, Experian, CRIF — credit history, existing loans
2. Alternative Data: UPI transaction history, app usage, income patterns
3. Behavioral Data: Repayment behavior on Slice, spending patterns

ML Pipeline:

Data Collection → Feature Engineering → Model Training → Scoring → Decision

Key Features:

• Credit bureau score (CIBIL 300-900)
• Income stability (salary credit frequency)
• Spending-to-income ratio
• Existing debt obligations (DTI ratio)
• Repayment history (DPD — Days Past Due)
• Digital footprint signals

Model Architecture:

• Gradient Boosted Trees (XGBoost/LightGBM) for tabular data — best for credit scoring
• Logistic Regression for interpretable baseline
• Ensemble of both for production

Real-time Scoring:

# Simplified scoring pipeline
class CreditScorer:
    def __init__(self, model, feature_store):
        self.model = model
        self.feature_store = feature_store
    
    def score(self, user_id):
        features = self.feature_store.get_features(user_id)
        score = self.model.predict_proba(features)[0][1]  # Probability of default
        
        # Map to credit band
        if score < 0.05: return "EXCELLENT", 50000  # Credit limit
        elif score < 0.10: return "GOOD", 30000
        elif score < 0.20: return "FAIR", 15000
        elif score < 0.35: return "POOR", 5000
        else: return "REJECT", 0

---

Backend Engineering

Question 7

Explain ACID properties in the context of financial transactions.

Property	Meaning	Financial Example
Atomicity	All or nothing — transaction fully completes or fully rolls back	If debit succeeds but credit fails, both must rollback
Consistency	DB moves from one valid state to another	Total money in system stays constant after transfer
Isolation	Concurrent transactions don't interfere	Two simultaneous payments from same account don't cause overdraft
Durability	Committed data survives system crashes	Once payment is confirmed, it persists even if server crashes

Implementation in Fintech:

# PostgreSQL transaction for money transfer
def transfer_money(from_account, to_account, amount):
    with db.transaction() as txn:
        try:
            # Check balance
            balance = txn.execute(
                "SELECT balance FROM accounts WHERE id = %s FOR UPDATE",
                [from_account]  # FOR UPDATE = row-level lock
            )
            
            if balance < amount:
                raise InsufficientFundsError()
            
            # Debit
            txn.execute(
                "UPDATE accounts SET balance = balance - %s WHERE id = %s",
                [amount, from_account]
            )
            
            # Credit
            txn.execute(
                "UPDATE accounts SET balance = balance + %s WHERE id = %s",
                [amount, to_account]
            )
            
            # Audit log
            txn.execute(
                "INSERT INTO transactions (from_id, to_id, amount, timestamp) VALUES (%s, %s, %s, NOW())",
                [from_account, to_account, amount]
            )
            
            txn.commit()
        except Exception:
            txn.rollback()
            raise

FOR UPDATE acquires a row-level lock — prevents concurrent transactions from reading the same balance (solves double-spending).

---

Question 8

What is event sourcing? Why is it valuable in fintech?

Event Sourcing = Instead of storing current state, store all state changes as an immutable sequence of events.

Traditional approach:

Account: { id: 1, balance: 5000 }  — Only current state

Event Sourcing:

Event 1: AccountCreated { id: 1, initial_balance: 0 }
Event 2: MoneyDeposited { id: 1, amount: 10000 }
Event 3: MoneyWithdrawn { id: 1, amount: 3000 }
Event 4: MoneyTransferred { id: 1, amount: 2000, to: 2 }
Current state: balance = 10000 - 3000 - 2000 = 5000

Benefits for Fintech:

1. Complete audit trail — regulatory requirement (RBI mandates)
2. Temporal queries — "What was the balance at 3 PM yesterday?"
3. Event replay — rebuild state, fix bugs, create new projections
4. Debugging — trace exact sequence that led to any state
5. Compliance — immutable log for fraud investigation

---

Question 9

Design a distributed lock mechanism for preventing double payments.

import redis
import uuid
import time

class DistributedLock:
    def __init__(self, redis_client, lock_name, ttl=30):
        self.redis = redis_client
        self.lock_name = f"lock:{lock_name}"
        self.ttl = ttl
        self.token = str(uuid.uuid4())
    
    def acquire(self):
        """Try to acquire lock with NX (only if not exists)"""
        return self.redis.set(
            self.lock_name, self.token,
            nx=True,  # Only set if not exists
            ex=self.ttl  # Auto-expire to prevent deadlocks
        )
    
    def release(self):
        """Release only if we own the lock (Lua script for atomicity)"""
        lua_script = """
        if redis.call('get', KEYS[1]) == ARGV[1] then
            return redis.call('del', KEYS[1])
        else
            return 0
        end
        """
        return self.redis.eval(lua_script, 1, self.lock_name, self.token)

# Usage for payment idempotency
def process_payment(transaction_id, amount):
    lock = DistributedLock(redis_client, f"payment:{transaction_id}")
    
    if not lock.acquire():
        return {"status": "DUPLICATE", "message": "Payment already being processed"}
    
    try:
        # Check if already processed
        if is_already_processed(transaction_id):
            return {"status": "ALREADY_PROCESSED"}
        
        result = execute_payment(amount)
        mark_as_processed(transaction_id)
        return result
    finally:
        lock.release()

---

Preparation Strategy

30-Day Slice Prep Plan

Week 1: DSA Foundations

• Arrays, Strings, HashMaps, Two Pointers — 5 problems/day
• LeetCode Medium focus
• Build strong foundation in complexity analysis

Week 2: Advanced DSA

• Trees, Graphs, DP, Heaps — 4 problems/day
• Focus on optimization and clean code
• Practice explaining approach before coding

Week 3: System Design + Fintech

• Study payment systems, UPI architecture, ACID, event sourcing
• Practice: Design payment gateway, wallet, credit scoring
• Read about RBI regulations, PCI-DSS compliance basics

Week 4: LLD + Mock Interviews

• SOLID principles, Design Patterns
• Practice 3 mock interviews
• Research Slice's products, blog posts, recent developments
• Prepare behavioral stories

---

Related Preparation Guides

• Groww Placement Papers 2026 — Fintech interview preparation
• Meesho Placement Papers 2026 — Startup engineering interviews
• Amazon Placement Papers 2026 — System design focus
• TCS Placement Papers 2026 — Campus hiring guide
• 30-Day Placement Preparation Plan — Structured approach

---

Frequently Asked Questions

Q: What is the fresher salary at Slice? A: SDE-1 at Slice ranges from ₹18-35 LPA (CTC including ESOPs). Exact package depends on campus tier and interview performance.

Q: Does Slice hire for non-engineering roles? A: Yes, Slice hires for Product, Design, Data Science, Risk & Analytics, and Operations roles in addition to engineering.

Q: What programming languages are used at Slice? A: Backend is primarily Java, Kotlin, and Go. Python for data/ML. React Native for mobile apps. For interviews, any language is accepted.

Q: Is fintech domain knowledge required? A: Not mandatory for freshers, but understanding basic payment flows, UPI, and financial concepts gives you a strong edge in system design rounds.

---

Last Updated: March 2026