Wednesday 16 April 2008

Just a Little Bit Proud

What with the recent passing of Charlton Heston a newcomer had to step in and play the lead role of Moses in our local kindergarten's model Passover Seder* later today, and my son Jake has scored the honour, leaving me just a little bit proud.

Charlton Heston as Moses


Jake as Moses

Here are the lyrics to one of the more amusing Passover songs that the children will be singing today, recalling the second of the ten plagues that Moses called down upon Pharaoh (and the Egyptians):

The Frog Song (Shirley Cohen)

One morning when Pharoah awoke in his bed
There were frogs in his bed, and frogs on his head
Frogs on his nose and frogs on his toes
Frogs here, frogs there
Frogs were jumping everywhere.

Fittingly, both of his grandfathers will be in attendance, and I look forward to hearing reports, seeing photos and -- technology permitting -- video of Jake with his "overflowing beard" in action.

*The Passover Seder is a special meal in which the story of the Jews' escape from slavery in Egypt is retold and celebrated with food, wine and singing. The model Seder is the kids' version where they learn how it all works. It's a bit like a Christmas pageant, but with more food.

Monday 14 April 2008

Interview Questions for Candidate Software Developers

Basically I am looking for evidence of the following
  1. Smart
  2. Gets things done
  3. Communicates effectively
  4. Passionate about software development
  5. Has a solid technical foundation
  6. Quick learner
  7. Cultural fit (sense of humor, down to earth, enjoys working with others)
In the past I have written down my questions for candidate software developers 0n scraps of paper, which get lost. Here are some somewhat open questions:

Work history
  1. Why are you interested in this job / company?
  2. Why now?
  3. Tell me about a tough lesson from your last job.
  4. What are the key things that you have learned about maintaining and enhancing a pre-existing software system?

Object-Orientation
  1. What is the difference between a class and an object?
  2. What is an interface? Why are interfaces useful?
  3. What is inheritance? Compare and contrast single and multiple inheritance.

Programming Language Theory

  1. What is recursion?
  2. What is an advantage of iteration over recursion?
  3. What is an advantage of recursion over iteration?
  4. *What is a closure?
  5. *What is a continuation?

Agile (assumes some [claimed] knowledge)
  1. Have you worked in an "agile team" before?
  2. Have you read up about Agile / XP / Scrum?
  3. Explain difference between waterfall and iterative development
  4. Explain some of the XP practices (e.g. pair-programming, test-driven development, continuous integration, re-factoring)
  5. What's Scrum about? How does it work?

Testing
  1. Difference between manual and automated testing?
  2. Which kinds of automated testing have you used?
  3. In which areas is it trickier to test automatically
  4. Test first or code first? Why?
  5. *What is Design By Contract?

Motivation

  1. Favorite things about working in IT / software development?
  2. Worst things?
  3. What do you want to learn more about?
  4. Let me solve it and report back, or let's figure this out together?
  5. What are the key elements that make for a good team?
  6. Tell me about a cool tool, language, or technique that you have learned and applied recently.
  7. Favorite and least favorite programming languages that you have used professionally?
  8. Why?
  9. What's wrong with [favorite]?
  10. What's good about [least favorite]?

Of course, a lot of the interview is about gauging the tone (affect) of the response and following up on interesting responses.

Additionally, I usually do a pair-programming exercise / challenge with technical candidates, usually with a little design phase and some test-driven development. This tells me a lot, but it is time-consuming and can be quite draining (especially if it doesn't go well!).

Sunday 6 April 2008

Cross-ferretization

Cross-ferretization, n. The art of stealing ferreting out ideas from other fields and applying them to one's own.

In programming, there are many generic job descriptions:
  • programmer
  • software developer
  • software engineer
  • software architect
  • computer scientist
  • hacker
  • etc.
Each of these has its own connotations, some overlapping, some contradictory.

Recently I have been delving back into (physical) architecture, and finding out a bit more about that field.

(Physical) architects are the generalists in a once-unified field that has splintered into civil engineers, draughtsmen, builders, interior designers, etc. Consequently their training delves into many fields, and in practice they work with many specialists, especially on large projects.

So it seems reasonable that there is a role for (software) architects in the (virtual) world, although such titles seem to be largely self-bestowed and not really as well-defined as (physical) architects.

Another reason for the interest in architecture in software development is the influence of Christopher Alexander and his notions of patterns and pattern languages on programming. This gave rise, largely via the famous Gang-of-Four book, to the notion of patterns in software (although the notion of pattern languages) was not as widely imported.

For what it is worth, Alexander's original writings have always resonated with me in a way that the Gang-of-Four's have not. So the other day when I spied an attractively packaged little book aimed at (physical) architects and students of architecture, entitled 101 Things I Learned in Architecture School by Matthew Frederick, I purchased it with little hesitation.

Quick review: "101" is not just a book for architects, but for anyone with an interest in any kind of design. Many of the "things" are of general applicability-- I especially like #29, about the importance of being process- rather than product-oriented, and #45, which contrasts simplicity with complexity and informed-simplicity. Such of the ideas are really very general. Others are specific to architecture, either practical points or theoretical tidbits, often admitting useful analogies. Each thing is accompanied by an illustration.

Every field needs a book like this.