Category Archives: General

Interview Skills for Developers


My company has been considering hiring another developer.    It got me thinking about some concrete things to do in preparation for an interview.  This is not an exhasutive list, just some ideas I jotted down at lunch.

  • Think about stories that demonstrate your experience and successes
  • Ask questions in the interview to learn what it is really like to work in the company.
  • Be ok with saying “I don’t know” instead of being vague or making things up.  On the other hand, having an idea of where to start after “I don’t know” seems like a good thing.
  • Rember that the interview team is listening to you talk and comparing that to your resume.  Be consistent!
  • Remember to look around at interview participants – not just one person
  • Ask questions to learn about the viability of the organization
  • Listen to what is said and not said during the interview conversation to better judge the organization culture
  • Assess the interview pace – fast, medium, slow.  What is that telling you?
  • Know what you want – for example, intellectual challenge, opportunity to make a certain amount of money, risk aversion.
  • Work style – collaborative, competitive, dysfunctional, individual

Like I said, this was the output of some lunchtime thinking.  There are tons of good resources out there – a little bit of awareness during an interview can help out alot.

Trust on the Other Foot

Who do you trust?  Your family?  Significant other?  Your colleagues?  Your client? Your dog?  Your goldfish?  The somewhat wilted potted plant in the corner?

The “who do I trust” perspective is common to all of us.  But it is really only half of the trust equation.

There’s the “Other Trust” I sometimes forget about.  And when I do, it smacks me in the back of the head and giggles.

Then, I stop and ask myself  “Who trusts me?”  and “Why?” or “Why not?”.

I’m working on doing this before I get whacked in the head.  I recommend thinking about the “Other Trust” once in awhile.  It’s a good way to check on the quality of your relationships – and how you are doing with them.  Before you get smacked in the head 🙂

WiFi Encryption

There are several different encryption options for Wi-Fi devices.

 These include:

  • WEP – uses RC4
  • WPA-Personal – uses TKIP encryption
  • WPA2-Personal – uses AES encryption
  • WPA2-Mixed – uses AES or TKIP encryption
  • WPA-Enterprise – uses shared key
  • WPA-Radius – integrated user authentication


OOAD Process

I’m jotting this down for future use.


  1. Domain model
  2. Functional requirements
  3. User stories/use cases
  4. Robustness analysis
  5. Sequence diagrams
  6. Code

This is based on some initial reading of the ICONIX process.


  • Class design
  • Class implementation
  • GUI design
  • GUI implementation
  • Database design
  • Database implementation
  • Refactoring of all system elements as required
  • Unit testing
  • Continuous integration
  • Keeping cost of change in system low
  • Architecture – identification of major blocks – hardest to change

Software Quality Assessment

I recently came across some questions about software quality that got me thinking assessing existing software. As a software developer and consultant, I’ve participated in many conversations about software quality. Here are some tools I’ve used in conversations about software quality.

1. Atrtributes of software quality of an existing system

Some of my principal concerns with software quality when I’m evaluating an existing system include:

a) How well does the software meet the user’s needs
b) Can an average user make use of the software reliably enough to get to a desired outcome
c) Ease of maintenance and enhancements
d) Technical soundness of system, primarily severity and number of open defects, frequency of system errors and crashes, and perception of stability by system users

2. Convincing others of your assessment

Historically, I’ve not been successful jamming ideas into peoples heads – they seem to get upset and resist. However, if I can involve them in a conversation about quality – and try to understand their perception – and set an example for them, often we are able to come to terms on a common definition. Even if it isn’t perfect, at least I know what to do to meet their expectations (today).

I recently read a story that I think describes this idea. Two developers walk into a village – and are told by the villagers there is an evil monster on the loose – and point to a watermelon. Both developers want to help the villagers understand that watermelons are not monsters. The first developer attacks the watermelon, easily defeats it and proceeds to eat it – trying to show the watermelon’s helplessness. The villagers find this killing and eating of monster flesh monstrous. The second developer lightly agrees with the villagers – and proceeds to share his knowledge of melons.

My short answer (now that I’ve dragged you through the longer one) is that I try to get them to convince me. Often we end up in a mutually acceptable definition – sometimes we don’t.

3. Quantifing software quality

Anything can be quantified (e.g. this software has blue quality). However, we lack rigorous, well defined industry standards to allow us to do this definitiely for all software systems. The final attributes of software quality are often subjective and context dependent. 

If an engineering team doesn’t have a scheme in place to quantify quality – it should create one. A basic scheme I’ve seen teams use in the past is:

  1. Number of open severe defects
  2. Client satisfaction with product
  3. User satisfaction with product
  4. Ability of engineering team and client to openly and effectively communicate
  5. Difference between desired frequency of use and actual frequency of use of the system
  6. Ability of client to operate and maintain the system
  7. Ability of the engineering team to evolve the system

4. Measuring software quality

A method I have used looks at some basic attributes of a software system for quality measurement:

  1. Outstanding defects and frequency (critical defects count more)
  2. User satisfaction with system
  3. Cost of ongoing maintenance for defect removal
  4. Future plans for system (low quality systems often have a replacement plan earlier than good systems)

5. Relationship between software quality and system scope, cost and schedule

I generally follow the old saying “Good, Fast, Cheap – Pick any 2”. Give me 2 degrees of freedom, and I have a fighting chance to still develop a system of reasonable quality. Mainly because I can made meaningful tradeoffs to reach the quality goal. Nail all my feet to the floor, and I can’t move at all, and the Vorpal Duck comes and eats me.

6. Software Quality as variable constraint

I believe that tradeoffs between software quality and the variables of system scope, cost and schedule happen all the time. My typical goal is to make these tradeoff decisions as explicitly vs. implicitly. This requires reflection on the current situation and goals – as an individual and as a team. I believe that as system implementors, we represent the interests of our non-technical customers when developing the system. If we make tradeoffs by significantly lowering or raising quality, we should engage the customer in understanding the implications of the decision. Significantly lowering quality can cause the customer pain the future. Significantly raising quality can cause the customer possibly uneeded schedule or financial pain in the present. This now (d)evolves into a discussion of good enough software.


“I’ve made peace somewhere between my ambition and my limitations.” – (from the movie, Teahouse of the August Moon.)

Getting it right the first time is not nearly as important as getting it right the second time.

Wide experience makes for deep tolerance.

It’s easier to pull down than to build up.

The most important events are often the results of accidents. (Polybius)

Action is the antidote for despair. (Joan Baez)

We cannot direct the wind, but we can adjust the sails. (Proverb)

The shortest way to do many things is to do one thing at once. (Samuel Smiles)

If you cannot feed a hundred people, then feed just one. (Mother Teresa)

Tell me and I’ll forget; show me and I may remember; involve me and I’ll understand. (Chinese proverb)

Sometimes you gotta create what you want to be a part of. (Geri Weitzman)

Ideas won’t keep; something must be done about them. (Alfred North Whitehead)

Do not let what you cannot do interfere with what you can do. (John Wooden)

The world stands aside to let anyone pass who knows where he is going. (Author unknown)

You don’t get to choose how you’re going to die. Or when. You can only decide how you’re going to live. Now. (Joan Baez)

The deepest principle in human nature is the craving to be appreciated and the desire to be important. (Dale Carnegie)

It is useless for us to reason a man out of a thing he has never been reasoned into. (Jonathan Swift)

Start with what you can do; don’t stop because of what you can’t do. (Author unknown)

Whatever you are, be a good one. (Abraham Lincoln)

If you think you can or you think you can’t, you’re right. (Henry Ford)

Be the change you want to see in the world. (Mahatma Gandhi)

Great wealth and contentment seldom live together. (Bob Phillips)

For every failure, there’s an alternative course of action. You just have to find it. When you come to a roadblock, take a detour. (Mary Kay Ash)

Have you got a problem? Do what you can where you are with what you’ve got. (Theodore Roosevelt)

Most people spend more time and energy going around problems than in trying to solve them. (Henry Ford)

When the only tool you own is a hammer, every problem begins to resemble a nail. (Abraham Maslow)

It is easier to do a job right than to explain why you didn’t. (Martin Van Buren)

“Only the ideas that we really live have any value.”
— Hermann Hesse. German novelist and poet, 1946 Nobel Prize for Literature, 1877-1962

Stockdale Principle – You have to be realistic bout your current situation and yet stay optimistic about the future.


Have you learned something new recently? If so – pat yourself on the back! Learning can be hard work.

But – have you ever unlearned something?

If you aren’t familiar with unlearning – I refer you to the popular “Mythbusters” TV show. I know many people who can’t get enough of this show. They look forward to it each week. I think it makes people feel good to be able to say “I know this isn’t true” – so they can forget about wondering if it was or not.

Plus – they Mythbuster crew likes to blow things up.  That’s always a good time!

I’m going to try to unlearn using underscores for private members in C#.

While this may sound trivial – I’ve felt need to change for several months – but it’s a habit that has crept into a couple of tools – and major chunks of recently delivered products.

Wish me luck!

What does “Done” mean?

Project manager walks up to you and asks “Is that task done?”. How do you answer?

My experience is that most people assume that they know what done means to the asker – and answer the question based on that assumption.

But – often, what “done” means needs to be discussed and possibly negotiated.

The Big Three

Among the soft skills I believe developers can benefit from improving are Leadership – Play – Improvisation

Leadership is all about change. IT is all about change. Solution developers are therefore agents of change. Nobody every says “Hey – let’s build a new system that does exactly what we do now!” New systems have new features, new workflows, new objects – new, new, new, new, new. Having a basic understanding of how change happens in an organization – and how to help facliltate it will serve developers well. If nothing else, it can help to moderate the frustration born from over-optimistic hopes for change to evolve. It’s hard – it requires everyone to put their shoulder to the wheel. Nothing helps change happen than a good and hopeful attitude.

Hopefully you enjoy developing software systems. If so, then take the opportunity to go play with something that is fun and excites you. One of the biggest complaints people have about their jobs is that they get bored with their work. To have a successful and satisfying career, play! Take and hour and play with Ruby or Python or Excel or Javascript.

Improvisation to me is using leadership and creativity on the fly to solve problems, create new understandings, facilitate conversations and to form and maintain relationships. Organizations don’t work – but they’re the best we have right now. What makes organizations work and be effective are the people inside the organizations who try every day to fill in the gaps and smooth over the bumps to get something done. Organizations are tools for people to accomplish results.

Questions are the Answer

A favorite quote if mine is “Questions can shape our lives.”  I also believe the following:

  • Questions lead to answers.
  • Answers lead to actions.
  • Action leads to change.

What questions do you ask yourself? Are you asking “Why isn’t my life more exciting?” or – are you asking “How can I make my life more exciting?” Even better “What exciting new thing can I do today?” The more your questions are specific and achievable – the more likely the ansewr is to to lead to change in your life.

What questions do you ask others? “When are you going to get that report done?” or “Did you do the laundry yet?” Are other’s questions implicitly giving you direction. Direction that you may or may not deserve or want. Can you get others to reshape their questions? “Do you have time to finish that report this week?” “I’m out of white shirts – are you doing laundry today – or should I put in a load myself?”

How about “Will heaven be interesting?” “What does done mean?”