Cog Culture Software Engineer Interview Guide

The 60-second brief

Candidate reports do not name a Cog Culture product, customer or technology platform, so this guide does not guess at one. The role description says a Software Engineer designs, builds and maintains software, from user-facing applications to backend processes, and works with product managers, designers and other engineers on new features, optimisation and bugs reported by users. The languages it mentions are Java, Python and JavaScript, with React and Node.js as example frameworks.

This guide is for candidates interviewing for the Software Engineer role at Cog Culture. It covers the three reported rounds (Coding Tests, Technical Interviews, Behavioral Interviews), the twenty reported questions, and a seven-day schedule. It makes no claim about what a particular team will ask.

Candidates report three rounds over roughly three to five weeks: Coding Tests, then Technical Interviews, then Behavioral Interviews. Reported questions span coding, technical fundamentals, system design and behavioral topics.

Focus areas

• Software Engineering (General)
• Coding/Hands-on Problem Solving
• Interview Process for SWE

Overview

The reported question set is broad rather than deep in any one area. Coding questions are classic algorithm problems: reversing a linked list, the longest substring without repeating characters, merging two sorted arrays, a palindrome check, and a prompt to explain the time complexity of your own solution. Technical questions cover object-oriented versus procedural programming, keeping code efficient and maintainable, optimising a database query, and Git experience. Design questions include a URL shortening service, a real-time chat architecture, RESTful API considerations, scalability and caching.

Because the set is broad, the preparation that pays off is fluency in fundamentals. Pick one of the languages the role lists (Java, Python or JavaScript) and write the four coding problems in it until the pointer handling, the sliding window and the two-pointer merge come out without hesitation. Then practise saying the time and space complexity out loud after every solution, since one reported question asks for exactly that.

The design and technical-domain questions reward structure. For each of the five design prompts, rehearse the same skeleton: requirements and scale, the read and write paths, the data model, the component you would add first, and what fails under load. For the database query question, rehearse a diagnosis order (look at the query plan, check indexes and row counts, then rewrite) rather than a list of tricks.

The behavioral round is reported to look at collaboration, adaptability and commitment to quality, and the reported prompts include pressure, prioritisation, conflict, motivation and feedback. Build a small bank of real stories from your own work and map each to several prompts, so you are adapting a story you know rather than inventing one under pressure.

The Cog Culture interview process

Candidates describe three stages, from coding tests through technical interviews to behavioral interviews, over about three to five weeks. Reports group the questions by type, not by round, so prepare every type.

Coding Tests

Candidates report Coding Tests as the first stage, described only as problem-solving through coding challenges. No platform, language or question list is tied to it, so treat the reported coding questions as the practice set: reverse a linked list, find the longest substring without repeating characters, merge two sorted arrays, check a palindrome, and explain the complexity of your solution. Tips mention both whiteboard and live-coding formats, so practise in a plain editor without autocomplete and by hand on paper. Choose Java, Python or JavaScript, the languages the role lists, and stay with it.

What to demonstrate

• Working code for standard algorithm problems in a language you choose
• How you break a problem into steps and explain your reasoning while you write
• Whether you can state and justify time and space complexity

How to prepare

• Write the linked-list reversal both iteratively and recursively, and test it on empty, single-node and two-node lists
• Solve the longest-substring problem first by brute force, then with a sliding window and a hash map, and state both complexities
• Merge two sorted arrays with two pointers, then handle unequal lengths and duplicates, and say why it is linear
• Write the palindrome check with two pointers and decide aloud how you treat case, spaces and punctuation

Technical Interviews

Candidates report Technical Interviews as a stage on technical skills and role knowledge. The reported questions that fit this format are technical-domain ones (procedural versus object-oriented programming, writing efficient and maintainable code, a challenging problem you solved, Git experience, optimising a database query) and system design ones (a URL shortener, a real-time chat architecture, RESTful API considerations, scalability and performance, caching). Reports file these by category rather than by round, so prepare both types. The role lists Java, Python and JavaScript, React and Node.js, and cloud, CI/CD and database knowledge as nice-to-have.

What to demonstrate

• Command of fundamentals such as object-oriented design and database query tuning
• Ability to structure an open design question around requirements, data model and failure modes
• Depth in one real technical problem you have solved yourself

How to prepare

• Write a two-minute answer contrasting procedural and object-oriented code, with one small example you could sketch on a whiteboard
• Prepare a query-tuning walkthrough: read the query plan, check indexes and selectivity, rewrite the query, and measure again
• Outline the URL shortener, the chat application and a REST API each on one page: requirements, data model, API, scaling step, failure case
• Pick one hard problem from your own work and prepare it with the symptoms, your diagnosis steps, the fix and the result

Behavioral Interviews

Candidates report Behavioral Interviews as the final stage, covering soft skills and fit with the company's culture. Reported evaluation areas include collaboration, adaptability and commitment to quality, and reported prompts cover working under pressure, prioritising across projects, a conflict with a teammate, what motivates you, handling feedback and adapting to a significant change. No list of specific company values is reported, so prepare evidence from your own work rather than slogans.

What to demonstrate

• Collaboration with teammates and cross-functional partners such as product managers and designers
• How you respond to change, ambiguity and feedback
• Whether your stories show your own decisions and their results

How to prepare

• Write six stories from real projects and map each to at least two of the reported prompts
• For each story, write the situation in two sentences, your specific decision, the trade-off and a measurable or observable result
• Rehearse a story where your Git or code-review habits mattered, since the version control question is a reported prompt
• Prepare one story about working with a product manager or designer, because the role description describes that collaboration

Where candidates lose points

Solving a coding problem silently and only stating complexity when asked

After every solution, say the time and space complexity, name the dominant operation, and note the edge cases you tested. One reported question is about explaining complexity, so make it a habit.

Answering the URL shortener or chat design question by listing components without requirements or a data model

Start with scope, then draw the write path and read path separately, pick the key or ID scheme, and name what you would add first when traffic grows. Close with a failure case.

Answering the database query question with 'add an index'

Describe a diagnosis order: read the query plan, check filters and join conditions against existing indexes, look at row counts, rewrite the query, then measure again. Mention when an index does not help.

Giving behavioral answers made of plural pronouns, with no personal decision

For every story, state what you personally decided, what the alternative was and what happened. Rehearse until a listener could point to your contribution.

Preparing company-values slogans instead of evidence

No specific values are reported, so prepare examples of collaboration, adaptability and quality from your own projects, including the Git, review and feedback habits the reported questions ask about.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Write the iterative version with three pointers: prev = None, curr = head; in the loop save nxt = curr.next, set curr.next = prev, then advance prev = curr and curr = nxt; return prev as the new head.
2. State the cost: O(n) time and O(1) extra space, since each node's pointer is rewritten exactly once.
3. Offer the recursive version (reverse the rest, then head.next.next = head and head.next = None) and note its O(n) call stack; in Python a long list hits the default recursion limit of 1000.
4. Test the edge cases aloud: empty list, single node, two nodes, and confirm the old head's next is None so the result has no cycle.
5. Mention the common variants: reversing only positions m to n, reversing in groups of k, and a doubly linked list where you swap each node's prev and next.

Follow-up

• Reverse only the nodes between positions m and n in a single pass.
• Reverse the list in groups of k nodes.
• What is the space cost of the recursive version, and when does it fail?

How would you find the longest substring without repeating characters in a string?

Medium · Coding / Algorithms

Approach

1. Name the brute force first: check every substring for repeats, O(n^3) naively or O(n^2) with a set grown from each start index.
2. Use a sliding window: keep a map from character to its last index and a left pointer; for each right index, if the character was last seen at an index >= left, move left to that index + 1; record the index and update best = max(best, right - left + 1).
3. Explain why the >= left check matters: on "abba", the final 'a' was last seen before the window, and moving left back to it would wrongly report length 3 instead of 2.
4. Give the complexity: O(n) time because each pointer only moves forward, O(min(n, alphabet size)) space; for ASCII a fixed array of 128 can replace the map.
5. Cover the edge cases: empty string returns 0, all identical characters return 1, all distinct return n; track the window's start index if the substring itself must be returned.

Follow-up

• Find the longest substring with at most k distinct characters.
• Return the substring itself, not just its length.
• How would you adapt this if the characters arrive as a stream?

Describe an algorithm to merge two sorted arrays.

Medium · Coding / Algorithms

Approach

1. Use two pointers, one per array: append the smaller current element and advance that pointer; when one array is exhausted, append the rest of the other. O(m + n) time and O(m + n) space for the output.
2. Take from the first array on ties (<= rather than <) so the merge is stable, which is the property merge sort relies on.
3. Handle the in-place variant where the first array has m + n slots: fill from the back with three pointers (end of each input and end of the buffer) so no unread element is overwritten, using O(1) extra space.
4. Check the edge cases: either array empty, duplicates across arrays, all of one array smaller than the other, negative values.
5. Extend it when asked: k sorted arrays merge with a min-heap in O(N log k) for N total elements, and data too large for memory is merged in chunks from disk (external merge sort).

Follow-up

• Merge in place when the first array has spare capacity at its end.
• Merge k sorted arrays and give the complexity.
• Find the median of two sorted arrays without merging them.

Explain the time complexity of your solution for a given problem.

Medium · Coding / Algorithms

Approach

1. Define n explicitly, then count work: nested loops multiply, sequential steps add, constants and lower-order terms drop; give space too, including the recursion stack, and say whether the output counts.
2. Quote the standard costs correctly: hash map lookup O(1) average but O(n) worst case, comparison sorting O(n log n), binary search O(log n), BFS or DFS O(V + E).
3. Solve recursions with a recurrence: merge sort is T(n) = 2T(n/2) + O(n) = O(n log n); naive recursive Fibonacci is exponential while the memoized version is O(n).
4. Use amortized analysis where it applies: appending to a dynamic array is O(1) amortized because capacity doubling makes the total copying O(n); a sliding window with an inner while loop is still O(n) because each pointer moves at most n times.
5. Point out hidden costs: x in list is O(n) versus O(1) average for a set, slicing copies O(k) elements, and repeated string concatenation in a loop can be O(n^2) with immutable strings, so a builder or join is safer.

Follow-up

• Why is appending to a dynamic array O(1) amortized?
• Your solution has a nested loop. Why is it still linear?
• When does the worst case of a hash table actually matter in practice?

Write a function to determine if a string is a palindrome.

Medium · Coding / Algorithms

Approach

1. Clarify the rules first: case-sensitive or not, whether to skip spaces and punctuation, and that an empty string and a single character count as palindromes.
2. Use two pointers from both ends moving inward, skipping non-alphanumeric characters if required and comparing lowercased characters; O(n) time and O(1) extra space.
3. Mention the one-liner s == s[::-1] as correct but O(n) extra space, and note that cleaning the string first also allocates a copy.
4. Flag Unicode: in Java and JavaScript strings are UTF-16, so characters outside the Basic Multilingual Plane are two code units and combining marks can break a naive character comparison.
5. Know the variants: allow one deletion (on the first mismatch try skipping either side, still O(n)), longest palindromic substring by expanding around each center in O(n^2), and a linked-list palindrome using fast/slow pointers and reversing the second half.

Follow-up

• Return true if the string can become a palindrome by removing at most one character.
• Check whether a singly linked list is a palindrome using O(1) extra space.
• Find the longest palindromic substring.

Can you explain how you would optimize a database query?

Medium · Technical / Domain Questions

Approach

1. Start from evidence: run EXPLAIN ANALYZE (PostgreSQL) or EXPLAIN (MySQL) and read the plan for sequential scans on large tables, row estimates far from actual rows, nested loops over big inputs and sorts spilling to disk.
2. Add or fix indexes: a B-tree on the filter and join columns; for a composite index put equality columns before the range column; a covering index (INCLUDE in PostgreSQL) can enable an index-only scan.
3. Make predicates index-friendly: WHERE LOWER(email) = ... cannot use a plain index on email (use an expression index), a leading wildcard LIKE '%abc' cannot use a B-tree, and an implicit type cast on the column can also block the index.
4. Cut the work itself: select only needed columns, filter before joining and aggregating, replace deep OFFSET paging with keyset paging (WHERE id > :last_id ORDER BY id LIMIT n), and collapse ORM N+1 queries into a join or an IN batch.
5. State the trade-offs: every index slows writes and costs storage, stale statistics mislead the planner (run ANALYZE), and heavy repeated aggregations may belong in a materialized view or a cache.

Follow-up

• Why might the planner ignore an index you just created?
• How would you order a composite index for WHERE a = ? AND b > ? ORDER BY b?
• How do you find which queries are slow in the first place?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Explain the differences between procedural and object-oriented programming.

Medium · Technical / Domain Questions

Approach

1. Define both precisely: procedural code is a sequence of functions that operate on data passed to them (C, shell scripts); object-oriented code bundles state with the methods that guard it, using encapsulation, inheritance and polymorphism (Java classes, Python classes).
2. Use one concrete example: payroll as a struct plus a calculate_pay(employee) function with a switch on employee type, versus an Employee base class whose pay() method each subclass overrides, so the switch disappears into dynamic dispatch.
3. Name the trade-off (the expression problem): OOP makes adding a new type cheap (one new subclass) but a new operation touches every class; procedural code makes adding an operation cheap but a new type touches every switch.
4. Give the costs of each: OOP encapsulation protects invariants, but deep inheritance chains couple classes, so prefer composition; procedural code is simpler for scripts and data pipelines but shared mutable data gets harder to reason about as it grows.
5. Close by noting Java, Python, JavaScript and C++ all mix paradigms, so the real decision is per module: stateful domain objects as classes, stateless transformations as plain functions.

Follow-up

• When would you choose composition over inheritance, and what goes wrong with a deep hierarchy?
• How does functional programming differ from both, especially around mutable state?
• Rewrite a type-based switch statement using polymorphism and say what it costs.

How do you ensure that your code is efficient and easy to maintain?

Medium · Technical / Domain Questions

Approach

1. Split the answer into efficiency and maintainability, and say efficiency starts with measurement: profile the real workload (cProfile, Chrome DevTools, a JVM profiler) before changing anything.
2. Fix algorithmic cost before micro-tuning: for example, replacing a nested-loop lookup that is O(n*m) with a hash set that makes it O(n+m), or batching N+1 database calls into one query.
3. For maintainability, name concrete habits: small functions with one responsibility, names that state intent, one home for each business rule, type hints or static types, and comments that explain why rather than what.
4. Back both with automation: unit tests on behaviour so refactors are safe, linters and formatters in CI, and small pull requests that a reviewer can actually read.
5. State the trade-off: when a faster version is harder to read, keep it only if a benchmark proves the gain on a hot path, and document the reason next to the code.

Follow-up

• Give an example where you made code faster at a readability cost. Was it worth it?
• How do you safely refactor legacy code that has no tests?
• What tooling would catch a performance regression before it ships?

Describe a challenging technical problem you solved and the approach you took.

Medium · Technical / Domain Questions

Approach

1. Pick a problem with a genuine technical core (a memory leak, a race condition, a slow query, a flaky integration) that you personally diagnosed, and tell it in the first person: "I traced ...", not "the team fixed ...".
2. Set the context in two sentences, then name the constraint that made it hard: it only reproduced under load, the logs lacked the needed field, or the fix could not take the service down.
3. Walk through the debugging sequence as hypotheses and evidence: what you suspected, which tool you used to test it (profiler, logs, git bisect, a minimal reproduction) and what each result ruled out.
4. Explain the fix and the alternatives you rejected, with the trade-off behind the choice (for example, adding a lock versus redesigning to avoid shared state).
5. End with a measured result (error rate, latency, memory before and after) and what you changed so the problem class cannot recur, such as a test, an alert or a code review checklist item.

Follow-up

• Which alternative solution did you reject, and why?
• How did you confirm the fix worked in production rather than just locally?
• If the same symptom came back tomorrow, what would you check first?

How would you design a URL shortening service?

Medium · System Design / Architecture

Approach

1. Fix the requirements: create a short code for a long URL, redirect on lookup, optional custom alias and expiry; state the assumption that redirects far outnumber creates, so the read path dominates.
2. Generate codes by base62-encoding a unique integer ID (a database sequence, or ID ranges handed out to each app server so they never collide); 7 base62 characters give 62^7, about 3.5 trillion codes. A hash of the URL needs a collision check, and sequential IDs are guessable unless shuffled.
3. Store a key-value mapping code -> long_url, created_at, expires_at, owner; partition by code, which makes a reverse lookup by long URL expensive unless you add a secondary index for deduplication.
4. Serve redirects from a cache (Redis, LRU eviction) in front of the store. Choose 301 versus 302 deliberately: 301 is cached by browsers and cuts load but hides repeat clicks, 302 sends every click through the service.
5. Record click analytics asynchronously through a queue so the redirect stays fast, rate-limit creation, and screen target URLs for abuse.

Follow-up

• How do you guarantee two servers never issue the same short code?
• Would you return 301 or 302, and what does each cost you?
• How would you count clicks per link without slowing the redirect?

Describe the architecture you would use for a real-time chat application.

Medium · System Design / Architecture

Approach

1. Scope it: one-to-one and group chat, message history, online presence, delivery and read receipts, and delivery to offline users through push notifications.
2. Hold persistent WebSocket connections on gateway servers behind a load balancer that supports long-lived connections; keep a session registry (for example Redis: user -> gateway) so any service can find where a recipient is connected.
3. On send, a chat service assigns a per-conversation sequence number, persists the message in a store partitioned by conversation_id and ordered by that sequence (a wide-column store suits this), then publishes it through pub/sub or Kafka to the recipients' gateways.
4. Make delivery at-least-once with client-generated message IDs so duplicates are dropped; clients acknowledge messages and, on reconnect, fetch everything after the last sequence they saw. Offline users get a push notification.
5. Name the scaling pressure points: fan-out cost in very large groups (switch to fan-out on read), presence via heartbeats with a TTL rather than per-event writes, and hot conversations concentrated on one partition.

Follow-up

• How do you order messages when two members send at the same moment?
• What happens to in-flight messages when a gateway server crashes?
• How would the design change for a group with 100,000 members?

What considerations would you make for designing a RESTful API?

Medium · System Design / Architecture

Approach

1. Model resources as nouns (/users/{id}/orders) and use HTTP semantics correctly: GET is safe and idempotent, PUT and DELETE are idempotent, POST is not, PATCH is a partial update.
2. Return precise status codes: 201 with a Location header on create, 400 for malformed input, 401 versus 403 for unauthenticated versus forbidden, 404, 409 for conflicts, 429 for rate limits; use one consistent error body (code, message, details).
3. Make POST retries safe with an Idempotency-Key header: store the key with its response and return the stored response when the same key arrives again.
4. Handle collections with cursor-based pagination for large or changing data, plus filtering and sorting parameters; use ETag with If-None-Match for 304 responses and If-Match for optimistic concurrency (412 on a stale write).
5. Plan for change and security: version through the path (/v1) or a header, keep changes additive (new optional fields, never renames or removals), require HTTPS with token-based auth, and rate-limit per client.

Follow-up

• How should a client retry a POST after a timeout without creating a duplicate?
• When would you pick cursor pagination over offset pagination?
• How do you ship a breaking change without breaking existing clients?

How do you approach scalability and performance in system design?

Medium · System Design / Architecture

Approach

1. Start with numbers: requests per second, read/write ratio, data size and growth, and a latency target stated as a percentile (p99), then do a back-of-envelope estimate before choosing components.
2. Find the actual bottleneck by measurement (profiling, load tests, per-tier metrics) instead of guessing; CPU, database, network and lock contention each have different fixes.
3. Scale the stateless tier horizontally behind a load balancer and keep session state in a shared store; put static content on a CDN.
4. Scale data deliberately: indexes first, then caching, then read replicas (which bring replication lag and read-your-own-writes problems), then sharding by a key (cross-shard queries and hot keys become the new cost).
5. Move slow work off the request path with queues and apply back-pressure; state the consistency you accept in exchange, and say what the extra capacity costs.

Follow-up

• One shard is receiving most of the traffic. How do you handle the hot key?
• What consistency problem do read replicas create, and how do you work around it?
• How would you load test this system, and which metrics would you watch?

Explain how you would implement caching in a web application.

Medium · System Design / Architecture

Approach

1. Name the layers and what each holds: HTTP caching in the browser (Cache-Control max-age, ETag), a CDN for public and static responses, an application cache such as Redis or Memcached for computed results and database rows, and a small in-process cache for very hot data.
2. Describe cache-aside concretely: on read, check the cache, on a miss load from the database and set the key with a TTL; on write, update the database and then delete the key rather than writing the new value into it.
3. Explain invalidation: deleting on write avoids two concurrent writers leaving an older value in the cache, though a narrow race remains, so pair it with a TTL or versioned keys; compare write-through (fresher, slower writes) and write-behind (fast writes, risk of loss).
4. Configure eviction (LRU or LFU with a memory limit) and design keys that include a version and, for user data, the user ID; mark private responses Cache-Control: private so a shared CDN never serves one user's data to another.
5. Plan for failure: prevent a stampede on hot-key expiry with request coalescing or a lock, jittered TTLs or stale-while-revalidate; if the cache is down, fall back to the database with limits; track the hit ratio.

Follow-up

• Why delete the key on write instead of updating it with the new value?
• How do you stop a stampede when a heavily read key expires?
• What must never be cached at the CDN layer?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

1. Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
2. Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
3. Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
4. Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

• The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
• Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

The plan follows the reported loop: coding fundamentals first, then technical and design questions, then behavioral stories, ending with a full mock run.

Day 1 — Set up the language and map the loop

• Choose Java, Python or JavaScript, the languages the role lists, and set up a plain editor with no autocomplete
• Write the three reported stages on one page and note which question types belong to coding, technical, design and behavioral practice
• Write a one-line complexity cheat sheet for arrays, hash maps, linked lists and sorting in your language

Deliverable: A one-page loop map and a language cheat sheet with the complexities of the structures you will use.

Day 2 — Linked list, merge and palindrome

• Reverse a linked list iteratively, then recursively, and test empty, one-node and two-node cases
• Merge two sorted arrays with two pointers, covering unequal lengths and duplicates
• Write the palindrome check with two pointers and decide how to treat case and punctuation

Deliverable: Three working solutions in your chosen language, each with a test list and a stated time and space complexity.

Day 3 — Sliding window and complexity explanations

• Solve the longest substring without repeating characters by brute force, then with a sliding window and a hash map
• Explain the complexity of each day-two and day-three solution aloud as if to a listener, naming the dominant operation
• Redo one problem by hand on paper to mimic a whiteboard format

Deliverable: A sliding-window solution with both complexities, plus a recorded or written explanation of every solution so far.

Day 4 — Fundamentals, Git and database queries

• Write your answers contrasting procedural and object-oriented code, and on keeping code efficient and maintainable
• Write a Git answer with a workflow, a revert-versus-reset example and a bisect story
• Work the practice-library keyset paging drill and the practice-library deploy-stall debugging drill, then summarise the query-tuning sequence
• Write the database query optimisation answer as a diagnosis order

Deliverable: Written answers to four technical-domain questions, plus notes from the two practice-library drills.

Day 5 — Design: URL shortener, chat, REST API

• Outline the URL shortener: ID generation, storage, redirect path, and collisions
• Outline the real-time chat architecture: connection handling, message storage, delivery and ordering
• List REST API considerations: resource naming, status codes, versioning, idempotent retries and pagination

Deliverable: Three one-page design outlines, each with requirements, data model, API, a scaling step and a failure case.

Day 6 — Scalability, caching and a technical story

• Write the scalability and performance approach: measure, find the bottleneck, then scale reads, writes or both
• Design a caching layer for a web application: what to cache, where, expiry, invalidation and stampede protection
• Write up one challenging technical problem from your own work with symptoms, diagnosis, fix and result

Deliverable: A scalability checklist, a caching design page and a finished challenging-problem story.

Day 7 — Behavioral stories and a full mock run

• Write six stories and map them to the pressure, prioritisation, conflict, motivation and feedback prompts
• Say each answer aloud, checking that every story names your own decision and a result
• Run a mock loop: one coding problem, one design outline and two behavioral answers, back to back

Deliverable: Six mapped stories and a mock-run note listing the weakest answer to fix before the real loop.

Behavioral stories for Cog Culture

Reports describe the behavioral stage as covering soft skills and fit, with collaboration, adaptability and quality named as areas. For a Software Engineer working with product managers, designers and other engineers, that means stories about code review, shared decisions and shifting requirements, told with your own decisions in the foreground.

1. Can you give an example of how you adapted to a significant change at work?

What is your experience with version control systems like Git?

Medium · Technical / Domain Questions

Approach

1. Answer in two layers. First, your day-to-day workflow: short-lived feature branches, small commits with messages that explain why, pull requests for review, and whether your team merges, rebases or squashes into main and why. Second, one specific situation that shows judgement.
2. Pick a situation with a decision in it: resolving a conflict between long-lived branches, tracing a regression with git bisect, or recovering lost work with git reflog. Say which command you used and why it was safe.
3. Show you know the difference between undoing on shared and private history: git revert adds a new commit and is safe once pushed, while reset or a force-push rewrites history and belongs only on your own unpublished branch (or with force-with-lease when the team agrees).
4. Tie Git to quality: protected main, required reviews and CI checks on every pull request. The role lists CI/CD experience as nice-to-have, so mention the pipeline you have worked with if you have one.
5. Avoid answering with a list of commands or the sentence 'I use Git every day'. Give a workflow, a problem and an outcome.

Follow-up

• When would you rebase and when would you merge or squash?
• A bad commit is already on main and others have pulled it. How do you undo it?
• How would you find the commit that introduced a bug in a repository with hundreds of commits?

Describe a time when you had to work under pressure. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Choose a situation with a real constraint, such as a release deadline, a production incident or a sudden change in scope, and describe it in two sentences.
2. Spend most of the answer on what you did: how you triaged, what you deliberately cut or postponed, what you kept non-negotiable (tests, a rollback path, a review), and who you told about the trade-offs.
3. Show how you stayed effective: breaking the work into the smallest shippable step, asking for help early, and communicating status instead of going silent.
4. Close with the result and what you changed afterwards, such as an alert, a runbook, a better estimate or a standing check, so the pressure does not recur in the same form.
5. The mistake that sinks it is a story of unplanned heroics that blames others or ends with 'we worked late'. Stress is context; your decisions are the content.

Follow-up

• What did you decide not to do, and who agreed to that?
• How did you keep quality up while time was short?
• What would you change so the same situation does not happen again?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. State a method before the story: list the competing items, estimate the impact of each and the cost of delay, check dependencies and who is blocked, then rank and agree the order with the people affected.
2. Support it with a concrete case in which three or more pieces of work competed, for example a feature, a bug reported by users and a code review, and say what you did first and why.
3. Show the negotiation: how you went to a product manager, designer or teammate with the trade-off (if A ships Thursday, B moves to next week) rather than quietly dropping something.
4. Say how you re-prioritise when something urgent lands, such as a production bug, and how you make your queue visible so others can see what moved.
5. Avoid 'I make a to-do list and work through it'. That describes a tool, not a decision.

Follow-up

• Two stakeholders each say their request comes first. What do you do?
• A task you ranked low turns out to block someone. How do you handle it?
• How do you handle a production bug that arrives mid-sprint?

Can you give an example of a time you had a conflict with a teammate and how you resolved it?

Medium · Behavioral / Leadership

Approach

1. Pick a real disagreement with a peer about a technical or process decision, such as an API shape, a testing approach or a review comment, not a personality clash with an obvious villain.
2. Describe the other person's position fairly, in terms they would accept, then yours. Interviewers cannot judge a resolution if the opponent sounds foolish.
3. Walk through the steps you took: a direct conversation first, then trying to understand their constraints, then bringing evidence such as a small prototype, a benchmark or a link to the requirement.
4. State how it ended and how the working relationship was afterwards, including the case where you were the one who changed your mind.
5. Do not choose a story where you simply won, or where it was passed to a manager without you trying anything.

Follow-up

• What if they still disagreed after you showed the evidence?
• What did you learn about how that person works?
• Would you handle it differently now?

What motivates you to perform well at work?

Medium · Behavioral / Leadership

Approach

1. Give two or three specific motivators and attach each to something you did, not a trait. For example: seeing a feature used, removing a recurring bug, or learning an unfamiliar part of a system.
2. Connect them to the work the role describes: building features, improving existing applications, debugging issues users report, and working with product and design colleagues.
3. Back it with a short example in which that motivation changed your behaviour, such as volunteering for the fix nobody wanted or staying until a rollout was verified.
4. Be honest about what drains you and how you handle it. A believable answer includes the unglamorous parts of the job.
5. Avoid generic lines such as 'I love solving problems' or answers centred only on pay or title.

Follow-up

• Tell me about a time your motivation was low. What did you do?
• How do you stay engaged during repetitive or maintenance work?
• What kind of work would you not want to do?

How do you handle feedback and criticism?

Medium · Behavioral / Leadership

Approach

1. Choose a real piece of critical feedback, ideally a code review or a design review, not a disguised strength such as 'I care too much'.
2. Describe your first reaction honestly, then what you did: asked clarifying questions, separated the substance from the tone, and decided what to change.
3. Show the change that stuck, for example a new habit like writing tests first or adding a design note before large pull requests, and how you checked that it worked.
4. Add the other direction briefly: how you give feedback to a peer, specific to the code and with a suggestion rather than a verdict.
5. If you disagreed with the feedback, say how you raised it with evidence and stayed open to being wrong.

Follow-up

• Describe feedback you disagreed with and what you did.
• How do you give feedback on a colleague's pull request?
• Has feedback ever changed how you work day to day?