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.

Year End Thoughts ...

The year draws to a close and it is time for the yearly retrospective again. Time really does pass quickly:

2007 RESOLUTIONS

So how did I do? From the 2006 year end retrospective, I had the following two goals:

• Make myself (almost) redundant
• Teach, not do

The first part is pretty much complete and in some ways through no real effort on my part. What happened in 2007 was that I stood aside and let my team leaders take on more and more responsibility. They all rose to the challenge and the team functions pretty well without me. These days, my role is mostly HR management with a small bit of project management on the side. The PM work isn't even because it is really necessary, but more because it is much faster for me to do it due to language and experience issues. My team leaders are a bit overworked at times so I jump in here and there to balance the load.

The second part turned out to be quite a bit different from what I expected. Rather than having long lectures and training sessions on how to do the work, it turned out to be a lot more effective to just let people do the work and give feedback where necessary. My team members are good enough that, for the most part, you can just throw them in and yell, "have fun swimming!" Now and then, feedback from gathered from peers or my personal experiences helped several people to improve what they were doing even better. However, it would be quite laughable to claim that I really taught them anything. For the most part, they figured out how to do things themselves and often came up with new ways that were far superior.

So in conclusion, both goals were achieved but in ways quite different from what I envisioned. I suppose this is one of the benefits of working with really good people :)

2007 LESSONS

The following are some of my major lessons for 2007. All these topics will probably be covered in more detail in later blogs:

• Timely feedback
• Groups also grow and mature
• Really learning from your team mates

If 2007 is anything to go by, the greatest value a manager in Exoweb provides is in giving timely feedback - both positive and negative. As mentioned earlier, I found that I did not really have to teach much. However, I did have to tell people how far along they were towards achieving the goals set for them. Without clear feedback, people are either demoralized by the uncertainty of their performance or wrongly assume they are doing well/badly. In retrospect, some of the people that did not work out in 2004-2006 may well have done a lot better given the correct feedback and corrective actions early. Things have gone a lot smoother in 2007 as the management team as a whole has gotten better at this.

Another realization was that it is not just people that grow and mature. Groups somehow do too. They take a life and culture of their own, often picking up best practices that make the group far superior than merely adding the individual members together. One clear example was when we threw a group of new people into a project. Although everyone individually was quite competent, they were all new and unfamiliar with best practices the rest of Exoweb has gained through bitter experience. As a result, the team repeated all the same mistakes and was on the verge of turning dysfunctional. Ultimately we disbanded the project and team, merged everyone into mature teams and things work out much better after that.

2007 was also the year I learned the most from my teammates. Partly because they were getting comfortable and confident in their teams/roles, partly because there was much more communication this year. The many subtleties of working with people, what works, what doesn't - all these I have learned from talking to my colleagues. Some give me feedback on what they have seen me do, giving me a chance to tweak methods better. Others try new things that have obviously good results. These I adapt into my own daily routine. Overall, 2007 was the year I learned the most about managing and working with people - even more than my days in evil MBA school.

There of course is a lot more I have learned over the course of the year. In many ways, working in Exoweb is like being in school - you are always learning new things every day. May this always continue.

2008 RESOLUTIONS

Strangely enough, I cannot think of anything that I would make as a new year's resolution. Sure, I can see many areas that need improvement/fixing, but these are things that will naturally fix themselves over the course of time. Maybe I'm getting complacent, but I honestly think that Exoweb has built itself a self-sustaining culture that will continuously improve itself as time goes on.

If anything, my resolution for 2008 is to ensure that 2008 is even better than 2007. 2007 was a really good year, but one should always try to strive for more. I would like to make things even better next year, from all aspects. What specifically, we'll figure it out as we go. However, Exoweb in 2008 should be an even greater place to work in than the years before ...

We Make It Up As We Go

Every now and then I find myself repeating the same thing in weekly chats, so I try to note them down in a blog post so the Exowebers that actually read the Exoweb Planet have a chance to see it. This particular one has to do with how we developed our work processes and best practices. There is no mystical method, no profound MBA insights or deep pondering. Quite simply, we make it up as we go.

That's not to say all our current processes are arbitrary. Every process or practice we have, we evolved to overcome a perceived problem. We experiment with different processes and those that work, we kept. Those that failed we learned from and moved on. The entire organization is a work in process, continuously trying to improve itself.

There are a few core values we do have, which very much reflect those of agile methodology: People over process, working code over documentation, etc. We also believe very much in making this a great place to work. Since you spend a huge portion of your waking hours at work, why wouldn't you want to make it as pleasant, as fun, as challenging a place as possible?

From these core values we simply figure things out as we go. For example, our current process of code reviews was triggered by the realization that our code quality wasn't good enough, that too much bad code and bugs were leaking into production systems. We tried the NASA style group code reviews but found that much too heavy. We then tried having a couple of core code reviewers doing all the work, but found that it did not scale and that the benefits of code review actually were disproportionately accumulating with the core reviewers. Our current method is a lightweight team review process that seems to combine the benefits of code review while reducing the cost. We are likely to make more tweaks and changes in the future, depending on future needs and ideas.

What does this mean for Exowebers? Most important of all, it means that it is the past ideas of all of us that have created the great environment we have. It means it is your future ideas that will make us an even better place to work. You need to pay attention to your environment, be willing to question our processes and methodologies, and contribute new ideas when they come to mind. No process is sacred. Given good enough reason, visible enough benefits, anything can be changed.

You can contribute ideas openly, by floating RFCs by email, or you can quietly suggest them to your team leaders in weekly chats. Whatever method you choose, it is important that the ideas are communicated and considered. Only then can we as a company improve. Only then can we make this place an even better place to work.

Yes, this includes higher salaries too. If you have ideas on how to make us more profitable, we can all share in the profits in the form of higher salaries :)

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.

Things I Would Like to See More In My Teams

Overall, I'm working with a great bunch of people, so don't let the topic mislead you - I'm really happy with the people I work with. However, nothing's ever perfect and there's always room for improvement. The following are things that have recently made me stop and think, "I wish I saw more of that ..."

• Curiosity
• Sharing of information
• Dissatisfaction

Curiosity

There is an immense amount of information that we don't know. In the IT industry particularly, it is critically important to keep learning and improving ourselves. A little curiosity goes a long way on making this happen.

We all know that the technologies we learn today are often out of date within five years. Even within the same language, the change can be enormous over time. Java users five years ago would not recognize or be able to read some of the code being produced today. Constant learning is critical to a long term career in IT. For that matter, it's possible that the famous Chinese stereotype that people over 30 cannot code may just be because too many fail to learn and by age thirty, their skills are almost useless.

Keeping up with the information flood out there is of course a skill. There is no way to learn it all and a challenge to find those really worth our time. However, a little effort such as by keeping up with a few good magazines and blogs goes a long way.

Sharing of Information

Everyone has different strengths and experiences. We all have learned different things and it is much easier to learn from someone who has already learned something than to figure out things from scratch. Because of this, learning from each other is a quicker path to improving ourselves than struggling on our own.

Yet too few try to learn from each other. This comes in two different forms - some don't like to share. They do not talk about what they have learned, do not mention it to others, etc. They do not blog, nor do they present in ExoForums (Exoweb's weekly information sharing session) nor do they even mention it in conversation. Anything they learn stays with them.

The other problem is actually receiving this information. This is related to the curiosity issue mentioned earlier. Exoweb has a planet listing all the blogs of colleagues, yet there are a fair number of Exowebers who do not even bother to read this. If one will not learn from their colleagues, who's knowledge and experience is most directly related to their work, what chance is there that this person will learn from anywhere else?

Dissatisfaction

Believe it or not, being dissatisfied can be a good thing if channeled properly. Dissatisfaction indicates that there is something that can be improved. By seizing upon this dissatisfaction and making the effort to ensure that improvement happens, one makes one's environment and self better.

It is too easy to notice a problem and shrug it off, accepting that it is a problem that one has to live with. Quite often this is not the case. If we invest a little of our time each day in removing the most irritating, most unpleasant annoyances in our lives, we find that bit by bit, our lives get better and better. Time and resources are limited so we can never fix everything that bothers us. However, as long as we take the time and effort to fix things, each day gets more and more enjoyable. Ultimately life is short. Why make it miserable too?

Most cultures with a strong work ethic believe in enduring hard, boring work to succeed. However, there's nothing in that ethic that says we can't find ways of doing things better. Just because it is hard or boring doesn't mean it always has to be that way. Sometimes it is far too costly to change. Sometimes it is not. Until we have aggressively investigated the problem, we will never know for sure.

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"

2006 Year End Thoughts

Can't believe another year has come and gone. It seems like only yesterday that I wrote the 2005 Year End Thoughts, and only a few days ago that I came back to China and started my career in Exoweb. Time really does fly when you are having fun, and I certainly have been having a great deal of fun in the last few years. Sometimes stressful and sleepless fun, but fun all the same :)

General summary of thoughts:

Things that I am happy about:

• Exoweb
  
  • Teams improving, growing
  • Culture
• Personal
  
  • Facing the different challenges over the last year
  • Learning to delegate

Things that need to be improved:

• Exoweb
  
  • Giving back to FOSS
  • Creating a continuous learning culture


• Personal
  
  • Working with people

Goals for 2007:

• Make self (almost) redundant
• Teach, not do

Things that I am happy about - Exoweb

Teams improving and growing - This last year has really seen a dramatic growth in the quality of the people within Exoweb. While continuously improving our HR process has helped us get some really good people, the major change has been the steady improvement of people already within Exoweb. There are various reasons for this but ultimately, I believe it is because we have finally passed a critical mass of smart people and everyone is now learning from each other. Processes/practices such as code reviews, ExoForums and blogging have helped encourage the sharing of information and it appears to be self-perpetuating. People are demanding high standards from each other and everyone brings in their own knowledge and skills. My primary concern is no longer raising standards but knowing when to step aside and let people more knowledgable than me figure things out.

Culture - building a good company culture isn't easy and I'll be one of the first to admit that I haven't really got the faintest clue how to go about it. Culture building is all about people and people skills aren't my greatest strength. Perhaps it is because I'm so clueless about culture building that I'm amazed that Exoweb has somehow produced (possibly by accident) a relaxed, open culture that many people find really attractive and unique. It's not perfect by a long shot and there's still so much more we can improve. Yet it is quite gratifying to hear people tell me that they find the culture of Exoweb one of the key selling points of the company and that they have never worked in a better place. Not everyone feels that way of course, but enough do. Personally, I've never worked with a better bunch of people, in a more comfortable environment. I am naturally biased though.

Things that I am happy about - Personal

Facing and Surviving the Challenges of the 2006 - 2004 and 2005 had different, lower level challenges for me. I joined Exoweb in 2004 as a senior team lead, so my main concern then was ensuring the success of a project with a small (5 devs total) team. The challenges then were a lot simpler! 2005 brought the challenge of maintaining quality in a team that was growing too large for me to personally review all code. 2006 was quite different - Exoweb continued to grow and the challenges that came up daily kept changing. The early part of 2006 was a battle to figure out how to scale technically. Or rather, how to ensure that the things I used to do still were being done when it was becoming obvious that one person could not possibly do it all.

The technical aspect of that problem was solved in early to mid 2006, among other things by the growing abilities of the team and instituting a more scalable version of code reviews (we created a cool trac plugin for this). This had the most fortuitous side effect of promoting learning even more from each other. With a great team that is continuously learning, most of my earlier technical challenges faded away.

Late 2006 was more an issue of scaling Project and Human Resources (HR) management responsibilities. The funny part was that as my team got better (and larger), the seniors within the team came to the conclusion that they did not want to do either PM or HR work, pushing all that to me. As a result, the workload in this aspect grew a lot faster than the team did in 2006. Surviving the PM aspect was done by the fine art of delegation (more about that later) while the HR aspect is still a serious work in progress.

Ultimately, I'm happy that I survived all the challenges of 2006. Ken in 2005, looking at these challenges, would have been quite intimidated. It was a good idea that I went into 2006 blind to the challenges ahead :). Looking back, I can certainly see many areas I could have done things far better but at least I can say that I haven't made an absolute mess of things.

Learning to Delegate - Every book about management talks about how one needs to delegate. Yet they tend to gloss over how to delegate. One thing I quickly learned long ago was that if you just pass a task to someone and hope that they will do it right, 90% of the time things turn out badly. It took some experimentation and trial and error, but in the end, my great lesson in 2006 was realizing that it all boiled down to figuring out who I could delegate what to. Everyone is different, with different strengths and weaknesses. The challenge was to find someone (or combination of people) that had the right strengths to do the task on hand. Not a skill I am strong at (more later about this), so it was harder than it should have been. But as I write this today, I have a good team that functions very well together, with most of the critical tasks covered and working well together.

Yes, I realize this may seem blindingly obvious to some people but it wasn't that obvious to me.

Things that need to be improved - Exoweb

Giving back to FOSS - Despite being strong believers and users of Free/Open Source Software, we don't contribute back nearly enough. Sure, some of us personally have done some work in FOSS advocacy or have code contributions here and there. However, as a company, I am still quite dissatisfied with what we have contributed back. Besides contributing server space (python.cn, Beijing LUG, etc), software usage, bug reports and a few patches here and there, we have given very little back to the ecosystem that makes our business model possible. Despite having people who profess to genuinely believe in FOSS, despite having a contribute back policy and allocating a percentage of developers time to such activities, too little is contributed back. This is something that we will have to focus more on in 2007.

Creating a continuous learning culture - Possibly because most of the seniors of Exoweb possess either the Learner or Input talents (see First Break All The Rules), we tend to expect that everyone will be like us - given the opportunity, will always try to learn and improve themselves. Unfortunately, that is not really the case. Some really talented software developers don't seek out knowledge for the sake of learning but are satisfied with learning only what is required to complete their task. Or despite the best intentions, they need a little external pressure. So despite having a 10% time self-improvement/contribute back policy in Exoweb, too many people do not take advantage of this. Yet continuous learning is a vital aspect of continuously improving the abilities of the organization.

Things that need to be improved - Personal

Working with People - I've touched on this previously, but I'm basically much better at computers and hardware than people. To me, computers seem so predictable - given a fixed input, they typically produce a fixed output. Humans are so much more variable, with too many factors to consider. Yet management is about people, not about computers. According to the Peter Principle, I'm quickly rising to my level of incompetence :)

However, the level of understanding of people I'm looking for might be a bit higher than most. The ability to figure out a person's strengths and weaknesses and combine them with other people/processes that complement their strengths and compensate for their weaknesses is a very rare talent. If you look at most management practices today, they are built to solve this talent shortage. Most large organizations have processes that cater to the lowest common denominator - they allow the organization to survive mistakes made by less competent people, but they get in the way of the truly talented hitting their full potential. We sometimes call that bureaucracy.

Most managers are either poor at or unwilling to manage individuals. It is hard to manage individuals - you have to really understand your team and know how to combine them to achieve maximum results. Most prefer to assume that every human being is interchangeable, that one person can be swapped for another without problems. This only works if you are using people at the lowest of their abilities, so that the job can be done by almost anyone. It does not work when you are trying to make the most out of everyone's unique combination of strengths and talents.

This will probably be my primary challenge in 2007 - to become competent at managing individuals.

Goals for 2007

Make myself (almost) redundant - I have delegated a large amount of my work to others already. I hope to finish this in 2007. Might be a while before I can delegate all the HR management aspects, but all the technical and project management aspects should be possible within 2007. I certainly hope to organize things so that I can go on a month long vacation and no one would notice :)

Teach, not do - One thing that is really hard for me - delegating tasks to someone else instead of just rolling up my sleeves and getting it done in a couple of hours. Only problem is that there are only so few hours in a day and so many problems that need to get resolved. Making myself redundant requires that I restrain myself from digging into problems and instead focus on teaching/guiding others to take over from me. Teaching is a large investment of time - it is always faster to do it yourself than to teach. But without this investment, the organization will never scale.

2007 looks like it will be bringing quite some challenges, many in areas where my strengths do not lie. Still, I wouldn't have it any other way. Life isn't fun without challenges and I can't think of a better team of people to face the unknown with than the crew of Exoweb. Happy New Year everyone!

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.

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.

Year End Thoughts

With 4 hours left to the end of 2005, it's time to reflect on how the year has gone and prepare for the coming of the new year. Overall, it has been a good year for me, though it has felt like I've been hanging on for dear life on to a runaway train. For FOSS, it has been a great year it continues to grow by leaps and bounds.

The greatest challenge in 2005 was for Exoweb to find and integrate good people into the team as we ramped up to satisfy client demands. Exoweb grew from an 8 man outfit when I joined in 2004 to a 34 person company today, and is still growing rapidly. We would actually be larger if we had not had such a tough time hiring good people. In the last year, we have streamlined our HR process, allowing us to screen 10 times the number of candidates we could previously, with minimal impact to the daily operations of Exoweb.

Beyond just increasing bodies though, Exoweb feels so much better a place to work in now. It was a nice place before that, but in the last year, we have managed to strengthen the company culture, added a bunch of really smart people and started processes to ensure that we are constantly improving. I can honestly say that the current Exoweb team is the smartest, most competent tech team I have had the pleasure of working with. It is both a joy and a challenge to work with intelligent people who are far more knowledgeable than you in their areas of expertise. We may or may not have the stellar brain matter that Google is reputed to have, but the current team can definitely give any other team a real challenge.

2006 will bring its own challenges, no doubt. The company culture is relatively young and it will be challenged quite a bit as it tries to accommodate the changing desires, needs and eccentricities of our growing and maturing developers.

Another thing that I am proud of is that Exoweb's contributions back to FOSS projects are growing. While we mostly filed bug reports in in 2003 and before, we started contributing code to small projects in 2004 and that trend has only accelerated in 2005. Since we became active users of django, several patches have been accepted into the main trunk and we should hopefully be contributing even greater functionality soon. We have patches in various other small projects such as EaseXML (formerly XMLObject), and identified performance improvements in projects such as PostgreSQL. We recently instituted a contribute-back policy, where developers can spend up to 10% of their working hours on FOSS projects, just contributing back to the community that makes our business possible.

Incidentally, the usage of FOSS is on the rise in China, even if the community does not appear to be that visible as yet. A growing percentage of the candidates going through our HR process are listing FOSS skills and projects on their resumes. More and more companies are using FOSS technologies in their daily work. We are also getting more business inquiries specifically seeking our FOSS skill set.

Finally, every competent FOSS person I know is fully employed and in huge demand. I know, because I tried to poach every single one not working in Exoweb :). For those who kept asking, "how can you find a job with FOSS skills?" a year or two ago ... HAH! Everyone I know has options - if they were not happy where they are right now, they could find a new job so very easily.

It has been a good, busy year. I am really looking forward to 2006 - more challenges, more growth and hopefully a bit more free time to relax and really play with technology again.

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.