7Park Data Software Engineer Interview Guide

The 60-second brief

Candidate material describes 7Park Data as a company working on data analytics and visualization for clients. For this role, candidates report building and maintaining software such as data pipelines, APIs and user-facing applications that run on large data sets. They also report collaborating with data scientists, product managers and other engineers.

This guide is for candidates interviewing for a Software Engineer position at 7Park Data. It covers the five reported rounds, the 25 questions candidates report across technical, system design, problem-solving, coding and behavioral themes, and a seven-day plan that moves from algorithms and SQL through system design to the stories you will need for the team and leadership interviews.

Candidates report five rounds over roughly 4-6 weeks: a phone screen, technical assessments, team interviews, leadership interviews and a final evaluation.

Focus areas

• Cognitive Assessment Tests
• Online Coding Test
• Problem-Solving in Coding Tests

Overview

The requirements candidates describe list Python, Java or C++, a solid grounding in data structures and algorithms, cloud services such as AWS or Azure, and database technologies. Reported nice-to-haves are machine learning frameworks, front-end work in React or Angular, DevOps practice and earlier data analytics or visualization work. The reported responsibilities are building and debugging software, creating data pipelines and APIs, watching application metrics, and joining design discussions. Preparation should therefore cover three areas: code you can write and reason about, data and system design fundamentals, and credible stories about working with other people.

The reported question set splits roughly into three groups. Coding questions are classic ones: reverse a linked list, find the longest substring without repeating characters, discuss the traveling salesman problem, explain the time complexity of your solution, and solve a challenge on a whiteboard or a live coding platform. Technical and design questions are conceptual: data structures for search, SQL versus NoSQL, normalization, data integrity in a distributed system, a URL shortening service, high availability, microservices versus a monolith, and a real-time analytics platform. The remaining questions are experience-based: debugging a production issue, optimizing a system, a complex project, and the behavioral prompts about challenges, priorities, mentoring, conflict, motivation, incomplete information, deadlines and pivots.

Because you may need to code, design and tell stories within the same loop, the cheapest improvement is to rehearse out loud. Say the complexity of every solution you write, the trade-off behind every design choice, and your own decision, not the team's, in every story.

Candidates also list a cognitive assessment, an online coding test and a personality assessment among the topics. For the coding test, practise at least one timed set in a plain editor. For the cognitive assessment, do one timed numerical and logical reasoning set of 20 to 30 minutes on Day 3, so quick problems under a clock feel familiar. For the personality assessment, answer honestly and in line with how you actually work, because that is the only way to stay consistent from one item to the next. No reported question is tied to a stage, so build answers that work in any round.

The 7Park Data interview process

These are the five stages in the order candidates describe them. No reported question is tied to a particular stage, so prepare every question type before the technical assessments.

Phone Screen

Candidates describe the phone screen as a first call about your background and how you fit the role. Make your own story clear before anyone tests your code: your recent projects, the languages and cloud services you used, and why this role on a data analytics team interests you.

What to demonstrate

• Your background and how it fits a Software Engineer role
• How you describe past projects and the technologies you used
• Basic communication before the technical stages

How to prepare

• Write a short career summary that names your strongest language among Python, Java and C++, plus your SQL and cloud experience.
• Pick one project involving data pipelines, APIs or a data-heavy application and be ready to explain your own contribution to it.
• Rehearse the cloud experience question with a specific system you ran on AWS, Azure or a similar provider.
• Prepare two or three questions about the team's work with data scientists and product managers.

Technical Assessments

Candidates report this stage as coding and system design assessments, and also mention an online coding test and a whiteboard or live coding platform. Expect to write working code while explaining your reasoning, and to talk through designs. Practise both typing in a plain editor and sketching on paper.

What to demonstrate

• Working code for algorithm and data-structure problems
• Your stated time and space complexity
• Design reasoning for scalable systems

How to prepare

• From the reported coding questions, solve the linked-list reversal and the longest-substring problem in your strongest language without help, then state complexity aloud.
• From the reported design questions, practise a URL shortener, a high-availability design and a real-time analytics pipeline, naming read path, write path, storage and failure handling.
• Prepare a decision rule for SQL versus NoSQL and a worked normalization example, since database questions are reported too.
• Run at least one timed online coding set on LeetCode or HackerRank, which candidates cite as useful practice.

Team Interviews

Candidates report team interviews as conversations with prospective teammates that gauge cultural fit and how well you collaborate. Because the role is described as working with data scientists, product managers and other engineers, be ready to talk about how you work with people as well as what you built.

What to demonstrate

• Collaboration with teammates and other functions
• Cultural fit with the team

How to prepare

• Write out the conflict story with both positions stated fairly and the evidence that settled it.
• Prepare a prioritization story with a real list of competing tasks and what you deferred.
• Prepare the mentoring answer around one named person and what changed for them.
• Practise explaining a data pipeline or API you built to a listener who is not on your team.

Leadership Interviews

Candidates describe leadership interviews as meetings with leaders about whether you align with the company's values and vision. Leadership themes reported here also apply to engineers who manage nobody: influencing others, collaborating in teams and mentoring.

What to demonstrate

• Alignment with company values and vision
• Influencing others
• Team collaboration
• Mentorship

How to prepare

• Prepare a story where you advocated for an idea and changed someone's mind, with the evidence you used.
• Prepare the incomplete-information story with the assumptions you wrote down and the checkpoint where you revisited the decision.
• Prepare the pivot story, including what you salvaged and how you told stakeholders.
• Be ready to tell a complex project from beginning to end with your own decisions marked, and a tight-deadline story with what you cut and what you protected.

Final Evaluation

Candidates describe the final evaluation as an overall review of your skills, experience and fit for the team. Use your preparation time to tighten the weakest spot from earlier rounds, not to learn new material.

What to demonstrate

• Your skills and experience
• Fit for the team you would join

How to prepare

• List the questions from earlier rounds that you answered poorly and rework each one, including complexity statements.
• Check that your technical answers and your stories tell the same account of what you have done, and retell your strongest two stories so they name your own decisions.
• Prepare questions about the team's projects and challenges, a tip candidates report.
• Rehearse the performance-optimization and production-debugging answers once more with real numbers from your experience.

Where candidates lose points

Answering SQL versus NoSQL with two definitions and no decision rule.

Prepare a rule tied to access patterns, consistency needs, schema stability and scale. Give one example where each side wins, and connect it to normalization and the data integrity question.

Writing code in silence and stating complexity only when asked, or getting the longest-substring window wrong on repeated characters.

Narrate the approach and the invariant. Say time and space complexity for every solution, and test with inputs such as 'abba' and an empty string before you declare it finished.

Treating the traveling salesman discussion as a request for a perfect solution.

Name it as NP-hard, give brute force at factorial cost, the Held-Karp dynamic program at roughly n squared times two to the n, and practical heuristics such as nearest neighbour and 2-opt, then pick one for the stated input size.

Starting a URL shortener or analytics platform design by drawing boxes without scope, a key strategy or failure handling.

Ask about scale and read/write ratio first, then cover ID or key generation, storage, caching, redirect behaviour and what happens when a dependency is down. For analytics, cover ingestion, aggregation and freshness.

Telling team stories in 'we' form, or answering the cloud experience question with a list of AWS and Azure service names.

For each story, name the decision you personally made, the alternative you rejected and the measured result. For cloud, describe one system you ran and one trade-off, not a catalogue.

Questions & practice

What data structures would you use to optimize search operations?

Medium · Technical / Domain Questions

Approach

1. Start from the query type, because it picks the structure: exact-match lookup, ordered or range lookup, prefix lookup, or membership testing under a memory limit.
2. Exact match: a hash table gives O(1) average lookup and insert, O(n) worst case under heavy collisions, and no ordering. Range or ordered queries: a balanced BST (red-black tree, Java TreeMap) gives O(log n) search and insert. A sorted array with binary search also looks up in O(log n) but inserts in O(n).
3. On disk, use a B+ tree index: high fan-out keeps the tree shallow, and the linked leaves make range scans sequential. That is why database indexes use it.
4. Prefix or autocomplete search: a trie looks up in O(L) for key length L. Full-text search: an inverted index maps each term to a posting list. Membership with little memory: a Bloom filter has no false negatives, a tunable false-positive rate, and no deletes unless it is a counting variant.
5. Close on the trade-offs: memory overhead, how often the data changes, and the worst case. A heap is not a search structure, because finding an arbitrary key in one is O(n).

Follow-up

• How would you return the top-k most popular completions for a prefix, not just any match?
• When would a sorted array beat a hash map for lookups?
• What changes if the index no longer fits in memory on one machine?

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Do it iteratively with three pointers. Set prev = null and curr = head. In the loop: save next = curr.next, set curr.next = prev, then move prev = curr and curr = next. Return prev as the new head. This is O(n) time and O(1) extra space.
2. The recursive version reverses the rest of the list, then sets head.next.next = head and head.next = null. It is O(n) time but also O(n) stack space, so a long list can exceed the recursion limit (1000 frames by default in CPython).
3. Cover the edge cases out loud: an empty list, a single node and two nodes. Confirm the old head's next becomes null so no cycle is left behind.
4. Test by building a short list, reversing it, printing it, and checking that the length is unchanged and the order is reversed.

Follow-up

• Reverse only the nodes between positions m and n.
• Reverse the list in groups of k nodes, leaving a short final group as it is.
• How would you reverse a doubly linked list?

How would you find the longest substring without repeating characters?

Medium · Coding / Algorithms

Approach

1. Name the brute force first: check every substring for duplicates, which is O(n^3), or O(n^2) if you grow a set from each start index.
2. Use a sliding window with a map from character to its last index. For each right index, if s[right] was last seen at or after left, move left to that index + 1. Then record the index and update best = max(best, right - left + 1).
3. The common bug is moving left backwards when a repeat was last seen before the window. The 'at or after left' check, or left = max(left, last + 1), prevents it.
4. Complexity: O(n) time, because each pointer only moves forward. Space is O(min(n, alphabet size)). For ASCII input, a fixed array of 128 replaces the hash map.
5. Edge cases: an empty string returns 0, all characters the same returns 1, all unique returns n. Settle case sensitivity and whether spaces count. Track the start index if the substring itself must be returned.

Follow-up

• Find the longest substring with at most k distinct characters.
• How would you handle a character stream too large to keep in memory?
• What changes if the input is Unicode and not ASCII?

Discuss your approach to solving a classic algorithm problem, like the traveling salesman.

Medium · Coding / Algorithms

Approach

1. Classify the problem: deciding whether a tour of length at most k exists is NP-complete, and finding the shortest tour is NP-hard. No polynomial-time exact algorithm is known, so the answer depends on n and on whether you need the optimum.
2. Exact methods: brute force over permutations is O(n!), or (n-1)! with a fixed start city. Held-Karp dynamic programming over subsets, dp[mask][j] = shortest path that visits mask and ends at j, runs in O(n^2 * 2^n) time and O(n * 2^n) space, which is practical up to roughly 20 cities.
3. For larger exact instances, use branch and bound or an integer linear programming solver.
4. Heuristics with their guarantees: nearest neighbour is O(n^2) with no constant-factor guarantee in general. Improve its tour with 2-opt local search. Christofides gives a 1.5-approximation, but only for metric TSP, where the triangle inequality holds. Simulated annealing or genetic algorithms handle very large instances without guarantees.
5. Close with the choice: exact DP for small n, approximation or heuristics with local search when n is large or a near-optimal tour is enough.

Follow-up

• Write the Held-Karp DP and explain its state and transition.
• Why does Christofides need the triangle inequality?
• How does the problem change with several vehicles that have capacity limits?

Can you explain the time complexity of your solution?

Medium · Coding / Algorithms

Approach

1. Count the dominant operations against named input sizes (n, m, k), not a single n when there are several inputs. State time and space separately, including auxiliary structures and the recursion stack.
2. Map common shapes: one pass is O(n), nested loops over the same input are O(n^2), comparison sorting is O(n log n) (also its lower bound), and binary search is O(log n). Solve recursive code with a recurrence: T(n) = 2T(n/2) + O(n) gives O(n log n) by the Master theorem.
3. Separate average, worst and amortized cost: a hash map lookup is O(1) on average and O(n) in the worst case, appending to a dynamic array is amortized O(1), and quicksort is O(n log n) on average but O(n^2) in the worst case.
4. Point out hidden costs: repeated immutable string concatenation in a loop can be O(n^2), Python slicing copies, and 'x in list' is O(n).
5. Tie the bound to the input size: at n = 10^5, an O(n^2) solution needs about 10^10 steps, which rules it out, while O(n log n) is comfortable.

Follow-up

• Can you do better, and what lower bound applies to this problem?
• What is the space complexity once you include the recursion stack?
• Walk through the amortized analysis of the data structure you used.

Solve a coding challenge on a whiteboard or live coding platform.

Medium · Coding / Algorithms

Approach

1. Restate the problem, then ask about input size, value ranges, duplicates, empty input and the expected output format. Write two small examples, one of them an edge case.
2. State the brute force and its complexity. Then name the pattern that improves it (hash map lookup, two pointers, sliding window, BFS or DFS, a heap, dynamic programming) and the complexity you are aiming for.
3. Code in the language you write fastest, with clear names and small helper functions, and say each step out loud as you write it.
4. Test by tracing an example by hand, then run the edge cases: empty input, one element, duplicates, negative numbers, and integer overflow in Java or C++.
5. Finish with the time and space complexity and one improvement you would make given more time.

Follow-up

• How would your solution change if the input arrived as a stream?
• Which unit tests would you write for this function?
• How would you make it safe to call from several threads?

Can you explain the difference between SQL and NoSQL databases?

Medium · Technical / Domain Questions

Approach

1. Relational databases have a fixed schema of tables, enforce foreign-key and unique constraints, support joins and ad hoc SQL, and give ACID transactions across rows and tables. They usually scale up first, then out with read replicas. Sharding works, but joins across shards get expensive.
2. NoSQL is several families, not one: key-value (Redis, DynamoDB), document (MongoDB), wide-column (Cassandra, HBase) and graph (Neo4j). Each is modelled around known access patterns, usually denormalised, and partitions horizontally by key.
3. Consistency differs by product. Cassandra has tunable consistency: when R + W > N, a read quorum overlaps the latest write quorum. Avoid blanket claims, though: MongoDB has supported multi-document transactions since 4.0, and Postgres JSONB stores schemaless documents.
4. Choose by workload. Pick relational for multi-entity transactions, integrity constraints and ad hoc reporting. Pick a NoSQL store for very high write throughput with key-based access, a schema that changes often, or data that has to be spread across many nodes.
5. Give a concrete split, for example raw high-volume events in a wide-column store or object storage and curated aggregates in a relational database, so the answer is a design decision and not a list of definitions.

Follow-up

• How do you answer a query that needs a join when your data sits in a key-value store?
• During a network partition, what does your chosen store give up, and is that acceptable for this data?
• How would you migrate a growing relational table to a NoSQL store without downtime?

Describe the process of normalizing a database.

Medium · Technical / Domain Questions

Approach

1. Say what normalisation is for: removing redundancy, and with it update, insert and delete anomalies, by decomposing tables along their functional dependencies.
2. Walk the normal forms precisely. 1NF: atomic values and no repeating groups. 2NF: no non-key column depends on only part of a composite key. 3NF: no transitive dependency, so every non-key column depends only on the key. BCNF: every determinant is a candidate key.
3. Work one example: an orders table that repeats customer_name, customer_email, product_name and unit_price on every line. Split it into customers, products, orders and order_items, linked by foreign keys.
4. Mention the decomposition properties. The join must be lossless. A 3NF decomposition that preserves dependencies always exists; BCNF sometimes cannot preserve every dependency.
5. Finish with the trade-off: more joins on reads. Denormalise on purpose for read-heavy or analytic workloads (a star schema), and keep the copies consistent with constraints, triggers or a single writer.

Follow-up

• Is every 3NF table also in BCNF? Give a counterexample.
• When would you denormalise, and how do you stop the copies from drifting apart?
• Which constraints would you add to the normalised schema so the database enforces what the design assumes?

How do you ensure data integrity in a distributed system?

Medium · Technical / Domain Questions

Approach

1. Define what integrity means for the system first: no lost or duplicated writes, invariants such as uniqueness or balances that always hold, and replicas that converge.
2. Inside one database, use transactions and constraints. Across services, prefer a saga with compensating actions over two-phase commit, which blocks while the coordinator is down. Use the transactional outbox pattern: write the business row and the outbox event in one local transaction, and let a relay publish the event.
3. Assume at-least-once delivery. Make consumers idempotent with idempotency keys, a dedupe table or upserts, so a redelivered message has no extra effect. Exactly-once is an end-to-end effect, not a delivery guarantee.
4. For concurrent writes, use optimistic concurrency (a version column or compare-and-set) or quorum reads and writes in replicated stores. Use a consensus protocol such as Raft for metadata that must have a single answer.
5. Add detection: checksums on transfers, reconciliation jobs that compare counts or hashes between source and sink, and dead-letter queues for messages that keep failing.

Follow-up

• A consumer writes to the database and then crashes before committing its offset. What happens, and how does your design cope?
• What are the trade-offs between two-phase commit and a saga for an operation that spans two services?
• How would you detect two replicas that have silently diverged?

How would you design a URL shortening service?

Medium · System Design / Architecture

Approach

1. Pin down the requirements first: create a short link, redirect, and optionally custom aliases, expiry and click analytics. The traffic is read-heavy. Size the key space: 7 base62 characters give 62^7, about 3.5 trillion codes.
2. Generate keys one of three ways. A unique ID (counter ranges handed to each server, or a Snowflake-style ID) encoded in base62 never collides, but its codes are guessable. A truncated hash of the URL needs a collision check and retry. A pool of keys generated in advance has to be handed out exactly once.
3. Store a code-to-URL mapping in a key-value or relational store, partitioned by code and with a uniqueness constraint on the code. Writes are a single-key insert.
4. On the redirect path, put a cache such as Redis in front of the store. A 301 is cached by browsers, which cuts load but hides repeat clicks. A 302 keeps every click visible for analytics.
5. Send click events asynchronously to a queue so analytics never slow the redirect. Add rate limiting on creation and scan destination URLs for abuse.

Follow-up

• If the same long URL is shortened twice, should it get the same code? What does each choice cost?
• How would you expire links and decide whether to reuse their codes?
• How do you handle a custom alias that someone else claims at the same moment?

Describe the considerations you would make for a high-availability system.

Medium · System Design / Architecture

Approach

1. Set a target and say what it allows: 99.9% availability permits about 8.8 hours of downtime a year, and 99.99% less than one hour. Also define RPO (how much data you can lose) and RTO (how fast you must recover).
2. Remove single points of failure. Run redundant stateless instances behind load balancers with health checks, spread across availability zones. Replicate the database with automatic failover: synchronous replication loses no committed data but adds write latency, and asynchronous replication is faster but can lose the last writes.
3. Contain failures with timeouts on every remote call, retries with exponential backoff and jitter, circuit breakers, bulkheads that isolate thread or connection pools, and load shedding. When a dependency is down, serve stale cached data rather than errors.
4. Make changes safe: rolling or canary deploys with automatic rollback, feature flags, and backward-compatible schema migrations.
5. Monitor against the target with health checks and SLO burn-rate alerts, keep runbooks, and test failover on purpose, because a failover path that has never run is not proven.

Follow-up

• The primary database fails while replication is asynchronous. What can be lost, and how do you bound it?
• What are the trade-offs of active-active versus active-passive across regions?
• How can retries turn a partial outage into a full one, and what prevents that?

What are the trade-offs between microservices and monolithic architectures?

Medium · System Design / Architecture

Approach

1. A monolith is one deployable: calls are in-process, transactions use one database, and local development and debugging are simple. Its costs grow with size: deploys are coupled, everything scales together, and many teams edit one codebase.
2. Microservices give independent deploys and scaling, clear team ownership, fault isolation and a free choice of technology per service. In exchange you get network latency and partial failures, consistency problems across databases each service owns (sagas instead of transactions), and the need for distributed tracing, service discovery and per-service CI/CD.
3. Decide by team count and size, how clear the domain boundaries are, whether components have very different scaling or release needs, and how mature operations are.
4. Offer the middle path: a modular monolith with enforced module boundaries, then extract services along bounded contexts with the strangler fig pattern when a module has a real reason to stand alone.
5. Name the anti-pattern to avoid: a distributed monolith, where services share a database or must be deployed in lock-step, so you pay the costs of both models.

Follow-up

• Given a monolith, which piece would you extract first, and why that one?
• How do you handle a business operation that has to update data owned by two services?
• How would you find why one request that crosses five services is slow?

How would you design a real-time analytics platform?

Medium · System Design / Architecture

Approach

1. Clarify event volume, the freshness target (seconds or sub-second), the query types (fixed dashboards or ad hoc slicing), whether counts must be exact or can be approximate, and how long data is kept.
2. Ingest into a durable, partitioned log such as Kafka or Kinesis, keyed so related events stay ordered in one partition. Use a schema registry so producers cannot break consumers.
3. Process with a stream engine (Flink, Spark Structured Streaming or Kafka Streams): windowed aggregates (tumbling or sliding) on event time, watermarks to handle late data, and checkpointed state so updates survive restarts without double-counting.
4. Serve aggregates from an OLAP store built for fast slicing (Druid, Pinot, ClickHouse), or from a key-value store when the dashboards are fixed. Keep raw events in object storage so you can backfill and reprocess after a logic bug.
5. Use approximate structures where exactness is not required: HyperLogLog for distinct counts (sketches merge across windows and partitions) and count-min sketch for heavy hitters. Salt hot keys so one key does not overload one partition.

Follow-up

• How do you handle events that arrive late or out of order?
• A bug corrupted a week of aggregates. How do you recompute them while the live pipeline keeps running?
• How do you answer distinct users over an arbitrary date range without storing every user ID per window?

Discuss a time you optimized a system for performance.

Medium · System Design / Architecture

Approach

1. Pick a story with a measured baseline and a reason it mattered: p95 or p99 latency, throughput, job runtime or cost, and the target you had to reach.
2. Show how you found the bottleneck before changing anything: a profiler or flame graph, EXPLAIN ANALYZE on slow queries, distributed traces, and resource metrics (CPU, memory, I/O, lock waits).
3. Explain the fix and an alternative you rejected, with the reason. Examples: a composite index, batching an N+1 query pattern, a cache with an explicit invalidation rule, replacing an O(n^2) step with a hash-based O(n) one, or parallelising independent work.
4. Quantify the result with the same measurement as the baseline. Say how you checked correctness and the absence of regressions (load test, output comparison), and what the change cost in memory, complexity or data freshness. Use "I" for your own part.

Follow-up

• How did you know the improvement came from your change and not from a drop in traffic?
• What became the bottleneck after your fix?
• If you had no load-test environment, how would you have shipped the change safely?

Describe a complex project you worked on and how you approached it.

Medium · Problem-Solving / Case Studies

Approach

1. Choose a project where you owned a substantial technical piece. Say in one or two sentences what made it complex: scale, legacy constraints, unclear requirements, or several teams depending on it.
2. Explain how you broke it down: clarifying requirements, writing a design document, cutting milestones, and building a prototype of the riskiest part first.
3. Walk through one major technical decision with the alternatives and why you chose as you did, for example batch versus streaming for a data pipeline, or the API contract between services.
4. Show execution: how you coordinated with the people who depended on the work, how you tracked risk, and one thing that went wrong and how you caught it.
5. End with a measured outcome and what you would do differently. Use "I" for your contribution and say plainly which parts were the team's.

Follow-up

• Which decision would you reverse today, and why?
• How did you handle a requirement that changed partway through?
• What would have broken first if usage had grown tenfold?

How would you approach debugging a production issue?

Medium · Problem-Solving / Case Studies

Approach

1. Size the impact and mitigate first: who is affected, how many, and since when. If users are hurting, roll back the latest deploy, turn off a feature flag or scale out before chasing the root cause.
2. Line the start time up against change events: deploys, config changes, traffic shifts, dependency incidents. Read error rate, latency and saturation dashboards to see which service and which resource moved first.
3. Narrow it down with logs keyed by request or trace ID and with distributed traces to find the failing hop. Compare failing and healthy hosts, regions or request types, then reproduce with captured inputs in a non-production environment.
4. Test one hypothesis at a time, and separate the symptom from the cause. For example, connection-pool exhaustion is often the symptom of one slow query that holds connections.
5. Close the loop: ship the fix with a regression test, add the alert or metric that would have caught it sooner, and write a blameless postmortem with owned action items.

Follow-up

• The issue hits a small fraction of requests and you cannot reproduce it. What do you do next?
• Rolling back did not fix it. Where do you look now?
• How would you find a memory leak in a service that is still serving traffic?

Suggested practice checklist

The plan moves from your story inventory through coding and algorithms, SQL and data integrity, system design, production experience, and finally a full out-loud run through the behavioral prompts, using the reported questions as the practice material.

Day 1 — Map the loop and build a story inventory

• Write the five reported rounds in order and next to each note whether it is mainly technical, collaborative or a review, then mark the one you feel least ready for.
• Choose your main language among Python, Java and C++, and list which of SQL, AWS or Azure experience you can speak about with examples.
• List five real projects or incidents and write one line on your own decision in each. These feed the stories in the later days.

Deliverable: A one-page round map with the weakest round marked, a chosen language, and a five-item story inventory with your own decision named in each.

Day 2 — Search structures, linked lists and sliding windows

• Write a table of access patterns against structures: hash table for exact lookup, sorted array or balanced tree for ordered and range queries, trie for prefixes, inverted index for text search. Add average and worst-case costs.
• Write the iterative linked-list reversal with previous, current and next pointers, then the recursive version, and state time and space for each.
• Write the longest-substring solution with a window and a map of last-seen positions, test it on 'abba', an empty string and a single repeated character, and state its complexity.

Deliverable: One access-pattern table, two working linked-list reversals, and a tested longest-substring solution, each with a spoken complexity statement.

Day 3 — Hard algorithms, live coding and timed assessments

• Write a one-page answer to the traveling salesman discussion: brute force at factorial cost, the Held-Karp dynamic program, why the problem is NP-hard, and when you would use nearest neighbour or 2-opt instead.
• Solve two problems on LeetCode or HackerRank in a plain editor with no autocomplete, talking through your approach as you go.
• Solve one problem on paper as if at a whiteboard, then type it into an editor and fix what the paper version got wrong.
• For the reported cognitive and personality assessments, do one timed numerical and logical reasoning set of 20 to 30 minutes, then fill in a personality questionnaire honestly and quickly, without trying to guess a preferred answer.

Deliverable: A one-page traveling salesman answer, two solved online problems with complexity notes, one whiteboard solution with its corrections, and a scored timed reasoning set with the mistakes noted.

Day 4 — SQL, normalization and data integrity

• Build a decision table for SQL versus NoSQL covering access patterns, transactions, schema change, scale and consistency, with one example where each wins.
• Take a single wide orders table with repeated customer and product fields and normalize it step by step to third normal form, naming each anomaly you remove.
• Write two or three queries against the normalized orders schema, including a join with GROUP BY and a window function. Then read the EXPLAIN ANALYZE output for one slow query and fix it with a composite index.
• Write an answer on data integrity in a distributed system: constraints, idempotent writes with request keys, transactions versus sagas, and reconciliation jobs that detect drift.

Deliverable: A SQL versus NoSQL decision table, a normalized schema with the anomalies listed, three working queries with one indexed before-and-after plan, and a written integrity answer covering four mechanisms.

Day 5 — System design: four reported designs

• Design a URL shortener: key generation by counter encoded in base 62 versus hashing, collision handling, a read-heavy cache, redirect status codes, and expiry.
• Write a high-availability checklist: no single point of failure, replication, health checks and failover, and graceful degradation. Add one failure scenario you would walk through.
• Compare microservices and a monolith by team size, deployment, data ownership and operational cost, and say when you would start with each.
• Sketch a real-time analytics platform: ingestion, stream processing, pre-aggregation, storage, and the freshness the dashboard needs.

Deliverable: Four design sketches, each naming scope, read and write paths, storage, and the first thing that breaks at ten times the load.

Day 6 — Production work: debugging, performance, projects, cloud

• Write your debugging sequence for a production issue: what changed, which metrics and logs to check, how to bisect, and how to separate the trigger from the cause.
• Write a performance story with a measured before and after, the bottleneck you found and the alternative you rejected.
• Outline a complex project from start to finish with your own decisions marked, and prepare the cloud experience answer using one system you ran.

Deliverable: A debugging checklist, one performance story with numbers, a project outline, and a cloud-experience answer, all spoken aloud once.

Day 7 — Out-loud behavioral run-through

• Answer each reported behavioral prompt aloud in the first person: technical challenge, prioritization, mentoring, conflict, motivation, incomplete information, deadlines and pivots.
• Check each answer against the inventory from day one so no two prompts rely on the same story unless you can show different decisions.
• Record yourself, remove every 'we' that hides your own contribution, and add the measured result to each story.

Deliverable: Eight recorded story answers, each with a named personal decision, a result, and one thing you would change.

Stories for the team and leadership interviews

Candidates report team and leadership interviews, and describe collaboration, influence and mentoring as themes. For an engineer, that means stories in which you made a decision, worked through disagreement and delivered something under constraints. Use the first person, name your own contribution, and prepare a result you can measure.

What is your experience with cloud technologies?

Medium · Technical / Domain Questions

Approach

1. Choose one or two systems you actually ran on a cloud provider and state what you owned: deployment, scaling, access control, monitoring or cost. A list of service names says little; a decision with a reason does.
2. Explain one choice with its alternative, for example a managed database against one you operate yourself, or a queue against direct calls, and what the choice cost you.
3. Give measurements you really have: latency before and after, deployment frequency, monthly spend, or incident count. Do not invent numbers.
4. Be honest about the edges. If you used Azure but not AWS, say so and map the ideas across: object storage, queues, managed relational databases, identity and permissions.
5. Link it to the work reported for this role by describing a pipeline or API you deployed, including how you watched it in production.

Follow-up

• What would you change about the security or cost of that setup?
• How did you respond when something in that environment failed?
• How would you move that workload to a different provider?

Tell me about a time you faced a significant technical challenge.

Medium · Behavioral / Leadership

Approach

1. Choose a challenge that was technically hard, such as a concurrency bug, a data-volume problem or a failed migration, and not one that was mainly about people or workload.
2. Spend two sentences on the situation and most of your time on the reasoning: how you narrowed the cause, which options you considered, and why you rejected the ones you did.
3. Name your own contribution in the first person. If a teammate solved a part, say which part and how you worked together.
4. Close with the result and one thing you would do differently, with evidence for how you knew the fix worked, such as a metric, test or reproduction that no longer failed.

Follow-up

• What was the first thing you tried, and why did it not work?
• How did you confirm the fix addressed the cause and not just the symptom?
• What would you put in place to stop it recurring?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. Anchor the answer in a real situation with two or three competing projects, not a general philosophy. Say what each was and who was waiting on it.
2. Name the criteria you used: user or customer impact, deadline, who is blocked, effort, and risk if delayed. Show how they ranked these specific tasks.
3. Describe how you communicated the order to product managers or teammates, including what you deferred explicitly and what they agreed to.
4. Say how you re-checked priorities when something changed. The common mistake is to answer 'I work longer hours', which describes effort and not prioritization.

Follow-up

• What do you do when two stakeholders each insist their work is first?
• Tell me about something you deprioritized that later became urgent.
• How do you handle an urgent request that arrives mid-sprint?

Describe your approach to mentoring junior team members.

Medium · Behavioral / Leadership

Approach

1. Use one named person (anonymised if you wish) and describe their starting point: new graduate, new to the codebase, or new to a language such as Python or SQL.
2. Show the methods you chose and why: pairing on a first task, code review comments that explain the reason, tasks that grow in size, and letting them own a small component.
3. Describe what changed for them in observable terms, such as shipping a feature alone or reviewing others' code, and what you changed in your own approach after.
4. Include a moment that did not work and how you adapted. Avoid a story in which you did their work for them or just gave answers.

Follow-up

• How do you give difficult feedback in a code review?
• What do you do when a junior colleague is stuck but does not ask for help?
• How do you balance mentoring time against your own deadlines?

Can you give an example of how you handled a conflict within your team?

Medium · Behavioral / Leadership

Approach

1. Pick a technical or working-style disagreement with a colleague, such as a design choice, a review comment or a deadline estimate, not a personality clash.
2. State the other person's position fairly before yours. A story that makes the other side foolish tends to fail.
3. Show the evidence you used to resolve it: a benchmark, a prototype, a requirement from a data scientist or product manager, or a decision from the owner of the area.
4. Report the outcome honestly, including a compromise or the times you turned out to be wrong, and the state of the working relationship afterward.

Follow-up

• What if the other person still disagreed after you showed the evidence?
• What would you do if your manager sided with them?
• Would you handle it differently now?

What motivates you to perform at your best?

Medium · Behavioral / Leadership

Approach

1. Give two concrete motivators, such as solving hard data problems, seeing users depend on something you shipped, or learning from stronger engineers, and back each with a short episode where it showed in your work.
2. Connect them to the reported work without claiming facts about the company: data pipelines, APIs and user-facing applications built on large data sets.
3. Show that the motivation survives routine work. Say what you do on a dull week to keep quality up.
4. Avoid answers that are only about pay, title or vague 'challenge', and avoid listing traits with no evidence.

Follow-up

• Tell me about a time that motivation was missing and what you did.
• What kind of work drains you, and how do you handle it?
• How do you stay motivated when a project is cancelled or changed?

Discuss a time when you had to make a decision with incomplete information.

Medium · Problem-Solving / Case Studies

Approach

1. Say exactly what was unknown and why you could not wait for it: a missing requirement, unclear traffic numbers, or an outage with partial logs.
2. Describe how you bounded the risk: you wrote down your assumptions, chose the option that was easiest to reverse, and asked the person who could fill the gap cheaply.
3. Name the checkpoint you set to revisit the decision, with the signal that would change your mind.
4. Report what happened, including what you learned afterward. A story where you simply moved fast and were right does not show a method.

Follow-up

• What evidence would have made you reverse the decision?
• How did you explain the uncertainty to stakeholders?
• What would you do differently if you faced it again?

How do you handle tight deadlines and pressure?

Medium · Problem-Solving / Case Studies

Approach

1. Use a real deadline with a visible consequence and say how you sized the work before deciding what to do.
2. Show scope decisions: what you cut or postponed, who agreed, and what you protected, for example tests on the riskiest path.
3. Say when you raised the risk. Early communication is a stronger story than quiet heroics or late nights.
4. Close with the delivery, the follow-up cleanup you scheduled for what you deferred, and how the pressure affected your own work habits.

Follow-up

• Tell me about a time you pushed back on a deadline.
• What did you leave out, and did it come back to hurt you?
• How do you keep quality up when time is short?

Give an example of a time you had to pivot your strategy mid-project.

Medium · Problem-Solving / Case Studies

Approach

1. Name the trigger for the pivot: new data, a failed experiment, a changed requirement, or a technical limit you found, and show that you noticed it yourself.
2. Account for sunk cost. Explain how you decided between continuing and changing, and what you salvaged from earlier work.
3. Describe how you re-planned and told teammates and stakeholders, including the revised timeline and risks.
4. Report the result and what you would watch for earlier next time. A story where the pivot was simply handed down, with no decision of yours, is weak.

Follow-up

• How did you know it was time to change course and not push on?
• How did you handle the work that was already finished?
• What did the pivot cost, and was it worth it?