Yesterday a reader commented on my old post about Excel VBA interview questions. As I am, again, spending a lot of my time trying to recruit another developer, I thought I’d tell you about what my current interview plan looks like.

What we’re looking for is a reasonably senior web developer. We’re a small software company with just a handful of developers, so we need someone who can pull their own weight, with no hand-holding or detailed management. Everyone is expected to not just code but also contribute meaningfully to discussions about design and architecture. They also need to share our values and mindset – to value code quality, maintainable code, good design.

The interview is complemented by a coding task, where I email the candidate a 1-page specification for an application and evaluate the code they send back. I therefore spend very little of the interview talking about detailed technical matters. The interview is for me to judge their aptitude and attitude at a higher level.

This is not an interview script. I wouldn’t ask these questions top to bottom. It’s more of a checklist for areas that I try to cover during an interview. This is also not a prioritized list.

For the rest of this post, “you” refers to the candidate.

1. Fit

What kind of a job are you looking for? What kind of company would you like to work for? What is important to you in your work? Why are you looking for a new job?

What I’m trying to establish here is whether the candidate would fit our firm. If they are looking for a fast-paced competitive environment, or a firm with international opportunities, they’re not for us.

What would you like to be doing in 5 years’ time? What do you enjoy most about programming? Have you been involved in requirements or testing in your previous projects?

This is to detect the wannabe project managers and business analysts, and people who are aiming for a managerial role. Nothing wrong with those, but we won’t be able to offer them a meaningful career path in our company. This is also to detect the pure programmers who have no interest in anything outside of code, who will consider testing and requirements work and usability studies to be “not their job”.

2. Passion, learning, interest

How do you keep up with current topics within the industry? Do you read any books? Blogs? Do you do any programming in your spare time? What’s your favourite tool?

Here I try to figure out whether programming is “just a job” for them, or whether they are truly interested in and passionate about writing software. It isn’t necessary for the candidate to do all of this, to read books and blogs and have hobby projects – but if they do none, it’s a great big warning sign.

3. Technical insight, critical thinking, big picture thinking

Explain the purpose of a recent project you worked on. Explain the design and the architecture. What choices and alternatives were considered? Why did you make the choices you made? What would you do differently if you had to do it again?

This separates the “drones”, the passive followers from the active minds. Even if the candidate wasn’t in charge of the project they describe, they should be aware of design choices and trade-offs.

Did you use an Agile process? What were the advantages and disadvantages? Did you use test-driven development, or unit tests or automated tests of any kind? How did that work?

If in this day and age the candidate has nothing to say about unit testing, they are not for us.

4. Some technical questions

This is a bit of a smorgasbord; I pick the areas that are relevant for the candidate’s area of strength. SQL and OOP for back-end developers and JavaScript and CSS for front-end candidates.

The home coding task tests general programming skills. Here I focus more on the specific technologies we work with. This whole area also ties in with #3, i.e. their ability to make trade-offs and informed choices.

OOP: Explain to me a design pattern that you have found useful. Why? Explain to me the purpose of the Single Responsibility Principle.

ASP.NET: Explain to me some different ways to save state between page requests. What are the pros and cons of each one? Which ones did you use in your last project? Why?

SQL: I give them an example table and ask them to write or dictate to me some simple queries against that table.

JavaScript: Explain callbacks, and why they are useful. Explain closures, and why they are useful.

CSS: Tell me about what you would use to build a page. Divs or tables? Why? How can you position a div – how can you center it, put it in a specific position on the page, etc.

5. Leadership and self-leadership

What was your role in the project? What were you responsible for? What are your weaknesses?

We need people with drive and initiative, who are able and willing to take on significant responsibility. The weaknesses question is mostly a basic indicator of self-insight.

Do you know any good developers in the Stockholm area? Send them to me!

ReQtest, the company I work for, is looking to add two more developers to our team, one for front-end work and one for the back-end. The foundation for our application is ASP.NET and C#. On top of that the front-end guy needs great JavaScript and CSS skills; the back-end developer needs experience of database development.

We’re a small and growing company so we offer lots of responsibility and variety in the daily work, and a say in just about all matters regarding both the product and the company. We use an Agile development methodology, and we value code quality and usability highly. It’s a great place to work.

Read more on monster.se: front-end developer, back-end developer.

Ingrid spends quite a lot of time with the iPad. The apps she uses most (apart from a movie player app) all come from one studio: Toca Boca. They make a variety of apps, some better than others. Originally the best ones followed a common structure but now they are branching out into more different kinds of play. We have every single one except the Helicopter Taxi which needs the iPhone camera to run.

I was going to list Ingrid’s favourites but then I realized that she loves almost all of them. Some days she plays one, then another day another app gets more time, and after a few days she comes back to the first one again.

Toca Tea Party

There’s Birthday Party and Tea Party, where you start by setting a table, choosing plates and cakes, and then proceed to eat the cakes and drink the tea and lemonade. These have great multi-touch support and work very well for several players. I believe that kids are supposed to invite their stuffed animals to the tea party but Ingrid usually plays with me instead.

Then there’s Toca Store, which is sort of similar but more clearly meant to be played together. One person takes the role of shopkeeper, the other is the customer. The shopkeeper chooses which items to sell, sets their prices, rings up the items on the till. The customer picks items to buy, counts up the coins, puts the stuff in their bag.

Of course you could play those things without an app, with actual physical items – and we have. But the app is 5 seconds away whereas setting up a tea party with real toy plates and cups takes time, so Ingrid is infinitely more likely to use the app than the real thing.

A bit similar is Toca Robot, where you build a robot by picking body parts for it. The graphics are well made and fun to look at: the robots can have arms with propeller attachments and a body like a fridge. When the robot is done you can fly it through a simple maze to pick up gold stars. Updates to the app have brought new varieties of each body part, as well as new mazes, so Ingrid keeps returning to this app.

Toca Robot

Toca Hair Salon and Toca Kitchen are two of a kind – you get some materials and can perform some actions on them. Cut, blow dry, comb, wash, colour hair; chop, fry, boil, mince food. I’ve found these somewhat disappointing – they sound like more fun than they actually are. In Toca Kitchen the choices are too limited, and they’ve skimped on the graphics: the results look dull. Frying things just makes them brownish, for example, so frying an egg doesn’t actually result in anything that resembles a fried egg. In Hair Salon the hair is difficult to control and the results are all too similar to each other, except for the colour and accessories, so what sounds creative boils down to a painting app.

Paint My Wings is actually a painting app where you paint the wings of a butterfly. The wings are mirrored, so whatever you paint on one wing also turns up on the other. There are other nice touches such as the butterflies talking to you (“that tickles!”) and using berry juice for the painting, making this a bit more interesting than just a plain drawing app.

Less open-ended is Toca Doctor which consists of a bunch of puzzles and mini-games. Ingrid liked these to begin with but they’re too simple for her now.

The building works here may be done but that doesn’t mean we’ve run out of work. We have painting to do, lighting fixtures to buy (there’s currently no lighting in the entry hall, or the stair hall, or the walk-in closet), books and bookshelves to move from the bedroom to the office/library…

This evening, after both kids were asleep and our productive time began, we got started on laying stone on the flat bit of ground between the garden stairs and the stairs to the porch. It was already paved before, but when the new porch got built, the upper flight of stairs became wider and moved slightly, so we ended up with an unpaved gap.

We chose paver blocks that come in a mixture of sizes, Fantasi Antik. We spent an hour and a half this evening designing a layout for the stones that we can live with.

Both Eric and I are “pattern people”: if there is a visual pattern, accidental or intentional, we cannot help noticing it. And if that pattern is in a place where there isn’t supposed to be one, it will keep catching our eye and irritating us. Like a visual itch. It often happens with cheapish printed products – cheap laminate flooring, fabric, wallpaper – where the pattern repeat is too short.

So we wanted to make very sure our paving is sufficiently random. In particular, no too-long unbroken lines, and no too-large rectangles of blocks. For example the long unbroken line down the middle of that marketing photo above would be a clear no-no.

It was almost like a computer game. Except with pixels of 70x70mm, weighing over half a kilogram each. And instead of trying to make order, we tried to make randomness. Sort of an anti-Tetris.

Yesterday’s comic at XKCD includes an interesting bit of Wikipedia trivia: “if you take any article, click on the first link in the article text not in parentheses or italics, and then repeat, you will eventually end up at "Philosophy"”.

I tried a few random Wikipedia articles (a random link from the Wikipedia front page, cucumber and Georgia) and it worked in all cases. The tendency became obvious after just a few hops: we skirted linguistics, science, then information, and via quantity on to philosophy.

From philosophy it’s six hops back around to science and you can go another round. The full loop is Science > Knowledge > Fact > Information > Sequence > Mathematics > Quantity > Property_(philosophy) > Modern_philosophy > Philosophy > Existence > Sense > Organism > Biology > Natural_science > Science. So you could equally well argue that all Wikipedia queries have their root in Existence, or in Knowledge, or in Information. Whatever you think is the most fundamental of all – take your pick.

Now some developer has actually made a tool for you to try this on your own: xkcd wikipedia steps to philosophy.

My first day back at work. It wasn’t a good day for going back to work: Adrian’s teething cough transformed into a plain and simple cold during the weekend and he was feverish and unwell all day yesterday. Neither of us got much sleep during the night. And he was totally not interested in food and just wanted to nurse, so I left Eric and him with a bottle and a heavy heart – and hurried back as soon as I’d finished my half-day of work.

In the end they managed pretty well of course, and Adrian had accepted the bottle, but he was happy to nurse when I got home.

At work I spent most of the day getting my new computer up and running and installing Windows. Installing stuff is, I think, my least favourite task at work. I’d rather scrub the kitchen than battle with network card drivers or look for the right download files on MSDN. A gazillion flavours of Windows 7, all of them with long names that look almost identical at a glance, so finding the right one is a real chore.

By the time I left the office my lower back hurt. Even though I only worked a half-day, and I do not sit still when sitting in front of a computer. I am just not used to this much sitting any more.

I had also forgotten that it is a good idea to bring something to read on the train.

Ingrid uses me as a random number generator occasionally, although she doesn’t of course know that that’s what it’s called. “Gold star or gold heart?” she asks me, or “Dora or Bolibompa?” – and then makes some sort of decision based on my answer. Last time I think it was to decide the order of eating her breakfast.

Ingrid is good at keeping Swedish and Estonian apart. When she mixes, it’s mostly semi-intentional: if she doesn’t know the right word in one language, she may borrow from the other.

But then there are some cases where she’s picked one word and keeps using it in both languages, even though a word with the same sound exists in that language and means something completely different. She does it very thoroughly and uses the grammar of the “surrounding” language, which makes it sound even more surreal, and even harder to figure out unless the listener knows both languages.

Thus, we have doppa (to dip) in Swedish – often used at mealtimes because she likes dipping bread in soup, dipping pasta in ketchup, dipping carrots in milk etc. No matter how many times I refer to it as “sa kastad” in Estonian, she keeps saying “ma topin”, which means “I’m stuffing”.

Sticking/piercing (as in sticking a needle in something) is called torkama in Estonian. Ingrid keeps saying torka in Swedish sentences, too, but torka means to dry in Swedish. So when she wants to say “I want to stick the potatoes” (to see if they’re done) she says “I want to dry the potatoes”.

A mug is called kruus in Estonian, and Ingrid keeps calling mugs krus in Swedish, too – “pappa kan du ge mig den blommiga krusen”. But krus in Swedish means ripple, crimp, although there is also an older word meaning large jug. An arrow is called nool in Estonian, and Ingrid uses that in Swedish, too (“vi ska gå dit nålen pekar”), but nål means needle in Swedish.

This is sort of funny to hear, but it is also interesting to observe, because in most cases, when I think about it, the words may mean different things in the two languages today, but they probably share a common root and origin. Needle / arrow is an obvious pair, mug / jug likewise. The Estonian language has gotten a lot of words from its various Germanic neighbours and conquerors, and it’s interesting to see just how deep such loans go, how common and quintessentially Estonian the words now feel. (The homophony of pierce / dry, however, looks to me like a total coincidence.)

While I was away in Estonia, SIFO (a Swedish polling / market research firm) sent me their Sverige Nu 2010 questionnaire (Sweden Now 2010). A few days ago I finally finished filling it in.

Filling in the questionnaire took a while – the questionnaire is 40 pages, all of them packed with checkboxes. There are so many boxes it becomes physically tiring to check them. Not all of the boxes need to be checked, of course, but I counted 87 checks on the center spread, which is reasonably representative of the whole thing.

I like questionnaires. I like seeing what kind of questions they ask. What is important to these people? What do they care about? And I like answering them, because I think in many respects my answers are different from the average respondent’s. I feel like I provide some balance and perspective to their data.

In this case, the focus of the questionnaire was on two things: what do I consume (and what could I be induced to consume), and what does my media consumption look like. On the whole, I got a distinct impression that this data will primarily be used by all kinds of firms to plan their advertising strategies.

How much do I earn? How much do I spend on clothes? Which hobbies do I have? What capital goods do I have in my household?

The categories for my spending were a bit odd: very detailed in some cases and yet not comprehensive. But when seen from an advertising angle, the questions all started to make more sense.

(First they ask me how much I spend on women’s clothing. Then two rows further down they ask specifically about underwear. Or, to take another example, there are separate categories for each of wine, spirits, and beer, and a category for weight loss products – but none for food, or household products.)

Which newspapers and magazines do I read? How often do I watch TV? Which channels? Which programmes? Which time of the day? Which Internet sites do I visit? (Some of this was spectacularly boring to answer. I watch no TV, I read a single Swedish newspaper and a single Swedish magazine, and visit almost no Swedish web sites. Swedish ones were the only ones they cared about, and a few large sites like Google and Facebook. Swedish companies aren’t going to advertise in the Economist or on NYTimes.com after all.

There were also some questions specifically about my opinions about advertising – what are my views on ads on TV, Internet, radio; do I open unaddressed mail, etc.

The other interesting thing about this questionnaire (apart from its unstated and yet clear focus on advertising) was its unevenness.

Some questions are very broadly applicable and SIFO will likely be selling those data to many of their customers. Other questions appear to be included by request of some specific company. (“How often do you visit Casino Cosmopol?”)

The questions appear to be designed by different people, with no one person responsible for co-ordinating the entire thing. Many questions have a scale of responses: how often do I do something, or how much do I spend on something. The questions will naturally have somewhat different scales – some things you do frequently, others less so. But the scales sometimes differed in detail when the overall range was similar. E.g. one question might have the alternatives “never, a few times per year, a few times per quarter, a few times per month, every other week, every week, daily / almost daily”, whereas another would have “never, a few times per year, a few times per quarter, a few times per month, 1-2 times per week, 3 times per week or more”, and a third would have the same as the second but add even more detail at the end. A few more hours of work would have made the whole questionnaire easier to use. At least they had a clear layout guideline – the smaller amounts always came first.

Some questions had noticeably badly designed response ranges. “How many times have you used the following sections of the Yellow Pages during the last 12 months? None, 1-2, 3-4, 5-6, 7-8, 9-11, 12-14, 15-19, 20-29, 30-49, 50+”. Who could possibly recall if they opened the Yellow Pages 6 times or 9 times in the past year? It’s going to be pure guesswork, and not very reliable data.

This is my summary of Nathaniel Schutta’s “Making web apps suck less”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

[various examples and illustrations of bad usability]

What does usability include in web apps?

• Learnability
• Efficiency
• Memorability – how easy is it to pick up an application again after a few months’ absence
• Handling errors
• User satisfaction

How much should you focus on each of these? As usual in software development, the answer is “It depends”.

• How many users will the system have?
• How often will they use it?
• Will they get training?
• Do they have alternatives to using your application?

How do you find usability problems?

• Ask users
• Watch them
• Try doing it yourself
• Just as comments are a code smell, (the need for) documentation is a usability smell. Warning signs include post-its stuck to the screen, looking things up in the manual.

Paper prototyping is a powerful tool for evaluating usability. Test them with actual users!

My opinion: A good intro for those who have never given usability much thought. Luckily we’ve come a bit further than this with our application.