Achieve Software Engineer Interview Guide

The 60-second brief

Candidates describe Achieve as a company where software engineers build financial products, including a decisioning platform. The reported role covers designing, coding and testing software, working with product managers and designers to turn requirements into working features, taking part in code reviews, and fixing defects in existing applications. The requirements candidates describe list JavaScript, PHP or Java, a framework such as React or Angular, SQL and NoSQL databases, and cloud services, with DevOps practice, Agile and UX/UI familiarity as extras.

This guide is for candidates interviewing for a Software Engineer position at Achieve. It covers the five reported stages, the reported technical questions (a JavaScript typeahead, the two-numbers-that-add-to-a-target problem, SQL query tuning, the Zend Framework, REST API and microservice design, real-time financial data processing, web performance debugging, ambiguous requirements), the behavioral prompts, and how to divide a week of practice among them. It rests on candidate reports, not on a published process.

Candidates report five stages over roughly 4-6 weeks: Initial Screening, Technical Interviews, Behavioral Interviews, Team Interactions and Final Discussions. The last stage may involve higher management.

Focus areas

• Typeahead / Autocomplete
• System Design
• Java

Overview

Candidates describe the work as a blend of new feature development and maintenance: designing, coding and testing software, reviewing teammates' code, fixing defects, and working with product managers and designers. The products mentioned include a decisioning platform and financial products. For preparation, that means breadth. You need clean code in a live exercise, a clear view of how a web application talks to a database, and the ability to explain a technical choice to someone who is not an engineer.

The stack candidates list is JavaScript, PHP or Java, React or Angular on the front end, SQL and NoSQL data stores, and cloud services, with DevOps practice as a bonus. The topics that stand out in reports are typeahead or autocomplete, system design, Java, the Zend Framework and Firebase. Write a typeahead from scratch in JavaScript until it is routine, be ready to compare SQL and NoSQL for a given workload, and if you have not used Zend, know what a PHP MVC framework provides and say plainly which frameworks you have used instead.

The reported questions fall into five groups. Coding: a typeahead function and a pair-sum problem. Technical knowledge: Zend Framework features, SQL query optimisation, Unix administration with shell scripting, and version control. Design: real-time data processing in a financial application, a microservices architecture for a new product, and REST API considerations. Problem-solving: debugging a web performance issue and clarifying ambiguous requirements. Behavioral: a challenging project, prioritising under tight deadlines, and a difficult team member. Candidates also mention live coding or a take-home assignment, so practise both explaining while you type and producing something a reviewer can read cold.

The Achieve interview process

Candidates describe five stages. The reports do not tie specific questions to specific stages, so prepare every question type for any technical or behavioral conversation.

Initial Screening

Candidates describe the Initial Screening as the first filter on fit for the role. Reports do not detail its format, so prepare for a conversation about your background and the stack the role lists: JavaScript, PHP or Java, React or Angular, SQL and NoSQL, and cloud services. Be ready to say which of those you have shipped with, not only read about.

What to demonstrate

• How your experience maps to the languages and frameworks the role lists
• How clearly you summarise past projects and your own part in them

How to prepare

• Write a two-minute summary of your last project naming the language, framework, database and where it ran, and your own contribution.
• Prepare one honest sentence for each listed technology you have not used (for example Zend or Firebase) that links it to something you have.
• Write down your logistics and availability so you can answer without hesitation.

Technical Interviews

The Technical Interviews are reported as several interviews on technical assessments and problem-solving. Candidates mention live coding or take-home work, and the question groups reported are coding (a JavaScript typeahead, a target-sum pair), SQL optimisation, Zend Framework features, Unix and shell experience, version control, system design and debugging a slow web application. Practise each aloud, because explaining the choice matters as much as the code.

What to demonstrate

• Working code in JavaScript or your strongest language, with complexity stated
• Database reasoning, including how you would speed up a slow SQL query
• Design reasoning for services, APIs and real-time data flows
• A systematic approach to a performance problem

How to prepare

• Write the typeahead function from a blank file: debounce input, match by prefix, cancel or ignore stale responses, and handle an empty query.
• Solve the target-sum pair problem with a hash map in one pass and state time and space.
• Take one slow query, read its execution plan, and explain the index or rewrite that fixes it.
• Outline answers for the real-time financial processing, microservices and REST API design questions.

Behavioral Interviews

Candidates describe the Behavioral Interviews as discussions of past experiences and how they connect to Achieve's goals. Reported prompts include a challenging project, prioritising under tight deadlines and working with a difficult team member, and candidates also mention leadership examples even for engineer roles. The reports file the Unix and version control questions under technical topics, but they are answered best as experience stories too.

What to demonstrate

• Ownership of a decision and its outcome in your own past work
• How you handle pressure, conflict and competing priorities
• Leadership and influence shown through examples, even without a title

How to prepare

• Build a story bank of four real examples: a hard project, a deadline trade-off, a disagreement, and a time you led without authority.
• Write each in situation, action, result form and cut the context to two sentences.
• Rehearse aloud using "I" for your own actions and name the result with a real measure.

Team Interactions

Team Interactions are reported as conversations with various team members, including engineers and product managers. The role is described as working with product management and user experience, so expect to explain technical choices in product terms and to clarify unclear requirements together. Design and API topics are natural material here.

What to demonstrate

• How you communicate with engineers and with product managers
• How you turn an unclear request into clear requirements
• Collaboration on design topics such as REST API considerations

How to prepare

• Prepare a list of clarifying questions for an ambiguous feature: who uses it, what success means, what must not break, what can wait.
• Practise explaining your REST API choices (resources, status codes, idempotent retries, versioning) to a non-engineer in plain terms.
• Prepare a short story about a code review where you gave or received feedback that changed the outcome.

Final Discussions

Final Discussions are reported as concluding conversations that may involve higher management. Reports give no format, so prepare for a wider conversation about the scope of your past work, how you prioritise and what you want from the role. Revisit your prioritisation and team-conflict stories, and prepare questions about the team, the products and how engineers work with product partners.

What to demonstrate

• The scope and impact of your past work
• How you prioritise and communicate trade-offs
• Fit with the team and your reasons for wanting this role

How to prepare

• Sharpen the tight-deadline story: what you cut, what you protected and what you told stakeholders.
• Prepare three questions about the products, team structure and how engineers and product managers work together.
• Write a short, specific answer to why financial products and why this role.

Where candidates lose points

Writing the typeahead as a fetch on every keystroke, with no handling of fast typing or out-of-order responses.

Debounce the input, cancel or ignore stale requests, normalise case and whitespace, handle the empty query, and explain how prefix matching works, whether a filter over an array, a sorted array with binary search, or a trie.

Solving the pair-sum problem with nested loops and stopping there, or returning the same element twice.

State the O(n^2) baseline, then use a hash map from needed value to index in one pass for O(n) time and space. Say what you do with duplicates and with no valid pair.

Answering the SQL optimisation question with "add an index" and no evidence.

Read the execution plan first, find the scan or join that dominates, then check whether an index is usable (a function on the column or a leading wildcard can defeat it), whether the query returns more columns or rows than needed, and measure before and after.

Answering the microservices, REST API or real-time financial processing design questions with a list of buzzwords and no boundaries or failure handling.

Name service boundaries and who owns each table, how services communicate, how a retried request avoids double-applying (idempotency keys), what is ordered or audited, and what happens when a dependency is down.

Giving behavioral answers in "we" with no personal decision, or answering the Unix and version control questions as lists of commands.

Use "I" for your own actions, give the decision, the alternatives and a measured result, and answer the Unix and version control questions with a real situation where your choice mattered.

Questions & practice

If given a project with ambiguous requirements, how would you clarify them?

Medium · Problem-Solving / Case Studies

Approach

1. Find the decision behind the request first: ask who the users are, what problem they have today and how success will be measured, so every later question is tied to an outcome rather than to a feature list.
2. Order the open questions by how much each one changes the design: data volume and scale, which failure behaviour is acceptable, permissions and compliance constraints, integrations, and deadlines. Ask the high-impact ones first.
3. Write back a short spec in my own words with acceptance criteria, explicit assumptions and non-goals, and get the product owner to confirm or correct it in writing before building.
4. Reduce the remaining uncertainty with a thin vertical slice, mock-up or prototype that stakeholders can react to, and keep the parts most likely to change behind clean interfaces.
5. Apply the same habit in a live coding question: restate the input, its size and edge cases (empty input, duplicates, invalid values) and confirm the expected output before writing code.

Follow-up

• Two stakeholders give you conflicting answers. How do you resolve it?
• The product owner is unavailable and the deadline is fixed. What do you build?
• Requirements change halfway through the sprint. How do you handle work already done?

Write a function to implement a typeahead feature using JavaScript.

Medium · Coding / Algorithms

Approach

1. Split the problem into matching and UI. For matching against a local list, normalise case and whitespace, then either sort the list once and binary search for the first entry with the prefix, scanning while startsWith holds (O(log n + k) per query), or build a trie (O(L) to reach the prefix node, then collect up to k results).
2. For ranked suggestions, store a popularity score per term and keep the top-k terms at each trie node, trading memory for constant-time lookup per prefix. Without that, collect matches and sort by score, which costs more per keystroke.
3. Debounce the input handler so the lookup or fetch runs only after typing pauses: let t; return (...a) => { clearTimeout(t); t = setTimeout(() => fn(...a), ms); }. Cache results per prefix in a Map so backspacing does not refetch.
4. Handle out-of-order responses: cancel the previous request with AbortController, or tag each request with an incrementing id and ignore any response that is not the latest. Clear the list on empty input and show a no-results state.
5. Make the dropdown usable and safe: ArrowUp/ArrowDown/Enter/Escape keyboard handling, ARIA combobox roles (role="combobox", aria-expanded, aria-activedescendant, listbox and option), and render matches with textContent rather than innerHTML to avoid XSS when highlighting the matched prefix.

Follow-up

• What is the difference between debounce and throttle, and which fits typeahead better?
• The dictionary has millions of terms and cannot ship to the browser. How does the server side change?
• How would you support typo tolerance or matching in the middle of a word?

Given a list of integers, find two numbers that add up to a specific target.

Medium · Coding / Algorithms

Approach

1. Confirm the contract first: return indices or values, whether exactly one answer is guaranteed, whether the same element may be used twice, and what to return when there is no pair.
2. State the brute force (check every pair, O(n^2) time, O(1) space), then improve it with a hash map from value to index in one pass: for each x, look up target - x before inserting x. That gives O(n) time and O(n) space.
3. Checking before inserting matters: it stops an element pairing with itself (nums = [3], target = 6) while still finding duplicates such as [3, 3] with target 6, because the first 3 is already in the map when the second arrives.
4. Mention the alternative: sort (value, index) pairs and move two pointers inward, O(n log n) time. On already-sorted input this needs only O(1) extra space, which is the better choice when memory matters.
5. Cover edge cases: negative numbers and zero, fewer than two elements, multiple valid pairs (say which one you return), and in Java, int overflow when computing target - x or a + b, which you avoid by using long.

Follow-up

• Return all unique pairs that sum to the target, without duplicates.
• The input is already sorted. Can you do it in O(1) extra space?
• Extend it to three numbers that sum to the target. What is the complexity?

Explain how you would optimize a SQL database query.

Medium · Technical / Domain Questions

Approach

1. Measure before changing anything: find the slow statement in the slow query log or APM, then run EXPLAIN (EXPLAIN ANALYZE in PostgreSQL, or in MySQL 8.0.18+) and compare estimated with actual rows to spot full scans, bad join orders and stale statistics.
2. Fix access paths with indexes: put equality columns first and the range or sort column last in a composite index (leftmost-prefix rule), and consider a covering index so the query never touches the table rows.
3. Remove what blocks index use: functions or casts on the indexed column (WHERE DATE(created_at) = ...), implicit type conversion, leading-wildcard LIKE '%term', and OR across different columns. Rewrite as a range or use an expression index.
4. Cut the work the query does: select only the needed columns instead of SELECT *, replace OFFSET paging with keyset paging (WHERE id > last_id ORDER BY id LIMIT n), and collapse ORM N+1 loops into one join or IN query.
5. State the trade-offs: every index slows INSERT and UPDATE and costs storage, a low-selectivity column rarely benefits from an index, and the planner sometimes chooses a sequential scan correctly. Re-measure with the same query and data after each change.

Follow-up

• The plan shows the index is used but the query is still slow. What do you check next?
• How would you add an index to a large, busy production table without blocking writes?
• When would you denormalise or add a cache instead of tuning the query further?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

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

1. 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.
2. 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.
3. 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.
4. 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?

What are the key features of the Zend Framework?

Medium · Technical / Domain Questions

Approach

1. Place it first: Zend Framework is a PHP framework built from loosely coupled components that can be used on their own. It became the Laminas Project under the Linux Foundation in 2020, so say which version you used (ZF1, ZF2/3 or Laminas).
2. Cover the MVC layer: routing to controllers and actions, view models and templates, and in ZF2/3 the module system, where each module brings its own config, routes and services.
3. Explain the ServiceManager (the dependency injection container with factories) and the EventManager (the MVC dispatch cycle runs as events you can attach listeners to). These two are what make ZF2/3 testable and extensible.
4. List the data and request components with real usage: Zend\Db TableGateway and the Sql abstraction for parameterised queries, Form plus InputFilter and Validator for input handling, Authentication and Acl/Rbac for access control, Cache for storage adapters.
5. Close with a trade-off from your own work, for example: I found the configuration-heavy setup slower to start with than lighter frameworks, but explicit factories made dependencies easy to mock in PHPUnit.

Follow-up

• How would you migrate a ZF2 application to Laminas, and what does the laminas-zendframework-bridge or namespace rewrite involve?
• How does a request flow from the router to a rendered response in a ZF MVC application?
• How do you prevent SQL injection when using Zend\Db?

Design a system for real-time data processing in a financial application.

Medium · System Design / Architecture

Approach

1. Pin the scope first: which events (card transactions, payments, balance changes), what volume and peak rate, which latency the consumer needs, and what must never happen (double-counting money, losing an event).
2. Ingest into a durable, replayable log such as Kafka, partitioned by account id so the events for one account stay in order. Process with a stream processor (Kafka Streams or Flink) using event time and watermarks so late events land in the right window.
3. Make processing safe to repeat: delivery is at-least-once, so give every event a unique id and make writes idempotent (upsert keyed on event id, or a processed-ids table updated in the same transaction). Use the transactional outbox pattern so a DB write and its event cannot diverge.
4. Store money as integer minor units or a fixed-point decimal, never floats, and keep an append-only ledger (double-entry if balances are involved) so every balance can be rebuilt and audited by replaying the log.
5. Plan for failure and compliance: a dead-letter topic for malformed events, a daily reconciliation job against the source of truth, consumer-lag alerts, encryption of PII at rest and in transit, and a replay path for reprocessing after a bug fix.

Follow-up

• A consumer crashes after writing to the database but before committing its offset. What happens and how does your design handle it?
• One very large merchant or account creates a hot partition. How do you rebalance without breaking per-account ordering?
• How would you add a real-time fraud or risk check without increasing the latency of the main path?

How would you approach building a microservices architecture for a new product?

Medium · System Design / Architecture

Approach

1. Question the premise for a new product: with an unproven domain I would start with a modular monolith with clear internal boundaries and split out services only where independent scaling, deployment or team ownership justifies the network and operational cost.
2. Draw service boundaries by business capability (bounded contexts), give each service its own datastore, and never let one service read another's tables. Shared data moves through APIs or events.
3. Choose communication per interaction: synchronous REST or gRPC when the caller needs an answer now, asynchronous events through a broker when it does not. Handle cross-service workflows with sagas and compensating actions, not distributed two-phase commit.
4. Build in resilience: timeouts on every call, retries with exponential backoff and jitter only for idempotent operations, circuit breakers, and an API gateway for authentication, routing and rate limiting.
5. Make it operable from day one: per-service CI/CD pipelines, contract tests between services, centralised logs with correlation ids, distributed tracing (OpenTelemetry), and health checks for the orchestrator.

Follow-up

• An order needs to reserve funds in one service and create a record in another. How do you keep them consistent if the second step fails?
• How would you split an existing monolith into services without a big-bang rewrite?
• What signals would tell you a service boundary was drawn in the wrong place?

Discuss the considerations you would take into account when designing a RESTful API.

Medium · System Design / Architecture

Approach

1. Model resources as nouns with clear hierarchy (/accounts/{id}/payments) and use HTTP methods by their semantics: GET is safe, PUT and DELETE are idempotent, POST is not. Support an Idempotency-Key header on POST so a retried create cannot run twice.
2. Return precise status codes: 201 with a Location header on create, 400 for malformed input, 401 versus 403 for missing versus insufficient credentials, 404, 409 for state conflicts, 429 with Retry-After, and one consistent error body (for example RFC 9457 problem details) with a machine-readable code.
3. Handle concurrency and long operations: ETag with If-Match for optimistic locking (412 Precondition Failed on a stale write), and 202 Accepted plus a status resource for work that finishes later.
4. Design for growth: cursor-based pagination rather than OFFSET for large or changing collections, filtering and sorting through query parameters, and a versioning strategy (URL prefix or header) with additive, backward-compatible changes inside a version.
5. Cover security and operations: HTTPS only, OAuth2 or token authentication with per-resource authorisation checks, input validation, rate limits per client, and an OpenAPI specification that serves as the contract and drives tests.

Follow-up

• A client times out on a POST that creates a payment and retries. Walk through what your API does.
• How would you roll out a breaking change to a response field that mobile clients already depend on?
• When would you choose GraphQL or gRPC over REST for this API?

How would you approach debugging a performance issue in a web application?

Medium · Problem-Solving / Case Studies

Approach

1. Define the symptom precisely: which pages or endpoints, which users, since when, and which percentile moved (p50 against p95/p99). Check whether it lines up with a deploy, a traffic change or a data growth step.
2. Split frontend from backend: the browser DevTools network waterfall shows whether time goes to server response (TTFB) or to download, render and JavaScript. Core Web Vitals (LCP, INP, CLS) and a Lighthouse or performance profile locate client-side cost such as large bundles or long main-thread tasks.
3. On the backend, follow a trace from the APM or OpenTelemetry to the slowest span. Typical culprits are slow or N+1 database queries (check the slow query log and EXPLAIN), a slow external call without a timeout, and connection or thread pool exhaustion.
4. Check resource saturation: CPU, memory and garbage-collection pauses, database connections, lock waits, and cache hit rate. A drop in cache hits often explains a sudden latency increase on unchanged code.
5. Reproduce with a profiler or load test, change one thing at a time, and confirm the fix with the same metric and percentile that showed the regression. Then add an alert or performance budget so the regression is caught next time.

Follow-up

• p50 is unchanged but p99 doubled. What does that suggest and where do you look?
• The slowdown only affects some users. How do you narrow it down?
• How do you prove a fix worked rather than coinciding with lower traffic?

Suggested practice checklist

Seven days built from Achieve's five reported rounds and its reported questions: two coding days, a SQL day, a design day, a debugging and framework day, a behavioral day, and a final mock.

Day 1 — Map the loop and your stack

• Write the five reported rounds in order and next to each note what you would be asked to show: Initial Screening, Technical Interviews, Behavioral Interviews, Team Interactions, Final Discussions.
• List the stack the role names (JavaScript, PHP or Java, React or Angular, SQL and NoSQL, cloud, Firebase) and mark where you have shipped code and where you have only read about it.
• Write your two-minute project summary and one sentence for each technology you have not used.

Deliverable: A one-page loop map, a stack self-assessment with gaps marked, and a written two-minute project summary.

Day 2 — Typeahead and the target-sum pair

• Write the JavaScript typeahead from scratch: debounce, prefix match, ignore stale responses, empty and no-match states.
• Add a second version using a sorted array with binary search or a trie and state the cost of building and querying it.
• Solve the pair-sum problem brute force, then with a hash map in one pass, and list your edge cases (duplicates, same element twice, no pair, negatives).

Deliverable: A working typeahead in both versions, a one-pass pair-sum solution, and a written complexity note for each.

Day 3 — SQL optimisation and data stores

• Take a slow query on a table you can load locally, read its execution plan, and fix it with an index or a rewrite, recording before and after timings.
• Write a one-page comparison of SQL and NoSQL for a workload you know, and note one case where each is the wrong choice.

Deliverable: A before-and-after query plan with timings, plus a one-page SQL versus NoSQL comparison.

Day 4 — System design: services, APIs and real-time data

• Outline a design for real-time data processing in a financial application: ingestion, queue or stream, processing, storage, audit trail, retries without double-applying, and what you do when a dependency is down.
• Outline a microservices architecture for a new product: service boundaries, data ownership, communication, and the argument for starting with fewer services.
• Write a REST API checklist: resource naming, status codes, pagination, idempotent retries, versioning, authentication and error format.

Deliverable: Three design outlines, each with components, one failure scenario and one trade-off written out.

Day 5 — Debugging, ambiguity and the Zend Framework

• Write a debugging sequence for a slow web page: reproduce, check the browser network panel, server response time, database queries, then caching and recent changes. State what each step rules out.
• Write the clarifying questions you would ask for an ambiguous feature request, then say what you would build while answers are pending.
• List the main components of the Zend Framework (MVC, service manager, event manager, forms and validation, database layer) in one line each, and note the equivalents in a framework you know.

Deliverable: A debugging runbook, a clarifying-question list, and a Zend component summary.

Day 6 — Behavioral story bank

• Write four stories in situation, action, result form: a challenging project, a deadline trade-off, a difficult teammate, and leading without authority.
• Rehearse each aloud in under two minutes, using "I" for your own actions and a real result.
• Record yourself once and cut the context until the decision is the main part.

Deliverable: Four written stories and one recorded rehearsal with notes on what to cut.

Day 7 — Unix and version control, then a full mock

• Prepare a real Unix or shell story and a version control workflow answer, including how you recover from a bad commit on main.
• Run a mock loop: one typeahead build, one SQL question, one design question and two behavioral stories, answered aloud in sequence.
• Write three questions for the team about products, the engineer and product manager working relationship, and what the first projects look like.

Deliverable: Two spoken answers on Unix and version control, notes from a full mock, and three questions to ask.

Stories for Achieve's behavioral rounds

Candidates describe the behavioral rounds as covering past experiences, leadership examples even for engineers, teamwork and conflict resolution. The Unix administration and version control prompts are filed with the technical questions in reports, but they are experience questions, so answer them with real situations too. Prepare stories where you made the decision and can state the result.

1. Describe a situation where you had to resolve a conflict within your team.

Describe your experience with Unix administration and shell scripting.

Medium · Technical / Domain Questions

Approach

1. Anchor the answer in one concrete system you actually administered: the machines or containers, what ran on them, and your part (user and permission management, package updates, services under systemd or cron, log rotation, disk and process monitoring). Claim only what you did.
2. Walk through one script you wrote: the problem, the tools (grep, awk, sed, find, xargs, curl, ssh) and the safety habits. Name set -euo pipefail, quoted variables, a trap for cleanup, meaningful exit codes, a dry-run flag, and idempotence so a rerun is harmless.
3. Show a diagnosis in order: df and du for disk, top or ps for load, lsof for open files, then journalctl or the service logs, stating what each step ruled out.
4. Say where shell stops being the right tool: once a script needs real data structures, JSON parsing or serious error handling, move it to a language with tests.
5. Connect it to delivery work: deployment scripts, build steps and CI jobs are where Unix skills show up for a software engineer, and DevOps practice is listed as a nice-to-have for this role.

Follow-up

• How do you make a script safe to run twice?
• A cron job stopped producing output without an error. How do you find out why?
• What does set -e fail to catch, for example inside pipelines or conditions?

How do you handle version control in your projects?

Medium · Technical / Domain Questions

Approach

1. Describe your real workflow: short-lived feature branches from main, small commits whose messages explain why, a pull request with review and passing CI checks, and a protected main branch.
2. Compare merge, rebase and squash. Rebase your own unpublished branch to keep history linear, never rewrite shared history, and use --force-with-lease instead of a plain force push on your own branch.
3. Cover conflicts: read both sides' intent, resolve, rerun the tests, and cut the number of conflicts by keeping branches small and syncing with main often.
4. Cover recovery: git revert for a bad commit already on shared main, git reset only for local work, git reflog to find lost commits, and git bisect to locate the commit that introduced a regression.
5. Mention hygiene that matters for a financial application: secrets and build artefacts stay out of the repository, releases are tagged, and a hotfix branch starts from the tagged release.

Follow-up

• A bad commit has reached main and been deployed. What do you do, in order?
• What does squash merge do to history and to a later git bisect?
• Two teammates changed the same function in different ways. How do you resolve it?

Describe a challenging project you worked on and how you overcame obstacles.

Medium · Behavioral / Leadership

Approach

1. Choose a project where you owned real decisions and the obstacle was specific, such as unclear requirements, a legacy codebase, a performance problem or a hard dependency. Set the scene in two sentences: system, users, constraint.
2. Spend most of the time on two or three obstacles. For each, give the options you weighed, why you chose one, and what it cost you. This reasoning is the story.
3. Show collaboration, since the role works with product managers and designers: who you aligned with, what you negotiated, and what you escalated.
4. Close with a result that is real and measurable (latency, defect count, delivery date, users unblocked) and one thing you would change.
5. The mistake that sinks it is a story where the obstacles were other people's fault, or where "we" does all the work and your own action is invisible.

Follow-up

• Which decision was riskiest, and what was the alternative?
• How did you know the solution worked?
• What would you do differently if you ran the project again?

How do you prioritize tasks when faced with tight deadlines?

Medium · Behavioral / Leadership

Approach

1. Lay out a method you really use: list everything, separate must-haves from deferrable work by user impact, dependency order and risk, and confirm the ranking with the product owner instead of guessing.
2. Tell one concrete deadline story: what you cut or postponed, what you refused to cut (for example tests around code that handles money or personal data), and the reasoning.
3. Show communication: you told stakeholders early what would slip, offered options (reduce scope, move the date, add help) and recorded the decision in writing.
4. Show follow-through: postponed items became tickets with owners, and you cleaned up after the deadline.
5. The mistake is answering "I work longer hours", or ranking by what you prefer to build rather than by impact.

Follow-up

• Two stakeholders each say their task is the top priority. What do you do?
• What did you decide not to do, and what happened as a result?
• How do you handle a task that grows once you start it?

Give an example of a time you had to work with a difficult team member.

Medium · Behavioral / Leadership

Approach

1. Pick a real but manageable conflict. Describe the behaviour and its effect on the work (missed review turnaround, dismissed suggestions, unclear handoffs), not the person's character.
2. Show you tried to understand their side first: a private conversation, questions about their constraints, and a shared goal you could both name.
3. Describe concrete actions: a working agreement on review timing or ownership, decisions written down, and for technical disagreements, evidence such as a benchmark or a small prototype.
4. Say if and when you involved a lead, after speaking to the person directly, and what you asked the lead to do.
5. Finish with the outcome and your own change in behaviour. A story that ends with the other person being wrong shows nothing about you.

Follow-up

• What if the behaviour had not changed?
• How did you give the feedback without it sounding like blame?
• Would you handle it differently now?