Cheating on interview tests ...

I never like rejecting resumes or people. I wish I could truly give everyone a chance to prove themselves. Unfortunately, the limited resources of a for-profit organization dictate that that some people get rejected without a thorough assessment of their abilities. We have to use a lot of different reasons to whittle down the huge list of applicants to a number we can actually interview.

Today I rejected 11 people (out of 43 finalists) for cheating stupidly.

We just finished a "programming party" 2 weekends ago. This is a recruitment event where we bring something like 110 students in over the weekend, run them through automated programming tests then hold a small party afterwards. The point is to give students a chance to see where we work and talk to our developers in an informal environment to find out what life is like in Exoweb.

We ran the tests using our older Exobench system, so the programming problems had been used for a while. Therefore I wasn't really that surprised that some of the candidates knew of the problems in advance. What I was surprised at was that so many of them blindly copied answers they obtained elsewhere without thinking it through. If they had, they would have found the errors that made it so easy to disqualify them.

The most glaring example is one of the test problems called Dominator. Given an array of numbers, the problem is to find out if there is a single number that occurs in more than 50% of the array. If it does, return it. It's a simple enough a problem and yet very useful for testing since it has both an easy (exponential complexity) and an ideal (linear complexity) answer. This gives us lots to talk about in the interview.

Apparently someone posted the code for the easy solution, except with one enormously glaring error - the code only searched half of the array, stopping its search at length/2. If you're looking for a number that takes up half the array, you can't evaluate only half the array since you don't know which half of the array this number might be in! This mistake showed up the most and no doubt there were some that honestly made this mistake. However, the cheaters were obvious because there were also other small mistakes that made their code identical.

An even more obvious copy was an ideal solution for another problem. Getting an ideal solution is rare and statistically, we see the ideal solution for this problem once every 400 tests or so. This time, we got 8 out of 110. That's almost 30 times what we would normally expect. However, 7 of the solutions had one glaring error - they forgot to consider an array of all negative numbers. In every single other case, if the programmer was smart enough to come up with the ideal solution, they would always consider the all-negative array boundary case. Somehow we got 7 people who suddenly made the same mistake at once ...

4 out of the candidates made both of these mistakes together (candidates do 4 random problems at a time). The rest made either one or the other. All have been rejected. I have been told that this is standard practice in local universities when a batch of identical exam answers are received.

There are still a few others that have suspicious answers (identical answers, including mistakes, etc) but they're not conclusive enough to reject. We'll take the chance with interviewing them. If they really did cheat, then we'll find out soon enough in the interviews.

I'm bummed out because I recognized a couple of the people rejected. They made very positive impressions while chatting during the party and we were looking forward to interviewing them. Finding their names in the list of bad cheaters was really sad.

Such is life.

Getting promoted to the level you are performing at ...

Some of the stuff I write about aren't my own thoughts but thoughts from fellow front-line managers. In particular, today's thought comes from Cindy:

You do not get promoted because you are doing your job well. You get promoted because you have been performing at the next level long enough for people to notice and reward you.

This came out of a discussion about how some people (fortunately not from Exoweb) were thinking that just because they had just started doing well at their jobs, they were due a promotion/raise. Coming from the other side of the trenches, this doesn't seem really realistic to me.

First - you never promote lightly. For the most part, you cannot demote someone. You end up having to terminate that person if you make a mistake. So until you are absolutely sure this person can perform at the higher level, you take your time with the promotion.

Second - humans have highly variable performance. Someone who is highly motivated today may be very demotivated tomorrow for no apparent reason. If what you are seeing is one of those peaks, promoting the person would be a mistake. One week later, the person could very be performing at a much lower level again. You need proven, sustained performance above the minimum level for the position to be promoted to.

Finally, a person doing well for the current position does not merit a promotion. Not unless you want the Peter Principle throughout the organization (people getting promoted to their level of incompetence.) A person doing well in their current position may get raises and bonuses, but never a promotion. Proof that one does well at the current position is rarely proof that the person would do better at a higher level. The skills are often different. The skills required for a software developer are different from that of an architect, project manager, etc.

Three Questions ...

This is the English version of Cindy's "3 Questions" blog post, written from a different viewpoint. As a bit of background, Cindy and I are both managers in Exoweb and one of our responsibilities is to carry out weekly chats with the people in our teams. Both of us have been asked these questions before and we figured it would be of interest to Exoweb people in general. I'm writing this without having actually read her post, so it should be interesting to see how our viewpoints differ.

The questions are:

• Does Exoweb give team members a chance to switch career paths?
• Are personnel evaluations transparent?
• If an employee makes a mistake, how will the company handle things?

Does Exoweb Give Team Members a Chance to Switch Career Paths?

Yes. We definitely prefer to use existing, proven and trusted team members to fill open positions, rather than taking a risk with hiring an unknown person from the outside. As long as the person appears to be competent and capable of taking the task, we are quite willing to take a chance.

We have had a few examples of these career changes so far, mostly people switching to project management positions. Two of our admin staff have switched over to project management roles in our software development teams. The admin team handles everything in Exoweb but actual software development, so is a lot more challenging than the name suggests. After battling with unreliable suppliers, organizing events for 40-50+ people and solving the problems that crop up in daily office life, they have proven that they are more than capable of getting the job done. That actually makes them very good project managers as they have the "get things done" attitude.

We had a software developer also try his hand at this a while back. He did a pretty good job at it, but after 6 months, found that it was really not something that he wanted to do and switched back to pure technology. This is also a learning experience that we are quite happy to allow our people to have within Exoweb - the chance to try new things out and discover if a certain path is for them. If it doesn't work out, such is life. You never know until you try and the experience typically makes you appreciate your chosen role more.

Are Personnel Evaluations Transparent?

Depends. We do our best to make obvious to the team member how they are perceived, both by team leaders and fellow team members. Depending on the team lead's management style and workload, we try to schedule chats between once a week to once every couple of months. During these chats, past accomplishments, challenges and issues are discussed, along with feedback on how the team member is doing. These chats are mostly informational and problem solving - for both sides to quickly identify and resolve issues that crop up. They also usually give team members a fairly clear idea of how they are doing.

Of course, not every team lead does things in the same way and there are large variances between each team. As a general rule we try to provide feedback, both positive and negative, as soon as possible and resolve problems before the grow too big.

However, we try to keep these evaluations as private discussions between team member and team lead. In this sense, personnel evaluations are very opaque. We usually do not make it obvious to others when someone is underperforming, even if the under performer knows very clearly that he/she is in trouble. Making this kind of information public while trying to resolve the problem is rarely helpful. We do share evaluations between team leads though, both for redundancy (in case one team lead has to take over for another) and also as knowledge sharing (e.g. how to handle situation x).

If An Employee Makes a Mistake, How Will the Company Handle Things?

In one of the management books I read many years ago, I came across a great story about making mistakes. Unfortunately, I no longer recall where it comes from (if anyone recognizes, please let me know!), but it goes something like this (heavily paraphrased):

There was a young man who had just joined Mega Corp, a huge organization with many capable and talented people. Being very eager to prove himself, the young man throws himself into his tasks and pushes himself to the limits of his abilities. Unfortunately, his eagerness results in him making a huge mistake, one that ultimately ends up costing the company USD10 million dollars.

This young man then walks into his manager's office, confesses to his mistake and finally ends with, "I guess you want my resignation now?"

His manager looks at the young man with a incredulous expression and replies, "are you crazy? We just spent 10 million dollars training you! How can you leave now? Now get back out there and apply your newly gained knowledge to earn us our 10 million dollars back!"

Everyone makes mistakes. As long as one honestly did their best and learns from it, we recognize that this is only natural and move on. We work together with each other to try to minimize mistakes and compensate for each other. We spend less time figuring out who is to blame and more on how to ensure it will never happen again.

For the most part, almost all first-time mistakes are forgiven. The rare exceptions we've encountered are when someone makes a mistake so bad that trust is irrevocably broken. As a highly trust based organization, once someone proves themselves untrustworthy, it is simply not possible to continue working in Exoweb, no matter how much we like the person. Fortunately, it is very hard to make this kind of mistake. It has only happened once in my memory.

The Three Aspects of Management

Found myself explaining for the third time in a day yesterday about the three different aspects of management that I deal with in my work in Exoweb. Thought it best to blog about them, to put down in writing what I have had to repeat multiple times last week.

These are my personal opinions/divisions of course and have no grounding in scientific research. They are merely based on personal experience. However, all managers in Exoweb perform at least one aspect and some can do all three.

In my daily work, the three aspects I end up spending my management time on are:

1. Tech Management
2. Project Management
3. Human Resource Management

Technical Management

This deals with the actual work that needs doing and varies by department. It is difficult, if not impossible, to do this type of management without solid knowledge and experience in doing this task yourself. e.g. An Accounting manager must understand and be able to balance his own books before attempting to supervise a team. Likewise a senior software designer/architect needs to solidly understand software (object oriented or otherwise) design patterns and the abilities/limitations of the technologies used to be effective.

This aspect of management typically involves setting and maintaining general technical quality in a team. Properly done, this also involves mentoring and training to ensure that team members are constantly improving and requiring less and less management. This is not that frequently done in practice though.

This aspect appears to require the least social skills of the three.

Project Management

To me this has two separate components - client management and juggling tasks and resources to complete the project in time. In theory, they could be handled by different people but in practice this is so inefficient that it is not practical.

Client management requires the most communication skills of the two as it involves managing client expectations, negotiating resources and dealing with the inevitable problems that arise. Strong social skills are especially useful with the class of clients that requires you to wine and dine them.

The second component requires mostly a logical mind to figure out how to achieve the maximum value for the client given available resources. This requires not just understanding client priorities but also the best way to utilize the team to achieve these priorities. e.g. Can the manager arrange the tasks so that dependencies between them are minimized and the team functions like a well oiled machine? Or will tasks clash, resulting in periods of inactivity followed by frantic crunch periods? What are the deadlines coming up and can the team make them?

Some understanding of how the work is done is useful but not to the depth of the tech manager. We have a few project managers that lack a technical background but are still quite capable of carrying out this component of management. Strangely enough, gamers who enjoy strategy or RPG games often do well at this. Ultimately, they involve the same skills - maximizing results by carefully allocating scarce resources.

Human Resource Management

This is often the most neglected aspect of management - the understanding, combination, development and motivation of team members. It also cannot be delegated to the HR department. Both First Break All The Rules and Peopleware are full of studies that show it is the first line manager that has the largest impact on employee morale, productivity and development. All the HR processes and motivational posters in the world will achieve nothing if the immediate manager of a team member sucks at this.

It is easy to neglect this because it this type of management is a long term investment and the symptoms of neglect take so long to show up. Morale is rarely measured and there are many possible reasons for why productivity is suffering. It is easy to blame/focus on something else, especially when there are so many other tasks that obviously need doing. When clients are screaming about late projects, it is very hard to invest in long-term training, even when it is clear that the lack of certain skills among team members is the reason why projects are late.

In my career, the best managers I remember - the ones I was happiest and most productive working for - were the ones that knew exactly how to motivate the team. They may have been merely competent at the other aspects (in some cases minimally competent) but they were far superior to their peers in understanding what made their people tick. They knew how to combine people together so their strengths built on each other and their shortcomings were compensated for by other team members or processes. Working for them was a joy and it was amazing what a gelled team could achieve. It could easily multiply the productivity of a team.

Doing this is hard, especially for the stereotypically anti-social techie. It requires more than just social skills. The manager also needs to really understand the unique strengths and characteristics of each team member. Many company processes/managers treat team members as interchangeable machines that perform the same as each other, rather than the unique individuals they are, with individual needs. They are forced to do this either because they cannot recognize the individuality of their people or are unable to find managers who can manage in this way. This results in work processes and practices designed for the lowest common denominator - meant to protect us from our weaknesses. How much more enriching would it be to work in a place that recognized and allowed us to utilize our strengths and achieve our fullest potential?

Final Thoughts

There are extremely few people who can do all three roles well. Even finding people who can do two (e.g. Tech and Project Management) roles very well is very hard. We are experimenting within Exoweb with having specialists in each of the three roles. Although not nearly as efficient as having all the roles combined in one person (communication overhead is much higher) it has been proven to work with the first two roles. The jury is still out on the third role - we don't know for sure if it can be done by someone who isn't already doing at least one of the other roles. It is also such a sensitive function that we are reluctant to experiment too much with it.

There are so many different ways to manage and we're only beginning to figure out what works for Exoweb's culture and people. Ultimately though, I would stick to the philosophy best summarized in this quote: "that's what management is - it's not about how much you can do yourself. It's about how much you can help others do"

KISS (or why MS CS students have a bad time in interviews ...)

It's that time of the year when Master's students are hunting for jobs in China and we are flooded with resumes from students with Masters of Science in Computer Science (MScCS). We've spent the last couple of weekends interviewing the candidates that passed the front interviews and it has not been pretty. In fact, it has been pretty sad.

The biggest problem we encounter with MScCS grads is made very apparent in how they approach one of the our typical programming problems. This particular problem is fairly simple and with a little bit of thought, can be made into a linear (computer performs x more calculations for every element added to n, where x is a constant number) or O(n) type of equation. Most competent people will come up with a O(n^2) algorithm (computer performs n operations for every additional element added to n, resulting in rapidly increasing number of calculations per element added) to it at first, then after a little thought, realize that there are a lot of duplicated operations, refactor that out and come up with the linear solution.

MScCS are a little different - almost all the ones we have interviewed to date encountered this problem, probably came up with the O(n^2) equation ... then went off the deep end. They would inevitably come up with complex, fancy algorithms that utterly failed to solve the problem. These fancy algorithms would often handle the common case but fail on the boundary cases. They were fragile, easily tricked or prone to failure. When these flaws were pointed out, these candidates would come up with even more complex algorithms or add a lot more if/else checks ... resulting in even more brittle and unreliable code. None of them, if unaided, could come up with the ideal solution.

Well, that's not really true. One particular candidate, after coming up with 4 complex, unworkable algorithms, finally said, "well, since you have given me such a tight time limit, I have no choice but to brute force it." He then proceeded to give the ideal solution. Linear time, handles all boundary cases. But he would rather give 4 non-working solutions rather than the working, "inelegant" solution.

What I find strange and rather disturbing about these interviews is that it is somehow related to the mindset of those who are doing their MScCS. Bachelor level grads or people with several years of working experience rarely make this mistake. They either do it right or not at all. Yet for some strange reason, the MScCS students seem to value fancy algorithms over _working_ algorithms.

Maybe it's the MScCS curriculum here in China which tries to focus on fancy algorithms. Maybe it's just that the MScCS feel the need to prove that their abilities are above the norm for CS graduates. Maybe we just have incredibly bad luck with our candidates. Whatever the reason, extremely few MScCS fresh grads have passed our interviews. As you can imagine, in a production environment, we highly value working code and eschew the fancy algorithms, especially algorithms that needlessly complex. Simplicity and correctness is far more important in our craft.

The famous quote attributed to Brian Kernigham comes to mind:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

When writing algorithms, another quote from Agile development comes to mind - "do the simplest thing that can possibly work." Keep It Simple ... er, let's call it Keep It Stupidly Simple (KISS) and avoid insulting anyone :)

Interview Programming Problems

Another Saturday done, another interviewing round finished. Thought I would put down into words what I look for when reviewing the programming problems done by candidates. I don't really care if candidates know what I look for - if they can do it in an interview, they can do it in their daily work. Especially so when code reviewers are likely to be at least as watchful as I am in an interview.

As an illustration, I'm using a problem we previously used in our written tests. We replaced it recently because everyone answered it in almost the same way, making it useless as a differentiator between candidates. The problem is as follows:

Implement a function "intersection". The function takes two ASCII strings and returns an ASCII string containing only those characters, that are simultaneously present in both arguments. The result should be as short as possible. For example:

intersection("abde", "bexy") may return "be" or "eb"
intersection("exoweb", "candidate") should return "e"

Almost all solutions (that work) are variants of the same form. Below was the minimum acceptable code to pass first round screening in Exoweb, in a prettied up python format:

def intersection(a, b):
   intersections = ""
   for char1 in a:
       for char2 in b:
           if char1 == char2:
               intersections = intersections + char1
   return intersections

(trivia - usage of the "in" keyword is up to 3 times faster than a str.find() call on my laptop)

(trivia #2 - something like 50% of candidates who make it to the written test are unable to write even the above snippet. After this test, 90% of all candidates who have submitted their resume have been eliminated)

There are two problems with the code above, one pretty obvious (not reading the requirements) and the other a lot less so (performance problem). The first is repeated characters in the return statement and the second is an algorithm that does not run in linear time.

The first problem is easy. Given "aaabbb" and "bbbccc", the algorithm above returns "bbbbbbbbb". The problem specification says "The result should be as short as possible." Failure to read the spec or forgetting to check for this is bad, but not fatal as long as one spots this quickly.

The second problem is one that less than 1% of the candidates manage to avoid - algorithmic complexity. If strings a and b were of length n, the double for loops in the algorithm result in a O(n^2) algorithm. For every character added to the length of string n, the computer can end up doing up to n+1 times more computations. This quickly becomes impossible.

On my laptop, with a data set tweaked for the worst case scenario, I get the following execution times:

(n=1,000) 0.00372 seconds
(n=10,000) 0.29497 seconds
(n=100,000) 30.20992 seconds

For every time I increase n by an order of magnitude (*10), the execution time increases by roughly two orders of magnitude (*100). Following this progression, a value of n=1,000,000 would take around 3,000 seconds or 50 minutes!

This problem is relatively easily solved and there are multiple solutions. For those languages without rich libraries, one solution is to build a 128 char length array (the problem specifies ASCII, which is only 128 values) and to run through each string once, putting a value into the array to specify that the character was found. Once complete, it's a matter of scanning all 128 elements to see what was found in both strings. All these operations are in linear time. This has also the advantage of ensuring that the returned result has no duplicates.

For languages with richer libraries or built ins, you can also use hashed containers or even set data types. We disallow using Sets in python because it would simply be too trivial. In Python 2.4, Set data types are built in and the code would look like this:

def intersection(a, b):
   return ''.join(set(a).intersection(set(b)))

Sets in Java aren't quite so feature rich, lacking the intersection() method, so we still allow it in Java. A non-set method in Python, using just the standard built-in data types might look like this:

def intersection(a, b):
   char_seen = {}
   intersections = {}
   for char in a:
       char_seen[char] = True

   for char in b:
       if char_seen.has_key(char)
           intersections[char] = True

   return ''.join(intersections.keys())

With a n=1,000,000 string size, this takes 1.7 seconds on my laptop, much faster than the expected 50 minutes required by the inefficient, O(n^2) algorithm. With the n = 100,000 string size, the algorithm takes 0.18 seconds, the expected roughly linear decrease in time.

The algorithm above can certainly be optimized further, for different focus areas. Using two dictionaries does waste a bit of memory, and there are probably faster ways of doing this. There are probably readability tweaks too.

In our interviews, it does not matter if the code has flaws on the first try (it must work though), as long as the interviewee can understand the problem when pointed out and fix them. No one is perfect and mistakes are to be expected. We just try to minimize them and fix them as soon as possible.

Teaching Software Engineering

Heh. Having spent a not insignificant proportion of the last 1.5 years doing HR work, I feel a great deal of sympathy when reading of the plight of others when doing HR. Some amusement too, as I recognize the problems and issues faced.

Today's fun article comes courtesy of planetpython.org, regarding teaching the Waterfall method in schools. I wince in sympathy because almost all of the people I interviewed, if they knew anything about development, knew only this method. Yet it is a method we (as in Exoweb) know doesn't work very well for us.

It's a nice, sunny Saturday afternoon so I'm too lazy to ruminate on why schools put too much emphasis on the Waterfall method and SEI methodologies, but I have been recently rambling to colleagues about a few complaints I had with my own college experience in software engineering:

• Overly simplified
• Short term projects
• No Challenge

Overly Simplified

This is related to the Waterfall issue. I realize that colleges first try to teach us the basics, then try to teach us the more complex stuff. But sometimes, the basics are so overly simplified that we learn the wrong things. e.g. the Waterfall method. To me, the failure of the Waterfall method is the assumption that it is possible to get perfect requirements and that they will never change. Working life has taught me that no plan survives first contact with reality. That lesson was most painfully learned.

What is sad is that too many people I meet still stubbornly stick to what they were taught in college. I still see too many people/organizations spending months trying to gather all the requirements while competitors gain a head start by producing an imperfect but workable product. I see man-years of developer time spent haggling over little requirement details, only to find the client or market has changed requirements in the time it took for them to sort out the exact details.

Yes, requirements are important and it is the cheapest stage in the software development process to make changes. Cowboy hacking just as frequently leads to disasters. However, there is a point of diminishing returns and most people following the Waterfall process go way past this point. Agile Development offers the best middle ground that I have found to date.

So, to wrap up this section of the rant, if schools would quit simplifying stuff too much, the tragedy of the 1 year requirements gathering phase would not occur.

Short Term Projects

Almost all college projects are for the duration of a single class - a single semester of a few months in length. This means that a student typically spends an entire semester building a system that works, then forgets about it afterwards.

The problem with this approach is that, like construction, it is much easier to build a small shack than it is to build a skyscraper. If you are just slapping a few pieces of wood together to cover some random stuff in your backyard, you really aren't concerned about how good the foundation is or if the darned thing collapses a few months later. It's not that hard to rebuild it. On the other hand, screw up the foundation of a skyscraper and very horrible things happen. Like software, those screw ups become apparently very late, when the cost of changing things (or failure) is very high. Yet the one semester projects mostly teach us the habits required to build small shacks.

Challenge

There is a quote from Peopleware that I enjoy about good builders:

"The minimum that will satisfy them is more or less the best quality they have achieved in the past."

This seems to be true for myself (not that I consider myself a great builder) and for many great developers that I respect. I cannot be sure that this applies to everyone, but it seems true enough for most.

The problem is that most schools don't really hold their students up to high standards or even show them that it exists. If the "best" that they've done is code that doesn't even compile (I know quite a few professors don't even bother to check this), then they will always be satisfied producing crap because they don't know any better.

I see this in some fresh grads that I interview - they are, in theory, some of the smartest kids graduating that year from their college. They have the highest grades, they've achieved more than their peers ... they think they are the king of the world. The only problem is that compared to the truly best in the world, they are crap. They don't automatically strive to improve their code, they use suboptimal algorithms, miss various corner cases, etc.

I have had classmates that have graduated after 2 years of courses taught in C++, yet still not know what a pointer is. I have interviewed candidates who graduated with a bachelor's degree in computer science, but have never written a line of code in their life. These schools do a great disservice to our profession and society in general (i.e. think of the cost of all that crappy code out there).

I know this has been suggested before by others, but perhaps one thing that would make things better would be a minimum competency exam, administered by a certification board. Professions such as law, medicine and accounting all have professional organizations that set minimum standards and administer an exam that all practicing members of that profession must pass in order to practice being a lawyer, doctor or certified public accountant. Perhaps we are approaching a time when software developers too must meet a minimum competency before being allowed to work on things like nuclear power plant controls or medical equipment. I know I would sleep better at night knowing my pointer-incompetent classmate was not writing the code for medical equipment that would one day be used on me.

HR at Exoweb

Greg and I got curious this morning about what our interviewees were writing about their experience on the web and decided to do a bit of searching. This ended up in me getting curious about a batch of HR related matters. Final result is a bunch of weird trivia:

Interview stats:

• Distinct resumes received in February: 1308
• Called for pre-screening interviews: 186
• Passed pre-screening: 19
• Job offers given: 3

Ouch. We have a huge attrition rate (0.2% get offers). Will write in more detail about the transition from stages 1-2 and 2-3 in later blogs and what typically kills a candidate.

Other fun tidbits we found from scanning bbs posts:

"Those guys must be poor! They're sharing offices with another company! Don't work there!"

Heh. When we moved to this office in 2004, Exoweb was all of 12 people, but we found this large space to renovate into a great loft. We ended up inviting 2 other companies owned by good friends (and fellow FOSS users) to join us. Since then, all of us have at least doubled in size, filling up the entire loft space and overflowing. Although it doesn't look like it, we actually take up the entire top floor of our building, except for one stubborn company that refuses to move out and give us total control of the floor.

"They have an all you can drink policy! Bunch of drunkards!"

We have an all you can drink soft drinks benefit. But I guess it doesn't help that some of the pictures of our office posted on the web have included pictures of "herb liquor tasting party" or "empty bottles after christmas party".

The Paranoid Programmer: From Junior to Mid

While chatting with a fellow developer, the question was asked: "How does one go about raising one's skills?" The answer to this sort of question is different for every person - every person has different talents and weaknesses and develops in different ways. At this moment in time, looking at the current Exoweb team, there are a few areas that I would particularly emphasize:

• Paranoia
• Mapper vs Packer
• Quality Plateau
• Knowledge Portfolio Investing

This particular entry is written mostly for Exoweb developers, but any feedback, comments or suggestions are welcome. Update 2006-01-15: Changed the title. Besides the fact that I've previously written something on what makes a senior, what I've written here will only get someone up to a mid level developer in Exoweb. There are a lot more things I left out on what makes a senior, like the soft skills.

Paranoia

Paranoia is good in a developer. Or perhaps some would prefer to refer to it as boundary checking. At any rate, it is always good for a developer to consider that Murphy's Law (anything that can go wrong, _will_ go wrong) is something we encounter far too often in our daily life. Once code is written and being inspected for improvements (you do go through your code again and see if you can improve it, right?), it helps a lot if the developer considers what can go wrong and how one can safeguard one's code against this.

As an example, one area that developers typically forget in web programming is url encoding. For instance, some insert usernames into the url as a variable. e.g. /user/john/details or /user_details?username=john. However, they forget that usernames can often include characters that are not legal in urls, such as spaces, &, ? or others. Worse, they may not even be ascii. In our global environment, it is no longer uncommon to encounter a lot of unicode characters. This of course leads to much pain later. Competent developers learn the first time they make this mistake and never repeat it. The superstars never make this mistake in the first place.

Paranoia can only go so far - you will miss something. Fortunately, that's what code reviews, pair programming, even more paranoid seniors and users^H^H^H^H^H beta testers are for - helping you catch your errors. But it helps the user experience (and your career) a lot if you catch as many of the bugs as possible before anyone else sees them.

Mapper vs Packer

The terminology comes from the Programmer's Stone, and it refers to a mindset. Are you a memorizer (pack information into your brain) or one who figures out the fundamental principles (maps connections between data points)? Packers have a tough time making senior in Exoweb because seniors are the ones that handle the most unusual, newest problems. For that, a packer has to find and pack the appropriate response. That can be rather hard to do. Instead, we need people who are adaptable to new situations and can figure out solutions to problems. Nothing is more annoying than a person constantly bombarding you with questions that could easily be answered with a little thought.

The Quality Plateau

Yet another term from the Programmer's Stone, this time in Day 2 of the website (I consider the first two days the most valuable). I wish they had a HTML tag to that particular section so I could link directly to it, instead of telling people to search for the heading. At any rate, that site shows how even code that is considered well written can be improved and made more readable. You may or may not agree with the style or the different methods used, but it is an eye opening experience - 26 lines of code reduced to 11 much more readable lines of code.

The Quality Plateau is not about reducing unnecessary variables, cramming things into as small a space as possible or holy wars about coding conventions. It is primarily about looking at your code and constantly finding ways to improve it. This mindset may seem expensive at first as you spend time looking over already functional code, but the long run benefits are enormous. Each time you see a way to improve your code, you learn something new for the next bit of code you write. Over time, you get better and better and start producing top notch code without much effort.

Knowledge Portfolio Investing

If the Quality Plateau is about constantly improving your code, then Knowledge Portfolio Investing is about improving yourself. This particular phrase comes from The Pragmatic Programmer, a book I highly recommend. As knowledge workers whose tools are only our intelligence and a computer, our greatest value lies in what is in our heads. If we do not constantly invest in increasing that asset, we will one day find ourselves penniless in our job - we will not have the value left to justify the high salaries that we believe we deserve.

It is hard to take time out to invest in ourselves, to learn something new every day. Work is tiring, our personal lives often seem more interesting and something always seems to come up. But none of us would have gotten this far if we hadn't invested time and effort in improving ourselves. No one in Exoweb has ever studied only the bare minimum required of them in school. Work should be no exception.

This is one of the reasons why Exoweb allocates 10% of work hours to employee improvement and tries to minimize overtime - to give every one of our developers time to continue developing themselves. This is a win-win situation for all parties involved as Exoweb's time and resource investment results in more competent and skilled developers. However, this all depends on the developers actually taking advantage of this time.

Final Thoughts

There are plenty of other things and more will be added over time as the situation change and other needs become more obvious. Of all of the above, the area that is ultimately most important is #4 - Knowledge Portfolio Investment. In the end, if a person is constantly trying to develop themselves, they will learn all the other areas.

The future, our industry and our targets are always moving. We can never be satisfied with hitting all the goals we set today, because by the time we hit them, needs will have changed and new goals are needed. However, if we are at least moving in the right direction, there will be a much shorter distance to travel to the new target after we hit the old one.

What Makes a Senior?

It is time for the semi-annual performance reviews again and a few questions raised during the reviews made me do some thinking. As a young, growing company, we find ourselves defining many things on the spot. Many things which may be well defined in larger, established companies, we do not find appropriate for Exoweb. One of these is the definition of what is a senior.

First, a little background - Exoweb has roughly 3 broad levels of software developers - junior, mid and senior. There are finer distinctions within each broad category, but those suffice for now. In general, what defines whether a person is either a junior or mid level is pretty clear - it is based on their ability to complete a task. Juniors normally require supervision and guidance, including being pointed in the right direction and perhaps some tutoring, in order to complete their tasks according to Exoweb standards. Mids are relatively independent, able to complete a task independently. It is defining what separates a mid from a senior that is tricky.

The problem is that our seniors have varied skill sets and roles. Although Exoweb knows very clearly who are the seniors within it, it is not always easy to articulate what makes them seniors. We do not look at education, expertise in any technology or years of work experience. There has never been a need to define the separation, perhaps because every senior that we have is clearly above and beyond the mids that there was never a need to define the role. We just knew.

However, people normally aspire to improve themselves and advance their careers. In order for Exoweb's mids to advance and join our critically important pool of seniors, it becomes more and more important to define what it is so people can work towards achieving this goal. In my mind, it comes down to one critical factor - trust.

We have to be able to trust our seniors to achieve the job. Exoweb defines its job (right now) as "delivering projects to our clients and ensuring they are happy with them." Simple enough. With that definition, the job of a senior is simple enough to define - we have to be confident that a senior, given a task and often a team, will achieve the task. That is all.

It does get a lot more complicated though, as you look at all the different aspects of delivering a project to our clients. There are multiple different aspects:

• Problem solving - This is just a general catch all for anything not covered below. The ability to see problems and ensure that they are resolved is another key quality we look for in a senior. They do not have to resolve it themselves, if it is not their field of expertise. However, they do have to spot problems before they negatively impact performance and ensure that they are resolved, one way or another. If a user interface is clunky and cumbersome, either resolve the issue or find the in-house usability expert to consult on the problem.
• Quality - We take great pride in our work. It hurts us when we are forced to rush out shoddy, buggy software. Even though it does happen, it should be something to be avoided where at all possible. The enforcers of excellence, when it is lacking among team members, are the seniors. They are the final, last chance to catch any defects before they hit our customers. This particular aspect of being a senior is often a thankless and tedious task. Yet someone must do it.
• Technology - The senior must understand enough of the technology to oversee the team and ensure that they are not going off a steep cliff. Besides knowing what technologies work well together, they must be able to spot and stop common pitfalls, bottlenecks and problems normally produced by less experienced team members. Or in some cases, depending on where their strengths lie, the senior must know where their limits lie and be intelligent enough to call for the assistance of another senior when they are out of their depth. This happens often as no one person can know every single technology.
• Project management - Someone has to manage the project and this typically falls to one of the seniors in the team. The person must be able to scope out the work, make estimates, allocate resources and monitor progress. Should any problems arise, the problems must either be resolved internally or escalated to more senior staff. Preferably the former.
• Leadership - Management is more than just looking at tasks and watching numbers. It is also about motivating people. Motivating intelligent, opinionated and confident team members is no easy task. People are far more unpredictable than computers. Yet someone has to do this. Leadership is a crucial resource in ensuring that a team of people are far more effective together than spinning their wheels individually. Leadership in this area can be either or both technology leadership and team cohesiveness.

Most seniors do not have every single aspect mentioned above. Some seniors have limited technology skills. Others are hopeless at motivating fellow team members. But part of being a senior is also knowing where one's weaknesses lie and compensating for them, either by teaming up with someone who has complementary skills, or putting in processes that compensate for this shortage.

In summary, seniors give Exoweb peace of mind. It is the knowledge that when something is passed to them, it will be done without problems. Attention can then be turned to other areas, such as growing the company and ensuring that Exoweb achieves its goal of becoming the workplace of choice for everyone here.

Interviewing Thoughts

Just some thoughts to trends/things that some people say when I am doing interviews. Some I strongly disagree with, others ... I am curious what other peoples thoughts and experiences are with them.

1. You can't keep up with the young 'uns
2. You have to change jobs every year, or you will never advance
3. If you learn on your own, without 'real' experience, it is worthless
4. To really become an expert, you must focus on one specific field and ignore the others
5. Details are not important. The compiler will catch it

1. You can't keep up with the young 'uns

This was first related to me by an applicant in her late twenties, with only a little working experience but lots of degrees. In the interview, she said that her goal was to move into project management because, "as you get older, your thought processes slow and you cannot code as fast as those young kids."

The sad part was, all the senior applicants I interviewed that day shared exactly the same viewpoint. All wanted to move out of coding and into project management. They wanted to get into management not because they enjoyed it or because it had to be done, but because they felt it was their only escape from obsolescence.

This is silly. This ignores all the experience and knowledge that older, more experienced coders have gained through painful experience. This assumes that a person's mental faculties begin deteriorating at such a young age (not true!) and that quantity of code equates to productivity. I know I certainly produced a lot more volume of code in my early programming years, but experience has taught me to produce more effective code. It takes fewer lines, has far fewer defects and is far easier to maintain later. If anything, the years have taught me that quality is far more critical than quantity. And woe to anyone that even thinks I'm close to being an old fart ...

2. You have to change jobs at least once a year, or you will never advance

This particular one really annoys me. It feels like the get-rich-quick days of the dotcom boom again. Demand for good technical people is high in China, especially so for those with FOSS skills. Because of this, opportunities abound and everyone is jumping from one job to another to get more money.

I suppose it does give a person more experience and probably a higher salary in the short run. But do you truly gain any skills when you jump around this quickly? By moving so much, you miss the big picture. Most major projects have lifecycles longer than a year.

An eye opening experience I find for most people is to be still around during the maintenance phase of a project. It is then that you realize that those fancy coding hacks you did, or that /* This will never happen */ section of code, will come back and bite you. You get to see the long-term price of taking shorts cuts and skimping on quality. It gives you an appreciation for doing things _right_, especially if you have been through two project lifecycles, where you have seen on where it went right and one where it went wrong.

3. If you learn on your own, without 'real' experience, it is worthless

One thing we always make a point to ask for is whether a person tinkers with technologies on their own, outside of what is required for work or class. More than one applicant has justified not doing so by saying, "if it was not done for work, it is not real world experience. It is worthless."

Is it? The best technical people I know are always voraciously learning. Some deliberately learn technologies far removed from their daily work, to stretch their brain to new ways of thinking. The diverse knowledge base they draw on seems to serve them well.

Yes, "real world" experience is valuable. You never truly appreciate the value of caches until you have been slashdotted, or when you max out all the CPUs on your server farm serving dynamic content. It is hard to really appreciate the value of distributed databases until you have so many transactions that the fastest hard disks in existence cannot write the transactions to disk as fast as they pour in.

However, they are not everything. There are many people with "real world" experience who still have not really learned the best practices and techniques. Unless you are really lucky, you cannot learn this unless you are constantly looking for it. The chances of you working with the best in your field are extremely limited, unless you're lucky enough to be working for someplace like google.

4. To really become an expert, you must focus on one specific field and ignore the others

Partially related to #3. I meet a lot of people with only Java experience. They know every single Java library, framework and technique there is. But nothing else. They have never touched another language, framework or system. They sneer at all others as inferior, but have never tried them.

Depth is valuable, but so is breadth. I have watched Java experts sink their systems as they tried to employ lower performance Java web caches, when squid outperforms the faster available system by an order of magnitude. I have seen people try to squeeze J2ME into embedded systems when an ncurses interface is the only thing that would have given a halfway decent response time.

As they say, when you only have a hammer, everything in the world looks like a nail. If you don't know anything else, you will always use the tools you know, even if they are not the most appropriate for the system. You miss the best of breed tools.

5. Details are not important. The compiler will catch it

Final peeve. Some applicants make careless and copious mistakes while answering their coding question. They explain this away as, "oh, the compiler will catch it when I run this on a computer."

The compiler is not your nanny. It is not your QA department. Even if you had a QA staff to back you up, the most qualified person to find errors in your code is you. There are insidious logic errors that no compiler will catch and even good code reviews and QA people may miss. The best and easiest time to catch errors is right after you have written the code, when all the variables, requirements and interfaces are fresh in your head. Spend the time to review your code and catch everything you can.

Attention to detail is really important. If you lack it, it comes back to haunt you. If you have it, your users may not be able to explain why, but they will like your work a lot more. It is like the Apple products which I rave about - the attention to detail and usability have given their products an incredible competitive advantage. Even with commodity, even sometimes inferior hardware, they can still command per unit profit margins that are the envy of other PC manufacturers.

HR Issues: Interviewing, Trainees and McDonalds

(Originally posted 20050327)

Just finished the regular Sunday interviewing session. An unusually good interview round, with 3 job offers going out after 10 interviews. Our average is 1 out of 10. Strangely enough, I don't feel so elated. Not sure why. Perhaps it was because the most impressive candidate on paper (all the right open source buzzwords) failed miserably at all the non-programming problems we gave him. Also tried a new tack learned from a recent Motorola acquaintance - trying to encourage interviewees and give them hints when they struggled with a question. Unfortunately, it was all the more depressing because the ones who _needed_ the hints typically couldn't do anything even when given the hints.

On the other hand, the last 2-3 days has been very good as I follow the progress of one of our trainees. Fresh out of college with no working experience, this trainee was added to one of our projects a month ago. For the longest time, relatively simple tasks took 1-2 weeks to complete. I wasn't disappointed since I expected the trainee to take quite some time to learn the technologies we used, but I was hoping that it might be a bit faster.

Like a dam bursting, that breakthrough happened 3 days ago. From 2 weeks to complete a task to finishing 2 tasks a day – I was amazed. Not too often that I get patches faster than they can be reviewed from any developer. Not only that, but the trainee was refactoring crappy code in our code base, producing high quality code I would have expected from someone with far more experience. Ok, so I did casually suggest those refactorings, but all the same, it was a very encouraging development.

That leads me to another tangent – some of our best people were underemployed before we hired them, due to that horrible 'working experience' requirement. Our best junior developer was working at McDonald's before being hired here! Too many could not find a job fresh out of school due to lack of working experience. We have reaped good benefits from hiring fresh graduates - eating the cost of training them for the first few months and reaping the rewards of hard-working developers with the right 'can-do' attitude. But if we hadn't hired them, their skills would have gone to waste. What a waste that would have been ...

Of course, we have had to eat the cost of losing some of these trainees who left for greener pastures the moment they became minimally functional. That is a challenge that every company has to face though. Hiring and retaining good talent is hard and we have only begun to build a corporate culture that is conducive to this.