The reported work is closer to mechanical design than to typical software engineering. Candidates describe reading 2D drawings, building accurate 3D models in CREO, and applying standards such as GD&T so that parts are functional and manufacturable. Engine components are the examples named. The requirements candidates describe list CREO or an equivalent CAD package, GD&T and manufacturing knowledge, the ability to read complex drawings, and basic programming for specific technical tracks.
Candidates describe the hands-on CAD test as the part that decides whether you move forward, and one reported task is modeling engine parts or components under a one-hour limit. Preparation therefore starts with a repeatable modeling routine: read the whole drawing, pick datum planes, build the base shape from a few well-constrained sketches, add detail features, then verify every dimension against the drawing. Practise it against the clock until the order is automatic, and use Creo 4.0 or later, the version candidates mention.
The second pillar is explaining engineering reasoning aloud. Reported questions ask how you apply GD&T in your designs, what matters when designing parts for casting, and how you make sure models meet standard tolerances. Tips from candidates say to state why you chose a modeling approach or a tolerance. Prepare answers anchored in a real part: which datums you chose, which feature control frames you applied, and which casting rules shaped the geometry.
The third pillar is easy to neglect. Candidates report that some tracks include basic programming, such as counting occurrences of given strings in a text file and generating a multiplication table from user-supplied rows and columns. These are small tasks, so the risk is carelessness on edge cases, not difficulty. Nice-to-have items candidates mention are automotive or engine-part design, familiarity with CAE and simulation tools, and a record of meeting design deadlines.
Resume Screening
reportedCandidates describe this first stage as a review of your resume for qualifications and fit with the role. No questions are reported for it, so the preparation is the document itself. The requirements candidates describe center on CREO, GD&T, manufacturing processes, reading 2D drawings and, for some tracks, basic programming. Make each of those visible with concrete evidence, such as the CREO version you used, the parts you modeled and the standards you applied.
What to demonstrate
- Fit between your listed experience and the requirements candidates describe for the role
- Evidence of CAD work: tools, versions and the kinds of parts modeled
- Evidence of GD&T and manufacturing knowledge, such as casting experience
How to prepare
- Rewrite each CAD project line as part, tool and outcome, for example a cast engine component modeled in CREO from a 2D drawing.
- List the GD&T and casting concepts you have genuinely applied, and drop any you cannot explain in a sentence.
- If you list programming, be ready to write a short file-reading or looping program, since some tracks include one.
- Mention any automotive or engine-part work and any CAE tools, which candidates describe as a plus.
Technical Assessment
reportedCandidates describe this stage as hands-on tool tests and technical interviews that check practical skills. The reported format covers question types such as converting a 2D drawing into a 3D model, modeling engine parts within a one-hour limit, explaining your workflow for assembly features and complex geometry, and explaining GD&T. Some tracks add basic programming. Treat the tool test as a timed build, since candidates describe it as decisive, and treat the technical interview as a chance to say why you chose each step.
What to demonstrate
- Working CAD output: a model that matches the drawing and was finished inside the time limit
- Workflow quality: how the feature tree and sketches are organized
- Applied GD&T knowledge, including where and why tolerances go
- Basic logic and string handling, in tracks that include programming
How to prepare
- Run timed 2D-to-3D builds on drawings with several views and a section, then compare every dimension against the drawing before you stop.
- Rehearse a spoken workflow for assemblies and complex geometry: base feature, datum references, assembly constraints, then detail features.
- Prepare one GD&T explanation built on a real part, naming the datum scheme and the feature control frames you would apply.
- Write the file-counting program and the multiplication-table program once each in your strongest language, with edge cases tested.
Final Technical Evaluation
reportedCandidates describe the final stage as an assessment of whether you can apply engineering theory to real challenges. Casting knowledge, tolerance control and the reasoning behind design choices fit this description, and tips from candidates mention explaining why you chose a modeling approach or a tolerance in a face-to-face conversation. The reports do not say which questions arrive in which round. Prepare to answer every reported fundamentals question with a worked example.
What to demonstrate
- Ability to connect theory, such as GD&T and casting rules, to a concrete part
- Reasoning about manufacturing limits, which candidates say you must be ready to explain
- Clarity when justifying a modeling or tolerance decision aloud
How to prepare
- Write a casting checklist and apply it to a real part: wall thickness, taper for mold release, fillets, parting line and machining allowance.
- Prepare an answer on keeping models within standard tolerances, including how you check the model against the drawing.
- Practise two-minute explanations that give the decision, the alternative you rejected and the reason.
- Bring a story about an error you caught before submitting a model, such as a missing dimension or a wrong tolerance.
PracHub editorial advice for the preparation topics above.
Modeling from the first view you read and missing dimensions or tolerances elsewhere on the drawing
Scan every view, section and note before opening a sketch, and list the datums and critical dimensions. After modeling, tick each dimension off against the drawing. Candidates specifically warn about missing dimensions and incorrect tolerances.
Starting with fillets and cosmetic detail, then running out of time on the one-hour engine-part task
Build the main volume first from a few sketches referenced to datum planes, add holes and bosses next, and leave rounds and pull angles for last. A clean feature tree also makes late corrections cheap.
Reciting GD&T definitions without tying them to a part
Prepare one worked example: choose datums A, B and C from the functional mounting surfaces, then say which feature gets position, flatness or profile control and why. Name what each datum constrains.
Answering the casting question with only 'add taper'
Cover the full set: uniform wall thickness to avoid hot spots, generous fillets, a sensible parting line, cores and undercuts, shrinkage and machining allowance, and material flow into thin sections.
Treating the programming tasks as trivial and handing in code that fails on awkward input
Test the string-counting program with an empty file, repeated and overlapping matches, differences in letter case and a missing file. Test the multiplication table with zero, one and non-numeric input.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Collapse a redelivered event batch into per-aggregate high-water marks
You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.
Approach
- One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
- Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
- Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
- If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.
Follow-up
- The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
- How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?
Identify the heaviest tenants in a five-minute window under memory pressure
The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.
Approach
- Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
- Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
- State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
- Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.
Follow-up
- The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
- Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?
Track a rolling failure rate per destination for circuit decisions
The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.
Approach
- Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
- Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
- State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
- Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.
Follow-up
- The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
- A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?
Keep soft-deleted accounts from blocking re-registration
app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.
Approach
- Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
- Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
- For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
- State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.
Follow-up
- A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
- How do you honour an erasure request while resource_revision.actor_user_id still references this table?
Hold a per-tenant active cap against concurrent creates
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
- 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.
- 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.
- 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.
- 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?
Convert a provided 2D engineering drawing into a 3D model in CREO.
Convert a provided 2D engineering drawing into a 3D model in CREO.
Approach
- Read the drawing before touching Creo: units, scale, the projection symbol in the title block (first-angle and third-angle put the side views on opposite sides), the general-tolerance note, and which views are sections or detail views showing internal geometry.
- Choose the base feature from the view that shows the most characteristic profile, sketch it on a default datum plane (FRONT, TOP or RIGHT) and place the part symmetric about a plane when the drawing is symmetric, so mirror and pattern features work later.
- Dimension sketches the way the drawing does, turning weak dimensions into strong ones, so each model dimension maps to a drawing callout and a later edit changes one value instead of breaking the sketch.
- Build in a stable order: main solids (extrude, revolve), then cuts and Hole features (standard or tapped holes, not cut extrusions), patterns and mirrors, and rounds and chamfers last; reference datum planes and axes rather than round edges so regeneration does not fail.
- Verify before submitting: Analysis > Measure on key distances, a quick check of every drawing dimension against the model, mass properties if a material is given, and a look for missing or over-specified dimensions (reference dimensions in parentheses do not drive geometry).
Follow-up
- The drawing is missing a dimension you need. What do you do, and how do you record the assumption in the model?
- How would you change your feature tree if you knew this part would become a family of sizes?
- Which features would you use for a hole shown in a section view with a counterbore and a thread?
Demonstrate proficiency in modeling complex engine parts or components within a strict one-hour time limit.
Demonstrate proficiency in modeling complex engine parts or components within a strict one-hour time limit.
Approach
- Plan on paper first: list the features in build order and mark which ones carry most of the geometry, so the hour goes on solids that matter and cosmetic details (small chamfers, cosmetic threads) come last if time remains.
- For a rocker arm, extrude the body profile from the side view, add pivot and end bores with Hole or revolve features, add ribs and lightening cuts, and mirror about the mid-plane where the part is symmetric.
- For an exhaust manifold, model the head-side flange as an extrude, route each runner as a sweep along a sketched trajectory (or a swept blend where the section changes), merge into a collector, then shell for wall thickness and add the outlet flange.
- Order rounds before Shell when you want the wall to follow the rounds at constant thickness, and keep the shell thickness below the smallest concave radius, otherwise the shell fails to regenerate.
- Save often (Creo writes a new numbered version on each save), regenerate after each feature, and keep sketches simple so a failure points to one feature you can fix in Resolve mode instead of a rebuild.
Follow-up
- Your shell fails at the end with twenty minutes left. What do you check first?
- How would you model runners whose cross-section changes from round to oval along the path?
- If you could not finish, which features would you have left out, and why those?
Explain your workflow for handling assembly features or complex geometries.
Explain your workflow for handling assembly features or complex geometries.
Approach
- Describe the order you use for a complex part: base solid, secondary solids, cuts and holes, patterns, then rounds and chamfers, with references to datum planes and axes rather than to edges created by rounds, so a change upstream does not break features downstream.
- Name the tools for freeform geometry: variable section sweep, swept blend, blend and boundary blend surfaces, then merge, solidify or thicken the quilt into a solid, and check that the quilt is closed before solidifying.
- For assemblies, fully constrain each component (Coincident, Distance, Angle Offset, Parallel, Normal) and use mechanism connections such as Pin or Slider only where motion is intended; check the status reads fully constrained instead of packaged.
- Mention top-down structure for related parts: a skeleton model carrying shared datums and interfaces so mating parts update together, subassemblies for large structures, and simplified representations to keep the model responsive.
- Close with checks: Global Interference on the assembly, Measure on clearances, and a regeneration with key dimensions changed to prove the intent survives edits.
Follow-up
- When would you cut a feature at the assembly level instead of in the part, and what does that do to the part file?
- A component flips orientation when a mating dimension changes. How do you diagnose and fix the constraint set?
- How do you keep two parts that share a bolt pattern in sync?
Explain the application of GD&T (Geometric Dimensioning and Tolerancing) in your designs.
Explain the application of GD&T (Geometric Dimensioning and Tolerancing) in your designs.
Approach
- Frame what GD&T is for: it controls form, orientation, location and runout relative to a datum reference frame (ASME Y14.5 or ISO 1101 / GPS), so the tolerance zone follows how the part fits and is inspected, instead of plus-minus coordinates that give square zones and stack along the dimension chain.
- Pick datums from function, using a flange as the example: primary datum the sealing face (three points of contact, three degrees of freedom removed), secondary a locating bore or hole (two), tertiary a feature that stops rotation (one).
- Match the control to the requirement: flatness on a sealing face, perpendicularity of a bore to its face, position for bolt holes, profile of a surface for cast freeform shapes, runout for rotating features; note ASME Y14.5-2018 removed concentricity and symmetry, leaving position, profile or runout to do that job.
- Show you can compute with it: a clearance hole of 10.0 to 10.2 mm with position 0.2 diameter at MMC allows 0.4 at 10.2 (bonus tolerance), and its virtual condition is 10.0 - 0.2 = 9.8 mm, the functional gauge pin size; floating-fastener tolerance is T = H - F, fixed-fastener is T1 + T2 = H - F.
- Add the precise points: a diameter position zone circumscribing a square plus-minus zone has about 57% more area, ASME applies Rule #1 (size limits also control form) while ISO 8015 defaults to independence, and features without a modifier are read regardless of feature size.
Follow-up
- Why would you use profile of a surface instead of plus-minus dimensions on a cast surface?
- What would the functional gauge for your bolt-hole callout look like, and what does changing the datum order do to the measured result?
- When would you not apply the MMC modifier on a position callout?
What are the key considerations when designing parts for casting?
What are the key considerations when designing parts for casting?
Approach
- Start with solidification: keep walls as uniform as the function allows and blend thickness changes gradually, because thick junctions cool last and form hot spots with shrinkage porosity; Chvorinov's rule (solidification time proportional to (V/A)^n, n about 2) explains why.
- Plan feeding: risers or feeders need a larger modulus (V/A) than the section they feed so solidification moves toward them; place heavy sections near feeders and avoid isolated thick bosses.
- Choose the parting line early, put a release taper on faces parallel to the pull direction, sized for the process, and avoid undercuts or plan cores for them; internal passages such as manifold runners need cores with core prints to locate them.
- Generous fillets at internal corners and no sharp intersections (L, T and X junctions) reduce hot tears and stress concentration; replace a heavy X junction with offset T junctions.
- Size the pattern and stock: shrinkage allowance on the pattern (often quoted around 1% for grey iron and about 2% for steel), machining allowance on faces that will be machined, process minimum wall thickness, and cast datum targets so the first machining operation can locate the part.
Follow-up
- Where would you put the parting line on a part like an exhaust manifold, and why?
- How does designing for sand casting differ from high-pressure die casting?
- How would you dimension and tolerance a surface that stays as-cast against one that is machined later?
How do you ensure your models meet standard engineering tolerances?
How do you ensure your models meet standard engineering tolerances?
Approach
- Model at nominal with the tolerance stored on the dimension (limits, plus-minus or symmetric display in Creo), and set the tolerance standard (ANSI or ISO) up front so tolerance tables and fit classes come out right; model at mid-tolerance only when the downstream user (a toolmaker or CNC programmer) needs it.
- Apply the general-tolerance standard for untoleranced dimensions (ISO 2768 classes f, m, c, v for linear and angular sizes) and tight tolerances only where function needs them, with ISO fits for mating features, for example H7/g6 for a close sliding fit and H7/p6 for a locational interference fit.
- Run a stack-up on the dimension chains that matter: worst case adds every tolerance, root-sum-square takes the square root of the summed squares and assumes independent, roughly normal, centred variation, so state which one is used and why.
- Check in the CAD model: Measure and Global Interference or clearance analysis on the assembly, and regenerate with critical dimensions at their limits (for example through family-table instances) to confirm parts still fit at the extremes.
- Finish with a standards check such as ModelCHECK or a checklist: every critical dimension toleranced, datums defined, units and tolerance standard consistent, no dimension driven by an unstable reference.
Follow-up
- Your worst-case stack fails but the RSS stack passes. What do you tell the design lead?
- How do you pick between a hole-basis and a shaft-basis fit system?
- How would you show that a tolerance is too tight to manufacture economically?
Write a program to read input from a text file and count the occurrences of specific strings.
Write a program to read input from a text file and count the occurrences of specific strings.
Approach
- Pin down the definition first: whole-word or substring matches, case sensitivity, whether overlapping matches count, and whether the target strings come from arguments, a second file or user input.
- Stream the file line by line (Python: with open(path, encoding='utf-8') as f) so memory stays independent of file size, and keep counts in a dict or collections.Counter keyed by target; in Java, BufferedReader with HashMap.merge.
- For whole words, split or tokenize each line (casefold() if case-insensitive, strip punctuation) and check membership in a set of targets: O(N) time over N characters, O(k) extra space for k targets.
- For substrings, note that str.count counts non-overlapping matches ('aaaa'.count('aa') is 2, while the overlapping count is 3); use a find loop advancing by one or a regex lookahead for overlaps, and Aho-Corasick for many patterns in O(N + total pattern length + matches).
- Handle edge cases: missing file (FileNotFoundError), bad encoding (errors='replace' or a declared encoding), an empty target (Python's ''.count rule returns len + 1, so reject it), and matches that span a line break when reading line by line.
Follow-up
- The file is 50 GB and the target list has 100,000 strings. What changes?
- How would you return the line numbers of each match as well as the counts?
- How do you test this program, and which inputs go in your test cases?
Create a program that takes user input for rows and columns to generate a multiplication table.
Create a program that takes user input for rows and columns to generate a multiplication table.
Approach
- Read rows and columns, convert them to integers, and validate: re-prompt on non-numeric input (catch ValueError in Python, check the scanf return value in C) and reject zero or negative values with a clear message.
- Use nested loops, i from 1 to rows and j from 1 to cols, printing i * j; the work is O(rows x cols) time, which matches the output size, and only O(1) extra space if values are printed as they are computed.
- Align the columns with a width computed from the largest value: w = len(str(rows * cols)) + 1, then f'{v:>{w}}' in Python or printf("%*d", w, v) in C.
- Optionally add a header row and a header column, and keep input parsing, table building and printing in separate functions so each part can be tested.
- Mention limits: for very large inputs the output itself is the cost, and in C or Java int overflows once rows * cols exceeds 2^31 - 1, so switch to long or cap the input.
Follow-up
- How would you print only the upper triangle, since i * j equals j * i?
- How would you write the table to a CSV file instead of the console?
- What changes if rows and columns arrive as command-line arguments instead of prompts?
Read latency spikes on a sixty-second sawtooth
The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.
Approach
- Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
- Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
- Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
- De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.
Follow-up
- The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
- How does your answer change if the recompute takes 4 seconds instead of 250 ms?
The plan follows the reported rounds and topics: GD&T, Creo workflow, 2D-to-3D conversion, casting and basic programming. Each day ends with something you can check, such as a model, an annotated drawing or a tested program.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and audit your gaps
- Write the three reported rounds and what each stage covers, then rate yourself from 1 to 5 on GD&T, Creo, 2D-to-3D conversion, casting and basic programming.
- Collect three practice drawings, including one cast part with a section view, and install or confirm Creo 4.0 or later.
- Update your resume so each CAD project states the part, the tool and the standards used.
Deliverable: A one-page self-rating with the weakest topic marked, three practice drawings ready and a resume revised for the screening round.
02GD&T you can explain
- Learn the feature control frame: symbol, tolerance zone, material modifier and datum references, and the families of form, orientation, location, profile and runout.
- Work out how datums A, B and C remove degrees of freedom, and annotate one practice drawing with a datum scheme.
- Say aloud how you apply GD&T in your designs and how you make sure tolerances are standard.
Deliverable: An annotated drawing with datums and three feature control frames, plus a written outline of a spoken GD&T answer.
Practice prompt ↗Practice prompt ↗03Creo workflow and assemblies
- Rebuild a simple bracket using datum planes, constrained sketches, extrude, revolve, hole, pattern and mirror, keeping the feature tree short and named.
- Add a second part and assemble it with constraints, noting which features reference which parent.
- Write a five-step spoken workflow for assembly features and complex geometry.
Deliverable: A bracket part and a two-part assembly with a tidy feature tree, plus the written five-step workflow.
Practice prompt ↗04Timed 2D-to-3D conversion
- Model a practice drawing with several views and a section under a timer, logging time spent reading, sketching, adding features and checking.
- Verify the model by measuring critical dimensions against the drawing and listing anything you could not confirm.
- Repeat on a second drawing and cut the slowest phase.
Deliverable: Two timed models, a time log per phase and a checklist of the dimension checks you ran.
Practice prompt ↗05An engine part under the one-hour limit
- Model an exhaust-manifold-style or rocker-arm-style part from a drawing in one hour: base volume, bosses, holes, ribs, then rounds and pull angles.
- Stop at the limit and note what was unfinished, then redo the part and move the unfinished work earlier.
- Write the order of features you would use on any engine component.
Deliverable: Two attempts at one part with times, plus a written feature order you can reuse in the test.
Practice prompt ↗06Casting design and tolerance control
- Write a casting checklist covering wall thickness, taper for mold release, fillets, parting line, cores, shrinkage and machining allowance.
- Apply it to your day-5 model, changing the geometry where it breaks a rule.
- Answer aloud how you keep models within standard tolerances, and how you would check this before submitting a model.
Deliverable: A casting checklist, a revised model with a list of changes made and a spoken answer outline for each question.
Practice prompt ↗Practice prompt ↗07Programming basics and a spoken run-through
- Write the file-counting program and the multiplication-table program in your strongest language, then test the empty, repeated and invalid-input cases.
- Optionally try the heaviest-tenants counting drill from the PracHub practice set to rehearse counting with a hash map.
- Run a spoken pass of your GD&T, workflow and casting answers, each giving the decision and the reason.
Deliverable: Two working programs with a list of tested edge cases, plus a recorded or written run-through of your technical answers.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates do not report dedicated behavioral questions for this loop, but tips from candidates say to explain the reasoning behind a modeling approach or a tolerance, and the role involves working with engineering leads and keeping documentation. Use these prompts to build short stories around design decisions, error checking and deadlines.
Tell callers you do not own that their integration breaks
A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.
Approach
- Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
- Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
- Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
- Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
- How would you detect a consumer that reads the field only during a monthly export?
- One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?
Estimate work you have never done and defend the range
You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.
Approach
- Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
- Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
- Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
- Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.
Follow-up
- How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
- Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?
Unblock an engineer without taking the keyboard
A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.
Approach
- Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
- Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
- Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
- Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.
Follow-up
- How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
- Their handler calls an external endpoint before recording that it did. What do you tell them to change first?
- 01
Walk me through a part you modeled from a 2D drawing: how you read the drawing, where it was ambiguous and how you resolved it.
- 02
Tell me about an error you caught in your own model before submitting it, such as a missing dimension or wrong tolerance, and what you changed in your checking routine afterward.
- 03
Describe a design task you completed against a hard deadline: what you cut, what you protected and what you would do differently.
- 04
Explain a tolerance or modeling-approach decision you made and defend it as you would to an engineering lead.
- 05
Describe how you picked up a new CAD tool version or standard revision and became productive with it.
What rounds do candidates report for the Software Engineer role?
Candidates report three rounds over about 3-5 weeks: Resume Screening, a Technical Assessment with hands-on tool tests and technical interviews, and a Final Technical Evaluation focused on applying engineering theory to real challenges. The reports do not say which questions fall in which round, so prepare for all question types.
PracHub Software Engineer practice ↗What should I practise first?
Start with timed 2D-to-3D conversion in CREO. Candidates describe the hands-on CAD test as the part that decides whether you move forward, and one reported task is modeling engine components within a one-hour limit. Practise a fixed order: read the drawing, build the base shape, add details, then check dimensions.
PracHub Software Engineer practice ↗Which CAD software and version should I know?
Candidates mention CREO 4.0 or later, and the requirements they describe accept an equivalent high-end CAD package. If your background is another system, learn the Creo equivalents for sketching, datum planes, patterns and assembly constraints before the tool test.
PracHub Software Engineer practice ↗Do I need to write code?
Some tracks include basic programming. The two reported tasks are counting occurrences of specific strings in a text file and generating a multiplication table from user-supplied rows and columns. Use your strongest language and test the awkward inputs, such as an empty file or a zero-row table.
PracHub Software Engineer practice ↗How do I answer the GD&T and casting questions well?
Anchor each answer in one real part. For GD&T, name the datum scheme and the feature control frames you applied and why. For casting, cover wall thickness, taper for mold release, fillets, parting line and machining allowance. Candidates say to explain why you chose a tolerance, so give the reason.
PracHub Software Engineer practice ↗How should I check my work before submitting a CAD test?
Candidates warn about missing dimensions and incorrect tolerances. Keep a checklist: every dimension from every view, section and note, datum references, units and any feature you skipped. Leave enough time at the end to run through it.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01CADOPT TECHNOLOGIES PVT Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.