Candidates describe the Software Engineer role as owning software from design through testing and deployment, working with product managers, system architects and other engineers, and taking part in code reviews and documentation. The requirements they list are proficiency in core programming languages, a solid grasp of data structures and algorithms, experience across the full software development lifecycle, and the ability to explain technical designs and project challenges. Familiarity with SAPUI5 or OpenUI5, Agile practice, technical documentation and systems engineering is listed as a plus.
The reported questions fall into three groups. Short fundamentals: which languages you are strongest in, the principles of data structures and algorithms, SAPUI5 versus OpenUI5, and how you handle database management. Open-ended problems: how to build software with superb performance, a walk-through of a recent project, the Traveling Salesman Problem and the manhole-cover brain teaser. Behavioral questions: your experience with data structure development, why the company needs you, your previous experience, the business analyst habits you saw, and how you handle work culture and team expectations.
The topic breakdown also lists MBSE, although no reported question names it. Know the one-paragraph definition: models, rather than documents, act as the main record of a system's requirements, structure and behavior. Most of the loop is about your own work, so build preparation around a resume inventory: for every project, the stack, the data structures and storage you chose, a trade-off you made and a bug you tracked down. Then add a DSA refresher with complexity statements you can say without hesitation, and rehearse the brain teaser by reasoning aloud rather than memorizing a verdict.
Initial Screening
reportedCandidates describe the first stage as a review of your application against basic qualifications. Nothing more is reported about its format, so treat your resume and your short career narrative as the material. Be ready to say which languages you work in, what you have built with data structures, and why you want this company.
What to demonstrate
- Match between your resume and the requirements candidates list: core languages, DSA, and the full software development lifecycle
- A short, structured account of your career path and your interest in ASD
- Whether your stated language and database experience is specific enough to discuss further
How to prepare
- Map each resume line to a requirement and write one sentence of evidence for it; every project you list may be discussed in depth
- Write a present-past-future career narrative and a reason for choosing ASD that refers to the engineering work candidates describe
- Pick the two languages you will name as strongest and prepare idioms, tooling and a project for each
Technical Assessment
reportedCandidates describe coding challenges and technical evaluations. A coding stage tests working code, so expect data structures, algorithms and complexity to be central. The reported technical questions also cover language proficiency, DSA principles, SAPUI5 versus OpenUI5, database management, performance, the Traveling Salesman Problem and a brain teaser; the reports do not say which round asks which, so prepare them all for any technical stage.
What to demonstrate
- Working code and the complexity of the solution you choose
- Command of core data structures and algorithms, as the requirements list them
- How you reason out loud on open-ended problems such as the Traveling Salesman Problem
How to prepare
- Build a cheat sheet of operation costs for arrays, hash maps, heaps, trees and graphs, then solve the overlapping-attempts and event-batch coding drills in PracHub's practice set aloud
- Write a ladder answer for the Traveling Salesman Problem: brute force, dynamic programming, then heuristics
- Prepare a half-page comparison of SAPUI5 and OpenUI5 and a structured answer on how you manage databases
Behavioral Interview
reportedCandidates describe interviews with team leads and managers that assess interpersonal skills and fit. The reported questions in this group cover why the company needs you, your previous experience, the business analyst habits you observed, and how you handle work culture and team expectations. This stage is about stories from your own work, told with specific decisions and outcomes.
What to demonstrate
- Interpersonal skills and team fit, as the stage is described
- How clearly you explain your own past work and decisions
- How you work with product, analyst and architect colleagues
How to prepare
- Write four short stories: a technical decision, a requirement that changed, a disagreement or feedback moment, and a time you adapted to a team norm
- Rehearse the answers on data structure development, previous experience and business analyst habits with concrete examples, not summaries
- Prepare an answer about why the company needs you that ties your strongest evidence to the requirements candidates list
Final Assessment
reportedCandidates describe the last stage as a review of overall performance before a decision is made. Little else is reported about its format. Use the days before it to close the gaps that surfaced earlier, and keep your project walk-through and career narrative consistent with what you already said.
What to demonstrate
- Overall performance across the earlier stages, as candidates describe it
- Whether your account of your own work stays consistent when revisited
How to prepare
- After each earlier stage, write down the questions that went worst and rework those answers
- Re-run the project walk-through: technologies used, challenges faced, how you overcame them
- Prepare questions about the team's software lifecycle, documentation and review practices
PracHub editorial advice for the preparation topics above.
Answering the languages question with a list of everything you have touched
Name two languages, then back each with a project, idioms, tooling and one limitation you hit. Be ready for a follow-up on memory model, typing or testing in each.
Presenting a Traveling Salesman answer as a single algorithm that solves it efficiently
State that it is NP-hard, then climb the ladder: brute force over permutations is factorial, Held-Karp dynamic programming is O(n^2 * 2^n), and nearest neighbour with 2-opt gives good tours without optimality. Name the input size each suits.
Giving a memorized verdict on the manhole-cover brain teaser and stopping
Reason aloud with criteria: a circle cannot fall through its own opening, is easy to roll, and is simple to manufacture. Test each criterion against alternatives such as squares, as the reported guidance suggests process matters more than the riddle's answer.
Walking through a recent project as a technology list with no failure or trade-off
Structure it as context, stack, two real challenges, what you tried, what worked and a result. Include one bug and the sequence you followed: reproduce, isolate, hypothesize, fix, add a regression test.
Answering the performance and database questions with generic advice
Define a measurable target, profile before optimizing, then discuss data structure choice, indexes, query shapes, caching and I/O with a number from your own work. Practice with the SQL and debugging drills in PracHub's practice set.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
What are the fundamental principles of Data Structures and Algorithms (DSA)?
What are the fundamental principles of Data Structures and Algorithms (DSA)?
Approach
- Open with complexity analysis: Big-O for time and space, worst case versus average versus amortised (a dynamic array append is amortised O(1) because resizes double the capacity).
- Map core structures to their operation costs: array O(1) index access; hash map O(1) average and O(n) worst-case lookup; balanced BST O(log n) with ordered traversal; binary heap O(log n) push and pop with O(1) peek; linked list O(1) insert or delete at a known node.
- Name the main algorithm patterns and when each applies: two pointers and sliding window on sequences, binary search on sorted data or a monotonic predicate, BFS and DFS on graphs in O(V + E), dynamic programming when subproblems overlap and have optimal substructure, greedy only when an exchange argument proves it.
- Know the sorting trade-offs: comparison sorts have an Omega(n log n) lower bound; merge sort is stable with O(n) extra space; quicksort averages O(n log n) but degrades to O(n^2); heapsort is in place but not stable.
- Tie it together with the principle of choosing the structure from the access pattern and constraints (input size, memory, ordering needs), then illustrate with one problem you solved that way.
Follow-up
- When would a balanced BST beat a hash map even though its lookups are slower?
- How do you prove a greedy algorithm is correct, or show that it fails?
- Explain why the worst case of hash map lookup is O(n) and how implementations limit it.
Find overlapping job attempts and peak concurrency from lease records
A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.
Approach
- Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
- For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
- For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
- Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.
Follow-up
- A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
- Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?
Collapse a redelivered event batch into per-aggregate high-water marks
You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.
Approach
- One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
- Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
- Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
- If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.
Follow-up
- The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
- How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
Stop tag and share joins from fanning out a page
resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.
Approach
- Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
- Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
- Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
- Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.
Follow-up
- The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
- A resource can be shared with the same user twice under different permissions. Does your count change, and should it?
Which programming languages are you most proficient in?
Which programming languages are you most proficient in?
Approach
- Name one or two languages you can defend in depth rather than listing every language you have touched, and rank them honestly: primary for production work, secondary for scripts or tooling.
- Back each one with evidence from a shipped project: what you built in it, roughly how large the codebase was, and which part you owned.
- Show depth below the syntax: for Python, that the CPython GIL keeps CPU-bound threads from running in parallel, so I use multiprocessing or native extensions there; for Java, how the JVM garbage collector and generics with type erasure affect design.
- Mention the tooling around the language that you actually use: build and dependency tools, test frameworks, profilers and linters.
- Close with how you pick up a new language: what you read first (memory model, concurrency, standard collections) and an example of ramping up on one for a project.
Follow-up
- What is a weakness or trap in your main language that has bitten you in production?
- How would you choose between your two strongest languages for a new service?
- How does your main language handle concurrency, and when have you had to work around it?
What is the difference between SAPUI5 and OpenUI5?
What is the difference between SAPUI5 and OpenUI5?
Approach
- State the core relationship: OpenUI5 is the open-source subset of SAPUI5, released under the Apache 2.0 licence, while SAPUI5 is the SAP-licensed distribution delivered with SAP platforms and covered by SAP support.
- Name what they share: the same MVC architecture (XML views, controllers, components), the core and sap.m control libraries, data binding, and models such as JSONModel, ResourceModel and the OData V2 and V4 models.
- Name what only SAPUI5 adds: libraries such as the smart controls in sap.ui.comp (SmartTable, SmartFilterBar), sap.viz charts and the SAP Fiori elements libraries, which matters if an app depends on them.
- Cover the practical consequences: where each is loaded from (the OpenUI5 or SAPUI5 CDN), that UI5 Tooling builds both, that OpenUI5 support is community-based through GitHub, and that an app using only shared libraries can move between them.
- Give a selection rule: OpenUI5 for apps outside the SAP landscape or where licensing matters, SAPUI5 when the app runs on SAP systems and needs SAP-only libraries or vendor support.
Follow-up
- If an OpenUI5 app later needs a SmartTable, what changes in your project?
- How does the OData V4 model differ from the V2 model in binding and batching?
- How do you structure a UI5 app so views stay declarative and logic stays testable?
How do you approach database management in your projects?
How do you approach database management in your projects?
Approach
- Start from schema design: normalise to roughly third normal form so each fact lives in one place, then denormalise deliberately where a measured read path needs it, and say what keeps the copies consistent.
- Derive indexes from the actual queries: composite index column order follows equality filters first, then range or sort columns; confirm with EXPLAIN or EXPLAIN ANALYZE, and remember every index slows writes.
- Treat schema changes as versioned migrations (Flyway, Liquibase, Alembic or similar) checked into the repo, and use expand-and-contract so old and new application versions both work during a deploy.
- Explain transaction boundaries and isolation: what has to be atomic, which isolation level you use, and how you avoid lost updates (row locks with SELECT ... FOR UPDATE or optimistic version columns).
- Finish with operations: connection pooling, monitoring slow queries, backups with point-in-time recovery, and restore drills, because an untested backup is not a backup.
Follow-up
- How would you rename a heavily used column without downtime?
- How do you find and fix an N+1 query problem coming from an ORM?
- When would you pick a document store over a relational database for a project?
How would you approach building software that delivers superb performance?
How would you approach building software that delivers superb performance?
Approach
- Define performance before optimising it: the target metric (p50 and p99 latency, throughput, memory, start-up time) and a budget, measured under a realistic load.
- Measure first: profile with a CPU profiler or flame graph, trace requests end to end, and find the hot path; Amdahl's law says speeding up a part that is 5% of the time can never save more than 5%.
- Fix in order of payoff: algorithm and data structure choice first, then I/O (batching, removing N+1 queries, adding indexes, pagination), then caching with an explicit invalidation rule such as cache-aside with a TTL.
- Use concurrency where work is independent: async I/O, connection pools and worker pools, while watching for contention on shared locks and for exhausting downstream connections.
- Keep it fast: load tests and benchmarks in CI that fail on regressions, plus production dashboards on the same metrics; state the trade-offs, such as caching adding staleness and complexity.
Follow-up
- Why does p99 latency matter more than the average for user-facing requests?
- How would you prevent a cache stampede when a hot key expires?
- Walk me through a time a profiler showed the bottleneck was somewhere you did not expect.
Can you walk through a recent project, including the technologies used, the challenges faced, and how you over
Can you walk through a recent project, including the technologies used, the challenges faced, and how you overcame them?
Approach
- Set context in a few sentences: the problem, who used the system, the constraints (scale, deadline, team size) and exactly what you owned.
- Describe the architecture as data flow: main components, how requests or data move between them, and where state is stored, so the listener can sketch it.
- Justify each technology against an alternative you rejected (for example a relational database over a document store because the data had joins and needed transactions), not just name the stack.
- Go deep on one hard challenge: the symptom, how you measured or reproduced it, the hypotheses you ruled out, the fix, and how you verified it worked.
- End with a measurable result (latency, error rate, delivery date, users) and what you would change now, which shows you can critique your own design.
Follow-up
- What would break first if usage grew ten times?
- Which decision on that project would you reverse, and why?
- How did you split the work with teammates, and where did you disagree?
How would you solve the Traveling Salesman Problem?
How would you solve the Traveling Salesman Problem?
Approach
- Clarify first: how many cities, symmetric or asymmetric costs, whether distances obey the triangle inequality, and whether an exact optimum or a good tour is needed; then note TSP is NP-hard, so no known polynomial exact algorithm exists.
- Brute force checks all (n-1)!/2 tours of a symmetric instance, which is only feasible for about 10 cities.
- Exact for small n: Held-Karp dynamic programming, where dp[mask][j] is the cheapest path that starts at city 0, visits the set mask and ends at j; dp[mask | 1<<k][k] = min(dp[mask][j] + d[j][k]); O(n^2 * 2^n) time and O(n * 2^n) memory, practical to roughly 20 cities; keep parent pointers to rebuild the tour.
- For large n use heuristics: nearest neighbour in O(n^2) for a starting tour, then 2-opt or Or-opt local search; in the metric case the MST double-tree method gives a 2-approximation and Christofides gives 1.5; without the triangle inequality no constant-factor approximation exists unless P = NP.
- Mention exact solvers for large real instances (branch and bound, integer programming with cutting planes, as in Concorde) and state which approach you pick for the size and accuracy given.
Follow-up
- Write Held-Karp and show how you reconstruct the tour from the table.
- Why does a 2-opt move improve a Euclidean tour that has two crossing edges?
- How would you handle time windows or several vehicles?
Why are manhole covers round? (Brain teaser)
Why are manhole covers round? (Brain teaser)
Approach
- Lead with the geometric reason: a circle has constant width, so a cover resting on a slightly smaller lip cannot fall through the opening whichever way it is turned.
- Contrast with a square: its diagonal is the side times the square root of 2, so tilted on edge a square cover can drop through its own opening.
- Add the practical reasons: a round cover needs no orientation to seat, can be rolled rather than carried, and fits a round shaft, which is simple to dig and spreads soil pressure evenly.
- Note the edge case to show precision: other constant-width shapes such as the Reuleaux triangle also cannot fall through, so the circle is chosen for the combination of safety, orientation-free fitting and easy casting.
- Talk through the reasoning aloud, list several factors, and say which one you consider decisive and why, rather than giving a one-line answer.
Follow-up
- How could a square cover be made safe?
- Which other shapes would also not fall through their own hole?
- Estimate how many manhole covers a large city has.
Listing latency scales with page size, not with filters
The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.
Approach
- Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
- Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
- Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
- Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.
Follow-up
- The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
- How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?
The plan follows the four reported rounds and the reported question set: map and inventory first, then DSA and data structures, databases and SAPUI5, performance and project walk-through, the brain teaser and behavioral stories, and a full mock loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and inventory your resume
- Write the four reported rounds (Initial Screening, Technical Assessment, Behavioral Interview, Final Assessment) with what each is reported to cover
- For every project on your resume, list the stack, the data stores, one trade-off and one failure
- Compare against the requirements candidates list (core languages, DSA, lifecycle, communication, plus SAPUI5/OpenUI5, Agile, documentation) and mark the gaps
Deliverable: A one-page loop map and a resume inventory table with gaps marked.
02DSA fundamentals and complexity
- Write a cheat sheet of operation costs for arrays, hash maps, heaps, stacks, queues, linked lists, trees and graphs, with when each fits
- Solve the overlapping-attempts and event-batch coding drills in PracHub's practice set aloud, stating complexity at the end of each
- Write your own answer to what the fundamental principles of DSA are: choosing structures from access patterns, and reasoning about time and space
Deliverable: A cheat sheet, two solved drills with complexity statements and a spoken DSA principles answer.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Build structures and answer the Traveling Salesman Problem
- Implement an LRU cache and a trie from scratch with tests for empty input, duplicates and capacity of one
- Prepare the data structure experience answer around one of them, with per-operation costs
- Write the Traveling Salesman ladder: brute force O(n!), Held-Karp O(n^2 * 2^n), nearest neighbour and 2-opt heuristics, and when each applies
Deliverable: Two tested implementations and a half-page Traveling Salesman answer.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Languages, databases and SAPUI5
- Choose your two strongest languages and write the evidence for each: a project, idioms, tooling, one limitation
- Write a database management answer covering schema design, indexes, transactions, migrations and backups, drawn from your projects
- Do the index and join fan-out SQL drills in PracHub's practice set
- Write a half-page SAPUI5 versus OpenUI5 comparison and check it against the current UI5 documentation
Deliverable: A language evidence sheet, a database answer and a SAPUI5 versus OpenUI5 comparison.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05Performance and the project walk-through
- Answer how to build software with superb performance: define a target, profile first, then structure choice, queries, caching and I/O
- Work the listing-latency debugging drill in PracHub's practice set and note your investigation sequence
- Write the walk-through of your most recent project: technologies, two challenges, how you overcame them, plus one bug story from reproduction to regression test
Deliverable: A performance answer, a debugging sequence and a project walk-through script.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Brain teaser and behavioral stories
- Practice the manhole-cover question aloud by listing criteria and testing alternatives instead of reciting one reason
- Write STAR stories for business analyst habits and for work culture and team expectations
- Write your why-you answer from the requirements candidates list, with evidence for two of them, and record your career narrative
Deliverable: A brain-teaser outline, two STAR stories, a why-you answer and a recorded career narrative.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full mock loop
- Run the stages in order: career narrative, a timed coding drill, then a technical question mix
- Answer the behavioral set aloud, then the project walk-through again
- Review the weakest answers and write three questions about the team's lifecycle, documentation and review practice
Deliverable: A scored list of weak answers and a final set of questions to ask.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates describe interviews with team leads and managers covering interpersonal skills and fit. The reported questions ask about your data structure experience, why the company needs you, your previous experience, business analyst habits and work culture. Answer with decisions you made and what came of them.
What is your experience with data structure development?
What is your experience with data structure development?
Approach
- Choose one structure you built or heavily customized, such as an LRU cache from a hash map and doubly linked list, a trie for prefix lookup, a ring buffer or an interval index, rather than listing structures you have imported from a library.
- Tell it as a story: the access pattern, the operations you needed and their target cost, the alternatives you rejected and why, then what you implemented.
- State per-operation time and memory overhead, and the invariants you tested: empty input, duplicates, capacity of one, and concurrent access if relevant.
- If your experience is mostly library use, say so and describe a choice between built-in structures backed by a benchmark or profile, such as list versus set membership or deque versus list for queues.
- Close with the measurable effect on correctness or speed, and avoid reciting textbook definitions.
Follow-up
- Why not use the standard-library version?
- How did you test that the structure's invariants always held?
- How would it behave at a hundred times the data or under concurrent writers?
What makes you think we need you in our company?
What makes you think we need you in our company?
Approach
- Open with the requirements candidates describe: core languages, DSA, the full software lifecycle and clear communication of designs. Pick the two where you have the strongest proof.
- For each, give a claim, one specific piece of evidence from your work, and an outcome you can defend with a number or a concrete result.
- Name one area you are still growing in, such as SAPUI5 or MBSE, and show how you have closed a comparable gap before.
- Avoid claims about the company's needs that you cannot know, and avoid arguments that you are the best; frame it as the value you would add to the work engineers there do.
- End with a bridging sentence about what you would work on first.
Follow-up
- Which of those strengths would be least useful in your first months?
- Give an example where that strength did not help.
- How do you know that is what the team needs?
Can you talk about your previous professional experiences?
Can you talk about your previous professional experiences?
Approach
- Use a present-past-future structure: your current role, two or three earlier steps chosen for relevance, and why this role is next.
- For each role give scope, stack and one result you can defend, and show growing ownership across requirements, design, implementation, testing and deployment.
- Pick one project to go deep on; every resume line is fair game, so prepare the reasons behind each technical choice.
- Explain moves and gaps factually and never criticize former employers.
- Keep it short enough to say aloud in one pass and finish by inviting a deeper dive into the project of their choice.
Follow-up
- Which of those roles taught you the most, and why?
- Which decision on that project would you reverse now?
- Walk me through the technology choice you mentioned on your latest project.
What were the business analyst habits you observed in your previous roles?
What were the business analyst habits you observed in your previous roles?
Approach
- Treat it as a question about requirements practice: elicitation, written acceptance criteria, user stories, traceability from requirement to test, stakeholder sign-off, change control and documentation. Name the two or three you actually saw.
- For each habit describe what it looked like, which problem it prevented and what you adopted yourself, for example turning Given/When/Then acceptance criteria into test cases and cutting rework.
- If you had no analyst, say who played the role, such as a product manager or tech lead, and which habits they showed.
- Link it to the lifecycle: translating abstract requirements into code, and a misunderstanding you caught early by asking before building.
- Avoid vague praise and avoid criticizing analysts or product colleagues.
Follow-up
- Which of those habits did you carry into your own work?
- Tell me about a requirement that changed late and how you handled it.
- How do you write a requirement so engineering and business read it the same way?
How do you handle work culture and team expectations?
How do you handle work culture and team expectations?
Approach
- Define team expectations concretely: code review norms, definition of done, agile ceremonies, documentation and release practice. Pick the ones you have worked within.
- Use a STAR story where your habit and the team's norm differed, or where you joined a new team: you observed, asked, confirmed the expectation explicitly, adjusted, and the outcome improved.
- Show balance: you adapt, and you also raise improvements with evidence, such as a retrospective proposal backed by data.
- Include a real piece of feedback you received and the specific change you made afterwards.
- Avoid saying you get along with everyone, and avoid stories where the team was simply wrong.
Follow-up
- What did you do when you disagreed with a team norm?
- Describe feedback that was hard to hear and what you changed.
- How do you set expectations with a new teammate when they are unclear?
- 01
What is your experience with data structure development?
- 02
What makes you think we need you in our company?
- 03
Can you talk about your previous professional experiences?
- 04
What were the business analyst habits you observed in your previous roles?
- 05
How do you handle work culture and team expectations?
- 06
Tell me about feedback you received and what you changed afterwards.
How many rounds are there and how long does it take?
Candidates report four rounds, Initial Screening, Technical Assessment, Behavioral Interview and Final Assessment, over about 3-5 weeks. Timelines can differ by team and location.
ASD Software Engineer candidate reports ↗What kinds of technical questions do candidates report?
Language proficiency, DSA principles, SAPUI5 versus OpenUI5, database management, building high-performance software, a recent-project walk-through, the Traveling Salesman Problem and a manhole-cover brain teaser. The reports do not tie each question to a round, so prepare all of them.
ASD Software Engineer candidate reports ↗Do I need to know SAPUI5, OpenUI5 or MBSE?
Candidates list SAPUI5/OpenUI5 familiarity and systems engineering experience as nice-to-have, and the topic breakdown includes MBSE. Prepare a short comparison of SAPUI5 and OpenUI5 and a plain definition of MBSE, where models rather than documents carry the requirements, structure and behavior of a system.
ASD Software Engineer candidate reports ↗Is there a take-home assignment?
No take-home is reported. Candidates describe coding challenges and technical evaluations in the Technical Assessment, and formats elsewhere in the loop that range from aptitude tests to coding rounds.
ASD Software Engineer candidate reports ↗How should I prepare for the brain teaser?
Do not memorize an answer. List criteria, such as safety, ease of handling and manufacturing, test alternatives against each, and state your conclusion. Say your reasoning aloud as you go.
PracHub Software Engineer practice ↗How should I prepare for the behavioral rounds?
Build stories from your own work: a technical decision, a late requirement change, feedback you acted on and a team norm you adapted to. Keep each focused on what you did and the outcome, and rehearse the reported questions about your experience, why the company needs you, business analyst habits and team expectations.
ASD Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01ASD Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.