Software Engineers at IBM work across hybrid cloud, enterprise automation, AI and data analytics, on platforms such as IBM Cloud, Red Hat OpenShift tooling and IBM Watson. Depending on the team, the work can be cloud-native microservices in Java or Go, tooling in C++, data automation pipelines in Python, or web frontends in React. Around that sits code review, testing, API and schema design, and debugging in staging and production.
The interview is just as broad. Candidates report an online assessment on algorithmic logic, then live interviews that assess live coding, CS fundamentals, system design concepts and the projects on your resume. Reported questions for the role include merging sorted arrays, diffing two JSON strings, Java interfaces versus abstract classes, C++ virtual dispatch, the Python GIL, Docker versus VMs, and rate limiting at an API gateway.
Prepare for that mix instead of relying only on algorithm drills. Pick one main language and learn its semantics well. Make sure you can explain how every technology on your resume works, not just that you used it. Keep a small set of behavioral stories that make clear what you did yourself.
Online Assessment
reportedCandidates describe this stage as an automated online coding assessment focused on algorithmic logic, taken on an online testing platform. Candidates in some regions report that it is combined with a short language-proficiency or CS-fundamentals screening, and some candidates report logical-reasoning sections. Treat it as if your code will be run on inputs you have not seen: get a correct version passing first, then improve it, and test degenerate inputs yourself before you submit. Candidates do not say which questions appear at this stage, so practise the coding categories in this guide: arrays, strings, hash maps, intervals and prefix sums.
What to demonstrate
- Algorithmic logic: choosing a suitable data structure and knowing the time and space cost of the code you wrote
- Correctness on degenerate inputs you test yourself: empty input, a single element and all-equal values
- Where your assessment includes them, logical-reasoning, language-proficiency or CS-fundamentals sections
How to prepare
- Solve the five reported coding prompts in the language you will use. Before running each one, write down what it should return for empty input, a single element and all duplicates.
- Drill the interval problems from the question bank as one pattern: sort by start and merge, sweep start and end events, and intersect free time across schedules.
- Practise building a prefix array in one forward pass and a suffix array in one backward pass (split-array distinct counts), and prefix sums for the range-count problems in the bank.
- Ask your recruiter whether your assessment includes reasoning, language or fundamentals sections, and practise that format instead of guessing.
Technical and Behavioral Interviews
reportedCandidates describe live interviews with senior engineers covering technical concepts and behavioral fit. Candidates report one to three of these sessions, led by senior software developers, engineering managers or technical architects, depending on team and location. Candidates report that they assess live coding, CS fundamentals, system design concepts and the projects on your resume. The resume part is where preparation helps most. Candidates report detailed questions about the architecture choices, database models and debugging approaches in the projects they list. You need to be able to explain how every technology on the page works, not just that you used it.
What to demonstrate
- Live coding with your reasoning spoken aloud, including the edge cases you check and the time and space trade-offs you make
- CS fundamentals and language semantics explained by how they work rather than by definition
- System design concepts stated as trade-offs rather than slogans
- Resume projects and behavioral fit: architecture choices, database models, debugging approaches, and a clear line around your own part of the work
How to prepare
- For each resume project, write down the main components, the data model, one decision you would reverse, and what you would change for ten times the traffic.
- Answer each reported language and CS question in this guide aloud. Then add the follow-up you would expect next (for example, what Java 8 default methods changed for interfaces) and answer that too.
- Prepare STAR stories that match the reported behavioral prompts: a hard bug you isolated, ambiguous requirements, convincing others to adopt a technical approach, and why you want this role.
- Remove any technology from your resume that you cannot explain in depth, because candidates report detailed follow-up questions on listed skills.
11 candidate reports. Individual accounts describe a particular role and hiring cycle.
IBM Software Engineer Interview Experience — An 80-Minute OA with Tree Distances and Django Debugging
IBM's OA was unproctored. Here are a few pitfalls to watch out for: Q1: Tree Pythagorean Triples The problem: Given a tree and three fixed vertices x, y, z, count the vertices whose distances to those three vertices, sorted as a ≤ b ≤ c, form a Pythagorean triple: a² + b² = c², with all three distances positive integers. My approach: Run BFS or DFS once from each of x, y, z, record the distances…
Read full experienceSoftware Engineer interview at IBM: automated rejection and silence
I completed a HackerRank online assessment under a tight timeline, but much of the rest of the process lacked human contact. I later received an automated-looking rejection notice without having heard from an actual person. In another similar timeline, I completed a HireVue-style interview with standard prompts and then waited more than a month and a half without an update. That long silence felt…
Read full experienceIBM Software Engineer interview: automation testing, then manager fit
The technical interview was direct about testing and engineering fundamentals. We discussed my automation-testing experience, C# and Python, Selenium, BDD concepts, and how those topics connected to my own projects. The final round was with a hiring manager and focused on problem-solving, communication, and fit. I had to describe challenges I had handled and place the role in the context of real…
Read full experienceIBM Software Engineer interview: coffee chat, pitch, and technical-behavioral session
I started with a more casual conversation than expected: a coffee chat about my background, resume projects, and prior work. There was no real coding pressure, just friendly questions and a sense of getting to know the role and team. The next step was more structured. I received an email with questions about my location and background, then had one 30-minute technical and behavioral session. It s…
Read full experienceIBM Software Engineer interview: campus shortlists and interrupted interview
My IBM process began with an on-campus assessment that combined multiple-choice questions and coding. Only a limited number of students were shortlisted. The technical interview took a fixed hour block and went well enough that the interviewer gave positive feedback. Afterward, HR announced names for the next stage in waves. When my name was not in the first list, I assumed I had been rejected. I…
Read full experiencePracHub editorial advice for the preparation topics above.
Submitting a coding solution that was never run against edge cases
Treat every coding answer as if it will be run on inputs you have not seen. When practising the reported coding questions, write the edge cases before you code. For merging sorted arrays, test one empty array and the case where every element of one array is smaller than the other. For the JSON diff, decide how you handle a key that exists on only one side, nested objects, arrays, and type changes such as 1 versus "1". For the split-array question, make sure both halves are non-empty. Run these cases before you submit.
Reciting definitions for language questions without explaining how they work
"An interface is a contract" does not answer the reported Java question. Explain how it works and what follows from it. An abstract class can hold state and constructors, and a class can extend only one. A class can implement many interfaces, and since Java 8 interfaces can have default methods, so the choice comes down to shared state versus a capability. For C++, explain that this is the implicit pointer to the object and that a virtual call goes through the object's vtable pointer. For Python, explain that the GIL lets only one thread run bytecode at a time in CPython, so threads help I/O-bound work but not CPU-bound work.
Listing tools on your resume that you cannot explain in depth
Candidates report detailed follow-ups on the architecture, database models and debugging behind listed projects. Go through your resume line by line. For each framework, database or cloud tool, prepare why you chose it, what went wrong with it, and how it works one level below where you used it. Remove anything you cannot defend. Separate your own work from the team's, so that when someone asks who made a decision you can answer directly.
Answering container and gateway questions with slogans instead of trade-offs
For Docker versus VMs, name the real difference. Containers share the host kernel and are isolated with namespaces and cgroups, so they start faster and cost less overhead. VMs run a full guest OS on a hypervisor, which gives a stronger isolation boundary. For rate limiting at an API gateway, name the algorithm (token bucket or sliding window), say where the counters live when many gateway instances run, and say what a limited client receives (HTTP 429 with a retry hint).
Giving a generic answer to the reported 'why IBM' question
The reported prompt connects motivation to hybrid cloud. Do not make claims about IBM's plans that you cannot back up. Read the job description and the team's public material, pick one area it names, and connect it to one of your own projects, such as a containerised service you deployed or a migration you ran. One concrete connection is worth more than a list of compliments.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Merge two sorted arrays into a single sorted array in non-decreasing o…
Merge two sorted arrays into a single sorted array in non-decreasing order using optimal space complexity.
Approach
- State the target complexity and say which constraint rules the naive version out.
- Name the brute-force solution and its complexity before improving on it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Split an integer array into two non-empty subarrays to maximize the su…
Split an integer array into two non-empty subarrays to maximize the sum of distinct integer counts across both split sections.
Approach
- State the target complexity and say which constraint rules the naive version out.
- Restate the input: its shape, its size, and what is guaranteed about it.
- Choose the data structure from the access pattern, not from familiarity.
Follow-up
- Which test case would catch an off-by-one here?
- What is the worst case, and how likely is it on real data?
Calculate the minimum number of insertions required to transform an ar…
Calculate the minimum number of insertions required to transform an arbitrary input string into a sequence of repeated string patterns.
Approach
- Name the brute-force solution and its complexity before improving on it.
- State the target complexity and say which constraint rules the naive version out.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Given two JSON-formatted strings, identify all keys that contain diffe…
Given two JSON-formatted strings, identify all keys that contain differing values.
Approach
- State the target complexity and say which constraint rules the naive version out.
- Choose the data structure from the access pattern, not from familiarity.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Explain the operational differences between `git stash` and `git rebas…
Explain the operational differences between git stash and git rebase during team development workflows.
Approach
- Reach for the cheapest primitive that closes the race, not the broadest lock.
- Say what the runtime actually does before reasoning about the code.
- Identify the window where an invariant is briefly untrue.
Follow-up
- Where could this allocate more than you expect?
- What happens if two callers reach this at the same time?
Explain the difference between an abstract class and an interface in J…
Explain the difference between an abstract class and an interface in Java, and describe when to use each in enterprise software architecture.
Approach
- Reach for the cheapest primitive that closes the race, not the broadest lock.
- Distinguish a value from a reference to it, and say which one you handed out.
- Name what is shared across threads and what owns each piece of state.
Follow-up
- Where could this allocate more than you expect?
- How would you prove the race exists rather than suspect it?
Locate a billing reconciliation gap without rescanning ninety million events
A tenant's sealed invoice total is 0.4% below the sum of its raw usage_event rows for the period. That tenant has 90 million events over 30 days in a table partitioned daily on ingested_at, and its rollups carry source_max_ingested_at, revision and sealed_at. Recomputing all 30 days from raw is correct, and you are not going to do it. Give the procedure that locates the divergent (workspace, sku, hour) cell, the cost of each probe, and the one query you run before any of it.
Approach
- Run the free query first. Sum raw quantity for the period restricted to
ingested_at <= source_max_ingested_atof the sealed rollups, and compare that against the unrestricted sum. The rollup stores the watermark precisely so this can be answered without a scan. If the whole 0.4% sits above the watermark, nothing is broken: it is late data, it becomes an adjustment line, and the investigation ends in one query. - Only if the gap survives that test do you bisect, and you bisect by dimension rather than by rows. Compare 30 per-day totals, then inside the offending day compare the 6 SKUs, then the workspaces, then the 24 hours. That is roughly 30 + 6 + W + 24 grouped probes, each an indexed range scan over one daily partition for one tenant, against O(N) per attempt for the naive re-fold.
- Quantify why naive is not merely slow but unusable mid-incident: at a generous 200,000 rows/second sequential, 90 million rows is about 7.5 minutes per attempt, you will want ten attempts, and every one competes for I/O on the same partitions live ingest is writing. The diagnostic worsens the backlog it is diagnosing.
- Before fetching each comparison, state what it would look like under each hypothesis. Two adjacent hours off by equal and opposite amounts is
occurred_atversusingested_atbucketing. A whole day offset by exactly N hours is a timezone applied at the wrong layer. A gap confined to one SKU in one workspace is an environment filter. The same(tenant_id, idempotency_key)present in twoingested_daypartitions is the dedup horizon losing a retry that crossed midnight. - Make the next bisection cheap by storing the aggregate you keep recomputing. A per-
(tenant_id, ingested_day)count and quantity checksum turns step two from thirty probes into one read, and it is the same number the reconciliation job already produces. - Whatever you find, the sealed period does not change value. The correction is an adjustment line pointing at the line it reverses, carrying its own
source_rollup_watermark, because the original invoice is the evidence of what the customer was charged.
Worked solution 35 min
- Reproduce the shape locally: generate 2 million events for one synthetic tenant over 5 days, fold them, then inject three defects, namely 0.2% of events bucketed by
ingested_at, a handful of duplicateidempotency_keyvalues whose retries cross midnight, and a block of events ingested after the seal. - Write the watermark-bounded query first and record how much of the gap it explains on its own.
- Bisect by day, then SKU, then hour, recording the probe count and the rows each probe touches.
- For each located cell, write down the predicted signature before querying it, then check whether the data matches the prediction.
- Time a full re-fold of the 2 million rows and extrapolate to 90 million.
Follow-up
- The gap is 0.4% in one direction on one day and 0.4% the other way the next day. What does that shape rule in, and what does it rule out?
- How do you distinguish a duplicate from a restatement, given
revisionandrecomputed_aton the rollup? - Ingest is still running while you investigate. What makes your two numbers comparable at all?
Decide which facts an invoice line copies instead of joining
invoice_line_item already denormalises tenant_id, which is reachable through invoice_id, and stores amount_minor even though quantity times unit_price_micros would recompute it. A reviewer asks you to normalise both away, and separately asks whether the tenant's legal name and billing address should be copied onto the invoice header. Decide each case. For every field you keep denormalised, name the read pattern or the invariant that justifies it, the anomaly the copy can develop, and the mechanism that prevents that anomaly here.
Approach
- Split the question into two kinds of copy, because they fail differently. A copy of a currently mutable fact is a cache: it drifts and needs invalidation. A copy of a fact frozen at write time is not a cache at all, it is the record of what happened, and normalising it away destroys information the source no longer holds.
- Keep tenant_id on the line. It costs 8 bytes, it leads every index on the table so no read is ever accidentally cross-tenant, and it turns a wrong join into an empty result rather than another tenant's money. Prevent the drift structurally: a unique constraint on invoice (invoice_id, tenant_id) plus a composite foreign key from the line on (invoice_id, tenant_id) makes a mismatched pair impossible, so the database enforces agreement instead of a code review.
- Keep amount_minor. Rounding must happen exactly once, at a named site, with a stated mode (half-even here). If readers recompute from quantity and unit_price_micros, every reader owns a rounding decision, and half-up and half-even diverge systematically across thousands of lines rather than cancelling out. A check constraint can bound the stored value but deliberately cannot re-derive it.
- Copy the legal name and billing address onto the invoice header, written once and never updated. The statement must show what was true when it was sealed, and the tenant record will change afterwards. This is a snapshot for the same reason
source_rollup_watermarkis stored per line: without it, nobody can reconstruct what the customer was told. - Name the read pattern that pays for all of it. Rendering, dispute response and export are per-tenant, per-period reads over thousands of lines that would otherwise join back to slowly changing dimensions that no longer hold the historical value. The write side is a once-per-period batch, so the extra columns cost nothing that matters.
- Concede the case where the reviewer is right: a mutable operational attribute such as the tenant's current plan name has no business on a line. If a report wants it, join. If a statement needs the plan as of the period, that is another snapshot and it belongs on the header with the rest.
Follow-up
- Write the composite foreign key and the unique constraint it requires on the parent. What does it cost on every line insert, and what does it do to a bulk load?
- A tenant is renamed after being invoiced. Which rows change, and what does the customer see on last quarter's PDF?
- Where does currency live, and what breaks if a tenant's billing currency changes between two periods?
Enforce a concurrent-run quota that survives simultaneous requests
A plan allows at most 20 concurrently running rows in job_run per tenant. The table holds run_id, tenant_id, workspace_id, status (queued, leased, running, succeeded, failed, timed_out, cancelled, lost), lease_token, leased_until, started_at and finished_at. Today the service runs select count(*) from job_run where tenant_id = $1 and status = 'running', compares the result to 20, then inserts. Under load a tenant exceeds the cap by exactly the number of concurrent requests. Name the anomaly, say which isolation levels do and do not prevent it, and give a version that holds, as SQL.
Approach
- Name it: write skew. Each transaction reads a predicate (the count of running rows), neither modifies what the other read, and both then insert rows that jointly violate an invariant no single row expresses. Read committed permits it. So does repeatable read, because snapshot isolation's first-updater-wins check fires only on conflicting row updates, and these are inserts touching disjoint rows.
- Enumerate the fixes with their real costs. SERIALIZABLE works: PostgreSQL's SSI tracks the predicate read and aborts one transaction with SQLSTATE 40001, which obliges the caller to retry and makes the abort rate rise with contention on a hot tenant. Folding the predicate into the write as
insert ... select ... where (select count(*) ...) < 20narrows the race to the statement's snapshot but does not close it under read committed. - Give the version that holds at read committed: serialise on a row both transactions must touch.
update tenant_concurrency set running = running + 1 where tenant_id = $1 and running < 20 returning runningupdates zero rows when the cap is reached, and zero rows is the rejection. This works because at read committed a blocked UPDATE re-evaluates its WHERE clause against the newly committed row; at repeatable read the same statement raises a serialisation error instead, so the isolation level changes the calling contract. - State the cost you just bought. That row is now a per-tenant serialisation point, so admission throughput for the tenant is bounded by one divided by the lock hold time; at a 2 ms hold that is roughly 500 admissions/second. Keep the critical section to the single UPDATE, with no network call or scheduling decision inside the transaction, and decrement in the same transaction that writes the terminal status.
- Close the leak the status enum implies: a run can end as
lost, so a crashed worker otherwise consumes a slot forever. Reconcile on a schedule againststatus = 'running' and leased_until < now(), and treat the counter as a fast path overjob_run, which stays the system of record.
Worked solution 25 min
- Seed a tenant with 19 running rows, then fire 8 concurrent sessions each running the select-then-insert, and count the resulting running rows.
- Repeat at REPEATABLE READ and confirm the count still exceeds 20.
- Repeat at SERIALIZABLE, count the 40001 aborts, and note that without a retry loop those requests fail rather than queue.
- Implement the atomic counter UPDATE, re-run the 8-way test, and confirm exactly 20 running rows with zero over-admissions.
- Kill a worker mid-run, let the lease expire, and check whether the slot comes back without intervention.
Follow-up
- Write the retry loop for the SERIALIZABLE version. What does the caller see when it keeps aborting, and what bounds the retries?
- Two regions each keep a counter. What is the effective cap, and what does admission do when the counter store is unreachable?
- The cap changes mid-flight on a plan upgrade. Do running jobs get killed, and what does the counter row look like during the change?
Compare containerization via Docker against traditional virtual machin…
Compare containerization via Docker against traditional virtual machines (VMs) regarding resource overhead, isolation, and startup times.
Approach
- Name the read and write paths separately; they rarely have the same bottleneck.
- Name the failure you are designing for, then the recovery path.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What would you drop to keep the system up under load?
- What breaks first when traffic grows ten times?
How do you implement rate limiters and API gateways within a microserv…
How do you implement rate limiters and API gateways within a microservices architecture to handle traffic spikes?
Approach
- Name the read and write paths separately; they rarely have the same bottleneck.
- Name the failure you are designing for, then the recovery path.
- Choose a partition key and say what query it makes expensive.
Follow-up
- How does this behave when that dependency is down for an hour?
- What would you drop to keep the system up under load?
Authorisation cache with a bounded revocation window
The edge gateway serves about 30k requests/second from roughly 120 pods across three regions and may add no more than 10 ms at p99. Each request presents an API key that must resolve to an authorisation context: tenant, workspace, scopes, entitlements and credential version. The control plane that owns those rows takes tens of writes/second. A revoked credential must stop authorising within a bound you state as a number. Design the cache - what is keyed, what invalidates it, how many tiers - and specify what the gateway does for the duration of a control-plane outage.
Approach
- Fix the entry shape before the topology: key on SHA-256 of the presented secret, value is the resolved context plus the principal's auth_version and a fetched_at. Cache negative lookups too, with a much shorter TTL and a bounded-size structure, because otherwise every sprayed invalid key is a control-plane round trip, and unbounded negative entries let a sprayer evict live ones.
- Compute the control-plane read load before choosing a TTL, and notice the multiplier is pods, not regions, when the cache is in-process: distinct_active_keys x pods / TTL. At 50,000 active credentials, 120 pods and a 60 s TTL that is 100,000 reads/second against a single-writer primary with read replicas, which is not serviceable - so the design needs two tiers, a per-region shared cache in front of the control plane with the in-process cache held to a few seconds.
- State the bound as the sum of the tiers, not as a hope: with a 10 s in-process TTL over a 60 s regional TTL, worst-case staleness absent any invalidation message is 70 s, because an in-process entry can be filled from a regional entry that was itself about to expire. Publish-subscribe invalidation on every credential and entitlement mutation makes the typical case sub-second, but it is lossy under partition, so the TTL is the only enforced bound and both tiers must subscribe.
- Make auth_version propagate through the same path: a password reset or sign-out-everywhere bumps the principal and revokes its keys with no hook of its own, so the invalidation publisher has to expand principal -> credentials and publish per key, or the cache keeps serving keys whose auth_version no longer matches.
- Decide the partition behaviour in advance and write it as two rules: on a cache hit past TTL, serve from the stale entry up to a grace ceiling (say 10 minutes); on a cache miss, refuse, because authorising something never seen converts a control-plane outage into an authorisation bypass. Worst-case revoked-key lifetime during an outage is then TTL + grace, about 11 minutes, and that number is the price of not turning a control-plane outage into a total data-plane outage.
- Protect the refill path: per-key single-flight so a mass invalidation or a cold pod does not stampede the control plane, TTL jitter so entries created together do not expire together, and a small separately replicated deny-list for compromised keys that is consulted on the hot path and survives control-plane loss.
Worked solution 35 min
- Write the cache entry shape - key, value fields, and which of those fields a request actually reads on the hot path - and mark which field makes a password reset propagate.
- Compute control-plane reads/second for TTLs of 10 s, 60 s and 300 s using distinct_keys x cache_instances / TTL, once with cache_instances = 3 regions and once with cache_instances = 120 pods, and note which of the two the in-process design actually implies.
- Enumerate the four states a revocation can be in - published and received, published and dropped, control plane unreachable, pod started after the publish - and write which entry serves the next request in each.
- Write the outage policy as two rules (hit past TTL within grace: serve; miss: refuse) and compute worst-case revoked-key lifetime as the sum of both tier TTLs plus the grace.
Follow-up
- A key is found in a public repository and must stop working in seconds, not minutes. What changes, and what does it cost on the request path?
- One region is partitioned from the control plane while the control plane itself is healthy. What do that region's pods do, and how do you distinguish this from a control-plane outage?
- How would you measure the actual revocation bound in production rather than asserting it from the configuration?
Regional error rate explodes after a dependency merely slows
A control-plane read replica in one region degrades from 4 ms to 120 ms. Within ninety seconds that region's gateway error rate rises from 0.01% to 40% and its p99 becomes bimodal, one mode near the old p99 and one at the client timeout. The other two regions are unaffected. The gateway retries control-plane reads three times with exponential backoff and no jitter. Give an ordered checklist that separates trigger from amplifier, the offered-load arithmetic, and the controls that break the loop.
Approach
- Split the incident into three questions before touching a control: what started it, what amplified it, and what would make recovery slow. Here they are the replica slowdown, the retry policy interacting with queueing, and a synchronised unjittered herd at recovery. They are different mechanisms and each needs its own control.
- Read the distribution rather than the mean. A bimodal p99 with one mode pinned at the client timeout is two populations, not one degraded path; split latency by cache hit and miss and confirm the fast mode is hits and the timeout mode is misses that reached the replica.
- Do the load arithmetic. Three retries turn one client request into up to four upstream requests, so offered load reaches roughly 4x on a dependency that is already slower, and it arrives at the worst moment. With utilisation approaching one, queueing delay grows superlinearly, which is why a 30x latency increase upstream does not produce a 30x increase downstream, it produces timeouts.
- Break the loop with controls that bound offered load rather than with more attempts: a concurrency limit on the control-plane client so at most N calls are in flight and the remainder fail fast, a circuit breaker scoped per dependency and region, and a retry budget capping retries at a small fraction of base traffic so amplification has a ceiling that does not depend on how many clients are retrying.
- Add full jitter to whatever retries survive, sleeping uniformly in [0, min(cap, base x 2^attempt)], so attempts de-correlate instead of arriving in waves aligned to the moment of failure.
- Decide the unreachable-dependency behaviour in advance, because it is the actual product decision underneath: serving from an expired credential cache keeps the product available while extending a revoked key's life past the stated bound, and failing closed converts a dependency degradation into a total outage. State the mode and the staleness number rather than letting the timeout choose.
Follow-up
- The replica recovers. Describe what happens in the first ten seconds with your controls in place versus without them.
- Which single metric would have paged before the error rate moved, and why is upstream latency by itself not it?
- Requests that fail fast under the concurrency limit still need an answer. What does the gateway return, and what does it do to the usage event it would otherwise have emitted?
Day one measures instead of guessing, under a fixed rubric, and the remaining hours are allocated in proportion to the gaps before any studying begins. The allocation is deliberately not renegotiated midweek, because the area that feels worst on day three is usually the one that is moving.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Coding: arrays, merging and hash maps
- Solve the reported merge-two-sorted-arrays prompt twice: once into a new array, and once in place from the back when the first array has spare room. State the extra space each version uses.
- Solve the reported split-array question with a prefix array of distinct counts and a suffix array of distinct counts, then take the best split where both halves are non-empty.
- Solve the reported JSON diff by parsing both strings and walking the keys recursively. Before coding, write down your rule for keys that exist on only one side, nested objects, arrays and type mismatches.
- Work the reported server-log problem: pin down the removal rule (minimum value and adjacent requests) on a small example by hand before coding, then return the accumulated response time.
- For each solution, predict the output for empty input, a single element and all duplicates, then run it and compare.
Deliverable: Four passing solutions, each with its edge-case table and stated time and space complexity.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Coding: intervals, strings and prefix sums
- Work through the interval problems in the bank as one pattern: merge meeting timings, maximum concurrent processes with a sweep line, minimum meeting rooms, and shared free time.
- Work the string problems: the reported minimum-insertions-to-a-repeated-pattern question, breaking adjacent duplicate characters, and the minimum subarray with k distinct integers using a sliding window.
- Do the prefix-sum range query on vowel strings and the fourth-least-significant-bit warm-up, (n >> 3) & 1.
- Finish with an unseen set under a timer, and submit only after your own edge-case check.
Deliverable: A one-page pattern sheet (sort and merge, sweep line, sliding window, prefix sum) with one solved example for each.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Language semantics and CS fundamentals
- Answer these aloud: abstract class versus interface in Java, including what default methods changed; `this` and virtual dispatch in C++; the Python GIL and what the `with` statement guarantees.
- Explain value versus reference types, and call by value versus call by reference, with a short code example in your main language.
- Review the other fundamentals: process versus thread, locks and thread safety, stack versus heap, garbage collection, and the four OOP pillars.
- Explain `git stash` versus `git rebase`, including why rebasing a branch other people have pulled causes trouble.
Deliverable: A fundamentals sheet with an explanation of how each thing works and one likely follow-up for each reported question.
Practice prompt ↗Practice prompt ↗04Web services, databases and SQL
- Explain why authentication must not use GET: credentials end up in URLs, server logs, browser history and caches. Then say what to use instead.
- Review primary keys, foreign keys, indexing and normal forms, and describe how the parts of MVC interact in a cloud service.
- Write a bank-style SQL query that counts tickets per product with a LEFT JOIN. Put the period and tier filters in the ON clause so products with zero tickets still appear, and explain why the same filter in WHERE drops them.
- Work the SQL drills: the denormalisation choices on an invoice line, then the concurrent-run quota worked exercise. Reproduce the write skew before you fix it.
- Work the billing-reconciliation worked exercise: run the watermark-bounded query first, then bisect by day, SKU and hour, predicting each probe's result before you run it.
Deliverable: Two SQL queries you can explain line by line, the quota fix with the failure case it prevents, and the reconciliation probe log.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Architecture and design questions
- Compare Docker containers with VMs on overhead, isolation and startup, and name the difference kernel sharing makes.
- Design rate limiting at an API gateway: pick the algorithm, say where counters live across instances, and say what a limited client receives.
- Take the URL shortener design from the bank through requirements, data model and scaling, treating the read path and the write path separately.
- Work the authorisation-cache design exercise and the retry-storm debugging drill, and practise stating a numeric bound and the trade-off behind it.
Deliverable: Two designs, each with a stated bottleneck and one trade-off you can defend.
Practice prompt ↗Practice prompt ↗06Resume deep-dive and behavioral stories
- For each resume project, write down the architecture, the data model, your part versus the team's, one bug you debugged, and what you would change for ten times the traffic.
- For every technology you list, prepare why you chose it and how it works one level down, or remove it.
- Write STAR stories for the hardest bug, ambiguous requirements, convincing others and an open-source contribution, and prepare spoken answers to why IBM and how you would use generative AI at work.
- Work the two behavioral drills aloud: estimating an index migration you have never run (a range plus the measurement that narrows it), and resolving the review disagreement over the quota check (demonstrate the race, then offer fixes with their costs).
- Tell each story aloud and rewrite any plural phrasing that hides what you did yourself.
Deliverable: A short brief for each resume project, four STAR stories each ending in a stated result, spoken answers to the why-IBM and generative-AI prompts, and spoken answers to both behavioral drills.
Practice prompt ↗Practice prompt ↗07Mock both stages
- Sit an assessment-style set of two unseen array or interval problems alone with no hints, then write extra edge cases afterwards and grade yourself against them.
- Run a live mock with a partner: one coding problem while thinking aloud, two fundamentals questions, a resume deep-dive, and one behavioral story.
- Ask the partner to interrupt with follow-ups on the technologies on your resume. Note every one you could not answer and fix it.
- Prepare questions for your interviewers about team development practices, the stack, and the deployment workflow.
Deliverable: A list of the gaps the mock exposed with a fix for each, plus your questions for the interviewers.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report behavioral questions on a hard bug or system failure, ambiguous or changing requirements, convincing teammates or stakeholders, and why you want the role. The question bank adds two more: how you would use generative AI at work, and your open-source contribution experience. Use STAR structure for the story-based prompts. Prepare one story per theme, say which part you personally did, and end each with a result you can state as fact. Candidates report detailed follow-up questions on the skills they list, so know the technical detail behind every story.
Why do you want to work as a Software Engineer at IBM, and how does yo…
Why do you want to work as a Software Engineer at IBM, and how does your technical background align with our hybrid cloud strategy?
Approach
- State the situation in two sentences and spend the rest on the reasoning.
- Pick a story where you made the decision, not one where you watched it.
- Give the blast radius: what could have broken, and what you measured.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Estimate a tenant-leading index migration you have never run
Someone needs a date. usage_event carries an index on (occurred_at) and needs (tenant_id, occurred_at); the largest tenant holds roughly a hundred times the median tenant's rows, the table is partitioned daily with years of retention, and you have never run a migration on a table this large. Give an estimate you would defend: how you decompose the work, the two or three numbers you would go and measure first, the range and confidence you state, and what you commit to when the person asking needs a single date today.
Approach
- Refuse the bare number and then give one anyway, in the form that is actually useful: a range plus the measurement that collapses it. 'Four to eleven days; one afternoon building this index on a restored copy of the largest partition takes that to within a day' is an answer, while 'it depends' is not.
- Decompose by failure mode rather than into equal chunks, because that is where estimates go wrong. On a partitioned parent you create the index ON ONLY the parent, build each partition's index with CREATE INDEX CONCURRENTLY, then ALTER INDEX ... ATTACH PARTITION, at which point the parent index becomes valid. CONCURRENTLY does not block writes but scans each partition twice, waits out older transactions, cannot run inside a transaction block, and on failure leaves an invalid index you must drop concurrently and retry.
- Name the two unknowns that dominate and price them: build time on one restored partition of realistic size, and whether the planner actually chooses the new index for the skewed tenant, since selectivity for a tenant holding most of the rows is a different question from selectivity for the median tenant. Both are half-day measurements against a replica, and both are cheaper than being wrong by a week.
- State the assumptions the range is conditional on, because that is what makes a slip a re-estimate instead of a credibility event: no partition above a stated row count, one concurrent build at a time so it does not compete with ingest for I/O, and an ingest backlog that can absorb the added write amplification while both indexes exist.
- Budget the step nobody budgets: verification and the old index's removal. Dropping the old index is fast, but deciding it is safe to drop means confirming no plan still uses it, and that confirmation waits on real traffic across a full weekly cycle rather than on your patience.
- Answer the single-date request honestly. Commit to a date for the first checkpoint — the measured build number from the replica — and to re-estimating on that date, and say plainly what you are not committing to yet. A date with a scheduled re-estimate is worth more to the asker than a confident wrong one, and you should say why in those words.
Follow-up
- The concurrent build fails half way through the largest partition. What is the state of the database and what do you do next?
- Your estimate slips by sixty percent. Which assumption broke, and at what point would you have known?
- The person asking needs the date for a customer commitment. Does your answer change?
Resolve a review disagreement over a quota check
A colleague's pull request enforces a per-tenant quota by selecting the current count and then inserting when it is under the limit. You flag it as a race. They reply that the transaction already runs at repeatable read, so the snapshot makes it safe, and the tests pass. Walk through taking that disagreement to a resolution: what you write in the review, what you demonstrate rather than assert, which fix you propose and why, and what you do if they still disagree after all of it.
Approach
- Answer the claim precisely instead of restating your objection, because they have made a specific technical argument. In PostgreSQL, repeatable read is snapshot isolation; this is write skew, which snapshot isolation permits by design. Both transactions read a count that is stable within their own snapshot, insert disjoint rows that the other cannot see, and both commit, so the limit is exceeded by exactly the concurrency.
- Demonstrate rather than cite. Two psql sessions, both BEGIN ISOLATION LEVEL REPEATABLE READ, both select the count, both insert, both commit: it succeeds. Repeat at SERIALIZABLE and the second commit fails with serialization_failure, SQLSTATE 40001. That takes two minutes, ends the argument without anyone conceding a position, and leaves an artefact for the next reviewer.
- Offer the options with their costs rather than a verdict. Serialisable plus a retry loop on 40001 is correct but obliges every caller to retry and degrades under contention. An increment-and-compare on a counter row — update tenant_quota set used = used + 1 where tenant_id = $1 and used < limit returning used — is safe even at read committed, because a blocked updater re-evaluates the WHERE clause against the row version it finally locks, and zero rows returned means full. A unique or exclusion constraint that makes the surplus write fail is the third.
- Name the plausible non-fix explicitly, since it is what usually gets merged instead: folding the count into the insert as insert ... select ... where (select count(*) ...) < limit is still racy under read committed, because the subquery cannot see the other transaction's uncommitted rows. It looks atomic and is not.
- Say what you do if they still disagree: escalate the decision rather than the disagreement. Attach the reproduction, hand it to the service owner or a third reviewer, and state that you will not block the merge if the owner accepts the risk knowingly — and that you want that acceptance written down.
- Close with the general lesson worth leaving in the review thread: a passing suite is weak evidence for a concurrency claim because it runs one request at a time. Ask for a test that runs two.
Follow-up
- Write the counter-row version. Does your answer change if the quota counts child rows rather than a column?
- Under serialisable, who performs the retry, and what does the API client see if the retry also fails?
- This is the third disagreement with the same reviewer this month. What changes in how you review?
- 01
Walk through the most technically challenging bug or system failure you encountered in a previous project, and detail how you isolated and resolved it.
- 02
Describe a situation where project requirements were ambiguous or changing rapidly. How did you structure your work to deliver results?
- 03
Tell me about a time you had to convince team members or stakeholders to adopt a specific technical approach or tool.
- 04
Why do you want to work as a Software Engineer at IBM, and how does your technical background align with IBM's hybrid cloud strategy?
- 05
How would you use generative AI at work?
- 06
Describe your open-source contribution experience.
Is this an official IBM interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at IBM. Rounds and questions reflect what candidates have reported, not a process IBM has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What does the IBM Software Engineer interview process look like?
Candidates report two stages: an automated online coding assessment on algorithmic logic, sometimes with reasoning, language-proficiency or fundamentals sections, then live technical and behavioral interviews with engineers. Candidates report one to three live sessions and about 2 to 4 weeks overall. Candidates report that the format varies by team, location, and whether you are a campus or experienced hire, so confirm yours with your recruiter.
PracHub Software Engineer practice ↗What topics come up in the technical questions?
The reported questions fall into four groups. The first is data structures and algorithms, mostly arrays, strings and hash maps. The second is language semantics and CS fundamentals: Java, C++ and Python internals, OOP, threads and memory. The third is web services and databases: HTTP methods, MVC, keys and indexing, containers and rate limiting. The fourth is your resume projects and behavioral stories.
PracHub Software Engineer practice ↗Are whiteboarding and live coding required in all rounds?
Not always. Candidates describe the assessment stage as coding-based. Candidates report that how much live coding the interviews include depends on team and location. Candidates describe a blend of resume deep-dives, spoken explanations, code walkthroughs and live coding, so prepare for all four.
PracHub interview research ↗Which programming language should I use?
Pick one of Java, C++, Python or JavaScript and know its standard library, memory model and idioms well. Reported questions cover Java interfaces, C++ virtual dispatch and the Python GIL, so expect detailed questions on whichever language you list as your strongest.
PracHub Software Engineer practice ↗How should I prepare for the resume deep-dive?
For every project, be ready to sketch the components, API structure and data flow, explain why you chose each tool, describe a bug you debugged, and say what you would change at ten times the traffic. Remove any technology you cannot explain in depth, because candidates report detailed follow-up questions on listed skills.
PracHub Software Engineer practice ↗Is SQL tested?
The question bank includes a SQL count query using LEFT JOIN with filtered join conditions and a database normal forms question, and there is a reported question on primary keys, foreign keys and indexing. Practise the difference between filtering in ON and in WHERE on a LEFT JOIN. A WHERE filter on the right-hand table removes the unmatched rows, which quietly turns the query into an inner join.
PracHub Software Engineer practice ↗How do the practice drills relate to the reported questions?
The reported questions are what candidates say they were asked. The drills are original practice for the same skills: concurrency-safe SQL, reconciliation, cache design, debugging, and behavioral judgement. Three of them have worked solutions (the concurrent-run quota, the billing reconciliation and the authorisation cache). The 7-day plan schedules the SQL drills and the reconciliation on day 4, the design and debugging drills on day 5, and the two behavioral drills on day 6.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
BairesDev Software Engineer Interview Questions & Guide 2026
Design practice for BairesDev software engineer prep that pushes past topology: turn a loose requirement into a schema and an API contract, then work out the read and write paths it implies.
Splunk Software Engineer Interview Questions & Guide 2026
Design practice for Splunk software engineer prep that pushes past topology: turn a loose requirement into a schema and an API contract, then work out the read and write paths it implies.
Cisco Software Engineer Interview Guide
Operational practice for Cisco software engineer candidates: picking the signal that catches a bad release early, and telling a latency regression apart from a shift in traffic mix.
Adobe Software Engineer Interview Guide
Database practice for Adobe candidates: how an index changes a query plan, and which anomalies survive a given isolation level, since read committed still permits non-repeatable reads.