4 ms·

I find architecture diagrams particularly useful for interviews of high-level candidates. I'll structure the first half as an informal conversation where I pic

I find architecture diagrams particularly useful for interviews of high-level candidates. I'll structure the first half as an informal conversation where I pick up some technical work they've done and get them to talk about it in depth. The second half is usually explaining the 10kft and 1kft arhitectural overview of our product. However, I find that pre-prepared architecture diagrams are not that helpful in this case. I just open up an excalidraw tab, screen share, and sketch out the diagram in real-time, explaining things as I go along, and trying to elicit conversation about the design. I do this because my biggest challenge when tackling new work is not necessarily the code, but the context of it. Where does this live? Where does it receive its inputs from? Where dose its outputs go? How are all of these things organized into the bigger picture? What gets persisted? What's transient? A good grasp of overall architecture allows you to produce your own heuristic for how to navigate the code, where to look for problems, build internal models of where things might be going wrong, etc. The sketches get thrown away each time. The process of drawing it out and explaining it is the value.

ShadowBanThis01 3y ago
Your approach sounds like what I’d expect for an experienced hire. Good for you. Sadly, it’s not what I’ve experienced lately.
jameshart 3y ago
I think there is something to the fact that drawing the diagram in front of someone - the performance of drawing - communicates something in itself. The way you place boxes initially to set out spatial relationships. The direction in which you draw the arrows. The speed at which you draw them - clearly and deliberately, or swiftly and as an aside. The things you drew and then had to erase and redraw bigger. The way you're able to augment the diagram as you go to elaborate on or clarify your audience's points of confusion. All of that is part of what you're communicating when you draw a diagram in front of someone. None of that is part of what you capture in a static diagram in an architecture document. That's one reason why I suspect that the diagrams in documentation shouldn't necessarily look like the ones you draw in a collaborative session.
ehnto 3y ago
> A good grasp of overall architecture allows you to produce your own heuristic for how to navigate the code, where to look for problems, build internal models of where things might be going wrong, etc. This is the benfit of using a framework, if you are building different projects. Learn one architecture intimately, and you save a lot of headroom. You can also hire people familiar with the framework, who have built this intuition already, even though they have never seen your codebase before.

ShadowBanThis01 3y ago

Your approach sounds like what I’d expect for an experienced hire. Good for you. Sadly, it’s not what I’ve experienced lately.

jameshart 3y ago

I think there is something to the fact that drawing the diagram in front of someone - the performance of drawing - communicates something in itself. The way you place boxes initially to set out spatial relationships. The direction in which you draw the arrows. The speed at which you draw them - clearly and deliberately, or swiftly and as an aside. The things you drew and then had to erase and redraw bigger. The way you're able to augment the diagram as you go to elaborate on or clarify your audience's points of confusion. All of that is part of what you're communicating when you draw a diagram in front of someone. None of that is part of what you capture in a static diagram in an architecture document. That's one reason why I suspect that the diagrams in documentation shouldn't necessarily look like the ones you draw in a collaborative session.

ehnto 3y ago

> A good grasp of overall architecture allows you to produce your own heuristic for how to navigate the code, where to look for problems, build internal models of where things might be going wrong, etc. This is the benfit of using a framework, if you are building different projects. Learn one architecture intimately, and you save a lot of headroom. You can also hire people familiar with the framework, who have built this intuition already, even though they have never seen your codebase before.