A process is an isolated unit of execution with its own virtual address space; a thread is a unit of scheduling inside a process that shares that address space with its siblings. Threads are cheap to create and can share data directly, which is exactly why they need locks. Processes cost more and need explicit interprocess communication, but a crash or memory bug in one cannot corrupt another.
Why interviewers ask this
This is the foundation for every conversation about concurrency, and interviewers use it to see how deep the mental model goes. They want the memory isolation point, the cost difference, and the consequence: shared memory means shared mutable state means synchronization. Bonus points if you connect it to how your runtime actually schedules work, since that decides whether threads help you at all.
How to structure your answer
- Anchor on the address space: isolated versus shared.
- Compare creation cost and context switch cost.
- Draw the consequence for synchronization and crash isolation.
- Tie it to how your language runtime schedules work.
Example answer
The difference that matters is memory. Each process gets its own address space, so one crashing or scribbling over a pointer cannot take the others down, but they can only talk through pipes, sockets or a shared memory segment you set up deliberately. Threads live inside one process and share the heap, so passing data between them is just a pointer, which is fast and also exactly why you need locks. Creation cost follows the same line: spawning a thread is cheap, forking a process is not. In practice I let the runtime decide my strategy. In Python, CPU bound work goes to multiple processes, because the global interpreter lock stops threads executing bytecode in parallel, while IO bound work is fine on threads or async. In Go or Java I would reach for threads or goroutines first. Getting that backwards is how you end up with eight worker threads all queued behind one interpreter and no idea why the box is idle.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What actually happens during a context switch?
- When would you pick async IO over threads entirely?
- How does a thread pool avoid the cost you described?
Related software engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions