Amsted Rail Software Engineer Interview Guide

The 60-second brief

Amsted Rail is a company in the rail industry. Candidates describe a Software Engineer role that is much closer to engineering support than to product software. The work they report: creating and revising 3D models and 2D engineering drawings, often in Creo CAD; organising and analysing large data sets in Microsoft Office, chiefly Excel, to help the team reach project goals; and turning technical requirements into written work instructions that other engineers and the shop floor can follow. The role works next to mechanical and process engineers and under engineering management, so most of what you produce is a model, a drawing, a spreadsheet or a document that someone else builds from or signs off.

This guide is for candidates interviewing for the Amsted Rail Software Engineer role, including students who are still enrolled in a degree. It covers the two reported rounds and all ten reported questions, which span data sets, CAD accuracy, work instructions, troubleshooting, deadlines, conflicting instructions, document errors, cross-functional work and motivation. The role requirements are summarised in the FAQ below. The guide does not cover algorithm drills, because candidates report the technical focus is on engineering software and data rather than algorithmic coding.

Candidates report two rounds over about 2-4 weeks: a Phone Screening about your background and fit, then One-on-One Sessions, held in person or virtually, with managers at several levels.

Focus areas

• 3D modeling
• 2D drawings (engineering drawings)
• Engineering documentation (technical writing)

Overview

Despite the title, the reported content of this role is CAD, documentation and spreadsheet work in a manufacturing setting. The topics candidates list are 3D modeling, 2D engineering drawings, engineering documentation, Creo CAD and work instructions, and the reported questions follow the same lines. If most of your preparation is LeetCode, you will be ready for the wrong interview. Prepare evidence instead: a part or assembly you modelled and how you checked it, a spreadsheet you built from messy data and how you proved its totals were right, and a procedure you wrote and then revised after someone tried to follow it.

Every reported question asks about experience: "how have you", "describe your experience", "give an example". None of them is a whiteboard problem. A strong answer names the tool and the feature you used (constraints and datum references in Creo, Power Query or PivotTables in Excel, a revision block and change log on a work instruction), the check that caught or prevented an error, and the result in numbers: hours saved, rework avoided, a part that fit on the first build. A story without the tool or without the check sounds like a description of a job posting.

Candidates say the job means working with mechanical and process engineers and spending time in manufacturing environments. The role requirements list plant visits that can involve bending, squatting and lifting up to 50 pounds. Expect to talk about how comfortable you are in industrial settings, and have a real answer to why you want to apply software skills in rail and manufacturing. The behavioral questions in this loop are about precision and traceability: a deadline under a manager, conflicting instructions, an error in a document or model, and keeping your work open to review. Prepare stories where you verified something before acting and left a record of what changed.

Candidates found the people they met candid about how the business runs. The one-on-one sessions are with managers at different levels, so bring questions about the problems the engineering team deals with most often, and about how models, drawings and work instructions move from engineering to the floor.

The Amsted Rail interview process

Candidates report two stages, a Phone Screening and then One-on-One Sessions, over about 2-4 weeks. Some candidates say the process went from first interview to feedback or an offer in about two weeks.

Phone Screening

Candidates describe the Phone Screening as a first call about your background and whether you fit the role. Nothing more specific is reported about its content, so prepare a short summary of your background rather than a full chronological CV. It helps to have your degree path, Microsoft Office skills, any CAD exposure and any manufacturing internship or co-op ready to mention, since those are the items in the role requirements. Have a specific reason for choosing rail and manufacturing in case it comes up, and an honest answer about plant visits and working in industrial settings. Close by asking what the one-on-one sessions involve and who they are with.

What to demonstrate

• The call is reported as an assessment of your background and fit for the role
• How clearly you can summarise your own experience on a call
• How well your history lines up with the role requirements you have read

How to prepare

• Write and time a two-minute background summary that names your CAD tool (Creo if you have used it), your strongest Excel skill and one document you wrote that someone else used.
• Prepare a 60-second answer to why you want rail and manufacturing, tied to something from your coursework or co-op, plus what you found when you researched Amsted Rail's products.
• Decide in advance how you will talk about plant visits and the role's physical requirements (bending, squatting, lifting up to 50 pounds), and about working on site.

One-on-One Sessions

Candidates report One-on-One Sessions, in person or virtual, with managers at different levels. The reported questions for this role fall into three groups: technical and domain proficiency (data sets, CAD accuracy, work instructions, troubleshooting), problem-solving and adaptability (deadlines, conflicting instructions, errors in documents or models), and culture fit (why rail, cross-functional work, transparency). Candidates also report scenario prompts such as how you version-control technical documents and what you do when a design requirement changes partway through a project. You meet several people, so make each story complete on its own: the situation, the tool, the check you ran, the result. Managers at different levels may ask about the same project, so be ready to tell it at two levels of detail, once with the Creo or Excel specifics and once as impact and decision.

What to demonstrate

• Depth in the tools the role reports: 3D models and 2D drawings in Creo, Excel data work, written work instructions
• How you handle deadlines, conflicting instructions and errors found in a document or model
• How you communicate with managers and with mechanical and process engineers

How to prepare

• Build one artefact story for each technical theme: a data set you organised, a model or drawing you checked for accuracy, and a work instruction you wrote and then revised.
• Write STAR outlines for the deadline, conflicting-instructions and document-error questions, each ending in a measurable result and a record of the change.
• Prepare an answer on how you version-control documents (numbering, revision letters, change log, approval, pulling superseded copies) and one on handling a requirement that changes partway through a project.
• Bring two or three questions for each manager about the engineering team's most common problems and how drawings and instructions reach the floor.

Where candidates lose points

Preparing only for algorithm coding and having no CAD, Excel or documentation examples to show

Candidates report that the technical focus is engineering software, CAD and data analysis rather than algorithmic coding. Before the loop, prepare three concrete artefacts or stories: a model or drawing, a data set you organised, and a work instruction you wrote. Know the tool features you used in each.

Answering the CAD accuracy question with what you modelled and nothing about how you checked it

Name the mechanisms: strong dimensions that capture design intent in place of weak ones, stable datum references, interference and clearance analysis, mass-properties checks, and comparing the drawing against the model and the requirement before release. Give one error you caught and what it would have cost.

Fixing a conflicting instruction or a document error quietly, with no authoritative source and no revision record

For the conflicting-instructions and document-error questions, show that you traced which source governs (the released revision, the spec or the change order), got the decision recorded, revised the document with a change log, and told everyone using the old version.

A data-set story with no numbers and no proof the result was right

State the size and sources of the data, the integrity checks you ran (row counts across merges, duplicate keys, control totals, unit consistency) and a measurable outcome. Say how someone else could rerun it.

A generic answer to why rail and manufacturing, or hesitating about plant work

Research Amsted Rail's products, connect them to a project where your work produced something physical, and decide before the phone screen how you will talk about plant visits and the role's physical requirements.

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

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

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

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

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

Approach

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

Follow-up

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

How have you utilized software tools to organize and analyze large data sets in previous projects?

Medium · Technical and Domain Proficiency

Approach

1. Pick one real project and give its shape first: where the data came from (ERP export, test logs, a supplier's BOM), how many rows and columns, and what decision it had to support. Then name the tools in order, for example Power Query to import and clean, an Excel Table with XLOOKUP or INDEX/MATCH to join sources, PivotTables to summarise, and conditional formatting to flag outliers.
2. Spend most of the answer on integrity checks. Keep the raw export untouched on its own sheet, compare row counts before and after each merge, use COUNTIFS to find duplicate keys, and reconcile a control total (total quantity or total weight) against the source system.
3. Name the traps you handled: part numbers stored as numbers losing the zeros at the front, dates imported as text, mixed units (inches against millimetres, pounds against kilograms), trailing spaces breaking lookups, and merged cells breaking sorts.
4. Say how you made it repeatable: a refreshable query instead of copy-paste, a notes tab listing sources and assumptions, input cells kept apart from formulas. Close with the outcome in numbers, such as hours per week saved or a defect trend someone acted on.
5. If the data outgrew Excel (the worksheet limit is 1,048,576 rows) or took minutes to recalculate, say what you moved to: Power Pivot or the Data Model, a database query, or Python with pandas, and why.

Follow-up

• How did you prove the summary numbers were correct before anyone used them?
• If the source system changed its export format next month, what in your workbook would break, and how would you find out?
• How would someone else rerun or extend your analysis without you?

How do you approach the creation and revision of technical work instructions to ensure they are clear and acti

Medium · Technical and Domain Proficiency

How do you approach the creation and revision of technical work instructions to ensure they are clear and actionable?

Approach

1. Start from the actual process, not from memory. Walk the station or task with the operator or process engineer, note every step and every tool, and collect the governing drawing and spec revisions.
2. Describe the structure: document number and revision, purpose and scope, safety and PPE, tools and materials, then numbered steps with one action each starting with a verb ("Torque bolts A-D to 45 ft-lb in a cross pattern"). Add annotated photos or exploded views from the CAD model at the steps where mistakes happen, and finish with acceptance checks and a sign-off.
3. Validate before release: have someone who has never done the task follow it while you watch silently, write down every hesitation or question, and fix each one. That test is the evidence that the instruction can actually be followed.
4. Explain revisions: a revision block and change log, review and approval, and removing superseded copies from the floor so only the current version is in use. When a drawing changes, check every work instruction that refers to it.
5. Edge cases to name: units and torque values that must match the drawing exactly, steps that differ between shifts, readers with different language or reading levels (more visuals, fewer words), and safety-critical steps that need a hold point.

Follow-up

• An operator tells you the instruction does not match how the job is really done. What do you do?
• Walk me through how you version-control your technical documents.
• How do you keep work instructions in sync when the referenced drawing is revised?

What is your process for troubleshooting a software-related issue that disrupts a project timeline?

Medium · Technical and Domain Proficiency

Approach

1. Use a real incident: a corrupted CAD file, an assembly that would not open after a software update, a spreadsheet macro that broke, or a licence or network drive outage. Say what it blocked and which date was at risk.
2. Lay out the sequence: reproduce it and define its scope (one file, one machine or everyone), establish what changed and when (update, new file version, moved folder), read the actual error message or log, then isolate by testing on another machine, another account or a clean copy of the file.
3. Separate unblocking from fixing: restore the last good version from backup or version history, or switch to a temporary workaround so the schedule keeps moving while you find the root cause.
4. Communicate early: tell your manager the impact, the workaround and an honest estimate. Escalate to IT or the software vendor once you have gathered the evidence they will need (version numbers, steps to reproduce, the error text).
5. End with prevention: the backup or check-in habit, the update procedure, or the file convention you introduced so it did not happen again.

Follow-up

• At what point do you stop digging yourself and escalate, and to whom?
• How did you tell your manager about the delay, and what did you promise?
• What did you change afterwards so the same failure could not stop the work again?

Suggested practice checklist

The plan follows the two reported rounds and the ten reported questions. It moves from the phone-screen pitch through the technical themes candidates report (Excel data, Creo models and drawings, work instructions, troubleshooting) to the behavioral stories, and ends with a mock of both stages.

Day 1 — Phone-screen pitch and motivation

• List the role requirements (engineering degree path, Microsoft Office, CAD familiarity, manufacturing internship or co-op) and write one piece of evidence from your history next to each.
• Write and time a two-minute background summary built around CAD, Excel and documentation work.
• Research Amsted Rail's products, then write a 60-second answer to why you want to apply software skills in rail and manufacturing, including how you will talk about plant visits.

Deliverable: A requirement-to-evidence table, a timed two-minute pitch, and a written why-rail answer that names specific products.

Day 2 — Excel data work and traceable spreadsheets

• Take a messy public data set (or a past project's export) and clean it with Power Query, join a second table with XLOOKUP, and summarise it with a PivotTable.
• Add integrity checks: row counts before and after the join, a COUNTIFS duplicate check, and a control total that reconciles with the source.
• Add a notes tab with sources, assumptions and a sheet map, then write your STAR answer for the data-set question and the transparency question from this exercise or a real project.

Deliverable: A cleaned workbook with visible integrity checks and a notes tab, plus written answers for the data-set and transparency questions.

Day 3 — CAD accuracy in Creo (or your CAD tool)

• Model a simple part, replacing weak dimensions with strong ones that capture design intent and dimensioning from datum planes, then change a key dimension and confirm the model regenerates cleanly.
• Build a two-part assembly, run an interference or clearance check, and make a 2D drawing with tolerances.
• Write a personal release checklist for models and drawings, and outline a story about an error you found in a model or document using it.

Deliverable: A part, assembly and drawing set with an interference-check result, a release checklist, and outlines for the CAD-accuracy and error-found questions.

Day 4 — Write and test a work instruction

• Write a one-page work instruction for a physical task you can test at home (assembling a small fixture or a piece of furniture), with numbered single-action steps, a tools list and annotated images.
• Have someone follow it while you watch without helping, write down every hesitation, then issue Rev B with a change log.
• Write your answer to the work-instructions question and a short answer on how you version-control technical documents.

Deliverable: Rev A and Rev B of a tested work instruction with a change log, plus written answers on creating instructions and controlling their versions.

Day 5 — Troubleshooting and deadline stories

• Pick a real software problem that threatened a schedule and write it as a sequence: scope, what changed, isolate, workaround, escalate, prevent.
• Write a STAR story about a tight deadline under a manager that shows your prioritisation method and what you traded away.
• Tell both stories aloud and cut any sentence that does not describe a decision or a result.

Deliverable: A troubleshooting walkthrough and a deadline STAR story, each with a measurable result, rehearsed aloud.

Day 6 — Conflicts, errors and cross-functional work

• Write a STAR story about conflicting instructions that names the governing source and how the decision was recorded.
• Finish the error-found story from day 3, adding the impact check and the prevention step.
• Write a cross-functional story with mechanical or process engineers that includes one point of friction and how evidence resolved it, plus an answer on handling a requirement that changes partway through a project.

Deliverable: Three complete STAR stories (conflicting instructions, error found, cross-functional work) and a changed-requirement answer.

Day 7 — Mock both rounds

• Run a mock phone screen with a friend: pitch, why rail, background and plant-work questions.
• Run two mock one-on-ones: one technical (data set, CAD accuracy, work instructions, troubleshooting) and one behavioral (deadline, conflicts, errors, cross-functional work, transparency). Tell the same project once at engineer depth and once at manager depth.
• Write three questions for the managers about the engineering team's most common problems and how documents reach the floor.

Deliverable: Notes from three mock sessions with one fix per weak answer, and a written list of questions for the one-on-one sessions.

Behavioural preparation

The behavioral questions candidates report for this role cover meeting a deadline under a manager, handling conflicting instructions, finding errors in documents or models, working with mechanical and process engineers, keeping work reviewable, and motivation for rail and manufacturing. Strong stories here show precision and traceability: you checked before you acted, you escalated to the right person, and the change left a record.

Describe your experience with 3D modeling or CAD software and how you ensure accuracy in your designs.

Medium · Technical and Domain Proficiency

Approach

1. Say which tool and what kind of work: parts, assemblies, sheet metal, 2D drawings. If you have not used Creo, name your tool (SolidWorks, Inventor, Fusion) and point out the ideas that carry over: a feature tree, parametric dimensions and parent-child references.
2. Explain how accuracy goes into the model: replace the weak dimensions and constraints Creo adds automatically with strong ones that capture design intent, so each sketch is fully defined. Dimension from stable datum planes and axes rather than from edges that can disappear, record intent in parameters or relations, and regenerate cleanly after every change.
3. Explain how you verify it: measure and mass-properties checks against expected values, interference and clearance analysis in the assembly, and checks that the drawing dimensions, tolerances and GD&T callouts match the model and the requirement. Add a checklist or peer review before release.
4. Give one concrete catch, such as a hole pattern that interfered with a mating part or a unit mismatch in an imported STEP file, and what it would have cost on the floor if it had gone through.
5. Separate model accuracy from drawing tolerance: a perfect nominal model still needs tolerances the process can hold, and that is a conversation with the manufacturing or process engineer.

Follow-up

• A dimension change makes your model fail to regenerate. How do you trace the broken reference?
• How do you control revisions of a drawing that has already been released to manufacturing?
• How do you decide which dimensions on a 2D drawing need tight tolerances?

Describe a time you had to meet a tight deadline under the supervision of a manager. How did you prioritize yo

Medium · Problem-Solving and Adaptability

Describe a time you had to meet a tight deadline under the supervision of a manager. How did you prioritize your tasks?

Approach

1. Use STAR, keep the situation short, and choose a real deadline with a manager involved: a drawing package due for a build, a data report for a review, or a co-op project handoff.
2. Show the prioritisation method: list every task, mark the dependencies (what blocks someone else), separate what must ship from what can follow, and estimate each item. Then confirm the order with your manager instead of guessing what mattered most.
3. Say what you traded away and why, for example releasing the critical drawings first and the reference drawings a day later, and how you told the people affected.
4. Give a measurable result, such as on time with zero rework or one day late on a non-critical item, plus what you would plan differently next time. Do not tell a story where the only plan was working late, or one that blames the manager for the deadline.

Follow-up

• What did you deliberately leave unfinished, and how did you decide?
• What would you have done if your manager had ranked the tasks differently from you?
• How do you report progress to a manager during a deadline crunch?

How do you handle situations where you receive conflicting instructions regarding a project requirement?

Medium · Problem-Solving and Adaptability

Approach

1. Make the conflict concrete: two engineers asking for different tolerances, a drawing that disagrees with a spec, or a manager's verbal instruction that contradicts a written requirement.
2. State the principle: you do not pick one side quietly. Find which source has authority (the released drawing revision, the controlling specification, an approved change order), take the conflict to both people with that evidence, and if they still disagree, escalate to the person who owns the decision.
3. Get the decision in writing, update the affected model, drawing or instruction under revision control, and tell everyone working from the old version.
4. Show that the work kept moving: continue on the parts the conflict does not touch while the decision is pending. The answer fails if you guessed and built to the wrong version, or if you stalled without escalating.

Follow-up

• What if both people giving you instructions are senior to you?
• What would you do if the decision came back after you had already finished work to the other version?
• How do you record a decision like this so nobody repeats the argument in six months?

Give an example of a time you identified an error in a technical document or model. How did you resolve it?

Medium · Problem-Solving and Adaptability

Approach

1. Use STAR, and start with how you found the error: cross-checking a drawing against the model, a BOM quantity that did not reconcile, a dimension that failed a tolerance stack, or a step in an instruction that could not be done in the order written.
2. Show that you verified before raising it: re-measured, checked the latest revision, and confirmed it was not your misreading. Then assess the impact. What had already been released, ordered or built from the wrong version?
3. Describe the fix through the proper channel: tell the document owner, correct it as a new revision with a change log entry rather than a silent edit, and notify everyone using the document.
4. Close the loop: check related documents for the same mistake and add a check (a checklist line, a review step, a formula that flags mismatches) so it is caught next time. The answer sinks if it blames the author or if the correction leaves no record.

Follow-up

• How did you confirm it really was an error and not a misunderstanding on your part?
• Had anything already been built or ordered from the wrong version, and what happened to it?
• What did you change so this kind of error gets caught earlier?

Why are you interested in applying your software skills to the rail and manufacturing industry?

Medium · Behavioral and Culture Fit

Approach

1. Anchor the answer in your own history: a course, capstone, co-op or project where software or data led directly to a physical part, a line change or a fixed defect, and what you liked about seeing that result.
2. Show that you researched the company: name the Amsted Rail products and the parts of the rail industry you read about, and connect them to the work candidates report for the role (Creo models and drawings, Excel analysis, work instructions).
3. Address the setting directly: you know the job means working with mechanical and process engineers and spending time in manufacturing environments, and you want that. A generic "I like technology" answer, or one that sounds like a fallback from a software-company search, works against you.
4. Finish with what you want to learn there in the next year or two, for example deeper Creo skills or how a manufacturing process is validated.

Follow-up

• What do you know about Amsted Rail's products, and which one interests you most?
• How do you feel about regular time on a factory floor?
• Where do you see this role taking you in a few years?

Describe your experience working with cross-functional teams, such as mechanical or process engineers.

Medium · Behavioral and Culture Fit

Approach

1. Pick a project with mechanical or process engineers (a capstone team, a co-op, a design-build competition) and be clear about which part was yours.
2. Show translation in both directions: learning their vocabulary (tolerances, cycle time, fixtures, process capability), turning their requirement into a model, spreadsheet or instruction, and explaining your tool's limits in terms they use.
3. Include one point of friction, such as a misunderstood requirement or a design the process could not make, and how you resolved it with evidence: a prototype, a measurement, data.
4. Give the result and what you do differently now, for example confirming requirements with a marked-up drawing before modelling.

Follow-up

• Tell me about a time you and an engineer misunderstood each other. What caused it?
• How do you explain a software or data limitation to someone who does not work in software?
• How do you get feedback from the floor on something you produced?

How do you ensure that your work remains transparent and accessible to those who need to review or implement i

Medium · Behavioral and Culture Fit

How do you ensure that your work remains transparent and accessible to those who need to review or implement it?

Approach

1. Answer with concrete practices, not values. Files go in a shared, controlled location with a naming convention, never on a personal drive. Documents carry a revision history and change log. Releases go through review and approval.
2. For spreadsheets: a notes tab listing sources, assumptions and the sheet map; input cells kept apart from formulas and colour-coded; key formulas locked; no hard-coded numbers buried in formulas.
3. For CAD: meaningful feature and parameter names in the model tree, relations commented, and drawings that state the model revision they came from. For work instructions: a PDF of the released revision where the floor can reach it.
4. Back it with an example where someone picked up your work without you, or a reviewer caught an issue because your work was easy to check, and say what that showed.

Follow-up

• If you were away for two weeks, how would a colleague pick up your current work?
• Walk me through how you version-control your technical documents.
• How do you make a complex spreadsheet reviewable by someone who did not build it?