How well these questions correlate to job performance is an interesting question but the goal I think is not for you to get to the "right" answer (in the sense

How well these questions correlate to job performance is an interesting question but the goal I think is not for you to get to the "right" answer (in the sense of figuring the optimal bin-packing approach on the fly). The goal is to see how you are able to take a broad problem and break it down by: 1. Identifying key assumptions or inputs. You may not know the dimensions of a 747 off-hand but ideally you can come up with a way of determining the number of ping-ping balls GIVEN the correct dimensions as input. That is you can come up with a model that you can plug the right numbers into once you look them up. 2. Clarifying the problem by asking questions and drilling in on requirements. 3. Create a model that you can communicate to others and allows you to make decisions just based on order-of-magnitude considerations. I.e. make decisions under uncertainty. All of those skills I think are relevant to software engineering and system design. For example, you may need to provision hardware long before you know the exact design of a system. Can you come up with a rough estimate of how much storage you will need? Or at least put reasonable upper bounds on it? How many qps would you expect a system to need to support and does that mean you have to use a distributed datastore vs a single RDBMS?