What's a good approach to sound convincing when talking about software design/engineering

Question

I've had a few instances where I've been asked about my approach to software design both in job interviews and in less formal settings. Lots of buzz words invariably come up: waterfall model, agile development, design patterns, UML, test driven development, requirements documents, user acceptance testing etc. etc. ad infintium.

My answer is invariably that the best approach depends on the project at hand. Using the waterfall model with a design specification document employing UML diagrams for a 3 page brochureware site is probably overkill. Likewise jumping straight to hammering out code on a life support control system is not a good idea.

In a short space of time the questioner will start to get this supicious look in their eye as they start thinking "he won't give a straight answer because he doesn't understand the concepts, must be a cowboy". I've found it's better to stick to just talking about "formal" software engineering processes along the lines of: Always use the waterfall model (call it SLC for extra points), gather a 50 page requirements document, turn it into a 100 page specification document with heavy use of UML and design patterns, hammer away at code for 6 months...

So my quandry is what approach should I use to sound convincing? Talk about my experiences on different projects or regurgitate Sommerville?

Answer 1

It is vital to establish from the start that you know what you're talking about. So you need to open with "I have worked on small projects and big projects, I have used waterfall and agile approaches, and " - the killer phrase - " in my professional opinion it is important to suit the weight of the methodology to the scale of the project in question." Which gives you a springboard for your "on the one hand, on the other hand" routine.

The other thing to make clear is that the choice of a specific methodology is less important than choosing one and sticking with it. Also that in waterfall, just as much as in agile, people, delivering code, collaboration and responding to change are the keys to success.

Answer 2

"How to sound convincing?" isn't really a software question, and just because you've added "when talking about software" doesn't make it so. You could make the topic anything and the answer is essentially the same.

You didn't ask, "When is a waterfall approach preferred to an agile approach?" or anything specifically related to software. (Although I'm sure that question has been asked previously).

This question should be closed. But I'll answer anyway, because I think it's interesting.

---

First, you don't want to "sound convincing." You want to BE convincing.

The best way to be convincing is to be confident. A confident person is persuasive.

Confidence is communicated in a number of ways, many of them non-verbal. Confidence or a lack of confidence is silently inferred by observers based on the speaker's

• Eye contact. This is #1. lack of eye contact, looking around the room when speaking = bad. Steady eye contact (without a charlie manson "LOCK ON" effect) = good.
• physical comportment. Neat clothing, sitting up straight, hands calm = good. Slouching, messy appearance = bad.
• body language. Turned away, folded arms = bad, defensive. Directly facing partner, arms open and relaxed = good, non-threatened and non-threatening.
• tone, volume, and rate of speech. Calm and measured, with good forceful volume = good. Rushed, staccato = not as good. Too Loud = not good. Too quiet = not good.
• appropriate formality. "dude, this one project I was on was sooo friggin radical." = bad. "I can speak from my professional experiences...." = good
• empathic attractiveness. If they like you, they will believe you. That means use the person's name, immediately after learning it. "Hello, John" is better than "Hello". Let them see your hands. Remain positive and constructive.
• willingness to engage. A direct response = good. Diversionary tactics = bad. No one diverts on purpose, but you will do so reflexively if you lack confidence in yourself around a particular topic.

All this comes from practice. People judge you, implicitly and instinctively, within 7 seconds of first meeting you. Therefore it's important to smile, deliver a firm handshake (but not too firm), introduce yourself in a professional manner, and exchange pleasantries in the very first moment you meet a potential client, employer, or boss.

The last thing that is super important to confidence is competence. You must be comfortable with your own competence. You must have a solid belief in your own competence in order to project that to others. If you are in doubt of your own abilities, that will be communicated, in some way, no matter how hard you try not to do so.

If you lack confidence in this or that particular area of questioning, read up on it, discuss it, understand it better. And then, you will gain confidence.

Answer 3

Be confident and do not fart.

Answer 4

That "suspicious look in their eye" is either because:

• they don't know what they are talking about
• you don't know what you are talking about

We don't know which one it is, so it is hard to give advice. Make sure that:

• you don't talk around in circles and end up confusing everyone
• you don't talk too much (this will lose you an interview real quick)
• explain the concepts in a simple straight forward way
• try to use actual examples that you've worked with when talking about these concepts. Talking about a whole range of projects like life support systems and brochure web sites would show that your knowledge is purely academic.
• don't try to know everything, even if you do.