cswork / libraryOpen practice workspace

Interview guides · IDC (International Data Corporation)

IDC (International Data Corporation) Software Engineer Interview Guide

IDC (International Data Corporation) Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at IDC (International Data Corporation), you serve as a key architect in the technical infrastructure that supports the world’s leading provider of market intelligence and advisory services. Your work directly impacts how data is processed, analyzed, and delivered to clients, turning complex market trends into actionable insights. You are not just writing code; you are building the digital backbone that enables IDC (International Data Corporation) to maintain its position as a global authority in the technology and telecommunications sectors. This role requires a balance of technical precision and practical problem-solving. You will often engage with legacy systems while simultaneously contributing to modern development initiatives.

This guide is scoped to a Software Engineer candidate at IDC (International Data Corporation).

Focus areas

  • Java
  • Swing (Java GUI)
  • EJB (Enterprise JavaBeans)

The IDC (International Data Corporation) interview process

IDC (International Data Corporation) candidates report 4 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Technical Screening

Initial assessments focusing on foundational technical knowledge.

What to demonstrate

  • Initial assessments focusing on foundational technical knowledge
  • Depth in Java

How to prepare

  • Answer aloud and timed: What are the primary differences between Stateless and Stateful session beans in an EJB environment?
  • Answer aloud and timed: How do you approach database table partitioning to optimize performance?

Face-to-Face Assessment

In-person evaluations that emphasize problem-solving skills and real-world applications.

What to demonstrate

  • In-person evaluations that emphasize problem-solving skills and real-world applications
  • Depth in Java

How to prepare

  • Answer aloud and timed: Can you explain the lifecycle and usage of top-level containers in Java Swing or similar UI frameworks?
  • Answer aloud and timed: How do you handle transaction attributes like 'Required' or 'Requires New' in a distributed system?

Coding Tasks

Candidates may be asked to perform coding tasks on-site.

What to demonstrate

  • Candidates may be asked to perform coding tasks on-site
  • Depth in Java

How to prepare

  • Answer aloud and timed: How would you implement a dynamic UI component (such as a tree-to-table data population) that responds to user selection?
  • Answer aloud and timed: Given a specific client requirement, how do you structure your code to allow for future enhancements without a complete refactor?

Complex Architecture Discussion

Discussion of complex architecture scenarios reflecting actual project requirements.

What to demonstrate

  • Discussion of complex architecture scenarios reflecting actual project requirements
  • Depth in Java

How to prepare

  • Answer aloud and timed: How do you approach the challenge of optimizing memory usage when handling large object counts?
  • Work Java until you can explain it without notes

Where candidates lose points

Own your resume

Every technology you list is fair game for deep-dive questioning. If you haven't used a tool in years, be prepared to explain your past experience with it honestly.

Practice live coding

Be ready to code on a whiteboard or laptop while explaining your logic. The ability to "think out loud" is a major indicator of a strong hire.

Clarify requirements

When given a scenario, ask clarifying questions before jumping into the code. This mimics real-world development and shows you are thorough.

Questions & practice

How would you implement a dynamic UI component (such as a tree-to-table data population) that responds to user

Medium · Real-Time Scenario & Problem Solving

How would you implement a dynamic UI component (such as a tree-to-table data population) that responds to user selection?

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Given a specific client requirement, how do you structure your code to allow for future enhancements without a

Medium · Real-Time Scenario & Problem Solving

Given a specific client requirement, how do you structure your code to allow for future enhancements without a complete refactor?

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

How do you approach the challenge of optimizing memory usage when handling large object counts?

Medium · Real-Time Scenario & Problem Solving

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

  1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
  2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
  3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
  4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

  • The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
  • How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

  1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
  2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
  3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
  4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

  • Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
  • Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

What are the primary differences between Stateless and Stateful session beans in an EJB environment?

Medium · Technical Core & Domain Knowledge

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

How do you approach database table partitioning to optimize performance?

Medium · Technical Core & Domain Knowledge

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Can you explain the lifecycle and usage of top-level containers in Java Swing or similar UI frameworks?

Medium · Technical Core & Domain Knowledge

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Listing latency scales with page size, not with filters

Easy · n+1 · latency · query batching

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

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

Suggested practice checklist

Built from the rounds and topics IDC (International Data Corporation) candidates report.

Day 1 — Map the IDC (International Data Corporation) loop

  • Write out the reported sequence: Technical Screening, Face-to-Face Assessment, Coding Tasks, Complex Architecture Discussion.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 4 reported rounds, with the weakest marked.

Day 2 — Work Java

  • Spend the session on Java, which IDC (International Data Corporation) candidates report being tested on.
  • Write one worked example in Java and time yourself on it.

Deliverable: One timed worked example in Java.

Day 3 — Work Swing (Java GUI)

  • Spend the session on Swing (Java GUI), which IDC (International Data Corporation) candidates report being tested on.
  • Write one worked example in Swing (Java GUI) and time yourself on it.

Deliverable: One timed worked example in Swing (Java GUI).

Day 4 — Work EJB (Enterprise JavaBeans)

  • Spend the session on EJB (Enterprise JavaBeans), which IDC (International Data Corporation) candidates report being tested on.
  • Write one worked example in EJB (Enterprise JavaBeans) and time yourself on it.

Deliverable: One timed worked example in EJB (Enterprise JavaBeans).

Day 5 — Answer out loud: Technical Core & Domain Knowledge

  • Answer aloud, timed: What are the primary differences between Stateless and Stateful session beans in an EJB environment?
  • Answer aloud, timed: How do you approach database table partitioning to optimize performance?

Deliverable: Spoken answers to 2 reported Technical Core & Domain Knowledge question(s), under time.

Day 6 — Answer out loud: Real-Time Scenario & Problem Solving

  • Answer aloud, timed: How would you implement a dynamic UI component (such as a tree-to-table data population) that responds to user selection?
  • Answer aloud, timed: Given a specific client requirement, how do you structure your code to allow for future enhancements without a complete refactor?

Deliverable: Spoken answers to 2 reported Real-Time Scenario & Problem Solving question(s), under time.

Day 7 — Dry run for IDC (International Data Corporation)

  • Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

How do you handle transaction attributes like 'Required' or 'Requires New' in a distributed system?

Medium · Technical Core & Domain Knowledge

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

  1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
  2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
  3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
  4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

  • What in that decision was irreversible, and did you know it was irreversible when you made it?
  • How did you tell the people who had already built on top of the original decision?

Argue against a design, lose, and commit anyway

Medium · disagreement · service boundaries · decision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach

  1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
  2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
  3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
  4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.

Follow-up

  • What threshold on that alert would have proved you right, and did anyone ever look at it?
  • If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?