CoinSwitch Software Engineer Interview Guide

The 60-second brief

CoinSwitch runs a crypto-asset platform for users in India. Candidates describe the Software Engineer role as backend-heavy engineering around that platform, with work such as low-latency trading engines, microservices, transaction ledgers and real-time market data. The responsibilities candidates see cover delivering features from design discussions through to production, turning product requirements into technical specifications, writing testable code, reviewing code, mentoring junior engineers and flagging technical debt. The requirements list one modern language (Java, Go, Python or JavaScript are the examples), solid data structures and algorithms, and experience with relational databases. Fintech or crypto experience, React for full-stack roles, and AWS or GCP are listed as extras.

This guide is for engineers preparing for the CoinSwitch Software Engineer loop, from the first assessment through the culture stage. It covers the four reported rounds, how to answer the behavioral and test-design questions candidates report (a difficult colleague, a motivation answer, a major challenge, handling pushback on your approach, and testing a graph problem), and how to build a seven-day plan that also covers the reported coding and system design questions. It describes what candidates report, not a published process.

Candidates report four rounds spread over roughly 3-5 weeks: Online Assessment, Screening Call, Technical Evaluation and Cultural Alignment. The number of rounds is reported to vary with seniority and team.

Focus areas

• Data Structures & Algorithms (DSA)
• Problem Solving
• System Design

Overview

The reported question list is dominated by two technical families and one behavioral family. The coding family is dynamic programming (Coin Change 2 and a classic knapsack), search over an array of strings, a tree traversal problem, and a graph problem about degree connections. The design family mixes two whole-system questions (a URL shortener and the database design for a locker management system) with three concept questions on NoSQL versus PostgreSQL, high availability with load balancing, and private versus public IPs. The behavioral family covers a difficult colleague, motivation for joining, the biggest past challenge, and handling feedback on your technical approach.

The stack signals are modest and specific. The requirements name a single modern language of your choice (Java, Go, Python or JavaScript), strong data structures and algorithms, and relational database experience. Candidates also report core computer science fundamentals (operating systems, computer architecture, database management) as expected background, and cloud familiarity (AWS or GCP) as a plus. That makes the private versus public IP question and the NoSQL versus PostgreSQL question answerable from concrete cloud and database knowledge rather than slogans. The role description also mentions ledgers and trading, so when you discuss consistency, anchor your examples in money-like data: idempotent writes, double-entry records and what must never be lost or duplicated.

Candidates describe the process as intense and some report inconsistent communication from the hiring side, so prepare for the pressure as well as the content. Practise explaining your reasoning out loud while you write code, state assumptions before you design, and justify each technology choice with an access pattern or failure mode. Some candidates report being asked to run code in a local IDE or an online compiler, so rehearse in that setting rather than in a bare text box. One verified candidate review also describes heavy work pressure, which is worth raising when you ask the team about workload.

The CoinSwitch interview process

Candidates report these four stages. The reports do not tie specific questions to specific rounds, so use the reported coding, design and behavioral questions as practice for the stage types that match them.

Online Assessment

The Online Assessment is reported as an initial test of technical skills and problem solving. Candidates also say the process can open with either this assessment or the screening call, so the order may differ. The reported coding topics are dynamic programming (memoization and tabulation), graph theory (connectivity, shortest paths, search), and Big O analysis of time and space. Treat it as working code under pressure: pick one of the languages the role lists, write from a blank editor, and finish each solution with a stated time and space complexity.

What to demonstrate

• Technical skills and problem solving, as the stage is described
• Correct, runnable code in a language you choose
• Complexity analysis stated for both time and space

How to prepare

• Solve Coin Change 2 and the classic knapsack from scratch in both memoized and table form, and say why the Coin Change 2 loop order counts combinations rather than orderings.
• Practise graph search (BFS and DFS) in your language with an explicit visited set, and write your own test inputs for it, including the degree-connections case.
• Code in a plain editor or an online compiler without autocomplete, and run your tests yourself before you call a solution done.

Screening Call

The Screening Call is reported as a conversation about your background and fit for the role. It is a good moment to learn how the rest of the loop is organised: candidates report that the round count varies with seniority and team, and some report inconsistent communication, so ask the recruiter what follows and when. Your main job is a concise, credible account of your work, since every technology on your CV can become a follow-up.

What to demonstrate

• Background and fit for the role as you describe it
• How clearly you summarise your own projects and your part in them
• Whether your stated experience matches the language and database requirements the role lists

How to prepare

• Write a two-minute walk through your CV and rehearse it aloud, naming the language, database and cloud tools you actually used.
• For each technology on your resume, prepare one sentence on how it works internally, not only how you called it.
• Prepare a specific answer to why this company, based on the platform's reported work (trading, ledgers, market data), plus questions about the team's technical challenges.
• Ask which stages remain and keep the recruiter's answers in writing, because candidates report uneven communication.

Technical Evaluation

The Technical Evaluation is reported as multiple rounds covering coding, system design and wider technical skills. Candidates describe two reported evaluation areas. The first is data structures and algorithms (dynamic programming, graphs, complexity), with reported example prompts such as optimizing a tree traversal for memory efficiency and explaining the performance cost of a data structure choice under a specific constraint. The second is system design: SQL versus NoSQL, sharding, replication and load balancing, and RESTful or gRPC API design, with prompts such as how the system handles a sudden spike in traffic and what changes if consistency requirements get stricter. Candidates also mention core CS fundamentals (OS, computer architecture, databases) and being asked to run code locally.

What to demonstrate

• Clean, optimised, bug-free code, with more than one approach and the trade-offs between them
• Defending database, caching and communication-protocol choices in a design
• Core computer science fundamentals behind those choices

How to prepare

• For each coding problem, give a brute-force approach, the optimised one, and the complexity difference, then run your own tests.
• Design the URL shortener end to end: ID generation, storage, read-heavy caching, redirect behaviour and what happens during a traffic spike.
• Prepare the locker management database schema with a constraint that stops two active bookings on the same locker, and be able to say why you chose PostgreSQL or a NoSQL store.
• Rehearse the stricter-consistency follow-up: name what you would change (transactions, synchronous replication, fewer caches) and what it costs in latency and availability.

Cultural Alignment

Cultural Alignment is reported as an assessment of fit with the company's culture and values. Candidates are advised to discuss their past projects with real engagement and to show they can learn and handle ambiguity. The reported behavioral questions are about a difficult colleague, what attracts you to CoinSwitch's vision and mission, your biggest challenge in a previous role, and how you take feedback when your technical approach is questioned. Prepare stories with decisions, trade-offs and results, not summaries of what the team did.

What to demonstrate

• Fit with the company's culture and values, as the stage is described
• Communication style and the way you describe past experience
• How you respond to disagreement about technical choices

How to prepare

• Write four stories in situation, action, result form: a difficult colleague, your largest challenge, a time your approach was challenged, and a decision made under ambiguity.
• Prepare a mission answer built from facts you checked yourself, such as the product's visible features and the engineering problems the role describes.
• For every story, prepare the numbers or observable outcome and one thing you would change.
• Prepare two questions for the team: its current technical challenges, and how it balances delivery speed against code quality.

Where candidates lose points

Writing the dynamic programming code before defining the state, then getting Coin Change 2 or the knapsack subtly wrong (the wrong loop order counts orderings, or a 0/1 knapsack reuses an item).

Define the state in words first, such as dp[a] = number of combinations that make amount a, and fix the loop order deliberately: coins in the outer loop for combinations, capacity iterated downward in a one-dimensional 0/1 knapsack. Then state O(n·amount) time and the space you used.

Answering the string-array search and tree traversal questions with the first approach that works, with no alternative and no complexity.

For the array of strings, ask whether queries are one-off or repeated, then compare a linear scan, sorting with binary search, a hash set and a trie for prefix queries. For the tree, give recursive, iterative-stack and constant-extra-space approaches and say what each costs.

Starting the URL shortener or locker database without scoping, then listing components with no reason for each (a cache, a NoSQL store or a queue added by habit).

State read and write volumes and failure expectations first, design the read path and write path separately, and justify each store by its access pattern. For the locker schema, show the constraint that prevents double booking, not just the tables.

Giving slogan answers to the concept questions: NoSQL because it scales, high availability because of replicas, public versus private IP without a network picture.

Tie each answer to a concrete failure or access pattern. For private versus public IPs, draw a public-facing load balancer, services and databases on private addresses, and outbound traffic through a gateway. For availability, say what fails over, what detects it and what data can be stale.

Going quiet when stuck, or only practising in an environment that differs from a local IDE or online compiler, since candidates report being asked to run code.

Narrate assumptions and ask clarifying questions when you hit a wall. Practise by writing, running and debugging real code in a plain IDE and an online compiler, and write your own test cases before calling a solution finished.

Questions & practice

How would you implement a solution for the Coin Change 2 problem using dynamic programming?

Medium · Data Structures and Algorithms

Approach

1. Define dp[a] as the number of coin combinations that sum to a, with dp[0] = 1 because there is exactly one way to make zero: choose no coins.
2. Loop coins in the outer loop and amounts from coin up to the target in the inner loop: dp[a] += dp[a - coin]. Keeping coins outside counts each multiset once; swapping the loops counts ordered sequences instead, which is a different problem.
3. Complexity is O(n * amount) time and O(amount) space with the 1-D array; the 2-D table dp[i][a] gives the same time with O(n * amount) space and is easier to explain first.
4. Edge cases: amount 0 returns 1 even with no coins, a coin larger than the amount contributes nothing, and counts can grow fast, so use a 64-bit type or take a modulus if the problem asks for one.

Follow-up

• How would you return the minimum number of coins instead of the number of combinations?
• What changes if order matters, so 1+2 and 2+1 count as different ways?
• Can you write the top-down memoised version and compare its recursion depth with the bottom-up table?

Given an array of strings, can you optimize the search time complexity?

Medium · Data Structures and Algorithms

Approach

1. Clarify the query first: exact match, prefix match, or substring; one search or many; and whether the array is static or receives inserts.
2. Baseline is a linear scan at O(n * L) per query, where L is string length. For repeated exact lookups, build a hash set once in O(total characters) and answer each query in expected O(L).
3. For prefix queries, a trie answers in O(L) plus the size of the output; alternatively sort once in O(n log n) string comparisons and binary search for the lower bound of the prefix, giving O(L log n) per query with far less memory than a trie.
4. Name the trade-off out loud: a hash set cannot do prefix or range queries, a trie costs a node per character, and a sorted array is cheap to store but O(n) per insert.
5. Edge cases: duplicates, empty strings, case and Unicode normalisation, and very long strings that make hashing itself the dominant cost.

Follow-up

• How would you support wildcard or one-typo fuzzy search?
• What would you do if the strings no longer fit in memory?
• How does the choice change if the array is updated as often as it is searched?

Explain your approach to solving a tree-based traversal problem.

Medium · Data Structures and Algorithms

Approach

1. Say which traversal the problem needs and why: preorder to copy or serialise, inorder to read a BST in sorted order, postorder when a node needs results from its children (heights, subtree sums), level order (BFS with a queue) for anything per depth.
2. Recursive DFS is O(n) time and O(h) stack space; on a skewed tree h equals n, which can overflow the call stack (Python's default recursion limit is 1000), so be ready to convert to an explicit stack.
3. BFS uses O(w) space, where w is the widest level; process one level at a time by reading the queue length before the inner loop.
4. If asked to cut memory, describe Morris traversal: it threads each node's inorder predecessor back to it, gives O(1) extra space and O(n) time, and restores the tree before returning.
5. Test on an empty root, a single node, a fully left-skewed tree and a complete tree before calling it done.

Follow-up

• Can you write iterative postorder with one stack?
• How would you return a zigzag level order?
• When would Morris traversal be unsafe, for example with concurrent readers of the tree?

Can you solve a classic knapsack problem and explain the time/space complexity?

Medium · Data Structures and Algorithms

Approach

1. State the 0/1 recurrence: dp[i][w] = max(dp[i-1][w], dp[i-1][w - weight_i] + value_i) when weight_i <= w, with dp[0][w] = 0.
2. Time and space are O(n * W). Reduce space to O(W) with a 1-D array by iterating w downward from W to weight_i, so each item is used at most once; iterating upward turns it into the unbounded knapsack.
3. Explain that O(n * W) is pseudo-polynomial: it is polynomial in the value of W, not in its bit length, which is why 0/1 knapsack stays NP-hard.
4. Separate the variants: fractional knapsack is solved greedily by value-to-weight ratio in O(n log n); greedy fails for 0/1.
5. To list the chosen items, keep the 2-D table (or a choice bitmap) and walk back from dp[n][W]; the 1-D array alone cannot recover them.

Follow-up

• If W is huge but total value is small, how would you change the DP?
• How would you reconstruct the selected items with O(W) memory?
• What if n is around 40 and W is very large?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

How would you design a URL shortening service (e.g., TinyURL)?

Medium · System Design (HLD & LLD)

Approach

1. Pin the API and the numbers: POST /shorten returns a code, GET /{code} redirects; estimate writes per second, the read-to-write ratio, and storage for the retention period before choosing components.
2. Key generation: base62-encode a unique 64-bit ID, where 7 characters give 62^7, about 3.5 trillion codes. Hand each app server a block of IDs from a central counter so there is no per-request coordination, or hash the URL and resolve collisions with a uniqueness check. Note that sequential codes are guessable.
3. Storage is a key-value lookup (code to long URL, owner, expiry), so a key-value or wide-column store partitioned by code fits; put a cache such as Redis in front of reads, because hot links dominate traffic.
4. Redirect choice: 301 lets browsers cache the redirect and cuts load but hides repeat clicks; 302 keeps every click visible for analytics.
5. Cover custom aliases (unique constraint), expiry and cleanup, rate limiting on creation, and screening for malicious target URLs.

Follow-up

• Should the same long URL always return the same code, and what does that cost?
• How would you count clicks per link without slowing the redirect path?
• How does the ID allocator avoid becoming a single point of failure?

Describe the database design for a locker management system.

Medium · System Design (HLD & LLD)

Approach

1. Name the entities: location, locker (location_id, size, status), parcel or order, user, and an assignment row (locker_id, parcel_id, pickup code hash, assigned_at, expires_at, picked_up_at) that also serves as history.
2. Index lockers on (location_id, size, status) so finding a free locker of the right size at a site is one index lookup.
3. Make allocation safe under concurrency: in PostgreSQL, SELECT a free locker FOR UPDATE SKIP LOCKED inside the transaction that inserts the assignment, or run a conditional UPDATE ... SET status = 'reserved' WHERE id = ? AND status = 'free' and check the affected row count.
4. Enforce one active assignment per locker in the schema with a partial unique index on assignment(locker_id) WHERE picked_up_at IS NULL, so a bug in application code cannot double-book.
5. Store the pickup code hashed, run a job that releases expired reservations and flags parcels for return, and keep the status column as a cache of the assignment table, not a second source of truth.

Follow-up

• If no locker of the requested size is free, how do you fall back to the next size up?
• How would you handle a locker that is reported broken while it holds a parcel?
• How would this schema scale to thousands of locations?

When and why would you choose a NoSQL database over a relational database like PostgreSQL?

Medium · System Design (HLD & LLD)

Approach

1. Decide from access patterns and invariants, not fashion: relational databases give joins, multi-row ACID transactions, foreign keys and check constraints, which is what money movement and balance ledgers need.
2. Name the NoSQL families and what each is for: key-value (sessions, caches), document (records whose shape varies), wide-column such as Cassandra (very high write rates queried by a known partition key, like time-series ticks or event logs), graph (relationship traversal).
3. Reasons to pick NoSQL: you know your queries in advance, need to spread writes horizontally across nodes, and can accept denormalised data and, in many stores, eventual or tunable consistency.
4. Costs to state: duplicated data across query-shaped tables, weak or no ad-hoc joins, and harder multi-entity transactions. Also note that PostgreSQL covers part of the gap with JSONB, partitioning and read replicas.
5. A strong answer is often both: PostgreSQL as the system of record, plus a NoSQL or cache store for high-volume, key-addressed data.

Follow-up

• How would you model the same data in Cassandra, starting from the queries?
• What does CAP force you to choose during a network partition?
• How would you migrate a growing table out of PostgreSQL without downtime?

How do you ensure high availability and load balancing in a distributed system?

Medium · System Design (HLD & LLD)

Approach

1. Start by removing single points of failure: run several stateless instances across availability zones, keep session state in a shared store, and make the load balancer itself redundant (managed LB, DNS failover or an active-passive virtual IP).
2. Explain load balancing: L4 versus L7, algorithms (round robin, least connections, consistent hashing when cache affinity matters), health checks that eject bad nodes, and connection draining during deploys.
3. Data tier: primary with replicas and automatic failover. Synchronous replication avoids losing acknowledged writes at the cost of latency; asynchronous can lose the last writes on failover. Say how you prevent split-brain (fencing or quorum).
4. Contain failures: timeouts on every call, retries with exponential backoff and jitter, circuit breakers, rate limiting and load shedding; for traffic spikes, add autoscaling and a queue to absorb bursts.
5. Quantify it: 99.9% availability allows about 8.8 hours of downtime a year, and dependencies in series multiply, so two 99.9% services in a chain give about 99.8%.

Follow-up

• What goes wrong with sticky sessions, and when are they still justified?
• How does your system handle a sudden spike in traffic?
• How would you test failover before a real outage?

Explain the role of private versus public IPs in your system architecture.

Medium · System Design (HLD & LLD)

Approach

1. Define the terms: private ranges from RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are not routed on the public internet; public IPs are globally routable, and IPv4 addresses are scarce.
2. Lay out the network: a VPC with public subnets holding only the internet-facing load balancer and a NAT gateway, and private subnets holding app servers, databases and caches with no public address.
3. Traffic paths: inbound requests enter through the load balancer, which forwards to private IPs; outbound calls from private hosts (patches, third-party APIs) leave through the NAT, so outsiders cannot open connections to them.
4. Layer controls on top: security groups that allow the database port only from the app tier, network ACLs, and admin access through a bastion, VPN or session manager rather than a public SSH port.
5. Mention practical details: give public endpoints stable addresses for DNS and partner allowlists, and plan CIDR blocks so peered VPCs or on-prem networks do not overlap.

Follow-up

• How does a server with only a private IP install updates?
• How would an engineer reach a private database to debug it?
• What breaks when two VPCs you need to peer use overlapping CIDR ranges?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Each day targets one family of reported questions: the coding topics, the design and database topics, then the behavioral stories. Days 1 and 6 cover running code outside a text box and mock sessions, which candidates report some interviewers ask for.

Day 1 — Map the loop and set up your coding environment

• Write out the four reported rounds (Online Assessment, Screening Call, Technical Evaluation, Cultural Alignment) with one line each on what candidates report, and mark the stage you feel least ready for.
• Choose one language from the role's list (Java, Go, Python or JavaScript) and set up a plain IDE plus an online compiler where you can write, run and debug code.
• Write a two-minute CV walk-through and list one internal-workings fact for each technology on your resume.

Deliverable: A one-page loop map with your weakest stage marked, a working local setup that runs a hello-world with a test, and a rehearsed CV walk-through.

Day 2 — Dynamic programming: Coin Change 2 and knapsack

• Solve Coin Change 2 as a memoized recursion, a two-dimensional table and a one-dimensional table, and write why coins go in the outer loop for combinations.
• Solve the 0/1 knapsack with a table, then compress to one dimension by iterating capacity downward, and note what changes for the unbounded version.
• Write time and space complexity for each version, including why the knapsack runtime is pseudo-polynomial.

Deliverable: Runnable solutions for Coin Change 2 and knapsack in your language, each with a stated complexity and a note on the loop-order mistake.

Day 3 — Strings, trees and graph test design

• For the array-of-strings search question, compare linear scan, sorted array with binary search, hash set and trie, and write when each wins by query type.
• Solve a tree traversal recursively, iteratively with a stack, and with constant extra space, noting recursion depth risk and the memory cost of each.
• Write a test matrix for a degree-connections graph problem (empty, isolated, cycle, disconnected, shortest versus longer path, k beyond the diameter) and implement the BFS to pass it.

Deliverable: Three solutions with complexities, plus a written graph test matrix that your BFS passes on your own machine.

Day 4 — Databases: schema design and SQL versus NoSQL

• Design the locker management database in PostgreSQL (lockers, sizes, bookings, status), including a constraint that prevents two active bookings on one locker, and write the booking query.
• Write a comparison of NoSQL and PostgreSQL by access pattern, transactions, consistency and schema flexibility, ending with the cases where you would pick each.

Deliverable: A locker schema with its constraints and booking query, a one-page NoSQL versus PostgreSQL decision table, and completed practice questions on concurrency and uniqueness.

Day 5 — System design: URL shortener, availability and networking

• Design the URL shortener end to end: state read and write volumes, choose an ID generation approach, pick a store, add a cache for redirects and describe collision and expiry handling.
• Write how you would keep the service highly available behind a load balancer: health checks, stateless services, replication, failover, and what data can be stale.
• Draw the network layout that answers private versus public IPs: public load balancer, services and databases on private addresses, and outbound access through a gateway.
• Answer the reported follow-ups aloud: how the system handles a sudden traffic spike, and what you change if consistency requirements get stricter.

Deliverable: A written URL shortener design, an availability checklist, a network diagram, and recorded spoken answers to the two follow-ups.

Day 6 — Mock round: coding aloud and debugging

• Pick one dynamic programming problem and one tree or graph problem from the earlier days and solve each aloud in your plain IDE, stating assumptions, writing tests and running them.
• Redo one earlier solution a second way and explain the trade-off between the two versions, the way the reported prompt about a data structure's performance cost asks.

Deliverable: Two recorded aloud solutions with passing tests, a note comparing two approaches, and a written debugging sequence for the memory-growth practice question.

Day 7 — Behavioral stories and the screening conversation

• Write situation, action and result outlines for the difficult-colleague question and the biggest-challenge question, each with the options you weighed and a measured outcome.
• Write the feedback story for when your technical approach is questioned, showing the evidence you used and one case where you changed your mind.
• Write your answer about what attracts you to CoinSwitch from facts you have checked, plus two questions for the team about its technical challenges and how it balances speed with code quality.

Deliverable: Four written story outlines, a mission answer, two team questions and a rehearsed screening-call summary.

Behavioral and culture preparation for CoinSwitch

Candidates report that the culture stage and the behavioral question group centre on how you communicate, what you have done before, and how you fit the company. For an engineering role that means stories with a technical decision, a disagreement and a measured result, and a motivation answer built from facts you checked.

1. Walk me through a project on your resume and explain how one of its technologies works internally.
2. Tell me about a time you had to deliver while requirements were unclear.

How do you handle test cases for a graph-based problem involving degree connections?

Medium · Data Structures and Algorithms

Approach

1. Treat this as test design for a graph where connections are counted in degrees. Start by pinning the definition: a degree is the shortest hop count, the graph may be directed or undirected, and the function may return people at exactly k degrees or within k. Every test case follows from those choices, so state them first.
2. Cover structural cases: an empty graph, a single node, a node with no edges, a start node that is not in the graph, self-loops, duplicate edges, a disconnected component, a cycle (to prove the visited set stops infinite loops), a star with high fan-out and a long chain for depth.
3. Cover degree-specific cases: a node reachable by both a 1-hop and a 3-hop path must appear as a first-degree connection only, k = 0, k larger than the graph's diameter, and for a directed graph a connection that exists in one direction only. These catch BFS level-counting bugs.
4. Check correctness with a hand-traced small graph, then an oracle: a brute-force all-pairs shortest-path run on small random graphs compared with the BFS result. Add one large input (for example a chain of 100,000 nodes) to check performance, O(V + E), and recursion depth; an iterative BFS avoids stack overflow.
5. Say the process aloud: write the tests before or alongside the code, run them in your editor, and fix failures one at a time. A short story about an edge case you missed once and how you now find it earlier makes the answer concrete.

Follow-up

• How would you test this if the graph did not fit in memory?
• Which input makes your BFS slowest, and how would you test for it?
• How would you write a property-based test for it, and what invariants would it check?

Tell me about a time you had a difficult working relationship with a colleague; how did you address it?

Medium · Behavioral and Cultural

Approach

1. Choose a conflict with real stakes, such as repeated blocked reviews, a missed handoff or a design dispute, where the friction affected delivery. Keep the situation to a few sentences and spend the rest on what you did.
2. Describe your own part honestly: what you assumed about the colleague, and what you changed once you learned their constraints. A story where the other person is the sole problem usually sounds incomplete.
3. Show a direct, private conversation about specific behaviour and its effect, with questions that asked for their view, before any escalation. Then show a concrete agreement, such as a review turnaround expectation, a written decision or a split of ownership.
4. Close with an observable result and the current relationship: a feature shipped, review cycles shortened or the two of you now pairing. Name what you would do earlier next time. The story fails if it ends with the manager solving it or with no resolution.

Follow-up

• What if they had not changed after that conversation?
• What would you do differently if you ran this again?
• How do you work with that person today?

What attracts you most to the vision and mission of CoinSwitch?

Medium · Behavioral and Cultural

Approach

1. This is a motivation answer, not a STAR story, so build it in three parts: what you know about the product, why that problem matches your experience, and what you want to own or learn there. Keep each part specific to you.
2. For the first part, use facts you verified: it is a crypto-asset platform, and the role description mentions trading, ledgers, market data and microservices. Use the product as a user if you can, and mention something you actually noticed. Do not state a mission you have not confirmed.
3. For the second part, link one real project to the problem: a ledger or payments system, a high-traffic service, a consistency bug you fixed. Explain why correctness, latency or security was hard in that project.
4. For the third part, show you understand the domain's risks, for example the cost of a duplicated or lost transaction or security of user assets, and say how you would approach learning them. Avoid flattery, price speculation and generic claims about changing finance.

Follow-up

• What concerns, if any, do you have about working in crypto, and how do you weigh them?
• What have you used or read about the product, and what would you improve?
• What would you want to build or learn in your first few months?

What was the most significant challenge you faced in your previous role?

Medium · Behavioral and Cultural

Approach

1. Pick a challenge where you made the key decisions and that you can explain technically, such as a slow query, a failed migration, a reliability problem or an ambiguous project with changing requirements. Skip a challenge that was only hard because of workload.
2. Structure it as situation, options, decision, result. Name at least two options you weighed and why you rejected the alternative, with the trade-off in plain terms (risk, cost, time or complexity).
3. State what could have gone wrong and how you contained it: a staged rollout, a rollback plan, a test, a benchmark or monitoring. Be ready to describe how the underlying technology works, since any detail of a project you mention can be examined.
4. End with a measured outcome (latency, error rate, delivery date or reduced incidents) and one lesson that changed your later practice. The story sinks if it is a heroic overnight rescue with no reasoning, or if the blame lands on others.

Follow-up

• Which alternative did you reject, and would you reject it again?
• How did you know the change caused the improvement?
• What would you do differently now?

How do you handle feedback when your technical approach is questioned?

Medium · Behavioral and Cultural

Approach

1. Use a real instance where a design, an algorithm or a pull request was challenged. Say what the approach was, what the objection was and who raised it, so the listener sees an actual disagreement rather than a polite hypothetical.
2. Show the sequence: you listened and restated the objection, separated evidence from preference, then tested the claim with a benchmark, a small prototype, a failure scenario or the project's constraints. Name the criteria you used to decide, such as latency, operational cost or consistency.
3. Show both outcomes in your behaviour: you changed the approach when the evidence favoured the critic, and you held your position with data and recorded the reasoning when it did not. Change on the first pushback and never changing are both weak answers.
4. Mention the follow-through: a short written decision, an updated pull request, and a check afterwards that the decision worked. Keep the tone about the code, not the person.

Follow-up

• What do you do when a more senior engineer is wrong and holds firm?
• How do you disagree and still commit when the decision goes against you?
• What if the debate is unresolved and a deadline is close?