A. Duie Pyle Software Engineer Interview Guide

The 60-second brief

A. Duie Pyle is described by candidates as a family-owned freight and transportation company that has operated in the Northeast since 1924. Its business includes Less-Than-Truckload (LTL) service centers and warehouse facilities, and the software role sits in the Information Technology group that supports them. Candidates describe the work as developing and maintaining Java applications that track shipments and support warehouse operations, covering analysis, design, development, testing and implementation. New hires are reported to go through a structured training period on the company's own architectures before taking on independent project work.

This guide is for candidates interviewing for a Software Engineer position at A. Duie Pyle, including the entry-level Java developer posting that candidates mention. It covers the three reported rounds, the Java, relational database, version control and CI/CD material candidates describe, the behavioral and situational questions reported for the role, and a seven-day plan that turns all of it into practice.

Candidates report three rounds over roughly 3-5 weeks: an Initial Screening with Human Resources, a Technical Screen with a senior engineer or IT manager, and a Final Panel Interview with members of the Information Technology group that mixes technical depth with behavioral questions.

Focus areas

• Java
• Version Control (VCS)
• Application Development

Overview

The work candidates describe is enterprise application development rather than product experimentation: Java applications that follow shipments and support warehouse operations, built and changed through the full software lifecycle. The day-to-day tasks reported include reading project specifications and asking about gaps before coding, writing documented and extensible code, moving changes through test environments into production, improving CI/CD workflows, and taking part in an off-hours support rotation with other developers. Candidates describe the technical questions as practical and experience-based rather than puzzle-style, so the best preparation is a set of concrete examples from your own projects, each with a decision, a trade-off and a result.

The stack candidates list is specific. Java is the main language. The relational databases named are MariaDB, MySQL and Postgres. Version control is Git and Subversion. The CI/CD tools named are TeamCity, Jenkins and Bamboo, and the code review tools named are UpSource, Collaborator and Crucible; the CI/CD and review tools are described as nice to have rather than required. You do not need to have used every product. Know one tool in each category well enough to describe a real pipeline or review, and know the vocabulary of the others so a question about Jenkins or TeamCity does not stall your answer.

The reported questions fall into three groups. The Java and fundamentals group covers a design pattern you used, keeping Java code extensible, Git versus Subversion with merge conflicts, and tuning a slow SQL query. The process group covers the role of CI/CD tools, handling critical code review feedback, and what to do with a vague specification. The behavioral group covers balancing urgent demands, troubleshooting under pressure for the off-hours rotation, explaining a technical problem to a business user, and why logistics. Candidates also report that logistics knowledge is not strictly required but helps, so spend an hour learning what LTL freight is and how a shipment moves through service centers and warehouses.

The A. Duie Pyle interview process

These are the three stages candidates describe, in the order they report them. Rounds are given by role of interviewer and topic area only, so prepare each topic area broadly rather than aiming at specific questions.

Initial Screening

Candidates report that the first stage is a conversation with Human Resources that checks your background, your degree and whether your technical level fits the role. The requirements candidates describe include an undergraduate degree in Computer Science or a related field, solid Java development experience, and working knowledge of relational databases and version control. Treat this stage as the place to show your experience maps onto that list, in plain language and without jargon, and to leave a clear impression of why logistics interests you.

What to demonstrate

• Whether your degree and work history match the requirements candidates describe for the role
• Baseline fit with the Java, relational database and version control stack
• Clear, concise communication about your own experience

How to prepare

• Write a short career walkthrough that names your Java projects, the databases behind them (MySQL, Postgres or MariaDB if you have used them) and the version control system you worked in.
• Write two sentences on why you want logistics and supply chain work, using facts you can state about LTL freight and warehouse operations.
• Prepare a question or two about the off-hours support rotation and the training period, since candidates report both as part of the role.

Technical Screen

Candidates report a technical conversation with a senior engineer or IT manager that focuses on Java, database concepts and version control. This is the stage where your fundamentals are checked, so expect to explain things aloud: object-oriented ideas in Java, how you write and tune SQL against MySQL, MariaDB or Postgres, and how you branch, merge and resolve conflicts in Git or Subversion. Answer with examples from real work, and when you state a rule of thumb, give the case where it fails.

What to demonstrate

• Working knowledge of Java and object-oriented design
• Relational database concepts, including SQL, joins and indexing
• Version control practice: branching and merge conflict handling

How to prepare

• Rehearse the object-oriented basics (inheritance, polymorphism, encapsulation, abstraction) with one shipment-style class model you can sketch from memory.
• Practise the slow-query routine: run EXPLAIN, read the plan, check whether an index is usable, rewrite, and measure again. Do it once on Postgres and once on MySQL.
• Set up a throwaway Git repository, create a merge conflict on purpose, resolve it, and write down the Subversion equivalent of each step.

Final Panel Interview

Candidates report an onsite or virtual panel with several members of the Information Technology group, combining technical deep-dives such as design patterns and architecture with behavioral questions. Because several people are in the conversation, expect to move between topics: a design discussion, how you handle code review and CI/CD, and stories about pressure and communication. Prepare a small set of well-rehearsed stories that can answer more than one question, plus one design example you can draw and defend.

What to demonstrate

• Depth in design patterns and application architecture, as reported for the panel
• Ability to work across a group of colleagues in the same department
• Behavioral and situational judgement, including pressure and ambiguity

How to prepare

• Choose one design pattern you have really used, and write out the problem, the alternative you rejected and the cost of the pattern.
• Prepare a CI/CD story and a code review story that include your own part, the tools you used and what changed afterwards.
• Rehearse the stories for urgent competing demands, the off-hours incident, and explaining a technical problem to a business user, each in a clear sequence with the outcome stated.

Where candidates lose points

Defining design patterns from memory with no project behind them

Pick one pattern you have really used (Factory, Observer or Singleton are the ones candidates mention) and tell it as problem, alternative, choice and cost. Be ready to say where a Singleton hurts, such as shared state and hard-to-test code.

Answering the Git versus Subversion question as a list of commands

Start with centralized versus distributed, then tell one real merge conflict: how you read both sides, what you checked, how you verified the result. Know the Subversion equivalents, including tree conflicts.

Saying "add an index" for a slow SQL query

Describe the sequence: EXPLAIN first, read the plan, check why an index is unused (a function on the column, a leading wildcard, a type mismatch, low selectivity), rewrite, then measure again. Mention MySQL, MariaDB and Postgres differences only where you have seen them.

Starting to design or code before clarifying a vague specification

Practise stating your questions first: inputs and their formats, status transitions and exceptions, volumes, who consumes the output, and what done means. Logistics data is full of exceptions, so ask about them explicitly.

Telling the off-hours support story as a solo hero with no follow-up

Tell it in order: impact, stabilize, diagnose, communicate, escalate, verify, then the change you made afterwards. Show calm and method, and say when you asked for help.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

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

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

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?

Describe your experience with relational databases. How would you optimize a slow-running SQL query in Postgre

Medium · Java and Technical Fundamentals

Describe your experience with relational databases. How would you optimize a slow-running SQL query in Postgres or MySQL?

Approach

1. Measure before changing anything. Capture the exact statement and its parameter values, then run EXPLAIN (ANALYZE, BUFFERS) in Postgres or EXPLAIN ANALYZE in MySQL 8.0.18+. Look for sequential scans on large tables, row estimates far off the actual counts, nested loops over a large outer input, and sorts spilling to disk.
2. Fix the access path with indexes. Use a B-tree on the filter and join columns. In a composite index, put equality columns before the range column, e.g. (status, created_at) for WHERE status = ? AND created_at > ?. Use a covering index (INCLUDE in Postgres, or InnoDB secondary indexes, which carry the primary key) to allow index-only reads.
3. Know what makes an index unusable: a function wrapped around the column (DATE(created_at) = ?), a leading-wildcard LIKE '%x', an implicit type cast, or a predicate that matches most rows. Rewrite the condition as a range, or add an expression index (Postgres) or a functional key part (MySQL 8.0.13+).
4. Rewrite the query and fix the calling code. Select only the columns you need. Replace correlated subqueries with joins or EXISTS. Use keyset pagination instead of a large OFFSET. Look for N+1 queries from the Java side (ORM lazy loading) and batch them into one join or IN list.
5. Check the environment and the trade-off. Make sure statistics are fresh (ANALYZE in Postgres, ANALYZE TABLE in MySQL and MariaDB), and look for lock waits and bloat. Find the worst offenders with pg_stat_statements or the MySQL slow query log. Every index slows writes and takes space, so confirm the gain on production-sized data.

Follow-up

• Why might Postgres choose a sequential scan even though a matching index exists?
• How would you find which query is slow in the first place when the symptom is a slow screen in a Java application?
• What does adding this index cost on a table with heavy insert traffic?

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?

Explain a design pattern you have used recently. What problem did it solve, and what were the trade-offs?

Medium · Java and Technical Fundamentals

Approach

1. Pick one pattern you actually shipped and name it precisely. Strategy is a good example: a growing switch over order or record types becomes an interface with one implementation per variant, chosen through a Map<Type, Strategy> or dependency injection.
2. Describe the problem before the pattern: what was being edited in every release, which tests broke together, or which bug kept coming back. Then say what changed afterwards, for example that adding a variant became a new class plus a test, with no edits to existing code (the open/closed principle).
3. State the costs honestly: more classes and indirection, a call path that is harder to follow in a debugger, and abstraction that is wasted when there are only two variants that never change. Say what would make you go back to a plain switch or an enum with abstract methods.
4. Contrast it with nearby patterns so it is clear you know the difference. A Factory decides which object to create. Observer decouples publishers from subscribers but hides ordering and error handling. Singleton is global state that is hard to mock, so I prefer a container-managed single instance that I inject.
5. Cover the Java details: keep strategies stateless so one instance can be shared across threads safely. If a Singleton comes up, use the enum or holder-class idiom, or double-checked locking with a volatile field.

Follow-up

• Why not just use a switch statement or an enum with a method per constant?
• How would you make a Singleton thread-safe in Java, and why might you avoid one altogether?
• Which pattern have you seen overused, and what did it cost the team?

How do you ensure your Java code is extensible and easy for another developer to maintain?

Medium · Java and Technical Fundamentals

Approach

1. Start from structure. Small classes with one responsibility, code written against interfaces, constructor injection so dependencies are explicit and replaceable, private final fields, and immutable value objects (records on Java 16+). Prefer composition over inheritance so a change in a base class cannot quietly break its subclasses.
2. Put extension points only where requirements have actually varied, and say why. Adding interfaces everywhere because of the open/closed principle makes code harder to read, so YAGNI is the counterweight.
3. Treat tests as part of maintainability. JUnit unit tests at the seams (with Mockito for collaborators) document intended behaviour and make refactoring safe. Before changing untested legacy code, I write characterization tests that pin its current behaviour.
4. Make the rules mechanical: one formatter, static analysis such as Checkstyle, SpotBugs or SonarQube run in CI, and code review against an agreed standard. That way style is not argued about in every review.
5. Make the contract readable: intention-revealing names, Javadoc on public APIs that explains why rather than what, Optional instead of null for absent return values, no swallowed exceptions, and a README or decision record for anything non-obvious.

Follow-up

• When does adding an interface or abstraction make code harder to maintain?
• How would you safely refactor a very large class that has no tests?
• Give an example where inheritance caused a problem that composition would have avoided.

Explain the role of CI/CD tools in a modern development environment. How have you used Jenkins or TeamCity in

Medium · SDLC and Process

Explain the role of CI/CD tools in a modern development environment. How have you used Jenkins or TeamCity in the past?

Approach

1. Define the terms precisely. Continuous integration means every push to a shared branch is built and tested automatically: compile, unit tests, static analysis, package. Continuous delivery keeps every build deployable, with production release behind an approval step. Continuous deployment releases to production automatically with no manual gate.
2. Walk through a real pipeline stage by stage. In Jenkins, that is a declarative Jenkinsfile kept in the repository (checkout, mvn verify or gradle build, test results published with the junit step, artifact stored in a repository, deploy to a test environment, gated promotion). In TeamCity, it is build configurations triggered by VCS changes and chained with snapshot and artifact dependencies.
3. State the principles behind it: build the artifact once and promote that same artifact through every environment, keep pipeline definitions in version control, keep secrets in the credential store rather than in the repo, and order stages so the fastest tests fail first.
4. Cover the hard parts of deployment: database migrations run in the pipeline (Flyway or Liquibase) with backward-compatible changes so old and new code can both run, a rollback that redeploys the previous artifact, and feature flags to separate deploying from releasing.
5. Close with one change you made yourself and its measured effect, such as a shorter build time or a class of bug caught earlier. If you have used a different CI tool, map it honestly to the same concepts instead of claiming Jenkins or TeamCity experience you do not have.

Follow-up

• What is the difference between continuous delivery and continuous deployment, and when would you choose each?
• A build passes on your machine but fails on the CI agent. How do you work out why?
• How do you ship a database schema change through an automated pipeline without downtime?

If you are handed a project specification that is vague or missing key details, what steps do you take before

Medium · SDLC and Process

If you are handed a project specification that is vague or missing key details, what steps do you take before you begin coding?

Approach

1. Read the whole specification first, then write out the open questions by area: inputs and data sources, expected outputs, business rules, error and edge cases (missing fields, duplicates, late or out-of-order records), volume and performance needs, who uses the result, and how acceptance will be judged.
2. Find the person who owns each decision and ask concrete questions that offer options, e.g. 'when two records conflict, should the latest one win or should both be flagged for review?'. Options get faster and clearer answers than open-ended questions.
3. Restate what I understood in writing, as acceptance criteria or given/when/then examples, and get it confirmed. Where an answer is not available, record the assumption and put it in configuration or behind a clear seam so it is cheap to change later.
4. Investigate before building: read the existing data model and current behaviour, look for a similar feature already in the codebase, and run a short spike on any technical unknown. Then give an estimate as a range tied to the questions that are still open.
5. Start on the parts that are clear so nothing stalls, and report early to my lead when a missing answer threatens the schedule. That beats waiting quietly or guessing on a rule that affects customer data.

Follow-up

• What do you do if the stakeholder is unavailable and the deadline does not move?
• How do you handle a requirement that changes after you have already started coding?
• Give an example of a missing detail you caught early that would otherwise have shipped as a defect.

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

The seven days follow the reported loop: orientation and the logistics context first, then Java, SQL, version control, delivery process and behavioral stories, and a full spoken rehearsal on the last day.

Day 1 — Map the loop and the business

• Write the three reported stages in order (Initial Screening, Technical Screen, Final Panel Interview) with the topic each covers and the one you feel weakest on.
• Write a one-page explanation of LTL freight, service centers and warehouse flow in your own words, then write a spoken answer to why you want logistics at A. Duie Pyle.
• List where your experience meets each reported requirement: Java, MySQL, MariaDB or Postgres, Git or Subversion, and CI/CD and review tools.

Deliverable: A one-page loop map, a one-page LTL explainer, and a written answer to the logistics question.

Day 2 — Java design and maintainability

• Write a short Java example of Factory and of Observer for a shipment-status feature, and note where each helps and where it adds needless indirection.
• Take a long method from your own code or a sample project, split it into small named classes with interfaces, and list the changes that this makes cheaper.
• Say your answer aloud to how you keep Java code extensible and easy to maintain, and to the design pattern you have used recently, using these examples.

Deliverable: Two pattern examples in Java, one before-and-after refactor, and spoken answers to both design questions.

Day 3 — Relational databases and slow queries

• Create a shipments table with a few hundred thousand rows in Postgres and in MySQL, run a query filtered by status and pickup date, and save the EXPLAIN output before and after adding a composite index.
• Find three ways an index becomes unusable (function on the column, leading wildcard, type mismatch) and reproduce at least one.

Deliverable: Two saved EXPLAIN comparisons, one reproduced unusable-index case, and a working transactional JDBC snippet.

Day 4 — Git, Subversion and merge conflicts

• Make a local Git repository, create two branches that edit the same lines, merge them, and resolve the conflict. Repeat with a rename on one side and an edit on the other.
• Create a local Subversion repository with svnadmin create, check out a working copy, produce a conflict, and resolve it with svn resolve.
• Write a comparison table of Git and Subversion covering history, branching, tags, locking and offline work, then say the Git versus Subversion answer aloud.

Deliverable: Two resolved conflicts (one Git, one Subversion), a comparison table, and a spoken answer that includes a conflict story.

Day 5 — Delivery process: CI/CD, code review and vague specs

• Outline a pipeline for a Java service with stages for build, unit tests, packaging, deploy to a test environment and promotion, then map each stage to a Jenkins job, a TeamCity build configuration or a Bamboo plan.
• Write a checklist of questions to ask about a vague specification: inputs, exceptions, volumes, consumers, and acceptance.
• Write the code review feedback story with the comment, your reaction, the fix, and the habit you changed.

Deliverable: A pipeline outline, a specification checklist, and a written review story.

Day 6 — Pressure, priorities and support

• Write the urgent-demands story: list the demands, the criteria you ranked them by, the communication, and what slipped.
• Write the off-hours incident story in the order impact, stabilize, diagnose, communicate, verify, follow up.

Deliverable: Two written stories and a recorded debugging walkthrough.

Day 7 — Full panel rehearsal

• Run a mixed rehearsal of a design pattern answer, a slow-query answer, a Git conflict answer, the incident story and the logistics answer, in that order, speaking aloud.
• Prepare a spoken explanation of a technical problem for a non-technical stakeholder, using an analogy from freight or warehouse work.
• List the weak answers from the rehearsal and rewrite the two weakest, then write three questions to ask the panel about the training period, the support rotation and the development process.

Deliverable: A recorded rehearsal, two rewritten answers, and a list of three questions for the panel.

Pressure, support and communication stories

Candidates report that behavioral and situational questions sit alongside the technical ones, particularly in the final panel. The reported prompts centre on working under pressure, the off-hours support rotation, communicating with business users, and the reasons for choosing logistics. Build stories where you made the decisions, name the trade-offs and state the outcome.

Walk me through the differences between Git and Subversion. How do you handle a complex merge conflict?

Medium · Java and Technical Fundamentals

Approach

1. Open with the model difference. Git is distributed: every clone holds full history, and you commit, branch and diff locally before pushing. Subversion is centralized: a commit goes straight to the server and raises one repository-wide revision number. That explains most of the day-to-day differences.
2. Cover branching. In Git a branch is a cheap pointer and merges use the commit history. In Subversion a branch or tag is a directory copy inside the repository, and merge tracking was added later through the svn:mergeinfo property. Mention Git's staging area and that Subversion supports file locking, which helps with binary files.
3. Walk a real conflict in order. Run git status to list conflicted files, read both sides of the markers, check each branch's intent with git log and a diff against the merge base, and edit the file to a result that keeps both intents. Rebuild, run the tests, then commit. If the picture is unclear, run git merge --abort and ask the other author before touching the file.
4. Add the Subversion version: svn update reports the conflict, you edit the file, mark it with svn resolve, and tree conflicts such as a rename against an edit need a decision on which side wins.
5. Name the edge cases: binary files, a file renamed on one branch and edited on the other, and a resolution that compiles but silently drops one side's change. Say how you guard against that, for example by running tests and asking the other author to review the merge.

Follow-up

• When would you rebase instead of merge, and what rule do you follow on shared branches?
• How would you migrate a Subversion repository with branches and tags to Git?
• How do you stop long-lived branches from producing painful merges?

Tell me about a time you received critical feedback during a code review. How did you handle it?

Medium · SDLC and Process

Approach

1. Pick a substantive comment, not a style nit: a missing null or error path, a query inside a loop, a method doing three jobs, or no test for the failure case. State the comment in one sentence so the listener can judge how serious it was.
2. Show how you reacted in steps. You checked whether the reviewer was right by reproducing the problem or reading the code again, asked a question if the point was unclear, and replied in the review thread instead of going quiet or quietly rewriting.
3. State what changed: the code fix, plus anything that outlasted the pull request, such as a new unit test, a checklist item or a team convention. If you have used a review tool such as UpSource, Collaborator or Crucible, say so; otherwise name the one you used.
4. If you disagreed with part of the comment, show how you settled it with evidence (a measurement, a requirement, a standard) and who made the final call. A story where the reviewer was wrong and you won sounds defensive; a story where you checked and adjusted sounds like ownership.
5. End with a habit that changed, for example a self-review pass before requesting review. The story fails if the reviewer is the villain or if the only lesson is that you accepted every comment.

Follow-up

• Tell me about a time you disagreed with a review comment and kept your approach.
• How do you give critical feedback on someone else's change?
• What do you check yourself before you ask for a review?

Describe a time when you had to balance multiple urgent demands simultaneously. How did you prioritize your wo

Medium · Behavioral and Situational

Describe a time when you had to balance multiple urgent demands simultaneously. How did you prioritize your work?

Approach

1. Choose a story with real simultaneous demands from different people, for example a production defect, a release deadline and a request from a business user. List each demand with who was affected and by when, in a sentence apiece.
2. Name the criteria you used to rank them: operational or customer impact, how fixed the deadline was, whether other people were blocked, whether the work could be paused safely with a rollback or workaround, and how large the effort was.
3. Show the communication. You told each requester what you would do first and when they would hear next, and when the priorities truly conflicted you asked your manager to rank them instead of choosing silently.
4. State the cost honestly: what slipped, who knew in advance, and the outcome. Add the tracking method you used, such as a short list or a board, so the story shows a repeatable habit and not a one-off scramble.

Follow-up

• Two managers both say their request comes first. What do you do?
• What did you deliberately not do, and who knew?
• How do you protect planned work when interruptions keep arriving?

As part of this role, you will be on an off-hours support rotation. Tell me about a time you had to troublesho

Medium · Behavioral and Situational

As part of this role, you will be on an off-hours support rotation. Tell me about a time you had to troubleshoot a critical issue under high pressure.

Approach

1. Set the scene briefly: the system, what broke, the time of day, who was affected, and how you were alerted. The prompt is about an off-hours rotation, so make clear you were responding away from normal working conditions.
2. Order the response as a sequence: assess impact and severity, stabilize before you diagnose (roll back a release, restart a stuck job, disable a feature, fail over), and only then look for the root cause.
3. Show the diagnosis. Check what changed recently (deploys, configuration, data volume), read the logs and error rates, inspect the database state, and test one hypothesis at a time so you never change several things at once.
4. Show communication and escalation: status updates to the affected users or business owners, and the point at which you brought in a colleague instead of struggling alone.
5. Finish with verification and follow-up: how you confirmed the fix held, the written summary of the incident, and the alert, test or runbook step you added so the next person on call is faster. Use a calm tone and facts, not heroics.

Follow-up

• At what point do you wake someone else up?
• How did you confirm the fix held before you stopped watching it?
• What would you change in monitoring or documentation after that incident?

How do you explain a complex technical problem to a non-technical stakeholder or business user?

Medium · Behavioral and Situational

Approach

1. Start from the listener's decision, not the mechanism: what happened, what it changes in their work, and what you need from them, such as approving downtime, choosing an option or accepting a delay.
2. Use an analogy from their world rather than software. For a slow lookup, an unsorted stack of freight bills against an indexed filing cabinet makes the point without any database vocabulary.
3. Offer two or three options with plain trade-offs in time, risk and cost, and give a recommendation. Define any acronym once, or avoid it.
4. Check understanding by asking the person to say what they will do next, then confirm the decision in writing. Bring a real example where your explanation changed an outcome, and one where your first attempt failed and you adjusted.

Follow-up

• The stakeholder insists on a deadline you think is unrealistic. What do you say?
• How do you decide how much technical detail to include?
• Tell me about a time your explanation did not land.

Why are you interested in working in the logistics and supply chain industry, specifically at A. Duie Pyle?

Medium · Behavioral and Situational

Approach

1. Build the answer from three parts: what you know about the business, why that appeals to you, and how your skills apply. Facts you can check publicly include that it is a family-owned freight and transportation company in the Northeast, operating since 1924, with LTL service centers and warehouse facilities.
2. Know what LTL means: shipments too small to fill a trailer are combined with other customers' freight and moved through service centers. Then connect it to software: tracking a shipment across handoffs, and handling exceptions such as damaged, delayed or rerouted freight.
3. Link it to the work candidates describe: Java applications that track shipments and support warehouse operations, long-lived enterprise systems, and an off-hours support rotation. Say which part you want and back it with an example from your history where software had a visible operational result.
4. If logistics is new to you, say so plainly and show what you have already learned. Avoid generic flattery and do not claim knowledge of internal systems you cannot have seen.

Follow-up

• What does LTL mean, and what could go wrong with a shipment in that kind of network?
• Which parts of your background transfer to shipment tracking and warehouse software?
• What would you want to learn first about the operations in your first months?