4 ms·

I failed a number of technical interviews because I can't make architecture diagrams. I come out of the first tech interview, coding/debugging, with praises. B

I failed a number of technical interviews because I can't make architecture diagrams. I come out of the first tech interview, coding/debugging, with praises. But then comes the second, the architecture interview, and I can't for the life of me draw the architecture of anything. I don't know how people learn to do that, I've learned to code/debug by being obsessive about it. But I don't see how that happens for system architecture. I've never used diagrams in my day-to-day work, so when it comes up in interviews I'm always surprised.

sarchertech 3y ago
Do you know how to design systems, and you just can’t draw them? Or do you need to learn how to design systems. If it’s the former, just practice drawing something you’ve designed with boxes, labels, and arrows. I’d it’s the latter I’d recommend https://www.goodreads.com/en/book/show/54109255 https://www.goodreads.com/en/book/show/54109255 as a good intro to the kind of “systems design” they do in interviews.
- kzhen 3y ago
  Hi jrimbault, article author here, like any skill this needs to be developed. As sarchertech says if you already know how to design systems but struggle with the drawing then practice is the key. When I started out the diagrams I produced were messy and not very presentable, but I kept refining them. Take the opportunities you have before you, for example, if you're building a system at work then take some time to try and draw up some architecture diagrams and run them by some people who you think will give you good feedback. Then keep refining them. If it's the later then there are some videos on youtube that introduce the C4 model - the key thing is to pick a method and try to stick with it, whether that is c4 or arch42 etc, try to learn the underlying principles and apply them.
politician 3y ago
The ask is to flatten a multidimensional space into a 2D plane, so out of the gate you're going to have problems. A really good architectural diagram doesn't have a lot of crossed lines, but you can only really do that when you have a small number of nodes or when the dataflow is broadly unidirectional. The interview is inherently unfair - when you use a drawing tool to build diagrams the work is iterative, but erasing marker during an interview looks like you've made a mistake. Start with a small top-level diagram, then build a hierarchy of increasingly detailed diagrams. Use the opportunity to steer the interviewer ("which area would you like to see in more detail?"). It also helps to have an understanding of how small bits of code map to graphical sketches, so that you can compose them later. Also, keep in mind that issues like poor handwriting and sloppy lines are exacerbated by large detailed diagrams.
swozey 3y ago
I work in platarch and I'll fully admit that my diagrams aren't the best, pretty ugly tbh. The people who do great diagrams typically have a lot of experience drawing them on whiteboards during meetings. It just hasn't been something I've done much and do it even less now that WFH. If you want to improve I'd recommend getting a whiteboard for your office and just start using it, then also learn mermaid or whatever language/app you want to use. I did use to make diagrams all the time when I was a field engineer for a distro company. Getting one of those small wacom tablets is really helpful in that case. I could draw in whatever app I was using at the time like draw.io or diagramly, I forget. I guess if we're all WFH now the latter is more important.. not sure if I'll ever have to whiteboard again.. Also, I ran across this today, making diagrams as gifs. Really interesting. Way too much work for me, though - https://aws.plainenglish.io/aws-architecture-in-motion-creating-animated-gifs-a836fad603b2 https://aws.plainenglish.io/aws-architecture-in-motion-creat...
- OJFord 3y ago
  Use the tools you know and all that, but PowerPoint seems like a roundabout/hard way of doing that to me - I'd just make the base in whatever diagramming tool I'm using, then add the colour/dot/whatever variation for each frame (cf. PowerPoint slide), rendering/saving each image, and then look up the args for `mogrify` to combine them into a single animated gif. Or there's probably a dozen SEO'd ad-chucking websites that'll do it too if you prefer (& it's not sensitive).
  - swozey 3y ago
    I wonder if theres some image openAI thing I can run a diagram through to add it lol. Theres not a chance I'm spending that long unless it's maybe for an interview.
    - tough 3y ago
      In fact ChatGPT does have diagraminig plugins you can talk to and output valid code-based diagrams. Havent tried.
jroseattle 3y ago
You're going to get a lot of advice, but some general comments for your consideration. As always, your mileage may vary. > failed a number of technical interviews because I can't make architecture diagrams I would caution against correlating interview failure to a lack of diagramming skill. Diagramming is a teachable skill; how to formulate architecture is much more complicated. If I am considering hiring someone who I see can design strong architectures but couldn't represent that in a diagram, I'm probably not dismissing them because of their drawing skills. But that's only when I believe they can design an intended architecture. > I can't for the life of me draw the architecture of anything I had an engineer on one of my teams who had the same problem. With him, he understood some things but in other aspects he was more murky. So, I asked him to start by writing down the architecture. Literally, write words and sentences that describe the collective of systems, i.e. Service "A" is a REST API, and it connects to Database "B"; a client connects to Service "A" over HTTPS, etc. etc. I don't know if this would help, but if you can do that, you can start to translate the words to pictures. > I don't know how people learn to do that By doing. I don't know anyone who has ever been trained to create an architecture diagram that knew what they were talking about. Just start small, and then ask someone to describe it back to you. When you begin to hear what you consider to be correct, you'll know you're making progress. > I've never used diagrams in my day-to-day work This tells me a couple of potential things: you're possibly not working in complex or large systems, or maybe are not responsible for communicating those systems to others. "Complex" is a relative term, so interpret that as you may. Ultimately, arch diagrams serve as a way to visualize complexity with the goal of letting others understand.
icedchai 3y ago
There is some "art" to it, but if you can draw boxes, arrows, and labels, you can make architecture diagrams. Basically, organize the boxes in layers and connect with arrows to represent request/response flows. You need to put in enough detail to make the diagram useful (or at least seem that way...), but leave a bunch out, otherwise it's too noisy. If you have too many arrows intersecting, you should rearrange things.

sarchertech 3y ago

Do you know how to design systems, and you just can’t draw them? Or do you need to learn how to design systems. If it’s the former, just practice drawing something you’ve designed with boxes, labels, and arrows. I’d it’s the latter I’d recommend https://www.goodreads.com/en/book/show/54109255 https://www.goodreads.com/en/book/show/54109255 as a good intro to the kind of “systems design” they do in interviews.

kzhen 3y ago
Hi jrimbault, article author here, like any skill this needs to be developed. As sarchertech says if you already know how to design systems but struggle with the drawing then practice is the key. When I started out the diagrams I produced were messy and not very presentable, but I kept refining them. Take the opportunities you have before you, for example, if you're building a system at work then take some time to try and draw up some architecture diagrams and run them by some people who you think will give you good feedback. Then keep refining them. If it's the later then there are some videos on youtube that introduce the C4 model - the key thing is to pick a method and try to stick with it, whether that is c4 or arch42 etc, try to learn the underlying principles and apply them.

politician 3y ago

The ask is to flatten a multidimensional space into a 2D plane, so out of the gate you're going to have problems. A really good architectural diagram doesn't have a lot of crossed lines, but you can only really do that when you have a small number of nodes or when the dataflow is broadly unidirectional. The interview is inherently unfair - when you use a drawing tool to build diagrams the work is iterative, but erasing marker during an interview looks like you've made a mistake. Start with a small top-level diagram, then build a hierarchy of increasingly detailed diagrams. Use the opportunity to steer the interviewer ("which area would you like to see in more detail?"). It also helps to have an understanding of how small bits of code map to graphical sketches, so that you can compose them later. Also, keep in mind that issues like poor handwriting and sloppy lines are exacerbated by large detailed diagrams.

swozey 3y ago

I work in platarch and I'll fully admit that my diagrams aren't the best, pretty ugly tbh. The people who do great diagrams typically have a lot of experience drawing them on whiteboards during meetings. It just hasn't been something I've done much and do it even less now that WFH. If you want to improve I'd recommend getting a whiteboard for your office and just start using it, then also learn mermaid or whatever language/app you want to use. I did use to make diagrams all the time when I was a field engineer for a distro company. Getting one of those small wacom tablets is really helpful in that case. I could draw in whatever app I was using at the time like draw.io or diagramly, I forget. I guess if we're all WFH now the latter is more important.. not sure if I'll ever have to whiteboard again.. Also, I ran across this today, making diagrams as gifs. Really interesting. Way too much work for me, though - https://aws.plainenglish.io/aws-architecture-in-motion-creating-animated-gifs-a836fad603b2 https://aws.plainenglish.io/aws-architecture-in-motion-creat...

OJFord 3y ago
Use the tools you know and all that, but PowerPoint seems like a roundabout/hard way of doing that to me - I'd just make the base in whatever diagramming tool I'm using, then add the colour/dot/whatever variation for each frame (cf. PowerPoint slide), rendering/saving each image, and then look up the args for `mogrify` to combine them into a single animated gif. Or there's probably a dozen SEO'd ad-chucking websites that'll do it too if you prefer (& it's not sensitive).
- swozey 3y ago
  I wonder if theres some image openAI thing I can run a diagram through to add it lol. Theres not a chance I'm spending that long unless it's maybe for an interview.
  - tough 3y ago
    In fact ChatGPT does have diagraminig plugins you can talk to and output valid code-based diagrams. Havent tried.

jroseattle 3y ago

You're going to get a lot of advice, but some general comments for your consideration. As always, your mileage may vary. > failed a number of technical interviews because I can't make architecture diagrams I would caution against correlating interview failure to a lack of diagramming skill. Diagramming is a teachable skill; how to formulate architecture is much more complicated. If I am considering hiring someone who I see can design strong architectures but couldn't represent that in a diagram, I'm probably not dismissing them because of their drawing skills. But that's only when I believe they can design an intended architecture. > I can't for the life of me draw the architecture of anything I had an engineer on one of my teams who had the same problem. With him, he understood some things but in other aspects he was more murky. So, I asked him to start by writing down the architecture. Literally, write words and sentences that describe the collective of systems, i.e. Service "A" is a REST API, and it connects to Database "B"; a client connects to Service "A" over HTTPS, etc. etc. I don't know if this would help, but if you can do that, you can start to translate the words to pictures. > I don't know how people learn to do that By doing. I don't know anyone who has ever been trained to create an architecture diagram that knew what they were talking about. Just start small, and then ask someone to describe it back to you. When you begin to hear what you consider to be correct, you'll know you're making progress. > I've never used diagrams in my day-to-day work This tells me a couple of potential things: you're possibly not working in complex or large systems, or maybe are not responsible for communicating those systems to others. "Complex" is a relative term, so interpret that as you may. Ultimately, arch diagrams serve as a way to visualize complexity with the goal of letting others understand.

icedchai 3y ago

There is some "art" to it, but if you can draw boxes, arrows, and labels, you can make architecture diagrams. Basically, organize the boxes in layers and connect with arrows to represent request/response flows. You need to put in enough detail to make the diagram useful (or at least seem that way...), but leave a bunch out, otherwise it's too noisy. If you have too many arrows intersecting, you should rearrange things.