A Software Engineer at the Jet Propulsion Laboratory (JPL) plays a critical role in the exploration of space, contributing to missions that expand human knowledge of the universe. Unlike typical commercial software roles, engineering at JPL/NASA requires developing software that must operate under extreme environmental constraints, with zero tolerance for failure. Whether you are writing embedded flight software for Mars rovers, architecting cloud-based ground data systems to ingest petabytes of telemetry, or building modeling tools for deep-space missions, your code will directly impact the success of active space exploration. The engineering challenges at JPL/NASA span multiple domains, meaning that software is highly integrated with hardware, systems engineering, and scientific instruments. Engineers here operate at the intersection of cutting-edge technology and rigorous physical sciences. The systems you build will serve scientists, mission operators, and the global research community, making the role highly collaborative, intellectually demanding, and strategically vital to national and international space endeavors. To succeed as a Software Engineer at JPL/NASA, you must possess not only technical excellence but also a deep curiosity and a commitment to precision. The laboratory values engineers who can think from first principles, adapt to ambiguous and unprecedented challenges, and maintain a rigorous standard of quality.
Resume Review
reportedInitial review of your resume by a recruiter or hiring manager to assess background and interest.
What to demonstrate
- Initial review of your resume by a recruiter or hiring manager to assess background and interest
- Depth in Software Engineering (General)
How to prepare
- Be able to walk your CV end to end in two minutes, and say why this company specifically.
- Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.
Preliminary Screening
reportedA preliminary screening focused on your background, interest in the lab, and basic technical alignment.
What to demonstrate
- A preliminary screening focused on your background, interest in the lab, and basic technical alignment
- Depth in Software Engineering (General)
How to prepare
- Answer aloud and timed: Describe a complex software system you designed. What would you do differently if you had to build it again from scratch?
- Answer aloud and timed: Explain the specific technical contribution you made to your most recent team or academic research project.
Technical Evaluation
reportedOne or two detailed technical phone or video interviews focusing on conversational technical discussions and system design.
What to demonstrate
- One or two detailed technical phone or video interviews focusing on conversational technical discussions and system design
- Depth in Software Engineering (General)
How to prepare
- Answer aloud and timed: How do you ensure the reliability and testability of your code when dealing with complex, multi-threaded applications?
- Answer aloud and timed: Explain how recursion works and describe what happens to the recursive call stack during execution.
Panel Interview
reportedAn intensive panel interview that includes a formal technical presentation followed by consecutive interviews on technical depth and team fit.
What to demonstrate
- An intensive panel interview that includes a formal technical presentation followed by consecutive interviews on technical depth and team fit
- Depth in Software Engineering (General)
How to prepare
- Answer aloud and timed: What are the primary differences between a stack and a queue, and in what scenarios would you choose one over the other?
- Answer aloud and timed: How do you handle memory management and prevent memory leaks in languages like C++ or Java?
PracHub editorial advice for the preparation topics above.
Going into the loop without having done this.
To maximize your chances of success during the JPL/NASA hiring process, keep these practical tips in mind:
Going into the loop without having done this.
Know Your Code Inside Out: Never put a project, language, or tool on your resume unless you can discuss it in deep, low-level technical detail. Interviewers will actively probe your resume to verify your actual hands-on experience.
Going into the loop without having done this.
Highlight Your Problem-Solving Process: When answering technical or system design questions, focus on explaining how you think. Break down the problem logically, state your assumptions, and discuss the trade-offs of your proposed solution.
Going into the loop without having done this.
Connect Your Work to the Mission: Make sure you have a clear, compelling answer for why you want to work at JPL/NASA. Research the laboratory's active missions and be ready to explain how your software skills can contribute to their success.
Going into the loop without having done this.
Prepare for Multidisciplinary Questions: Be ready for questions that bridge software with other engineering fields. Showing that you understand how software interacts with hardware, sensors, or physical constraints is highly valued.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you ensure the reliability and testability of your code when dealing with complex, multi-threaded appli
How do you ensure the reliability and testability of your code when dealing with complex, multi-threaded applications?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
Explain how recursion works and describe what happens to the recursive call stack during execution.
Explain how recursion works and describe what happens to the recursive call stack during execution.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
How do you handle memory management and prevent memory leaks in languages like C++ or Java?
How do you handle memory management and prevent memory leaks in languages like C++ or Java?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
Explain why the owner filter ignores the listing index
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
- 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.
- 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.
- 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.
- 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?
Denormalise tenant onto revisions and backfill it live
resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.
Approach
- Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
- Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
- Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
- Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.
Follow-up
- The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
- How do you verify the backfill actually finished, given rows are still being inserted while it runs?
Walk me through the architecture of a major project you worked on. What were the key bottlenecks, and how did
Walk me through the architecture of a major project you worked on. What were the key bottlenecks, and how did you resolve them?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
Describe a complex software system you designed. What would you do differently if you had to build it again fr
Describe a complex software system you designed. What would you do differently if you had to build it again from scratch?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Explain the specific technical contribution you made to your most recent team or academic research project.
Explain the specific technical contribution you made to your most recent team or academic research project.
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
What are the primary differences between a stack and a queue, and in what scenarios would you choose one over
What are the primary differences between a stack and a queue, and in what scenarios would you choose one over the other?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Explain the difference between relational databases and NoSQL databases like MongoDB. When is a document store
Explain the difference between relational databases and NoSQL databases like MongoDB. When is a document store more advantageous?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Describe how an HTTP request is structured and what happens behind the scenes when a client communicates with
Describe how an HTTP request is structured and what happens behind the scenes when a client communicates with a server.
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
How do you design software to handle unexpected hardware failures or communication dropouts?
How do you design software to handle unexpected hardware failures or communication dropouts?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
If you are building a system that processes real-time telemetry, how do you manage data ingestion rates to pre
If you are building a system that processes real-time telemetry, how do you manage data ingestion rates to prevent data loss?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Describe your familiarity with robotics software architectures or designing algorithms for autonomous systems.
Describe your familiarity with robotics software architectures or designing algorithms for autonomous systems.
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
How would you approach designing a software interface for system operators who need to monitor critical hardwa
How would you approach designing a software interface for system operators who need to monitor critical hardware components in real time?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Why do you want to work at JPL/NASA, and what specific space exploration missions or technologies interest you
Why do you want to work at JPL/NASA, and what specific space exploration missions or technologies interest you the most?
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- Design the error taxonomy before the success shape; callers branch on it.
Follow-up
- What happens if the caller retries after a timeout?
- How does a client discover it is on an old version of this contract?
Edge instances grow 400 MB per hour until the nightly restart
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
- 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.
- 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.
- 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.
- 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?
Built from the rounds and topics JPL/NASA candidates report.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the JPL/NASA loop
- Write out the reported sequence: Resume Review, Preliminary Screening, Technical Evaluation, Panel Interview.
- For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.
Deliverable: A one-page map of the 4 reported rounds, with the weakest marked.
02Work Software Engineering (General)
- Spend the session on Software Engineering (General), which JPL/NASA candidates report being tested on.
- Write one worked example in Software Engineering (General) and time yourself on it.
Deliverable: One timed worked example in Software Engineering (General).
03Work Behavioral Interviewing / Competency Questions
- Spend the session on Behavioral Interviewing / Competency Questions, which JPL/NASA candidates report being tested on.
- Write one worked example in Behavioral Interviewing / Competency Questions and time yourself on it.
Deliverable: One timed worked example in Behavioral Interviewing / Competency Questions.
04Work Technical Interview Problem Solving (General)
- Spend the session on Technical Interview Problem Solving (General), which JPL/NASA candidates report being tested on.
- Write one worked example in Technical Interview Problem Solving (General) and time yourself on it.
Deliverable: One timed worked example in Technical Interview Problem Solving (General).
05Answer out loud: Project & Resume Deep Dives
- Answer aloud, timed: Walk me through the architecture of a major project you worked on. What were the key bottlenecks, and how did you resolve them?
- Answer aloud, timed: Tell me about a past programming project where you had to learn a completely new technology or language on the job. How did you approach it?
Deliverable: Spoken answers to 2 reported Project & Resume Deep Dives question(s), under time.
06Answer out loud: Technical & Computer Science Fundamentals
- Answer aloud, timed: Explain how recursion works and describe what happens to the recursive call stack during execution.
- Answer aloud, timed: What are the primary differences between a stack and a queue, and in what scenarios would you choose one over the other?
Deliverable: Spoken answers to 2 reported Technical & Computer Science Fundamentals question(s), under time.
07Answer out loud: Systems & Multidisciplinary Engineering
- Answer aloud, timed: How do you design software to handle unexpected hardware failures or communication dropouts?
- Answer aloud, timed: What is your experience with Unix/Linux systems, and how do you optimize software performance at the operating system level?
Deliverable: Spoken answers to 2 reported Systems & Multidisciplinary Engineering question(s), under time.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Behavioural rounds judge the decision you made and what it cost.
Tell me about a past programming project where you had to learn a completely new technology or language on the
Tell me about a past programming project where you had to learn a completely new technology or language on the job. How did you approach it?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
What is your experience with Unix/Linux systems, and how do you optimize software performance at the operating
What is your experience with Unix/Linux systems, and how do you optimize software performance at the operating system level?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
Describe a time when you had a technical disagreement or conflict with a teammate. How did you handle it, and
Describe a time when you had a technical disagreement or conflict with a teammate. How did you handle it, and what was the outcome?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
Tell me about a time when you had to work with highly ambiguous requirements. How did you define the scope and
Tell me about a time when you had to work with highly ambiguous requirements. How did you define the scope and deliver the project?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
How do you handle a situation where a critical deadline is approaching, but your software still has unresolved
How do you handle a situation where a critical deadline is approaching, but your software still has unresolved bugs?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
Describe a time when you had to explain a highly complex technical concept to a non-technical stakeholder or t
Describe a time when you had to explain a highly complex technical concept to a non-technical stakeholder or teammate.
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
- 01
Tell me about a past programming project where you had to learn a completely new technology or language on the job. How did you approach it?
- 02
What is your experience with Unix/Linux systems, and how do you optimize software performance at the operating system level?
- 03
Describe a time when you had a technical disagreement or conflict with a teammate. How did you handle it, and what was the outcome?
- 04
Tell me about a time when you had to work with highly ambiguous requirements. How did you define the scope and deliver the project?
How difficult is the Software Engineer interview process at JPL/NASA?
The interview difficulty is average to difficult, depending on the specific team. While you will not typically face ultra-high-pressure competitive programming puzzles, the technical depth, resume scrutiny, and the final panel presentation require thorough preparation and a deep understanding of your past work.
JPL/NASA Software Engineer candidate reports ↗What is the typical timeline from application to offer?
The timeline can vary significantly due to the laboratory's thorough review process and administrative requirements. Some candidates receive offers within a few weeks, while others—especially those applying during hiring freezes or for highly sensitive roles—may experience a process that takes several months.
JPL/NASA Software Engineer candidate reports ↗Does JPL/NASA require security clearances for Software Engineers?
Because JPL/NASA is a federal facility, all positions require a background check and drug screening. Some specific roles, particularly those dealing with national security, critical infrastructure, or flight systems, may require a formal security clearance.
JPL/NASA Software Engineer candidate reports ↗Can I work remotely as a Software Engineer at JPL/NASA?
Remote work policies depend heavily on the specific team and project. While some ground software, cloud architecture, and data science teams offer hybrid or remote flexibility, roles that require direct interaction with hardware, cleanrooms, or mission control operations are primarily on-site in Pasadena, CA.
JPL/NASA Software Engineer candidate reports ↗How should I prepare for the technical presentation?
Select a project where you had complete technical ownership and can explain every detail. Structure your presentation to cover the problem statement, your architectural design, the specific challenges you overcame, and your individual contributions. Practice presenting to peers and be ready for highly detailed technical questions.
JPL/NASA Software Engineer candidate reports ↗How hard is the JPL/NASA interview?
Candidates most commonly rate JPL/NASA interviews as medium, based on 320 reported interviews. About 66% of candidates who interview go on to receive an offer.
JPL/NASA Software Engineer candidate reports ↗What topics does JPL/NASA test in interviews?
JPL/NASA interviews most often cover Stakeholder Communication, Professional Communication, Presentation Skills, Project Management, and Budgeting (Business Budgeting). The exact emphasis depends on the specific role you apply for.
JPL/NASA Software Engineer candidate reports ↗Where is JPL/NASA headquartered?
JPL/NASA is headquartered in Pasadena, US.
JPL/NASA Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01JPL/NASA Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
candidate · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
platform · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Zebra Technologies Software Engineer Interview Guide
What Zebra Technologies asks Software Engineer candidates, from reported rounds and questions.
Stone Software Engineer Interview Guide
What Stone asks Software Engineer candidates, from reported rounds and questions.
Paysafe Software Engineer Interview Guide
What Paysafe asks Software Engineer candidates, from reported rounds and questions.
Phonepe Software Engineer Interview Guide
What Phonepe asks Software Engineer candidates, from reported rounds and questions.