The work candidates describe sits where general software engineering meets blockchain security. The product line they list is smart contract audits, security tools and blockchain infrastructure, and the role is described as building secure software for decentralized applications, reviewing code and working through requirements with other teams. That is why the reported questions mix two kinds of material: engineering fundamentals that any backend or full-stack candidate meets (synchronous versus asynchronous code, interfaces, debugging, API design, microservice scalability), and a smaller group with a blockchain flavour (a transaction-processing system, fraud analysis on transaction histories, a dApp for digital identities).
The requirements candidates describe name Python, JavaScript and Solidity, a solid grounding in algorithms and data structures, and experience with web frameworks. Familiarity with blockchain, cloud platforms such as AWS or Azure, and DevOps practice is described as a plus rather than a requirement, and candidates mention 3-5 years of development experience and a computer science degree. The topic breakdown for this loop adds Solidity, Solidity compiler frontend, formal methods, React and algorithmic problem solving. No specific question is reported for compiler frontend or formal methods, so treat them as areas where your resume may be probed and make sure you can explain the basics.
For preparation, split your time across three layers. First, the three reported coding questions (maximum profit from stock prices, hash table implementation and complexities, balanced binary tree check) are small enough to master fully, including edge cases and complexity. Second, the design and case-study questions reward a structured method: scope, components, failure behaviour, then trade-offs. Third, the behavioral round is reported as an assessment of fit and interpersonal skills, with prompts on team conflict, prioritizing across projects and motivation, so each needs a real story or a concrete framework prepared in advance.
Phone Screen
reportedCandidates describe the Phone Screen as an opening call about your background and how well you fit the role. No technical content is reported for it, so treat it as the first chance to link your experience to what the role involves: Python, JavaScript or Solidity work, web development, and anything touching security or blockchain. Have a short, structured account of your career and a clear reason for wanting security-focused blockchain work.
What to demonstrate
- Your background and how it maps to the Software Engineer role
- How clearly you can summarize your own projects and contributions
- Fit with the role as candidates describe it, including language and web framework experience
How to prepare
- Write a concise career narrative that ends with why security-focused blockchain engineering, and rehearse it aloud until it holds together without notes.
- List your projects with the language, your specific contribution and one concrete outcome each; mark which ones used Python, JavaScript, Solidity or a web framework.
- Skim blockchain basics (blocks, transactions, hashing, signatures, smart contracts) so you can follow and join a conversation about them even if you have not built on a chain.
- Ask what the later stages cover, so you know whether coding or case studies are expected next.
Technical Interview
reportedCandidates describe the Technical Interview as a stage that may include coding challenges or case studies. It is where the reported coding questions are practised: maximum profit from stock prices, hash table implementation with its complexities, and the balanced binary tree check. The reported case-study and design questions cover a blockchain transaction-processing system, fraud analysis over transaction histories, a digital-identity dApp, API design factors and microservice scalability. Language and engineering concept questions (synchronous versus asynchronous, interfaces, debugging a complex issue) are also reported for this loop. Practise writing working code first, then explaining it, and for design questions state scope and assumptions before components.
What to demonstrate
- Working, correct code for algorithm and data structure problems
- Structured reasoning from requirements to design in a case study
- Command of core concepts such as asynchronous execution, interfaces and debugging method
- How well you explain technical choices and their trade-offs
How to prepare
- Solve the stock-price profit, hash table and balanced-tree problems in your strongest language until you can state the complexity and list edge cases without prompting.
- Write a one-page outline for the blockchain transaction-processing design: submission, validation, ordering, confirmation, retries and failure handling.
- Prepare a fraud-analysis plan for transaction histories: what counts as fraud, which features and rules you would start with, how you would validate findings.
- Practise explaining synchronous versus asynchronous behaviour and the purpose of interfaces using a concrete example in Python or JavaScript.
Behavioral Interview
reportedCandidates describe the Behavioral Interview as an assessment of fit with the company culture and of interpersonal skills. The reported prompts are about handling a conflict in your team, prioritizing across multiple projects and what motivates you; a prompt about persuading teammates to adopt your approach is also mentioned. Prepare specific stories in which you made the decisions, and give each one a clear situation, the options you weighed, the action you took and a result you can state.
What to demonstrate
- Fit with the company culture, as the round is described
- Interpersonal skills: handling disagreement, persuading peers, working with a team
- How you reason about priorities and your own motivation
How to prepare
- Write three stories with named decisions and results: a team conflict, a prioritization under competing deadlines, and a time you persuaded others to adopt your approach.
- Prepare a spoken answer for what motivates you, backed by two real examples from your work history.
- Review the responsibilities candidates describe (code review, cross-functional specification work) and pick a story from your own experience that shows each.
- Rehearse each story aloud so the situation takes a couple of sentences and the rest covers your decisions and what changed.
PracHub editorial advice for the preparation topics above.
Answering the synchronous-versus-asynchronous or interfaces question with a textbook definition only
Pair each definition with a concrete example in a language you use, such as Python asyncio or JavaScript promises. Say when blocking code is the right choice, and show an interface decoupling a caller from an implementation you can swap, for instance a test double.
Giving hash table complexity as plain O(1) and missing the balanced-tree edge cases
Separate average from worst case for the hash table, mention load factor, resizing and collision handling, then state the cost of each operation. For the balanced-tree question, avoid recomputing heights at every node; return height and balance status in one pass. For the stock prices question, handle empty input and falling prices, where the best profit is zero.
Opening the blockchain transaction-processing or digital-identity design with buzzwords instead of scope
Ask who submits transactions, how many, and what finality the user needs. Then separate submission, validation, ordering and confirmation, and say what happens on retries, duplicates and failures before you add components.
Treating the fraud-analysis case as 'train a model' without defining fraud
Define what fraud means for these transactions, list the features and rules you would examine first (amounts, velocity, counterparties, timing), choose a baseline, and say how you would validate findings and cost false positives.
Telling behavioral stories where you were a bystander, or where the conflict has a villain and no resolution
Choose stories where you made the decision, give the other side's reasonable position, show the evidence you used, and state the outcome and what you would change.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the differences between synchronous and asynchronous programming.
Explain the differences between synchronous and asynchronous programming.
Approach
- Define both precisely: a synchronous call blocks the caller until the result is ready, so control follows source order; an asynchronous call starts the work and returns at once, and the result arrives later through a callback, a promise/future, or resumption after await.
- Separate asynchrony from parallelism: a single-threaded event loop (JavaScript, Python asyncio) interleaves tasks at await points, which is concurrency without parallel execution. CPU-bound work still blocks the loop, so I move it to worker threads or processes (worker_threads, ProcessPoolExecutor).
- Give the case where it pays: I/O-bound fan-out. Issuing ten RPC or HTTP calls with Promise.all or asyncio.gather makes total latency roughly the slowest call instead of the sum of all ten.
- Name the pitfalls: a missing await (an unhandled rejected promise in JS, a coroutine that never runs in Python), errors that surface far from their cause, shared state changing between await points even on one thread, and unbounded concurrency that needs a semaphore or pool limit.
Follow-up
- If one call inside Promise.all rejects, what happens to the others, and when would you use Promise.allSettled instead?
- How would you call a blocking library from inside async code without stalling the event loop?
- Would making a CPU-heavy hashing routine async make it faster? Why or why not?
Write a function to calculate the maximum profit from an array of stock prices.
Write a function to calculate the maximum profit from an array of stock prices.
Approach
- Clarify the variant: the standard version allows one buy followed by one later sell and returns 0 when no profit is possible; empty or single-price arrays also return 0.
- Name the brute force: try every buy/sell pair with i < j, O(n^2) time, O(1) space.
- Give the one-pass solution: keep the minimum price seen so far and, at each price, update best = max(best, price - minPrice), then update minPrice. O(n) time, O(1) space; a strictly decreasing array correctly yields 0.
- Be ready for the other variants: unlimited transactions is the sum of all positive day-to-day differences, O(n); at most two transactions is a four-variable DP in O(n); at most k transactions is a DP in O(n*k); a cooldown or fee is a small hold/cash state machine.
- Test aloud with edge cases: [7,1,5,3,6,4] gives 5, [7,6,4,3,1] gives 0, a single element gives 0, and equal prices give 0.
Follow-up
- How does the solution change if you may make as many transactions as you like?
- Now allow at most two transactions. What state do you track?
- Return the buy and sell days as well as the profit. What changes?
Explain how you would implement a hash table and what its time complexities are for various operations.
Explain how you would implement a hash table and what its time complexities are for various operations.
Approach
- Describe the structure: an array of buckets, with index = hash(key) mod capacity (or hash & (capacity - 1) when capacity is a power of two, which needs a hash whose low bits are well mixed), plus an equality check to confirm the key.
- Explain collision handling: separate chaining keeps a list per bucket (Java's HashMap converts a bucket to a red-black tree at 8 entries once the table has at least 64 buckets); open addressing probes for the next free slot (linear, quadratic or double hashing), is cache-friendly, and needs tombstones for deletion. CPython's dict uses open addressing.
- State complexities: insert, lookup and delete are O(1) on average with a good hash and a bounded load factor; worst case is O(n) when keys collide (O(log n) per bucket with Java's treeified bins).
- Cover resizing: when the load factor passes a threshold (0.75 by default in Java's HashMap) I allocate a larger array, typically double, and rehash every entry. That insert costs O(n), but doubling keeps inserts amortized O(1).
- Mention the edge cases: mutating a key after insertion strands it in the wrong bucket, and attacker-chosen keys can force collisions (hash flooding), which is why Python uses keyed SipHash for str and bytes.
Follow-up
- How do you delete under linear probing without breaking later lookups?
- How would you make the table safe for concurrent readers and writers?
- Why does a power-of-two capacity help, and what does it demand of the hash function?
Given a binary tree, write a function to check if it is balanced.
Given a binary tree, write a function to check if it is balanced.
Approach
- Pin the definition: a tree is height-balanced when, at every node, the heights of the left and right subtrees differ by at most 1. Checking only the root is wrong, because both root subtrees can share a height while a deeper node is unbalanced.
- Name the naive version: call a height function at every node top-down. That recomputes heights, costing O(n^2) on a skewed tree and O(n log n) on a balanced one.
- Give the optimal version: a post-order recursion that returns the subtree height, or -1 as a sentinel once any subtree is unbalanced, and stops early on -1. Each node is visited once: O(n) time, O(h) stack space.
- Handle edge cases: an empty tree is balanced, a single node is balanced, and a degenerate chain of many nodes can exceed Python's default recursion limit of 1000, so an iterative post-order with an explicit stack and a height map is the safe fallback.
- Distinguish the term from 'complete' or 'perfect' trees, and note this is the same invariant AVL trees maintain.
Follow-up
- Write it iteratively without recursion.
- Return the lowest node at which the balance condition fails.
- Given an unbalanced binary search tree, how would you rebalance it?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
Hold a per-tenant active cap against concurrent creates
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
- 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.
- 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.
- 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.
- 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?
What is the purpose of using interfaces in object-oriented programming?
What is the purpose of using interfaces in object-oriented programming?
Approach
- State the core idea: an interface is a contract of method signatures with no implementation, so callers depend on the abstraction rather than a concrete class. That gives polymorphism and dependency inversion.
- Give concrete payoffs: swapping implementations behind one contract (an in-memory repository in tests, a Postgres one in production), injecting test doubles, and letting a class implement several interfaces in Java or C#, where a class can extend only one class.
- Contrast with an abstract class: it can hold state, constructors and shared implementation, while an interface traditionally holds none (Java 8+ default methods blur this). I pick the abstract class when implementations share real code.
- Show the idea across languages: TypeScript interfaces are structural and erased at compile time, Go types satisfy interfaces implicitly, Python uses ABCs or typing.Protocol, and a Solidity interface declares external functions only (no state variables, constructor or bodies), used to call another contract such as an ERC-20 token.
- Add the design cautions: keep interfaces small (interface segregation), and skip an interface for a class that will only ever have one implementation and no test seam.
Follow-up
- When would you choose an abstract base class over an interface?
- How does an interface let you unit-test a component that normally talks to a database or a blockchain node?
- How would you add a method to an interface that many classes already implement without breaking them?
How would you design a system to process transactions in a blockchain environment?
How would you design a system to process transactions in a blockchain environment?
Approach
- Fix the scope out loud: am I designing the chain's own transaction pipeline (mempool, ordering, execution, consensus) or an off-chain service that submits and tracks transactions on an existing chain? I state which and the target throughput and finality needs.
- Ingest and validation: verify the signature, nonce, balance and fee/gas limit; deduplicate by transaction hash; keep a mempool indexed by sender and nonce and ordered by fee; gossip valid transactions to peers.
- Ordering and execution: the block producer selects by fee while respecting each sender's nonce order; execution must be deterministic so every node reaches the same state root; a consensus protocol (for example a BFT-style or proof-of-stake scheme) agrees on the block and defines finality.
- For the off-chain service side: a nonce manager per signing account, idempotent submission keyed by transaction hash, explicit states (submitted, pending, included, confirmed after N blocks or finalized), fee-bump replacement for stuck transactions, and reorg handling that rolls back state derived from orphaned blocks.
- Name the throughput trade-offs: capacity is bounded by block gas limit and block interval; options are batching, layer-2 rollups and sharding, each paying in latency, complexity or weaker composability. An indexer that copies blocks into a queryable database serves reads.
Follow-up
- A block you marked confirmed is dropped in a reorganization. What does your system do?
- How do you prevent a signed transaction from being replayed on the same chain or on another chain?
- Throughput needs to grow a hundredfold. Which of your components changes first?
Given a dataset of transaction histories, how would you analyze it to identify fraudulent activity?
Given a dataset of transaction histories, how would you analyze it to identify fraudulent activity?
Approach
- Clarify before modelling: which fraud types matter (account takeover, wash trading, laundering through layered transfers, sybil accounts), whether labelled fraud cases exist, and what action a flag triggers.
- Build features at account and graph level: transaction velocity in sliding windows (count and value per hour or day), deviation from the account's own baseline, share of new counterparties, round amounts, and graph features such as fan-in/fan-out, cycles that return funds to the origin, and proximity to already-flagged addresses. A SQL window function (SUM over a time-range window partitioned by account) computes the velocity features.
- Choose the method from the labels: rules and simple thresholds as a baseline; unsupervised scoring (isolation forest, clustering) when labels are missing; a supervised model such as gradient-boosted trees when they exist, with a time-based train/test split to avoid leakage.
- Evaluate for heavy class imbalance: accuracy is meaningless when fraud is rare, so report precision and recall, PR-AUC, and precision at the number of cases reviewers can actually check; weigh the cost of a false positive against a missed case.
- Plan for drift: feed analyst decisions back as labels, monitor score distributions, and retrain as behaviour shifts.
Follow-up
- Only 0.1% of transactions are fraud. How do you evaluate and compare models?
- How would you detect a ring of addresses trading the same asset back and forth to inflate volume?
- How do you keep the detector useful once the people being flagged change their behaviour?
Describe a challenging technical problem you faced in a previous project and how you resolved it.
Describe a challenging technical problem you faced in a previous project and how you resolved it.
Approach
- Pick a problem with real technical depth that I personally diagnosed or designed, such as a memory leak, race condition, data corruption or a performance regression, and state the constraints and stakes in two or three sentences.
- Walk the investigation in order: the hypotheses I formed, the evidence that ruled each one out, and the tool or measurement that finally exposed the cause (profiler, heap dump, trace, bisect).
- Explain the fix and its trade-off: the alternatives I considered, why I rejected them, and what the chosen fix cost in complexity, latency or delivery time.
- Close with a measured outcome (for example p99 latency or error rate before and after) and the lasting change: a regression test, alert or runbook.
- Avoid the mistakes that sink this answer: a team story told in 'we' with no visible personal contribution, a problem that was only organisational, or no technical detail an engineer could check.
Follow-up
- What would you do differently if you hit the same problem tomorrow?
- Which alternative fix came closest, and why did you reject it?
- How did you verify the fix worked rather than the problem going quiet on its own?
How would you design a decentralized application (dApp) for handling digital identities?
How would you design a decentralized application (dApp) for handling digital identities?
Approach
- Fix the actors and requirements: issuers (who attest facts), holders (users), verifiers (services checking claims); the needs are user control, privacy, revocation, key recovery and low verification cost.
- Keep personal data off-chain: a public, immutable ledger cannot honour deletion requests, and even hashes of low-entropy data such as birthdates can be brute-forced. On-chain I store only identifiers, public keys or controller addresses, and revocation status; credentials live in the user's wallet. W3C Decentralized Identifiers and Verifiable Credentials give the data model.
- Contracts and flows: a registry contract maps each identifier to its controller and keys, with only the controller allowed to rotate keys; issuers sign credentials off-chain; a verifier checks the issuer signature and an on-chain revocation bitmap or status list. Zero-knowledge proofs or selective disclosure let a user prove a predicate (over 18) without revealing the value.
- Security and cost: plan key loss up front (social recovery with guardians, multisig), batch revocation updates to save gas, restrict every state-changing function with access control, and have the contracts reviewed for the usual vulnerability classes.
- Client side: a web front end (React, which candidates list in this stack) connects a wallet and signs in by signing a server-issued nonce with a domain and expiry, so a captured signature cannot be replayed.
Follow-up
- A user loses their private key. How do they regain control of their identity?
- How do you revoke a credential without revealing on-chain which person held it?
- How do you stop a signed login message from being replayed against another site or later in time?
What factors do you consider when designing an API for a service?
What factors do you consider when designing an API for a service?
Approach
- Start from the consumers and resources: who calls it (browser, mobile, other services) decides REST, gRPC or GraphQL; model resources as nouns, keep naming consistent, and use cursor-based pagination for large or changing collections rather than offsets.
- Design for retries: GET, PUT and DELETE are idempotent by HTTP semantics, POST is not, so creation or payment-style endpoints accept an idempotency key and return the original result on a repeat.
- Define errors as carefully as success: correct status codes (400 validation, 401 unauthenticated, 403 forbidden, 404 missing, 409 conflict, 429 rate limited) plus a structured body with a stable machine-readable code clients can branch on.
- Plan evolution: make additive changes backward compatible, version breaking changes in the path or a header, and publish a deprecation window; describe the contract in OpenAPI or protobuf.
- Cover the non-functional side: authentication and authorization (OAuth 2.0 tokens, API keys), per-client rate limits, timeouts, request ids for tracing, and latency targets.
Follow-up
- How do you paginate a list that gains new items while a client is iterating through it?
- You need to rename a field many clients depend on. How do you roll that out?
- A client times out on a create request and retries. How do you avoid creating the record twice?
Explain how you would ensure scalability in a microservices architecture.
Explain how you would ensure scalability in a microservices architecture.
Approach
- Make services stateless so they scale horizontally behind a load balancer, with autoscaling on CPU, latency or queue depth; move session state into a shared store such as Redis or into signed tokens.
- Scale the data layer, usually the first bottleneck: a database per service, read replicas for read-heavy paths, cache-aside caching with explicit invalidation, and partitioning by a key that spreads load evenly.
- Decouple with asynchronous messaging: queues or event streams (Kafka, for example) absorb bursts, and consumers scale out per partition. Delivery is at-least-once, so consumers must be idempotent.
- Stop one slow service from cascading: timeouts on every call, retries with exponential backoff and jitter, circuit breakers, bulkheads and rate limiting at the gateway.
- Measure before scaling: distributed tracing and per-service rate, error and duration metrics, plus load tests, to find the real bottleneck. Name the costs: extra network hops, and sagas with eventual consistency instead of distributed transactions.
Follow-up
- How do you keep an order and its payment consistent across two services without a distributed transaction?
- How do you find out which service will fall over first under ten times the load?
- How do you stop client retries from turning a partial outage into a full one?
Describe how you would approach debugging a complex software issue.
Describe how you would approach debugging a complex software issue.
Approach
- Reproduce first: capture the exact input, environment, version and configuration, then shrink it to the smallest case that still fails. A bug I cannot reproduce I can only guess at.
- Collect evidence before theorising: stack traces, logs joined by request or correlation id, metrics around the first failure, and a list of what changed (deploys, config, dependency versions, input data).
- Narrow the search space by bisection: git bisect between a known-good and known-bad commit takes about log2(n) builds, and checking intermediate state at component boundaries halves the suspect code each time.
- Pick tools to fit the bug: a debugger with breakpoints locally; added structured logging or tracing in production; for race conditions, remember extra logging changes timing, so use stress runs, thread sanitizers or deterministic replays.
- Fix the root cause, not the symptom: write a regression test that fails before the fix and passes after it, confirm the original signal is gone, and record what made the bug hard to find.
Follow-up
- How would you debug an issue that only appears in production and never reproduces locally?
- The failure happens once in a few hundred runs. What changes in your approach?
- How do you convince yourself the fix addressed the cause rather than hiding the symptom?
A seven-day plan that follows the three reported rounds: fundamentals and the profile conversation first, coding and concept questions next, then design, role-specific topics and behavioral stories.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and your own profile
- Write the three reported rounds on one page (Phone Screen, Technical Interview, Behavioral Interview) and note what each stage is described as covering.
- List each project you could discuss, with its language (Python, JavaScript, Solidity or a web framework), your contribution and a concrete outcome.
- Write a one-page sheet of blockchain fundamentals: blocks, transactions, hashing, digital signatures, what a smart contract is, and what a fork is.
Deliverable: A one-page loop map, a project inventory with language and outcome, and a blockchain fundamentals sheet.
02Coding fundamentals
- Solve the stock-price maximum profit problem in one pass, and test it on empty input and on strictly falling prices.
- Implement a hash table with chaining and resizing; write the average and worst-case cost for insert, lookup and delete.
- Write the balanced binary tree check in O(n) by returning height and balance together, then compare it with the naive approach.
Deliverable: Three working solutions in your strongest language, each with a complexity note and an edge-case list.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Concepts and debugging method
- Write a short explanation of synchronous versus asynchronous programming with one code example each in Python and JavaScript.
- Explain the purpose of interfaces with an example where swapping an implementation is useful, such as replacing a real service with a test double.
- Write a debugging walkthrough from a real bug you fixed: symptom, reproduction, bisection, root cause, fix, regression test.
Deliverable: Two short written explanations with code, and one debugging walkthrough.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Blockchain-flavoured design
- Outline a transaction-processing system: how transactions are submitted, validated, ordered and confirmed, including duplicate handling and retries.
- Outline a digital-identity dApp: what is stored on-chain, what stays off-chain, and how a user proves ownership without exposing personal data.
- For each outline, list the first thing that breaks at ten times the load and what you would do about it.
Deliverable: Two design outlines, each with components, failure behaviour and a scaling bottleneck.
Practice prompt ↗Practice prompt ↗05API, microservices and analysis
- Write a checklist of API design factors for a service: versioning, idempotent retries, error taxonomy, pagination, authentication.
- Write a scalability plan for a microservices system: stateless services, queues, caching, database partitioning and observability.
- Write a fraud-analysis plan for transaction histories, and work the practice SQL question on why an owner filter ignores a listing index to practise query tuning.
Deliverable: An API checklist, a microservice scalability plan, a fraud-analysis plan and a worked query-tuning answer.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Role-specific topics
- Write brief notes on Solidity basics: storage versus memory, require and revert, events, and reentrancy with the checks-effects-interactions fix.
- Build a small tokenizer and recursive-descent parser for arithmetic expressions to understand the stages of a compiler frontend.
- Write loop invariants and pre- and postconditions for your day 2 solutions, and define model checking, theorem proving and SMT solving in a sentence each.
- Build a React component that fetches a list from an API and shows loading, error and empty states.
Deliverable: A Solidity notes page, a working parser, annotated invariants for the day 2 code and one React list component.
07Behavioral stories and a full rehearsal
- Write the team-conflict story and the prioritization answer in the situation, options, action, result form, and say each aloud.
- Prepare an answer on what motivates you, with two examples, plus a story about persuading teammates to adopt your approach.
- Pick your strongest technical challenge for the project question and rehearse it, then run one full spoken pass of the weakest design outline.
Deliverable: Four rehearsed stories (conflict, prioritization, motivation, persuasion), one project story and one spoken design pass.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The Behavioral Interview is reported as an assessment of fit and interpersonal skills, and the reported prompts cover team conflict, prioritizing across projects and what motivates you. The role is described as collaborative, with code review and cross-functional specification work, so choose stories that show you working with others and making decisions. Rehearse each as situation, options, action and result.
Describe a time when you had to handle a conflict within your team.
Describe a time when you had to handle a conflict within your team.
Approach
- Choose a conflict where the disagreement had a technical or delivery stake, such as two designs, a review dispute or a deadline against quality, and where you personally took action rather than observing.
- Set the scene briefly: who disagreed, what each side wanted, and why both positions were reasonable. Do not cast the other person as the problem.
- Show how you resolved it with evidence: a prototype, a benchmark, a written comparison of options, or a conversation to understand the other person's constraint first.
- State the outcome and the relationship afterwards, including any process change that stopped the same conflict from recurring.
- The mistake that sinks this answer is a story where you were simply right, or where nothing was resolved. Include what you would adjust in your own behaviour.
Follow-up
- What would you do differently if you faced the same disagreement again?
- How do you work with that person now?
- What if the person you disagreed with had been more senior than you?
How do you prioritize tasks when working on multiple projects?
How do you prioritize tasks when working on multiple projects?
Approach
- Lead with the method, then prove it with one real example. A usable method: list every commitment with its deadline, impact and who is blocked by it, then rank by impact and urgency.
- Show the trade-off being made explicit: what you moved first, what you postponed, and who you told. Name the person you confirmed the ranking with when stakeholders disagreed.
- Give a concrete case, for example a production defect that put users at risk against a planned feature, and say how you decided which one went first and what you reported to the other stakeholders.
- Cover the follow-through: how you track the list, how you re-rank when something new arrives, and when you ask for help or push back on scope.
- The mistake that sinks this answer is saying you work longer hours or multitask; it names no criteria and shows no decision.
Follow-up
- Two stakeholders each say their request is the top priority. What do you do?
- What did you drop, and how did you tell the people affected?
- How do you re-prioritize when something urgent arrives mid-week?
What motivates you to perform at your best?
What motivates you to perform at your best?
Approach
- Name two or three genuine drivers, such as hard problems, ownership of an outcome, learning from stronger peers, or visible user impact, and pair each with a concrete moment from your work where it showed.
- Tie at least one driver to the work this role involves as candidates describe it (security of decentralized applications, code review, collaborating on specs), but only where it is true for you.
- Describe the conditions under which you do your best work: the kind of feedback, autonomy and team setting, backed by an example where those conditions produced a result you can state.
- Keep it grounded and brief: one example per driver, no list of abstract virtues.
- The mistake that sinks this answer is a generic reply (passion, money, teamwork) with no evidence, or a driver that contradicts the role.
Follow-up
- What demotivates you, and how do you handle it when it happens?
- Describe a stretch when your motivation was low and what you did about it.
- How do you stay engaged on repetitive maintenance work?
- 01
Describe a time when you had to handle a conflict within your team.
- 02
How do you prioritize tasks when working on multiple projects?
- 03
What motivates you to perform at your best?
- 04
Describe a time you had to persuade others in your team to adopt your approach.
- 05
Describe a challenging technical problem you faced in a previous project and how you resolved it.
How many rounds are there and how long does the process take?
Candidates report three rounds: a Phone Screen, a Technical Interview and a Behavioral Interview. Reported timing is about 3-5 weeks, and one set of reports gives 2-4 weeks. The shape can vary by team and level, so ask the recruiter what each stage covers.
PracHub Software Engineer practice ↗Which programming languages should I prepare?
The requirements candidates describe name Python, JavaScript and Solidity, with web frameworks and React also mentioned. For coding questions, use the language you are strongest in; for role-specific topics, be able to discuss any of these languages that appear on your resume.
PracHub Software Engineer practice ↗Do I need blockchain experience?
Candidates describe blockchain familiarity as a nice-to-have, not a requirement. Even so, several reported questions have a blockchain flavour (a transaction-processing system, a digital-identity dApp, fraud analysis on transaction histories), so learn the fundamentals: blocks, transactions, signatures, smart contracts and what finality means.
PracHub Software Engineer practice ↗What kinds of questions are reported?
They span five groups: language and engineering concepts (synchronous versus asynchronous, interfaces, debugging), case studies, coding (stock-price profit, hash table, balanced binary tree), system design (dApp, API design, microservice scalability) and behavioral prompts. Candidates also mention object-oriented design patterns and optimizing a slow database query as example topics.
PracHub Software Engineer practice ↗Should I prepare Solidity compiler frontend and formal methods?
They appear in the topic breakdown for this loop, but no specific question is reported for either. Prepare the basics: the stages of a compiler frontend (lexing, parsing, syntax tree, type checking) and what loop invariants, pre- and postconditions and model checking mean. Go deeper if your resume lists them.
PracHub Software Engineer practice ↗How should I prepare for the Behavioral Interview?
Prepare specific stories rather than general principles. Cover a team conflict, prioritization across competing projects, your motivation and a time you persuaded teammates. For each, state the situation briefly, the options you weighed, what you did and what changed as a result.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01CertiK Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.
Shopify Software Engineer Interview Guide
Timed practice for Shopify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.
Ramp Software Engineer Interview Guide
Systems practice for Ramp software engineer candidates, weighted toward payments and lending work: the load that actually arrives, the failure modes that matter there, and the invariants a partial outage must not break.