Should I bring design diagrams to a software developer interview?

Question

If my current workplace allowed me to bring masked versions of design diagrams of a (solo) software project that I worked on, would it be a good idea to bring them to interviews? Would interviewers appreciate this?

Answer 1

This sounds like a bad idea. Even if your current employer for some reason knows you are interviewing and is ok with you bringing design documents on an interview, having those documents is going to raise eyebrows at the interview. The interviewer will certainly ask if you have permission, and in the back of his or her head is going to be the thought "is this guy going to take our design docs and flash them around?".

As an alternative just brush up on your work (if you need to) and be ready to discuss (in general) the work you have done, technologies used, how you made design decisions, etc.

Answer 2

Should I bring design diagrams to a software developer interview?

Unless you are asked specifically to bring them, or bring samples of your work, I would leave diagrams at home, because:

1. Bringing diagrams is not standard interview protocol (most people talk through their design).
2. Your design might be faulty or wrong, or misinterpreted by your interviewers.
3. Your design might be inappropriate (too simplistic or too complicated).
4. The diagrams may be of poor quality.
5. Your diagrams might be irrelevant to the conversation, but you might be tempted to show them anyway.

It is much better and easier to decide during the interview if your design is relevant and appropriate. If it is, you can always draw it on a white board.

Your ability to walk through a solution or design on a whiteboard is a desirable skill, and much less risky than trying to prepare a single design that may or may not be relevant or appropriate.

If my current workplace allowed me to bring masked versions of design diagrams of a (solo) software project that I worked on...

I would not do this -- using a masked diagram may be worse than no diagram at all, if detail, context, or integrations are missing.

Answer 3

As somebody who does technical interviews:

• Bring the things you were asked for. It never hurts to have a few slides summarizing your previous work, but show these if asked, or if you are asked freely to introduce pu them there.
• Do never contact an interviewer by sending him documents to "support you story" if he did not ask for it.
• Do not forcibly try steer the direction of the interview to the topics you imagine
• Do not pull out some documentation of your previous work without being asked during the interview - this is for me an extreme version of trying to get in control of the situation

From the perspective of an interviewer:

• I have a catalog of questions, we need to go trough some of these - taking to much control from your side will take time. (and while I am lenient toward questions which are answered in a wrong way, if I have questions with a good answer in the interview time, it's not good)

• When trying to steer the direction of the interview into previous experiences, be careful.

  1. I had candidates lecturing me on how good their method/algorithm would fit to our problems. I accept that but then I go full force into having them explain the meaning of this in detail. And it's much harder for me to discard a wrong answer if you put all your technical weight behind it and still don't see the forest full of trees.
  2. In that case you don't demonstrate that you are competent, but that you stubborn and a hammer-nail person

• Typically i don't really care what you did before, whats important to me

  1. You can technically communicate in various settings
  2. You can explain the details I asked for - everybody can pick details and explain them, but i basically had physics PhD explain which type of screw was on their setup
  3. You are willing to go away from an approach if there are complex reasons why it should not be done

• all unsolicited contact to an technical interviewer is annoying. The company allocated the time for this, the interview will be/was executed, and HR communicates with you. Deviating from this protocol shows a certain lack of professionalism.

Answer 4

YES, YES and YES. Seeing how deeply competitive tech is everything you do has to make you stand out from the other candidates. Anyone can talk to someone about a project they have worked on but what has HUGE impact is if they can see your project.

You can just simply ask them in the interview if they would be interested in seeing your project. Most clients will say yes. Then you can see in project and you can then tell them about the project, and stories of the learning that you gained from it.

It makes you a more 3 dimensional person and not just a 'another interviewee'. Plus there is the bonus you can relax more in the interview setting.

A win/win for everyone.