Ajna Infotech Software Engineer Interview Guide

The 60-second brief

The reported role is a Lead STIBO MDM Developer position inside the Software Engineer track. Candidates describe work on Master Data Management (MDM) solutions built on the STIBO Systems (STEP) platform: data models with hierarchies, attributes and references, workflows, business rules written in JavaScript and Java, and integrations that keep product data synchronized between upstream and downstream systems. Reported day-to-day duties run from gathering requirements with business stakeholders through deploying and monitoring configuration in production, building Web UI screens for data stewards, working with DevOps and cloud teams on CI/CD, and running projects such as moving legacy product data into STEP or building real-time API integrations for e-commerce storefronts. Candidates do not describe Ajna Infotech's own products beyond this role, so the guide stays on the platform and the work.

This guide is for experienced engineers interviewing for the lead-level STIBO MDM Software Engineer role at Ajna Infotech. Candidates describe the requirements as 5+ years of software engineering with 3+ years on STIBO MDM implementations, plus Java, JavaScript, and REST and SOAP integration work. It covers the three reported rounds, STEP modelling and business-rule questions, integration and architecture design, and the leadership stories, with a plan that adds practice on the engineering skills underneath them. It is not a general algorithm-puzzle guide.

Candidates report three rounds over about 3-5 weeks: a Recruiter Phone Screen, a Technical Evaluation on Java, JavaScript and STIBO STEP fundamentals, and an Onsite Interview Loop (onsite or virtual) with system design, behavioral and collaboration sessions.

Focus areas

• Master Data Management (MDM)
• STIBO MDM
• MDM Data Modeling

Overview

The work is master data: one trusted record per product, enforced by a platform data model, validated and routed by business rules, and exchanged with other systems through APIs and message flows. The topics candidates see attached to this loop are Master Data Management, STIBO MDM, MDM data modeling, data quality management and entity resolution or deduplication. In practice that means being able to explain how you shape a hierarchy, where an attribute lives, how a rule validates or routes a record, how duplicates are matched and merged, and what happens to downstream consumers when any of that changes.

The 15 reported questions fall into three groups. The STEP-focused group covers configuring a new product hierarchy, tuning JavaScript business rules during bulk imports, reference types versus link types, customizing the STEP Web UI, and versioning with data inheritance in complex product models. The integration group covers syncing real-time pricing from an ERP through STIBO to an e-commerce platform, REST versus an event-driven message queue for syndication, malformed XML in an inbound feed, securing outbound API endpoints, and monitoring failures between STIBO and legacy systems. The leadership group covers a technical migration, an infeasible stakeholder request, mentoring, a production bug, and balancing delivery speed against code quality.

Candidates report that the technical round centres on your own earlier STEP work and the reasons behind its design. The preparation advice candidates receive adds that you may be asked to write or review short Java or JavaScript snippets for business rules, data transformations and API calls, rather than abstract algorithm puzzles. So prepare three or four projects you can narrate in detail: the data model, one rule you wrote or tuned, one integration and one thing that failed. Practise the small code tasks too: flatten a nested XML payload, validate and route a record, make a per-record rule safe for bulk loads. If you have not touched a STEP module, say so and describe the nearest problem you solved, as candidates are advised to do.

For design questions, start by pinning down data volume, read and write ratio, latency tolerance, which system owns each field and what must happen when a consumer is offline; candidates report these prompts are deliberately vague.

The Ajna Infotech interview process

Candidates report three rounds over about 3-5 weeks, and say some final sessions may be held on the same day. The stages below are what candidates describe, not a published schedule.

Recruiter Phone Screen

Candidates describe a first call that covers your background, where you want to work (reports name a Houston, TX office) and whether your technical profile broadly fits the role. Expect the call to touch on your background and technical fit, so be ready to show lead-level STEP experience: have a short career narrative that names your years on STIBO implementations, the languages you write rules in, and the one project you would lead with.

What to demonstrate

• Background fit for a lead STIBO MDM role
• Location preferences against a Houston, TX based position
• High-level technical fit across STEP, Java, JavaScript and integrations

How to prepare

• Write a spoken summary of your career that puts STEP implementations, Java and JavaScript business rules, and REST or SOAP integrations in the first few sentences.
• Choose the single project you will lead with and be able to state its data model, its volume and your personal role in one breath.
• Settle your answer on a hybrid schedule with regular in-office presence in Houston, and your own constraints, before the call.
• Ask what the technical evaluation will contain, including whether you should expect to write or review code.

Technical Evaluation

Candidates describe a technical round centred on Java, JavaScript and STEP basics, in which you are asked to take the interviewer through earlier STEP projects and defend why you designed them the way you did. The preparation advice candidates receive also says to be ready to write or review short Java or JavaScript snippets tied to business rules, data transformations or API integrations. Practise the STEP-fundamentals question types (hierarchy configuration, reference versus link types, Web UI customization, inheritance and versioning, rule performance, workflow states and transitions) out loud, and keep the code short and correct.

What to demonstrate

• Hands-on knowledge of Java, JavaScript and STEP fundamentals
• Ability to explain the how and the why of past implementations
• Working code for business rules, transformations or API calls, where the format includes it

How to prepare

• Prepare a walkthrough for each of three past implementations: model structure, key rules, integrations, what you would change.
• Answer the STEP-fundamentals questions aloud, in particular hierarchy setup, reference versus link types and versioning with inheritance.
• Write from memory a rule that validates an attribute and routes the record, rewrite it to be safe for a bulk import, and write a function that flattens a nested XML or JSON payload into rows, handling missing and repeated elements.
• Sketch a product-onboarding workflow in STEP: its states, the transitions between them, the business actions and conditions on each transition, escalation and timeouts for stalled tasks, and the error path for records that fail validation.

Onsite Interview Loop

Candidates describe an onsite or virtual loop with system design and architecture, behavioral and leadership, and cross-functional collaboration sessions, some of which may fall on the same day. The integration questions (ERP pricing to storefront, REST versus queue, malformed XML, outbound security, monitoring) are the design practice for this stage, and the leadership questions are the behavioral practice. Open each design by asking about volume, ownership and failure behavior, and tie each decision to the business outcome.

What to demonstrate

• System design and architecture for MDM integrations
• Behavioral and leadership examples at a lead level
• Collaboration with product managers, data stewards and other engineering teams

How to prepare

• Rehearse the ERP-to-STIBO-to-storefront design with a diagram that shows the source of truth, the transport, retries and the failure path, plus a clarifying-questions list: volume, read and write ratio, latency target, field ownership, consumer outage behavior.
• Prepare a matching and merge design for duplicate product records: match algorithm and match codes, the score for auto-merge versus the band sent to steward review, survivorship rules for the golden record, and how a merge reaches downstream consumers and the references that point at the losing record.
• Write five STAR stories covering a migration, an infeasible request, mentoring, a production bug and a speed-versus-quality trade-off, each with your personal action separated from the team's.
• Prepare how you would explain a data-quality or merge rule to a product manager and to a data steward in different terms.

Where candidates lose points

Starting the ERP pricing-to-storefront design by drawing boxes before asking anything

Open with volume, latency tolerance, which system owns price, and what must happen when the storefront or STEP is offline. Candidates report design prompts are deliberately vague, so the questions are part of the answer.

Answering REST versus an event-driven message queue as a matter of taste

Compare them on coupling, delivery guarantees, retries, ordering, back-pressure and consumer outages, then say where each fits. Real-time price pushes and bulk syndication may justify different choices in the same design.

Saying a slow JavaScript business rule needs optimizing without a diagnosis

Describe the sequence: measure which rule fires and how often during the import, find per-record lookups or repeated work, batch or cache them, narrow when the rule triggers, and re-measure on a bulk load.

Describing past STEP work as what the team did, so your own contribution is unclear

For each project prepare one line starting with I: the model you designed, the rule you wrote, the integration you led. Candidates are told to separate team from individual contribution in the action part of STAR.

Behavioral stories with no failure, or no moment where you led

The migration prompt asks what went wrong, so choose a story with a real defect, how you detected it and what changed afterwards. Show a decision that was yours, not one you watched.

Questions & practice

Explain the difference between reference types and link types in STIBO data modeling.

Medium · STIBO MDM & Technical Domain

Approach

1. Start with what each one connects. A reference is a typed, one-directional relationship from one object to another (a product to its accessory, its replacement or an image asset), configured with valid source and target object types. A classification link puts a product into a node of a classification hierarchy, which is how the product is grouped outside its primary product hierarchy.
2. Explain what each can carry. A reference can hold its own metadata attributes, such as a quantity or sort order, that describe that particular relationship and belong to neither object. A classification link mostly records membership. The classification node defines the group and, depending on the setup, which attributes apply to its members.
3. Give the modelling rule. Use a reference when the relationship itself has meaning or data (cross-sell, bill of materials, spare part). Use a classification link when the question is which group a product belongs to, especially when the product has to appear in several alternative taxonomies.
4. Cover cardinality and downstream effects. Decide whether a reference type allows one target or many, and how deleting or replacing a target is handled. Outbound mappings have to export each type explicitly, so consumers do not see a new type until the export is configured.
5. Mention that terminology varies. STEP versions name and group these types differently in system setup, so base your answer on the version you used and on a concrete example from a model you built.

Follow-up

• Where would you store the fact that an accessory is sold in packs of six?
• How would you migrate a relationship stored as an attribute holding an ID into a proper reference?
• What happens to references that point at a product later deleted or merged as a duplicate?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

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

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

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

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?

Walk me through the steps to configure a new product hierarchy in STIBO STEP.

Medium · STIBO MDM & Technical Domain

Approach

1. Start from the business structure, not the tool. Agree the levels (for example category, family, product, SKU), which level owns which attributes, and whether a product sits under one parent or several. In STEP each level becomes an object type, with valid parent-child object types set so that, for example, a SKU cannot be created directly under a category.
2. Define attributes and attribute groups next. Make each attribute valid only for the object types that use it, attach LOVs and units where values are constrained, and decide which level maintains each value and whether children inherit or override it. Choose ID conventions early, because object IDs are hard to change once other data references them.
3. Keep the primary product hierarchy apart from alternative groupings. Put the web taxonomy or regulatory classes in classification hierarchies linked to products, so reorganising the catalogue does not mean moving thousands of products to new parents.
4. Connect the operational pieces: business conditions for mandatory data at each level, the import configuration that maps source columns to the new object types, Web UI screens and privileges for the stewards who maintain the hierarchy, and the outbound mapping so downstream systems receive the new structure.
5. Test it with a sample load in a lower environment, including edge cases: a product moved between nodes, a node deleted while it still has children, and a value overridden at a lower level. Then promote the configuration through the environments instead of rebuilding it by hand in production.

Follow-up

• The business merges two categories that already hold live products. How do you restructure the hierarchy?
• Where would you put an attribute that is mandatory for one region's products and irrelevant everywhere else?
• How do downstream systems find out that a product moved to a different parent?

How do you optimize JavaScript business rules that are causing performance issues during bulk data imports?

Medium · STIBO MDM & Technical Domain

Approach

1. Measure before changing anything. Time a representative import with the rules on and then off, and log execution time and call counts per rule. That tells you whether the cost comes from one slow rule, a rule firing more often than it needs to, or rules setting off each other through their writes.
2. Reduce the work done per object. A rule that walks every child of a large node, or fetches the same reference object again for each imported item, makes the import O(N*M). Fetch each object once, keep it in a local map keyed by ID for the rest of that call, and return early when none of the attributes the rule depends on changed.
3. Put the cheapest condition checks first so most objects exit before any expensive lookup. Skip writes that would set a value it already holds, since each write can trigger more validation or event processing.
4. Take work that does not have to happen synchronously out of the import path. Run heavy derivations afterwards as a separate bulk or background step, and keep only the validations that must stop bad data inside the import. If the logic really is heavy, consider a Java extension instead of JavaScript and explain what that costs in deployment and maintenance.
5. Check the result at production volume. Compare timings before and after, and compare outputs on a sample to show the rule still produces the same results. Keep a regression import in the test environment so the slowdown cannot come back unnoticed.

Follow-up

• How would you find which of twenty rules causes the slowdown without switching them off one at a time in production?
• What can go wrong if you move a validation to after the import finishes?
• How do you stop a rule that writes a value from triggering itself again?

Can you describe how you have customized the STEP Web UI to improve user workflows?

Medium · STIBO MDM & Technical Domain

Approach

1. Build the answer around one steward task and how it changed. Say who did the task, how many screens and clicks it took, where the errors came from, and what you measured afterwards (task time, rejected records, rework).
2. Name the specific Web UI pieces you changed. Examples: a task list for each workflow state so stewards see only the items waiting for them, node detail screens with attribute groups laid out as tabs in the order of the task, LOV dropdowns instead of free text, and a table or bulk-edit view for changes that apply to many products.
3. Show how you moved validation earlier. Business conditions shown on the screen flag missing mandatory values before submit, instead of the record bouncing back from the workflow later. Custom actions (buttons that run business actions) handle repetitive edits that used to take several steps.
4. Cover roles and permissions. Give each user group its own screens or visibility so a pricing steward and a content steward do not wade through each other's attributes, and show values mastered in another system as read-only.
5. Finish with maintenance. Promote screen configuration through the environments like any other configuration, keep custom components to a minimum because each one has to be retested on platform upgrades, and say how steward feedback decided your next change.

Follow-up

• How did you show that the change reduced errors instead of just moving them somewhere else?
• What did you do when two steward groups wanted conflicting layouts on the same screen?
• What broke, or nearly broke, at the next platform upgrade?

Design an integration strategy to sync real-time pricing updates from an ERP into STIBO, and then out to an e-

Medium · System Architecture & Integration

Design an integration strategy to sync real-time pricing updates from an ERP into STIBO, and then out to an e-commerce platform.

Approach

1. Ask questions before you draw anything. Is the ERP the system of record for price, with STEP only enriching and distributing it? How many price changes per hour at peak? How stale can the storefront be? Are prices future-dated? Which price lists, currencies and channels exist? Does a price need steward approval? An approval step works against real-time updates.
2. Inbound: the ERP publishes price-change events to a queue, or calls a REST inbound endpoint. Each event carries SKU, price list, currency, amount, effective date and a source version or timestamp. Use that version for idempotency and ordering: apply an update only if it is newer than the stored one, so retries and out-of-order deliveries cannot roll a price back.
3. Inside STEP, validate with cheap, deterministic business rules: the amount is not negative, the currency is known, the SKU exists, the change is within a configured percentage band. Send only the exceptions to a steward workflow so a person does not block the normal path.
4. Outbound: publish each change to the e-commerce platform through a durable queue, or through an outbound endpoint with retries, keyed by SKU so updates for one SKU stay in order. Failed messages go to a dead-letter queue and raise an alert. A periodic full reconciliation compares prices across the ERP, STEP and the storefront to catch silent drift.
5. State the trade-off. Sending high-frequency price changes through MDM adds a hop and another point of failure. The alternative sends prices from the ERP straight to the storefront and gives STEP a copy for governance. Choose based on whether MDM adds validation or enrichment the storefront needs.

Follow-up

• The storefront is down for two hours during a promotion. What happens to the queued price updates when it comes back?
• How do you handle a price change scheduled for midnight in several time zones?
• A wrong price went live. How fast can you correct it, and how do you find every channel it reached?

What are the trade-offs between using a REST API versus an event-driven message queue for downstream data synd

Medium · System Architecture & Integration

What are the trade-offs between using a REST API versus an event-driven message queue for downstream data syndication?

Approach

1. REST push from MDM to each consumer is simple, returns success or an error on every call and is easy to debug. But it ties MDM to every consumer's availability: when a consumer is down, MDM has to hold the change and retry, and N consumers mean N calls and N separate failure paths.
2. With REST pull, consumers ask MDM for changes since a cursor. The consumer sets the pace and downtime on its side causes no loss. The costs are polling load on MDM and freshness limited by the polling interval.
3. A message queue decouples MDM from its consumers. MDM publishes once, each consumer reads at its own pace, and messages persist while a consumer is offline. Kafka keeps the log for a configured retention period, so a consumer can replay from an offset. RabbitMQ deletes a message once it is acknowledged, so replay needs a separate store.
4. Queues have their own costs. Delivery is usually at-least-once, so consumers must be idempotent (deduplicate on entity ID plus version). Kafka keeps order only within a partition, so key messages by product ID. And MDM no longer knows whether a consumer applied a change unless consumers send status events back.
5. Close with a rule for choosing. Use events for many consumers, high volume or consumers that can tolerate lag. Use REST for a few consumers that need synchronous confirmation or on-demand lookups. A common hybrid publishes a small change event and lets consumers fetch the full record over REST, which keeps messages small but adds read load on MDM.

Follow-up

• A downstream system is offline for a day. How do you make sure no master data change is lost?
• Would you put the full product record in each event or only the changed fields, and why?
• How do you change the message schema without breaking an older consumer?

How would you handle a scenario where an inbound data feed contains a high percentage of malformed XML records

Medium · System Architecture & Integration

How would you handle a scenario where an inbound data feed contains a high percentage of malformed XML records?

Approach

1. First sort the failures by type, because each needs a different response. Some XML is not well-formed (bad encoding, unescaped ampersands, truncated files). Some is well-formed but fails the XSD. Some passes the schema but fails business rules. Count each type on the failing feed before you decide anything.
2. A high failure rate is a problem at the source, not with individual records. Set a batch-level threshold. Above it, reject or pause the whole feed and alert the team that owns it instead of loading a partial catalogue. Below it, load the valid records and quarantine the rest.
3. Make sure one bad record cannot sink the whole file. An XML parser cannot continue past a well-formedness error in the same document, so ask the source to send one record per message or file, or split the large document before parsing where record boundaries are reliable. Parse with StAX or SAX so memory grows with nesting depth, not with file size as a DOM does.
4. Quarantine records with context: the raw record, the error type, line and column, and the feed ID, so a steward or the source team can fix it and send it again. Make reprocessing idempotent so a resent record does not create a duplicate. Do not silently fix values, because that hides upstream defects.
5. Harden the parser. Disable DTDs and external entity resolution to block XXE, handle encoding explicitly, and alert on the trend in error rate, since a sudden jump usually means the source changed its schema version or export settings.

Follow-up

• The business wants to load whatever parses because the catalogue launches tomorrow. What do you do?
• A third of the records fail on a feed that was clean last week. How do you find the root cause?
• How do you make sure a record that is fixed and resent later does not overwrite a newer valid update?

Describe your approach to securing outbound API endpoints originating from the MDM platform.

Medium · System Architecture & Integration

Approach

1. Authenticate both ends. The MDM platform authenticates to each consumer with OAuth2 client credentials (short-lived access tokens, scopes per consumer) or with mutual TLS, and it verifies the consumer's server certificate. Reuse a token until shortly before it expires instead of requesting a new one for every call.
2. Keep secrets out of configuration files and code. Store client secrets and private keys in a vault or the platform's secured settings. Rotate them on a schedule, with an overlap period in which the consumer accepts both the old and the new credential.
3. Limit what leaves the platform. Use a separate outbound mapping per consumer that exports only the attributes that consumer needs, and keep cost, supplier and personal data out of feeds that do not need it. Payloads that carry more data than needed are a common source of leaks.
4. For webhook-style pushes, sign each payload with an HMAC over the body and a timestamp, so the receiver can check integrity and reject replays outside a time window. Require TLS 1.2 or later, and restrict outbound network access so the platform can reach only approved hosts.
5. Make it auditable. Log each outbound call with the consumer, endpoint, record IDs and result, but never the token or other secrets. Alert on spikes in authentication failures and on calls to unexpected destinations.

Follow-up

• How do you rotate a consumer's credential without interrupting the sync?
• One consumer has been compromised. What do you revoke, and what do you check again?
• A partner can only accept basic auth over HTTPS. Do you allow it, and with what compensating controls?

How do you monitor and alert on integration failures between STIBO and legacy systems?

Medium · System Architecture & Integration

Approach

1. Watch the symptoms the business would notice, not just errors: the time of the last successful exchange for each integration, the backlog size and the age of its oldest message, throughput against a normal baseline, and errors per endpoint. Alert on freshness and backlog age, because a feed that silently stops produces no errors at all.
2. Give every exchange a correlation ID and record which IDs it carried. Then one failing product can be traced from STEP's outbound endpoint logs to the legacy system's import log.
3. Classify failures. Transient ones (timeouts, a locked target) get automatic retries with backoff and alert only if they persist. Permanent ones (a validation rejection, a mapping error) go straight to an error queue and a ticket, because retrying them only adds noise.
4. Legacy targets often take files rather than API calls, so check the outcome as well as the transfer. Did the file arrive? Was it picked up? Do record counts or checksums in STEP and the legacy system match in a scheduled reconciliation?
5. Keep alerts actionable. Send each alert to an owner with a link to a runbook, group repeated failures into one incident, and review alerts that fired with no action taken so people keep trusting the thresholds.

Follow-up

• How would you detect that the legacy system accepted the data but applied it wrongly?
• What threshold would you set for backlog age, and how would you tune it?
• An alert has fired every night for a month and everyone ignores it. What do you change?

How do you balance the need to deliver features quickly with the need to maintain high code quality and archit

Medium · Leadership & Behavioral

How do you balance the need to deliver features quickly with the need to maintain high code quality and architectural integrity?

Approach

1. Give a rule for deciding, not a slogan. Separate changes that are cheap to undo (a Web UI screen, a report, a rule behind a switch) from changes that are expensive to undo (the data model, object IDs, an integration contract other systems depend on). Move fast on the first group and review the second carefully.
2. Name what you will not skip even under a deadline: code review on business rules, configuration kept in version control and promoted through a CI/CD pipeline instead of edited in production, and automated tests or regression imports for the rules that protect data quality.
3. When you take a shortcut, make it visible. Write down the debt, its risk and its owner, and agree with the product manager when it will be paid back. That makes the trade-off a shared decision instead of a cost engineering absorbs without telling anyone.
4. Use delivery methods that make speed safer. Release the smallest useful slice to one category or one consumer first, measure the effect, then widen the rollout.
5. Back it up with one concrete example from your own work: a deadline you met by putting something off, what you put off and why that was safe, and whether the debt was later paid. Do not claim you never compromise, because that sounds like you have not been tested.

Follow-up

• Tell me about a shortcut that turned out to be expensive. What did it cost, and what did you change afterwards?
• A stakeholder wants a data model change live this week. How do you decide whether that is safe?
• How do you keep the team's quality bar when you are not reviewing every change yourself?

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

Medium · lock contention · ddl · migrations

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

Approach

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

Follow-up

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

Suggested practice checklist

The plan follows the reported loop: day one maps the rounds and your projects, days two and three cover STEP modelling, rules, workflows and code, days four and five cover integration design, deduplication and operations, and days six and seven cover the leadership stories and a full mock.

Day 1 — Map the loop and inventory your projects

• List the three reported rounds and mark what each covers: background and location, Java, JavaScript and STEP fundamentals, then design, behavioral and collaboration.
• Write a one-page entry for each of three past STEP implementations: data model, key rules, integrations, volume, what failed, and your own role.
• Write the spoken career summary for the recruiter call with your STEP years and stack in the first sentences.

Deliverable: A round map, three one-page project entries and a written recruiter-call summary.

Day 2 — STEP data modeling, hierarchies and inheritance

• Write out the steps to configure a new product hierarchy for a catalog, from top-level nodes to attribute placement and validation.
• Write a comparison of reference types and link types with one concrete product example for each and when you would choose either.
• Write your rules for inheritance, overrides and versioning (Main versus Approved workspace, partial approval, revisions, dimension-dependent values), plus the edge cases for moving a node or retiring one with live children.

Deliverable: A hierarchy walkthrough, a reference versus link comparison, an inheritance and versioning rule sheet, and the solved practice item.

Day 3 — Business rules, workflows, bulk imports and the Web UI

• Write a Java or JavaScript business rule that validates an attribute and routes the record, rewrite it to avoid per-record lookups during a bulk import, and note the tuning sequence: measure, check trigger frequency, batch or cache, narrow the trigger, re-measure.
• Sketch a product-onboarding workflow in STEP: its states, the transitions between them, the business actions and conditions on each transition, escalation and timeouts for stalled tasks, and the error path for records that fail validation.
• Prepare a spoken account of a Web UI customization you built for data stewards, with the workflow problem it solved and how you checked it helped.
• Do the practice item on denormalising a column and backfilling it live, to rehearse batching large writes safely.

Deliverable: A validate-and-route rule with its bulk-safe rewrite and tuning notes, an onboarding workflow sketch, a Web UI story and the solved practice item.

Day 4 — Integration design: pricing sync, transport and bad feeds

• Whiteboard the ERP to STIBO to e-commerce pricing sync: source of truth, transport, ordering, retries, and what happens when a consumer is offline.
• Write a REST versus message queue table (coupling, delivery guarantee, retries, back-pressure, ordering) and pick one for price pushes and one for bulk syndication; then outline a SOAP/WSDL feed from a legacy ERP: contract-first from the WSDL, WS-Security headers, and mapping the payload to STEPXML.
• Outline the handling of an inbound feed with many malformed XML records: classify the failures, reject or pause the whole feed and alert its owner when the failure rate passes a batch threshold, and below it validate against the schema, quarantine bad records with reasons and load the rest.
• Do the practice item on collapsing a redelivered event batch into per-aggregate high-water marks, to rehearse idempotent consumers.

Deliverable: A pricing-sync diagram, a transport comparison table with a SOAP outline, a bad-feed handling outline with its threshold rule, and the solved practice item.

Day 5 — Deduplication, security and monitoring

• Write out STEP matching for duplicate product records: the match algorithm and match codes, the score for auto-merge versus the band sent to steward review, survivorship rules for the golden record, and how a merge reaches downstream consumers and the references pointing at the losing record.
• Write a checklist for securing outbound endpoints from the MDM platform: authentication between systems including OAuth2 flows, transport encryption, scoped credentials, secret rotation, rate limits and audit logging.
• Design alerting for integration failures between STEP and a legacy system: which metrics, which thresholds, who is paged, and where failed messages are held for replay.

Deliverable: A matching and merge design, a security checklist, a monitoring and alerting design and a narrated diagnosis of the practice item.

Day 6 — Leadership stories in STAR form

• Write STAR outlines for the migration, the infeasible stakeholder request, mentoring a junior engineer and a production bug, with your own actions marked.
• Write a two-sided answer to the speed versus code quality question with a real example where you chose each.
• Say each story aloud and cut it until the situation takes two sentences and the reasoning gets the most time.

Deliverable: Five STAR outlines with personal actions marked and one recorded answer for each.

Day 7 — Full mock loop and gap repair

• Run a mock of the Technical Evaluation: explain one past implementation, answer a STEP fundamentals question and write a short rule from memory.
• Run a mock design session on the pricing sync with clarifying questions first, then one behavioral question back to back.
• List the three weakest answers from the mock and rework each.

Deliverable: A recorded mock covering one technical, one design and one behavioral answer, plus a reworked list of the weakest three.

Lead-level stories to prepare

Candidates report the onsite stage includes behavioral and leadership and cross-functional collaboration sessions for this lead role. The topics reported are leading technical projects, handling conflict and pushback with business stakeholders, mentoring junior engineers, and tying technical decisions to business outcomes. Use STAR, mark which actions were yours rather than the team's, and be ready to say what went wrong in each story.

1. How do you balance the need to deliver features quickly with the need to maintain high code quality and architectural integrity?
2. Tell me about a time you strongly disagreed with a product manager regarding the technical approach to a new feature. How did you resolve it?

How do you handle versioning and data inheritance in complex product models?

Medium · STIBO MDM & Technical Domain

Approach

1. Treat the two words separately and say so: inheritance answers where a value is defined and who receives it, and versioning answers how change over time is recorded, approved and reversed. Anchor both in one product model you owned, since a real example is expected.
2. Inheritance: define an attribute at the highest hierarchy level where it is true for every descendant, let children receive it, and allow an override only where the business needs one. State the rule when a parent value changes after a child overrode it (the override stays) and how stewards can list overrides so drift is visible.
3. Versioning in STEP terms: edits land in the Main workspace and reach the Approved workspace only through approval, which is its own action and can be partial (approving some changed attributes or references while others wait). Use revision history to see who changed what and to revert an object to an earlier revision. Model regional or language variants as dimension-dependent values in contexts, not as copies of the product. Downstream syndication should read the Approved workspace only.
4. Name the edge cases: moving a node to a new parent silently changes every inherited value below it, a new parent-level attribute can conflict with existing child values, retiring a node with live children needs a rule, and bulk imports can write into inherited attributes. Say how you tested each before release.
5. Close in STAR form with the trade-off: deep hierarchies and heavy overriding make a model hard to reason about, so say what you flattened or constrained and what improved (fewer conflicting values, fewer data-fix requests), using only outcomes you can defend.

Follow-up

• What happens to the children when a parent value changes after they were overridden?
• How do you roll back a bad bulk change to inherited attributes?
• How would you model a product whose attributes differ by region?

Tell me about a time you had to lead a complex technical migration. What was your strategy, and what went wron

Medium · Leadership & Behavioral

Tell me about a time you had to lead a complex technical migration. What was your strategy, and what went wrong?

Approach

1. Choose a migration where you made the plan and the go or no-go call, such as moving legacy product data into a master data platform. Name the source, the target, the record volume and the downstream systems that depended on it, in a few sentences, then spend the answer on the reasoning.
2. Lay out the strategy as steps: inventory and profile the source data, write mapping and transformation rules, run trial loads with reconciliation (record counts, key checks, sampled field comparisons), choose phased versus single cutover and why, and define the rollback before the cutover starts.
3. Pick a failure that really happened: duplicate keys, unmapped attributes, a load far slower than the trial, or a downstream consumer breaking on a changed field. Say how you detected it (the reconciliation or an alert), what you did in the moment and what you changed in the process afterwards.
4. Show leadership explicitly: how you split the work, how you kept business stakeholders informed, and which decisions were yours. A story with no real failure, or one that blames another team, is the version that sinks.

Follow-up

• Why a phased cutover instead of a single one, or the reverse?
• How did you prove every record arrived intact?
• What would you change in the plan if you ran the migration again?

Describe a situation where a business stakeholder requested a feature that was technically unfeasible. How did

Medium · Leadership & Behavioral

Describe a situation where a business stakeholder requested a feature that was technically unfeasible. How did you handle the conversation?

Approach

1. First show that the request really was infeasible, and what kind: a technical limit, a data limit, or too costly for the value. State the evidence you gathered before refusing, such as a small spike, a measurement, or a query showing the data does not exist.
2. Begin the conversation from the business goal behind the request, restate it to the stakeholder, then explain the constraint in business terms (data accuracy, downstream breakage, support burden) rather than platform jargon.
3. Bring two or three alternatives with their cost and what each gives up, and describe how the stakeholder chose. A request to skip validation or approval steps in a master data flow is a natural example if you have one.
4. Finish with the result and the paper trail: what shipped, how the relationship stood afterwards, and where the decision was written down. A flat no, or a story where you simply gave in, misses the point.

Follow-up

• How did you know it was infeasible rather than just expensive?
• What if the stakeholder had escalated to your manager?
• What did the alternative cost them, and did they accept it?

Give an example of how you have mentored a junior engineer who was struggling with a specific technology.

Medium · Leadership & Behavioral

Approach

1. Pick one specific technology the person struggled with, such as writing business rules in JavaScript or reading a data model, and one person. Say what the gap actually was (a concept, the tooling or confidence), and how you found out by pairing, reading their code or asking them to explain it back.
2. Describe the plan as steps: a small first task they could finish, pairing at the start, then review-only, then an unassisted task. Use code review comments that explain the reason behind a change, and leave a short written reference they can reuse.
3. Make the outcome observable: they delivered a task alone, review rounds dropped, or they began answering others' questions. Use only results that happened. Be clear about what you did versus what they did, since taking over their task defeats the story.
4. Include one adjustment: your first approach did not land, you noticed, and you changed it. Say what you learned about teaching that applies to the next hire.

Follow-up

• What did you change when the first approach did not work?
• How do you review someone's code without discouraging them?
• How did you decide when to stop pairing and let them work alone?

Tell me about a time you discovered a critical bug in production. How did you manage the resolution and commun

Medium · Leadership & Behavioral

Tell me about a time you discovered a critical bug in production. How did you manage the resolution and communicate with leadership?

Approach

1. Walk the sequence in order: how the bug was detected, how you sized the blast radius (which records, which downstream consumers), and how you contained it first, by pausing a feed, disabling a workflow step or rolling back, before looking for root cause.
2. Describe the communication to leadership as a fixed shape: what is affected, what is known and not yet known, what is being done, and when the next update comes. Say how often you updated and what you said while the cause was still unclear.
3. Cover recovery and verification: repair the bad data, re-send corrected records to the systems that received bad ones, and confirm with counts or sampled checks. In a master data setting, containment includes the downstream systems that consumed the bad values.
4. End with the root cause, your own role in it if you had one, and the guard you added, such as a validation rule, an alert or a regression test. A story that is all heroics with no communication, or that hides the cause, is the weak version.

Follow-up

• How did you decide between rolling back and fixing forward?
• What did you tell leadership before you knew the cause?
• What did you change so the same bug cannot reach production again?