I have interviewed a number of candidates in the past, mostly on their technical skills. I also have been interviewed a few times over the years. There is one thing that I really dislike about technical interviews, it is the technical questions.

Now not so much the technical questions but the ones that ask about things like the “final” or “synchronized” keywords in java or the types of joins in SQL. I could concede that a few are fair game. They are sometimes used by managers to filter candidates. However in that case I would suggest something shallow and short that enables you to terminate the interview quickly and save time. Otherwise you risk two things. One the candidate may have a deeper understanding of the problem than the interviewer (and possibly than the person who wrote the question, especially for standardised questionnaires in large organisations) and therefore give an answer the interviewer misjudges as wrong. The other is that people who have no practical experience in the matter but only read a few books (say to get a Java certification) can answer these flawlessly.

So aside from my personal preference when I am interviewed, it seems to me these questions are typically of little value to evaluate the candidate’s possible contribution to a team or company. My personal approach is on the completely opposite side. I try to have the candidate talk about his experiences in some technical details. This provides more details about the actual work than what typically appears on the resume (and discovered in many cases that it was a lot less interesting than presented). It also gives me an idea on what the person actually did in the project described in the resume. I was never disappointed with this approach. And I don’t think it takes significantly more time to filter out bad candidates.

Now there is a third, rather interesting approach. I had the privilege to be interviewed for a job opening a few weeks ago. I was actually interviewed three times by three different persons. Two of them were asking questions in the bookish style (by the way there is always the pitfall in that type of questioning that you actually have the wrong answers). The third one (well actually the second one in order of appearance) started with the bookish questions but used them to trigger deeper conversations on the subject. I found this way of driving the interview extremely interesting. First from a candidate’s point of view you suddenly feel as if you were comparing notes with a peer rather than being formally interviewed. Which means that both the interviewer and the candidate quickly get a feel of how things would go if they were team-mates. It goes beyond the mere questioning to establish a rapport which in turn gives more useful information for both sides.

Unfortunately, my other interviewers at that company must have felt differently because I got asked twice the same questions plus a few that were inspired (or directly lifted ?) from logical quizzes and internet riddles (like the three blue hat). Also, by contrast, at no point during these other interviews did I feel like I truly wanted to work at that company…

I recently was given the following problem during an interview.

3 persons are in a dark room along with three blue hats and two red hats. Each person picks a hat randomly without knowing its colour. When the light comes, the first person expresses she cannot tell what colour her hat is. Same for the second one. The third one is blind and exclaims she knows which colour her hat is.

Let’s call the characters A, B and C in order of appearance and let’s express the solution space as binary numbers where 0 is blue, 1 is red. Solutions are expressed in terms of binary numbers representing CBA sates.

space = {000,001,010,011,100,101,110}

111 is not possible as there are only two red hats.

The uncertainty of A translates in {x,y in space such that x xor y = 001}
The uncertainty of B translates in {x,y in space such that x xor y = 010}

The solution is therefore the intersection of {x,y in space such that x xor y = 001} and {x,y such that x xor y = 010} which is {x,y such that x xor y = 011} or {001,010}

Therefore the third character wears a blue hat. The same result can be achieved using if then and else. However this way of expressing the solution shows more. For one it shows that the solution is symmetric around the third person as the narration indicated. It also makes it clear that what makes the solution possible is the di-symmetry in the number of hats. Which means that, it is as logical to solve the problem from the narrative as to go through the resolution steps. A quick text analysis shows the characters symmetry and the hats di-symmetry and leads to the conclusion.

You can also memorise the solution, or the steps, but it is not as fun.

It is really unfortunate I did not have the wit to come up with all that until I reflected a bit on the story. I am sure I would have made a better impression otherwise. Oh well…

The financial world is abuzz with what happened at Société Générale. Many among the professionals are surprised by the size of the loss but not at all by its possibility. Why ?

In the past 10 years the systems security has greatly improved: requirements on password composition, frequent renewal of passwords have done a great deal for that. A bit deeper a lot of things are logged, traced, recorded: phone conversations, e-mails, application use. Even deeper, applications support things like two person checks, roles, permissions to ensure that users are allowed to do only what they are supposed to and get appropriate approvals for this. I would not dare to contend that these protections and safeguards are completely foolproof but for most of the applications I know, hacking them is beyond the reach of a master in finance.

So what gives ? I will give a few examples.

If in a back-office the official procedure is to use cross checks to avoid errors (pairing in agile terms), what really happens most of the time is that operators will exchange their passwords to enable them to do the cross check alone. Why would someone do that ? Because otherwise everybody would have to be here all the time, for very long days, taking no vacations, not being sick.

In a front-office, as noted by some commenters, passwords are on yellow sticky notes inside drawers or underneath keyboards. Why would someone do that when they signed a paper saying they should not ? Because in many applications, other traders cannot act on each other’s trades. Or the procedure to be able to do so is too complex. Or one of them started a trade and it finalizes while he is out getting a cup of coffee. His colleagues naturally cover for him and breach those security checks to accommodate team work.

I will not pile on with users that have permissions they should not, permissions that are not timely maintained when a user changes role, the heavy use of excel for critical things, failures in systems and missing checks.

To simplify, back-offices are the production line and front-offices the sales/engineering force. I have not yet spoken of the risk control part because I have little experience in this area. Believe it or not, risk control has considerably matured and is now very important in many firms. It always hold veto power over the front-office. Unfortunately, without the back-office risk control is half blind (as the SocGen example shows). The sub prime crisis on the other shows that risk models have a hard time keeping-up with financial innovation.

So what is the point in this ?

A lot of ink was devoted to the idea that information systems were tricked to produce unreasonable exposure. The reality is that it is the actual (as opposed to written) processes of the bank that were taken advantage of. The point is that when people cannot work under the rules and procedures they bend them or they give up. Either way problems of this nature will happen. Empowering workers to make appropriate changes to the way they work increases productivity and quality (such as better operations reports in this case). This is the realization at the core of Kaisen in the Toyota production system, this is also the core of Agile methodologies.

After Cesar’s comments on You shall not compromise quality! and the obvious confusion between quality and qualities, I created the following simple analogy. I believe it conveys the point efficiently.

If your house is flooded, two plastic bags and some tape will be enough to keep your feet dry. The quality requirement (qualities) is that they do not have holes. The quality of the bag is measured by the number and position of the holes. If you are lucky they are all high on the bag and your feet may stay dry.

If you go fishing in a swamp, you should use specially designed boots. The quality requirements (qualities) are that they have no holes, are able to resist various environmental aggressions and that they are comfortable. The quality of the boots will be a combination of the comfort, sturdiness and water tightness.

Compromising quality is that you don’t apply the best practices, use the wrong tools (ever tried to knit boots or plastic bags ?), promising more than can be achieved (like trying to make a plastic bag with half the necessary plastic or making boots when the soles are above budget).

Final point, good boots are not cheap. Plastic bags are relatively cheap and can be used for lots of things but they easily break and end up polluting the landscape (who just thought Excel out loud ?!?).

Last week-end Agile in Action asked whether we (as professionals) should you always do what customer wants (and don’t skip the comments at least one of those is great, will give you pre canned arguments in such a discussion and its not mine) ? It concluded that if a customer wants to compromise quality the author would walk away. I would agree with him, when it is possible because it is very much the sign of a barbarian culture on the clients part.

The way I understand it,  quality is a measure of how well the software product finally delivered implements the desired properties (or qualities) and in particular the desired functionalities. In that context, compromising quality means that you are prepared to deliver a product that may not be fit for its intended purpose. Which generally really means they you want to go to the market as fast as possible, let the customer test (discovering in the process what they really use and how) and then fix the problems as fast as possible. In short a barbarian approach. I believe that stating it this way is actually acceptable because it means the client understands the implications of the choice to be as fast as possible (and it may even be ok to execute on this in very specific circumstances).

Obviously, this is exactly the kind of situations that Agile methodologies address best. They enable to discover the functionalities the client really cares about as well as how they should work. They enable to make the other -ilities emerge though refactoring when they become desirable attributes of the product. They enable to bring features to market as soon as they work (as opposed to before they are tested). They are more satisfying for both the client and the implementor.

In conclusion, rather than compromising quality for the things you need, drop the things you don’t. Unless your client wants to consciously sabotage the product and specify the bugs, truly making them features.

I referred some time ago to an article by Robert L Glass published in IEEE’s Software magazine entitled "Greece vs. Rome Two Very Different Software Cultures". You can purchase this article but I find it a bit expensive for a two pages column. It is based on The Olduvai Imperative by Peter DeGrace and Leslie Hulet Stahl. Unfortunately this book seems out of print (although it can be found from specialty book shops online).

The author of the article describes three work cultures. The greek one where workers are "(…) individuals or self motivated members of teams" that were behaving like contractors and the roman one where the worker is "(…) sacrificing himself for the good of the organization, giving up his individuality, and closely identifying with his group." are taken from the book. He adds a third one, the barbarian.

He goes on to describe the compared values of each culture (I would have to reprint the whole article to give them here and I don’t want to infringe on the IEEE and Robert L Glass copyrights). Let me go straight to the conclusion as it applies to Agility: "Greeks would fit pretty well in the Agile Camp, Romans would be working mightily to improve their CMM level, and barbarians would say "huh?" if you mentioned either one.".

The article finishes with an excellent tale (taken from the book) telling what many of us have witnessed for a long time. The roman produces a great deal of external activity and produces a lot of artifacts showing more productivity. He beats the greek who took time to think of a simple solution that did not display enough effort. But Robert L Glass adds that in reality the barbarian wins by coding like crazy, introducing tons of bugs and then saving the day by fixing them. The barbarian, in our current software culture will be celebrated as a hero.

I know it is a very sad story. I blame Microsoft Windows a lot for that, having ingrained in the popular culture that bugs and crashes happen and are a normal part of software. But that is only my personal nag.

This is sort of my bottom line for this conference.

I was very happy with it. Most of the talks tickled my imagination and that is the primary thing I was looking for. Many others gave me details on more technical subjects that I wanted to learn about.

I was a bit disappointed by the overall scientific level, meaning that a lot of the talks were about practical, particular experiences and I would have loved to see a bit more of hard science on the program (or maybe there was and I did not pick the right sessions). It also seemed to me that the overall computer science (and more broadly science) culture level was low (once again this is my perception, I may be awfully wrong, please feel free to flame me in that case) which made me reflect on Neville Holmes complaints in IEEE Computer about the training of software practitioners. This coming from someone who has mostly abandoned the scientific practices and principles I was trained with.

One final perception about this conference. All the speakers seemed to be familiar with each other and had made similar presentations in other conferences. The really good part about this is that all the sessions are sort of tied together. On the other hand it made me wonder if we were not falling into group think: a group of people with similar opinions reinforcing the consensus while (consciously or inconciously) excluding dissenting thoughts. This feeling is even stronger when the ties of many of the participants with thoughtworks are made visible.

Anyway, bottom line is it was great but, there as anywhere, you should not forget to be curious and skeptical.