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.

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!).

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.

Bit rot vs Re-usable code

The intellectual property in a software company is diffuse. The explicit IP can be found in patents, papers, documents and, above all, the code base. The tacit IP exists in people's heads.

It is the tacit IP that allows for innovation and change. Indeed, a good way of understanding the possibility of change is the extent to which the maintainers of the software have a theory of how it works. If they do, they can change and extend it. If they cannot they are likely damaging the conceptual integrity of the code-base.

In The Worthlessness of Code James Turner advocates regularly rewriting to ensure that the software development team understands what they are working with, and in-particular, so that the original designers effectively refresh and transfer their knowledge to new hires.

In the comments the rebuttals of "continuous re-writing", and "re-usable code" are raised. Personally, I sympathize with Turner. I used to have a motto: Before re-use, use. This mocked the scenario of people trying to writing libraries or frameworks that would be used multiply, before being deployed successfully even once. Oy! The better alternative is to extract, abstract and generalize after an initial success or two.

What about libraries? The good ones do have a long life. This comment from the Reddit comments on Turner's article draws an important distinction:

How about "reusable code is an asset, single-use code is a liability"?

I like this idea. There is the abstracted, cleaned stuff that ends up in libraries, and gets re-used, and there is the more scripty stuff that glues things together and gets the short-term job done.

This raises the possibility of a new, somewhat informal metric: Ratio of multiple-use (quality code) to single-use (get-it-done code).

What makes X hard?

Mark Guzdial has written a nice article, What makes programming so hard?

But I say, "Programming: Easy. Dancing: Hard." What he is really talking about is the bimodal nature of skill acquisition. In many areas: Some people really get it; and others don't get it at all, and then there is the group in the middle who kinda get it.

Of course this, split is not accepted in certain fundamental skills: Talking, walking, self-feeding, toileting, where only those with significant disabilities are excused a reasonable competence.

In fact, everyone will find many things hard and many things easy. For example, when I audited a drama subject as part of a teaching degree I found a bunch of (lovely) people who united in their terror of mathematics. In my mathematics subjects, I am sure that I would have found some who felt the same way about getting up on stage.

So what are the elements of (basic) programming?

* Composition
* Decomposition
* Visualization
* Precision and clarity
* Use of and acquisition of formal language
* Memory
* Planning
* Logic
* Numeracy

Deficiency in any of these is likely to lead to frustration. But I maintain that there are two qualities that are necessary for any kind of learning:

* Wanting to learn X
* Patience when an element of X does not come easily

Another factor is having learned something in the past which interferes with the new area of learning. Examples:

* Tennis requires a firm wrist on impact; squash a flexible wrist
* Riding a bike caused me to almost throw myself off an adult-sized trike
* My English grammar makes it hard for me to adapt to Hebrew
* "You can teach anyone Lisp in 1 day, but it takes 3 if they already know C" (the use of parentheses is radically different)

If someone really wants to learn something, and is patient and quietly determined, and has access to an instructor who can help in the basic areas, learning is possible, and may be surprisingly fruitful.

One test of a dance teacher is whether (s)he can teach someone who lacks a sense of rhythm or is uncoordinated can teach these fundamentals, not just so that they can be applied in learning dances, but are transferable to other areas.

Similarly for other teachers.

How many boys? How many girls?

I hadn’t heard this one before, but I like it a lot:

In a country in which people only want boys, every family continues to have children until they have a boy. If they have a girl, they have another child. If they have a boy, they stop.

What is the proportion of boys to girls in the country?

Apparently used as a Google interview question (not that I’m a great fan of puzzle-based interviewing).

My long solution first

Distribution of families as proportions of all families in the country:

½: B
¼: GB
1/8: GGB
1/16: GGGB
etc.

Let F be the number of families.

How many boys?

Since every family stops after they get a boy the number of boys is F.

Alternatively, we can count the contributions of the different families:

Total boys = F x (½ + ¼ + 1/8 + 1/16 + ...)

This demonstrates that the infinite sequence

½ + ¼ + 1/8 + 1/16 + …

sums to 1, which is also apparent if you stand 1 meter from a wall and 50 cm then 25 cm etc., etc.

How many girls?

Again we sum:

Total girls / F = ¼ x 1 + 1/8 x 2 + 1/16 x 3 + …

= 1/4 + 1/8 + 1/16 + …
+ 1/8 + 1/16 + …
+ 1/16 + …
+ …

= 1/2 x (½ + ¼ + 1/8 + 1/16 + ...)
+ 1/4 x (½ + ¼ + 1/8 + 1/16 + ...)
+ 1/8 x (½ + ¼ + 1/8 + 1/16 + ...)
+ …

= 1/2 x 1
+ 1/4 x 1
+ 1/8 x 1
+ …

= ½ + ¼ + 1/8 + 1/16 + ...

= 1

So, Total girls = F

Solution

Equal numbers!

Simplifying assumptions?

Birth rate of 50-50

• No multiple births
• Large population
• No account made of multiple generations

Even without these assumptions, I would guess that the solution roughly holds.

Simple solution

Each child born has a 50-50 chance of being a boy or a girl. Each birth is independent, and not influenced by decisions of this, or any other family, so naturally half are boys and half are girls.

What's important?

Computer scientist and mathematician Richard Hammond -- he of the Hamming Code -- used to ask his colleagues two questions. In order:

1. What the most important issues in your field?, and the follow-up
2. Why aren't you working on those?

Often this induced a cold-shoulder response, but others were grateful for the nudge.

I have been meditating on what the equivalent question should be in a business, as opposed to Science. My tentative questions are:

1. What are the most important issues facing our customers?
   
2. Why aren't we working on those?
   

From this it follows that deeply understanding our customers' issues is of paramount importance.