Interview guides · Applied Research Associates

Applied Research Associates Software Engineer Interview Guide

Applied Research Associates Software Engineer interview guide: phone screen, technical evaluations, project presentation, C++ and OOP questions, 7-day plan.

The 60-second brief

Applied Research Associates (ARA) is a research and engineering firm. Candidates describe its project work as spanning defense, security and transportation, from simulations to infrastructure modeling. Software engineers are reported to sit in teams with scientists and engineers, writing code that analyzes data, models physical phenomena and runs as operational software. Candidates mention modern C++ simulations as well as maintenance of older systems, and C++ is the language most often named for the role, with C#, Python and MATLAB listed as useful on some teams.

This guide is for candidates applying to ARA as a Software Engineer, from new graduates to experienced hires. It covers the three reported rounds (Phone Screening, Technical Evaluations, Technical Presentation), the behavioral and technical questions candidates report, and a seven-day plan that spends most of its time on C++ and Java memory, object-oriented design, complexity, SQL joins, debugging, and the project you will present.

Candidates report three rounds spread over about 3-5 weeks: Phone Screening, Technical Evaluations and Technical Presentation. The pace is reported to vary with project urgency and location.

Focus areas

OOP (Object-Oriented Programming) concepts
Inheritance and polymorphism
Modern C++ features

Overview

The reported questions cluster around fundamentals rather than puzzles. Expect to explain smart pointers and what people mean by modern C++, the basic ideas of object-oriented programming, stack versus heap (including which one Java uses), when an O(n^2) approach can be a reasonable choice over O(log n), the difference between inner and outer joins, and which design patterns you know. Candidates also describe the Rule of 3/5 and comparisons between data structures such as a hash set and a tree-based set. Prepare each of these as a short spoken explanation with a concrete code example, because a definition alone does not show you can use the idea.

The work described for the role is software that serves scientists and engineers: simulations, data analysis and models of physical systems, plus maintenance of older code. That makes C++ ownership and lifetime, resource management and readable, documented code the most useful things to practise. If you have used C++14 or C++17 recently, pick one feature you can describe precisely (what it replaced, what it changed in your code), since a question asks for exactly that.

Two parts of the loop reward preparation you can do entirely on your own. The Technical Presentation asks you to take a panel through a previous project and defend your design choices, and the behavioral questions (a problem you solved, a project you care about, a conflict, asking for help when stuck, and any concerns about defense work) are all about your own history. Choose your presentation project early, because the same project can anchor several of those answers.

Candidates also describe debugging and logic problems solved on a shared screen or whiteboard without an IDE, including writing pseudo-code for something like a Fibonacci sequence. Practise reading short C++ and Java snippets on paper, saying what each line does, and naming the bug before you fix it.

The Applied Research Associates interview process

These are the three stages candidates describe, in the order they report them. Teams and locations differ, so confirm the exact format with your recruiter.

Phone Screening

Candidates report this as an initial screening call to check fit for the role. Little else is reported about its format, so treat it as a conversation about your background: the resume and college or work projects, why this kind of research-and-engineering work interests you, and the basics of the languages you list. Walk in with a short project pitch you can extend if asked, and keep C++ and OOP fundamentals fresh in case the conversation turns technical.

What to demonstrate

How clearly you summarize your background and projects
Fit for the role as candidates describe the screen
Basic command of the languages on your resume

How to prepare

Write and rehearse a two-minute summary of your resume that ends on the one project you would present to a panel.
Prepare a plain answer to the question about explaining your resume and your college projects, with one technical detail per project.
Review one-sentence answers on OOP, stack versus heap and smart pointers in case the call includes quick fundamentals.
Prepare questions to ask the recruiter about the next rounds and about which language the team uses.

Technical Evaluations

Candidates describe this stage as in-depth technical assessments that include coding challenges and evaluations. Reports of the loop's evaluation areas mention language internals, memory management, OOP principles, algorithm complexity, data-structure trade-offs, reading code for logic errors, writing pseudo-code and whiteboarding math or logic problems. Some candidates also report a take-home or live coding assessment depending on the role. Practise explaining while you write, and be ready to work without an IDE.

What to demonstrate

Working code and correct reasoning in coding challenges
Knowledge of memory management, OOP and complexity
Ability to find and explain logic errors in provided code
Pseudo-code that shows the algorithm independent of syntax

How to prepare

Drill the C++ memory topics: smart pointers, ownership, the Rule of 3/5, and stack versus heap, including what Java does differently.
Practise explaining the OOP basics (inheritance, polymorphism, encapsulation, abstraction) with a small class hierarchy you write yourself.
Compare a hash set with a tree-based set on lookup cost, ordering and memory, and be able to say when each fits.
Do timed paper exercises: write Fibonacci in pseudo-code and discuss its complexity, and sketch inner and outer joins on a whiteboard.

Technical Presentation

Candidates report that you present a previous project to a panel, showing technical depth and how you communicate. Reports describe slides with graphs and architecture, followed by questions in which you defend your design choices. Pick a project where your own contribution is clear, and structure the talk as problem, design, the obstacle you hit and how you got past it, and the outcome. Expect to explain why you chose your languages and frameworks and to know how any technology you name works underneath.

What to demonstrate

Ownership of a technical solution from concept to implementation
Communication of complex work to a panel
Justification of design and technology choices when questioned

How to prepare

Build a short deck with a problem statement, an architecture diagram, one or two graphs of results, and a slide on the biggest obstacle.
List every technology on your slides and write two sentences on how each works under the hood and why you chose it.
Rehearse the talk aloud for a colleague and collect the hardest questions about your design choices, then write answers.
Prepare an honest answer to the question about concerns working on defense or high-stakes technology, since it is a reported question.

Where candidates lose points

Presenting a project as 'we did' without saying what you built

Mark on each slide what you personally designed, wrote or debugged. Prepare to explain your own module in detail, since the panel Q&A is about defending your design choices.

Naming a technology on your slides or resume that you cannot explain internally

For each language, framework or library you list, write two sentences on how it works under the hood (for C++, ownership and lifetime; for Java, where objects and references live) and why you chose it.

Giving textbook definitions of OOP, smart pointers or stack versus heap with no example

Attach a short code sketch to each answer: a base class with a virtual function for polymorphism, a unique_ptr transferring ownership, a local variable versus a new allocation. Then state a trade-off.

Going quiet when asked to debug or solve a problem without an IDE

Practise narrating on paper: say what each line does, state the invariant you expect, name the bug, then fix it. For pseudo-code tasks like Fibonacci, state the base cases and complexity first.

Giving a rehearsed or evasive answer to the question about defense and high-stakes work

Decide your honest position beforehand and be ready to explain it in a few sentences, including what you would want to know about a project's purpose. Do not claim facts about ARA you cannot support.

Questions & practice

What are smart pointers, and what is modern C++?

Medium · Technical Fundamentals and OOP

Approach

Define a smart pointer as an RAII object that owns a heap allocation and frees it in its destructor, so cleanup happens on every exit path, including exceptions, without a manual delete.
std::unique_ptr: sole ownership, move-only (copying does not compile), and with the default deleter it is the size of a raw pointer. Create it with std::make_unique (C++14) and hand ownership on with std::move.
std::shared_ptr: shared ownership through a control block holding a reference count that is updated atomically. The count is thread-safe; the pointed-to object is not. std::make_shared puts the object and control block in one allocation. std::weak_ptr observes without owning, and lock() returns an empty shared_ptr once the object is gone.
Call modern C++ the C++11-and-later style: move semantics and rvalue references, auto, lambdas, range-for, nullptr, constexpr, then C++14 make_unique and generic lambdas, and C++17 std::optional, std::variant, std::string_view and structured bindings. In practice it means the rule of zero: owning members are smart pointers or containers, so the class needs no hand-written destructor.
Name the pitfalls: two shared_ptrs that each point at the other leak because neither count reaches zero (break the cycle with weak_ptr), and building two separate shared_ptrs from one raw pointer deletes it twice. A raw pointer or reference is still fine as a non-owning observer.

Follow-up

When would you pick shared_ptr over unique_ptr, and what does it cost you?
Explain the rule of three and the rule of five, and how smart pointers let you follow the rule of zero instead.
How does weak_ptr break a parent-child reference cycle?

Explain the difference between stack memory and heap memory, and which one Java uses.

Medium · Technical Fundamentals and OOP

Approach

Stack: each thread has its own stack of frames. Locals are allocated when a function is entered and freed automatically when it returns (LIFO), so allocation is a pointer adjustment and the memory stays cache-friendly. The size is limited, so very deep recursion overflows it.
Heap: memory allocated at runtime whose lifetime is not tied to a scope (new/delete or smart pointers in C++, garbage collection in Java). It is shared by all threads, slower to allocate, can fragment, and is where memory leaks and use-after-free bugs come from in C++.
Java uses both. Every thread's stack holds frames with local primitives and object references, and every object and array lives on the heap, which the garbage collector reclaims once the object is unreachable. HotSpot's escape analysis can scalar-replace objects that never escape a method, but the language model is still that objects live on the heap.
Contrast this with C++, where an object can live on the stack and its destructor runs at scope exit (RAII). Mention the classic C++ bug of returning a pointer or reference to a local, which leaves it dangling.
Name the failure modes: StackOverflowError against OutOfMemoryError in Java, and stack overflow against leaks or heap corruption in C++.

Follow-up

In Java, where do a local int and a local reference to a new object live, and what happens to each when the method returns?
How does the garbage collector decide an object can be freed?
Why might you allocate a large buffer on the heap rather than the stack in C++?

In what case would you use an O(n^2) runtime over O(log(n))?

Medium · Technical Fundamentals and OOP

Approach

Start by saying that Big-O describes how cost grows as n grows. It drops constants and lower-order terms, so for small n the asymptotically worse algorithm can be faster in wall-clock time.
Use the standard example: insertion sort is O(n^2) but has tiny constants, works in place, is stable and runs in O(n) on nearly sorted input. That is why common std::sort implementations (introsort) switch to insertion sort for small partitions.
An O(log n) lookup is never free. Binary search needs sorted data and a balanced tree needs to be built, which costs O(n log n). If you query only once or twice, a plain scan is cheaper overall, and a contiguous array scan often beats pointer-chasing in a tree for small n because of cache locality.
Give the other reasons: simpler code that is easier to verify and maintain, lower memory use (O(1) extra space), and worst-case predictability. Then say how you would decide: measure with realistic sizes and find the crossover point instead of guessing.
State the risk: if n can grow, the quadratic choice becomes the bottleneck. Document the assumed input size or add a size check that switches algorithms.

Follow-up

How would you find the input size where the faster asymptotic algorithm starts to win?
Quicksort is O(n^2) in the worst case. Why is it still widely used, and how do implementations guard against that worst case?
What changes if this code runs on a system with strict timing limits?

What is the difference between inner and outer joins in SQL?

Medium · Technical Fundamentals and OOP

Approach

INNER JOIN returns only the row pairs where the join condition matches in both tables. LEFT OUTER JOIN returns every row from the left table, with NULLs in the right table's columns where nothing matches. RIGHT is the mirror image, and FULL OUTER keeps unmatched rows from both sides.
Show it with two small tables, for example employees and departments: an employee with no department disappears from the inner join but appears in the left join with a NULL department name.
Point out the common bug: a WHERE filter on a right-table column, such as WHERE d.name = 'X', removes the NULL rows and quietly turns a left join into an inner join. Put that condition in the ON clause when you want to keep the unmatched rows.
Show an anti-join: LEFT JOIN orders o ON o.customer_id = c.id WHERE o.id IS NULL finds customers with no orders. NOT EXISTS expresses the same thing and is clearer.
Edge cases: NULL keys never match with =, a one-to-many join multiplies rows (which inflates SUMs), COUNT(*) counts an unmatched left row as 1 while COUNT(o.id) counts it as 0, and MySQL has no FULL OUTER JOIN, so you emulate it with a UNION of a left and a right join.

Follow-up

Write a query that lists every customer and their order count, including customers with zero orders.
Why did the row count go up after you added a join, and how would you fix the totals?
What is the difference between putting a filter in the ON clause and putting it in the WHERE clause of a left join?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

What are the basic ideas of Object-Oriented Programming (OOP)?

Medium · Technical Fundamentals and OOP

Approach

Name the four ideas and give each a one-line meaning: encapsulation (state is private and changes only through methods that keep it valid), abstraction (callers depend on an interface, not the implementation), inheritance (a derived class reuses and extends a base), polymorphism (one call resolves to different behaviour depending on the object's type).
Use one running example, such as a Sensor base class with a virtual read() and Radar and Gps subclasses, so that every principle points at the same code.
Separate runtime polymorphism (virtual functions resolved through the vtable when you call through a base pointer or reference) from compile-time polymorphism (overloading and templates). Overriding replaces a virtual function; overloading is a different signature under the same name.
Give the C++ traps: a base class that is deleted through a base pointer needs a virtual destructor, or the behaviour is undefined, and passing a derived object by value as its base slices off the derived part.
Close with the trade-off: inheritance is for true is-a relationships that hold the Liskov substitution principle (the Square-extends-Rectangle example breaks it), and composition is usually the better tool for reusing code.

Follow-up

When would you use composition instead of inheritance? Give an example.
Why does a polymorphic base class need a virtual destructor?
What is the difference between an abstract class and an interface, and how do you express each in C++?

Rebuild the search projection while it serves nine thousand queries

Medium · projections · eventual consistency · rebuild

The read-model service answers about 9k queries/second at a 120 ms p99 from a projection built off the event log, normally under 2 seconds behind. A mapping change forces a full rebuild from resource_revision, during which apply lag rises to minutes. Writes continue at 1.2k/second and events at 4k/second. Design the rebuild: how the new index is populated and cut over, how position is tracked per log partition, what the API returns alongside results so a client can tell a stale answer from a current one, and the criterion for cutting over.

Approach

Build into a second index and swap an alias rather than mutating the live one. The rebuild is then reversible by pointing the alias back, so a bad mapping costs a wasted rebuild instead of an outage. The price is peak storage for two full copies and double apply load during catch-up, and both numbers should be stated up front rather than discovered when disk fills.
Track position per log partition, not globally. Order is guaranteed only within an aggregate's partition, so progress is a vector, and the only number safe to publish is taken from the least advanced partition - the slowest one is what bounds completeness. Publishing the most advanced partition's position declares the projection current while another partition sits twenty minutes behind.
Make apply idempotent so the backfill and the live tail can overlap without a freeze. Each document records the aggregate_version it reflects, and any event at or below that version is discarded. This is why the event carries the full fact and not a delta: a delta cannot be discarded safely, and a consumer that calls back to read current state applies a state newer than the event it is processing, which is how a projection ends up with changes applied out of order.
Turn lag into a contract instead of a surprise. Return the watermark with every result set, and return the version produced by a write so the client can compare the two. A client that wrote version 7 and receives results at a watermark older than its own commit can show that its change is still landing, rather than rendering the previous value as current. Blocking the read until the projection catches up would convert a staleness problem into an availability problem at 9k queries/second, and choosing not to do that is the trade.

Follow-up

The rebuilt index disagrees with the primary tables for 300 documents. Which is authoritative, and how do you decide without freezing writes?
The rebuild doubles load on the log and pushes the projection p99 from 120 ms to 400 ms. What do you throttle, and which signal sets how much?

Do you have previous debugging experience?

Medium · Practical Engineering and Debugging

Approach

Answer with one specific bug rather than a yes. Give the symptom, how you reproduced it, how you narrowed it down, the root cause, the fix, and the test you added so it cannot come back.
Show a repeatable sequence: reproduce it reliably, shrink the input or code to a minimal failing case, form one hypothesis at a time and test it with a breakpoint, an assertion or targeted logging, and use git bisect when you know a good commit and a bad one.
Name the tools for the stack you used. For C++: gdb or a debugger for a backtrace from a crash or core dump, AddressSanitizer or Valgrind for use-after-free and buffer overruns, ThreadSanitizer for data races, and compiler warnings (-Wall -Wextra) as the first pass.
Candidates report being asked to spot errors in code shown on screen, so practise reading snippets for off-by-one loop bounds, uninitialized variables, integer overflow, = written for ==, dangling references and unchecked null pointers, and explain each error aloud as you find it.
Separate the trigger from the cause. A crash that appears only in an optimized build often points to undefined behaviour, such as an uninitialized read or out-of-bounds access, rather than a compiler bug.

Follow-up

How would you debug a crash that happens only in release builds?
How do you approach a bug that shows up only intermittently?
What was the hardest bug you have tracked down, and what would have found it sooner?

Please explain your resume and your college projects.

Medium · Practical Engineering and Debugging

Approach

Prepare a two-minute walk through your resume that names the thread connecting your roles and projects, then be ready to go deep on any single line of it.
For each project you list, rehearse the same structure: the problem, what you personally built, the architecture (components, language, data flow), one design choice and the alternative you rejected, the hardest bug or obstacle, and a result you can back with a number or a demo.
Know every technology on the page well enough to explain how it works underneath. If you list C++, expect to explain memory ownership in your own code. If you list SQL, be able to explain the joins and indexes you relied on.
For team or college projects, separate your contribution from the team's with I statements, and say how you tested your part (unit tests, simulation runs, comparison against known results).

Follow-up

Why did you choose that language or framework for the project?
What would you change if you rebuilt it today?
How did you verify that the results were correct?

Describe a way you have recently used a C++14/17 feature.

Medium · Practical Engineering and Debugging

Approach

Pick one feature you have actually used and show the code before and after. Examples: std::optional<T> as a return type instead of returning -1 or nullptr for no result; structured bindings in for (const auto& [key, value] : map); std::make_unique instead of a bare new.
Explain why it is better: optional puts no result into the type, so the caller has to handle it, and it stores the value inline with no heap allocation. Structured bindings remove .first and .second noise, and make_unique keeps ownership explicit and exception-safe.
Know the pitfall of the feature you chose: std::string_view does not own its characters, so a view of a temporary std::string dangles. Dereferencing an empty optional with * is undefined behaviour, while value() throws std::bad_optional_access.
Mention a second feature briefly to show range: if constexpr for compile-time branches in templates, std::variant with std::visit as a type-safe union, generic lambdas with auto parameters (C++14), and std::filesystem (C++17).
Say how you enabled it (-std=c++17 or the CMake CXX_STANDARD setting) and any compiler or toolchain limits you ran into on the project.

Follow-up

What does std::optional cost in memory compared with returning a pointer?
Show a case where std::string_view leads to a dangling reference.
Which C++20 feature would you most want to use next, and why?

What software design patterns do you know and how do they work?

Medium · Practical Engineering and Debugging

Approach

Group the patterns you know by purpose: creational (Factory Method, Builder, Singleton), structural (Adapter, Decorator, Facade) and behavioral (Observer, Strategy, Command). For each one, give the problem it solves before its structure.
Strategy: an interface with interchangeable implementations, or a std::function member, chosen at runtime, such as swapping one numeric solver for another without touching the caller. Observer: a subject keeps a list of subscribers and notifies them on change. In C++, hold the observers as weak_ptr, or unsubscribe them in the destructor, so the subject never calls a destroyed object.
Adapter: wrap an existing or legacy interface so it matches the one new code expects. Factory: centralize creation so callers depend on an abstract type and new subclasses do not change the call sites.
Be balanced on Singleton: it guarantees one instance, and a function-local static is initialized thread-safely since C++11, but it is hidden global state that makes testing harder. Passing the dependency in explicitly is usually better.
Tie at least one pattern to code you wrote, and name the C++ idiom RAII (resource acquisition tied to object lifetime) as the pattern that sits underneath smart pointers and lock guards.

Follow-up

What problems does Singleton cause, and what would you use instead?
Implement Observer in C++ so that a destroyed observer is never called.
When would you use templates (compile-time strategy) instead of virtual functions for Strategy?

Suggested practice checklist

Seven days built around the three reported rounds: the C++ and Java fundamentals the technical stage covers, the project you will present, and the behavioral questions candidates report. Each day ends with something you can show.

Day 1 — Map the loop and choose your presentation project

Write the three reported rounds (Phone Screening, Technical Evaluations, Technical Presentation) and, beside each, what you need ready for it.
List your past projects and pick the one you will present to a panel; note your own contribution, the architecture and one obstacle you overcame.
Write a two-minute resume summary that ends on that project.

Deliverable: A one-page loop map, the chosen project with its three key points, and a written two-minute resume summary.

Day 2 — C++ memory and smart pointers; stack versus heap

Write short examples with unique_ptr, shared_ptr and weak_ptr, including a reference cycle and how weak_ptr breaks it, and explain what modern C++ changed compared with raw new and delete.
Write a small class that owns a buffer and implement the Rule of 3, then the Rule of 5; note when the Rule of 0 applies.
Explain stack versus heap in C++, then what Java does (objects on the heap, references and primitive locals on the stack) and how garbage collection differs from manual ownership.

Deliverable: Working code for the smart-pointer and Rule of 3/5 examples, and a written 60-second spoken answer each for smart pointers and stack versus heap.

Day 3 — OOP and design patterns

Write a small class hierarchy that shows encapsulation, abstraction, inheritance and polymorphism with a virtual function, and note why a base class needs a virtual destructor.
Pick four design patterns (for example factory, observer, strategy and singleton), sketch each in a few lines, and note a downside of each.
Record yourself explaining the basic OOP ideas and two patterns without notes.

Deliverable: A hierarchy with working code, four pattern sketches with one trade-off each, and one recorded spoken answer.

Day 4 — Complexity, data structures, SQL joins and modern C++

Write three reasons an O(n^2) approach can beat an O(log n) one (small n, tiny constants, no preprocessing or index available, simpler and safer code) and test one with a quick benchmark.
Compare a hash set with a tree-based set on lookup cost, ordering, memory and worst case, and write when you would pick each.
Using two small tables, write inner, left, right and full outer join queries and note which rows each keeps.
Choose one C++14/17 feature you have used (for example auto, lambdas, structured bindings, optional or make_unique) and write how it changed your code.

Deliverable: A benchmark result, a hash-versus-tree comparison table, four join queries with outputs, and a written paragraph on the C++14/17 feature.

Day 5 — Debugging and pseudo-code without an IDE

Print three short C++ or Java snippets with a logic error (off-by-one, dangling reference, integer overflow) and find each by reading, saying aloud what every line does.
Write pseudo-code for Fibonacci in recursive, memoized and iterative forms and state the complexity of each.
Write a short account of a bug you debugged, in order: symptom, reproduction, hypotheses, the evidence that confirmed the cause, the fix.

Deliverable: Three annotated bug findings, three Fibonacci pseudo-code versions with complexities, and one written debugging story.

Day 6 — Build and rehearse the project presentation

Build the deck: problem statement, architecture diagram, one or two graphs of results, the obstacle slide, and the outcome.
List every technology on the slides and write how each works underneath and why you chose it.
Present aloud to a friend and write down the five hardest questions about your design choices, with answers.
Rehearse your answers to the questions about a problem you solved and a project you care about.

Deliverable: A finished slide deck, a technology-justification list, and written answers to five hard questions.

Day 7 — Behavioral answers and a full mock

Write and say aloud your answers to the internal project conflict question and the question about asking for help when stuck, using situation, action and result.
Decide your honest answer on working on defense or high-stakes technology and say it aloud until it takes under a minute.
Run one mock loop: a two-minute resume summary, three fundamentals questions drawn at random from days 2 to 4, and your presentation opening.

Deliverable: Three polished behavioral answers and a mock-loop self-review listing what to fix.

Behavioural preparation

The behavioral questions candidates report for this role ask about your own history: a problem you solved, a project you care about, a conflict inside a project, whether you ask for help when stuck, and how you feel about defense or high-stakes work. Candidates also describe presenting a project and answering questions about it, so the same stories do double duty. Prepare each with the situation, your own action in the first person, and a result you can point to.

Do you have any concerns working on technology that could be used for defense or high-stakes operations?
Please explain your resume and your college projects.