5 ms·

> That's a basic question and if that's considered "tricky" you've got a real problem on your hands. If they aren't warned then it's reasonable to assume that

by wmil 13y ago

> That's a basic question and if that's considered "tricky" you've got a real problem on your hands. If they aren't warned then it's reasonable to assume that every department has employees. Otherwise why would it exist?

aidos 13y ago
Fair point. Experience has taught me to internally question whether or not each relationship should use a left join or not. The fact that it says "List all departments" made me think it should be a left join. In fact, to me that screams "left join". Really, in a philosophical sort of way, it's the use of the query that determines which join to use. They want ALL departments, you give them ALL departments. Using a left join you protect yourself in the future - with a performance hit. As you say, if there was a guarantee that the data didn't contain empty departments you'd use an inner join. Most importantly, a reasonable developer should know to ask the question - if not of the examiner, at least to themselves. Just making an assumption is not the right approach.
dspillett 13y ago
It is a good way to expose real world experience. Client requirements are usually vague enough (heck, internal requirements are sometimes vague enough) for there to be problems like this discovered later. or a given business it might be valid for there to be departments that are empty at a particular time. Someone with extensive real world experience will know to never assume any detail not included in the specification no matter how much of a non-brainer that assumption might seem at the time. They will either ask if empty sets need to be considered, or they will preface/suffix their answer with "assuming there are no empty departments or you don't want to report on them if there are" or "assuming there might be empty departments and you want them included in the report" - either way they are showing an ability to parse requirements and identify possible ambiguity that should to be queried. You've got a multi-level differentiator there: * The bad candidates will not be able to give a working answer * The fine candidates will give a working answer though might miss the exact requirement (as it isn't properly stated and they just assume) * The best candidates will spot the deficiency in the spec
Nick_C 13y ago
I can think of two business reasons straight off: 1) a department changed its name, or 2) the department used to have employees but is now defunct, such as the Typing Pool department. My point is, to try to be aware of the assumptions that you are otherwise unconsciously putting in to your program's business logic.

by wmil 13y ago

aidos 13y ago

Fair point. Experience has taught me to internally question whether or not each relationship should use a left join or not. The fact that it says "List all departments" made me think it should be a left join. In fact, to me that screams "left join". Really, in a philosophical sort of way, it's the use of the query that determines which join to use. They want ALL departments, you give them ALL departments. Using a left join you protect yourself in the future - with a performance hit. As you say, if there was a guarantee that the data didn't contain empty departments you'd use an inner join. Most importantly, a reasonable developer should know to ask the question - if not of the examiner, at least to themselves. Just making an assumption is not the right approach.

dspillett 13y ago

It is a good way to expose real world experience. Client requirements are usually vague enough (heck, internal requirements are sometimes vague enough) for there to be problems like this discovered later. or a given business it might be valid for there to be departments that are empty at a particular time. Someone with extensive real world experience will know to never assume any detail not included in the specification no matter how much of a non-brainer that assumption might seem at the time. They will either ask if empty sets need to be considered, or they will preface/suffix their answer with "assuming there are no empty departments or you don't want to report on them if there are" or "assuming there might be empty departments and you want them included in the report" - either way they are showing an ability to parse requirements and identify possible ambiguity that should to be queried. You've got a multi-level differentiator there: * The bad candidates will not be able to give a working answer * The fine candidates will give a working answer though might miss the exact requirement (as it isn't properly stated and they just assume) * The best candidates will spot the deficiency in the spec

Nick_C 13y ago

I can think of two business reasons straight off: 1) a department changed its name, or 2) the department used to have employees but is now defunct, such as the Typing Pool department. My point is, to try to be aware of the assumptions that you are otherwise unconsciously putting in to your program's business logic.