3 ms·
A long standing interview question I've used is "draw us an ERD for this domain" (orders/customer/products). It's what at first is a seemingly simple question
by RowanH 14y ago
A long standing interview question I've used is "draw us an ERD for this domain" (orders/customer/products).
It's what at first is a seemingly simple question to start drilling into understanding of systems "so if I was going to do X, what would you change in your ERD?" "how about if scenario Z was going to happen, would you change anything?"
Strange how every now and then you get a "system architect" that can't answer that one.
- meaty 14y agoThat's usually because the architects don't give a shit about the storage model and recognise that the external interface/contract is far more important and that can be mapped to whatever schema supports the model. That's their domain. All they see is: "how can we ensure that this whole thing still works when someone does scenario X". The schema is almost 100% irrelevant to us and we have nearly 2000 tables in our system. We have two hibernate implementations which put that all behind a testable interface: something SQL can't give you on it's own.
- pdwetz 14y agoI don't envy your 2000 tables. Or hibernate, but if you have something that works for your team (and is testable) I'm not about to complain. As an architect, I will say that I do care about the storage model, but I'm obviously coming from a different place.