Buu Nguyen's Blog

Being responsible for hiring developers in almost every position I landed, I’ve screened probably a few hundreds of developers CVs through out my career. Following is the list of mistakes I often found in CVs.

• First and most common mistakes: the CV lists too many skills. In fact, I’ve seen many CVs with roughly a dozen lines mentioning about many dozens of technologies and tools. In many cases as the on-site interviews revealed, these developers just possessed superficial or absolutely no knowledge about the things they listed. One can only go so far (to the on-site interview) being untruthful. On the other hand, even if these developers really know about these things, among the too many things they list, I can hardly find the ones that should really stand out (i.e. the things that the candidates have expertise in.) Now, there are those of you who really have extensive set of skills under your belt and want to list them all, it’s still better if you can highlight the top skills that you master so that they can stand out from the rest. Most of the time, employers don’t care about the skills you are not really good at. Think about it, would I hire a top .NET developer to write Java code just because the guy happens to know a bit about Java?
• Some candidates describe what they were supposed to do instead of what they actually did in their previous positions. If one implemented the security module of a software using Spring Security or used Struts 2.0 to implement a web module of another software then I would want to know about that. On the other hand, I don’t want to read a some general job description stating the obvious and of little interest (to me) such as “designed and implemented the application”, “worked with QA to resolve defects”, and “participated in code review” etc. (Guess what, if you’re not doing these things, you are not developers.) On the other hand, some candidates went so far quoting text from the job description while they have not actually carried out such responsibilities and that has resulted in quite a couple of embarrassing on-site interviews. Be very specific about the things that you did is the key to avoid this mistake.
• Mention too much about the clients and products. As a matter of fact, I’ve seen some CVs in which every project is accompanied with a lengthy paragraph describing the product and its client. Much of this information is pulled out of the marketing information provided in the client’s or product’s website. Keep this in mind: most employers don’t care about the vision of your client organization and the greatness of the product. For the software that you built, only 2 things should be mentioned in the CV: what problem the software solves and what technologies it is built with. Anything other than that is noise and should go away. For the client, the name and a link to their website are more than enough. For the really rare case that I want to learn more about the client, I will find more information through the provided link (or Google, for heaven’s sake).
• Some CVs mention too trivial projects. Don’t get me wrong, it’s good to demonstrate how much passionate you are about this software engineering by listing things like, say, personal projects but there’s no point mentioning some trivial toy or university projects in your CVs. Think about it, how much value the employer gains knowing that a developer can code a Tic Tac Toe game or a shopping cart? Absolutely nothing unless you expect us to say to ourselves “Look, that guy is really cool – he can code Tic Tac Toe.” Save the space for more valuable things instead. If there’s no such thing, better save us some reading time by removing them from the CV.
• Spelling and grammar mistakes in CVs. I am constantly surprised that many developers don’t even care to do a quick check to make sure no grammatical and spelling mistakes in their CVs. After all, it only takes a few minutes for this check to be done with any word processing software. Without doing this, one risks leaving a bad impression to the recruiter; the impression that the author of this CV is either lazy, doesn’t care about getting the job, about doing the right things, or about going the last mile to get the work done. That might be a harsh conclusion one can come up with given just a few spelling mistakes, but given the sheer amount of CVs recruiters have to screen for any particular position, they are not supposed to be very patient and tolerant of poorly written ones.
• A bonus tip: don’t be afraid to list your certifications if you have any. This is actually not a common mistake, but since there is a rising number of people who suggest that developers should not include certifications in their CVs, I think it’s worth setting an alarm. Anyone who have under their belt a few certifications know that it’s not the papers themselves that have a lot of value but the actual studying process that one usually gets through to get those papers is valuable. Plus, if one spends the time that would otherwise be spent on vacation or gaming to study and achieve some certifications relevant to her work, it means that she cares, if is not passionate, about her job. And that is never a bad thing. Finally, with all things being equal, some companies would prefer to hire developers with one or more certifications than others because that would help with the partnership process with vendors like, say, Microsoft (like it or not, there are obvious benefits to become partner of the big vendors).

That’s it, the top CV mistakes. Am I missing anything?

I’ve just read two interesting blog posts this week, Jeff Atwood’s Programming Love It or Leave It and Jay Fields’ The Cost of Net Negative Producing Programmers. Jeff Atwood basically thinks that people who don’t have passion for programming should not go into the field while Jay Fields thinks that poor programmers add significant cost to any project and should not be in the industry as well. If I were to read these a year ago, I would have wholeheartedly agreed with them. After all, I too had to maintain the very poor code written by incompetent programmers and couldn’t help but wishing they were never programmers in the first place. And I had strong opinion in passion being one of the top criteria for hiring programmers and felt bad about those who are not passionate enough to spend extra time learning stuff beyond the work at hand. But a year working exclusively in a managerial role has changed my view on that quite a lot. Don’t get me wrong, I still think passion and talent are important attributes of developers, it’s just that they are much less important than what I used to believe.

Indeed, when you are in a position to receive projects from clients and responsible for hiring people to accomplish those projects, you’ll quickly realize one thing: there are just not enough talented or passionate developers, much less those who are both passionate and talented. Truth be told, I was extremely selective in my hiring to the extent that I was infamously known among the HR department as a “candidate eliminator”. And yet, I think less than 5% of those I selected into onsite interview met both criteria. That said, if I had rigidly maintained my rules of placing passion and talent before any other, I would never have found enough people for all the projects. In such situation, there are 2 things one can do: give up and reject the client projects for not being able to find enough members to staff in, or staff the best you can and find ways of accomplishing the projects. Now, nobody in his or her right mind would go with the first option.

After spending more than a year working with impassionate and not talented people, I have come to realize that a team which has such developers can still deliver good result. Now, among those people, I have yet to find a person who is passionate but has poor programming skills, but the remaining categories (impassionate but talented and impassionate and not talented) turned out to add value to the team in one way or another. Specifically, I realized that impassionate developer can still be good developers. These developers would rather go home early and spend time taking care of their family or pursuing their real passions. They never write any blog or participate in any open source projects nor do they have any plan to do so. And they only learn things as they are needed instead of browsing through latest books and blogs to learn about the trendy things. But when they do something, they do it with utmost attention and most importantly, they write good code. That should not be a surprise. You just need to realize that good developers are, well, good developers regardless of whether they spent 8 or 16 hours per day programming. (Although the one spending more time may learn more.) As a matter of fact, two developers in one of the projects I worked on were not passionate about software development at all. They just realize that programming is something they are good at, so they do it to get the money to spend on the things they really love. One guy’s passion is photography, but he is smart enough to know that he can’t make as much money being a photographer. He loves it, but he simply has no talent for it.

I’ve been talking about good developers who are not passionate. How about those who are both impassionate and have bad programming skills? I worked with them too, and I have to say: such people are NNPPs mostly because they are mismanaged. A good manager will recognize the strengths and weaknesses of their members to put them into the right position. Before you laugh at the idea, think about all the work that need to be done for the projects to be successful. Are you sure that all of such work require really smart developers to do? Do you need good developers to maintain the project’s build scripts? Or setup a build system? Or evaluate a tool? How about writing project documentations? Or migrate one source control system to another? Simple bugs of well understood components (or even more complex bugs but have the new code reviewed by good developers, but that’s another story)? The point is, in just about any software development project, there are always some work which smart and passionate people hesitate to do (and may not do it well if they have to do it) but enthusiastically accepted by others. Let the latter do such work, they are neither passionate nor smart but they work for the pay in order to do things they really love. Therefore, they are willing to do so and even feel happy for not being asked to do more than what they are capable of doing. And you, the passionate and smart developer, can be happy too. The right-person-for-the-right-job is the name of the game.

Having said all these, sometimes some people just don’t fit to your project, then you have to let them go. But the point remains the same, things would be much easier if we can find all the top guns and put them into the team. But we simply can’t. Sometimes, we have to live with what we get and do the best about it. Just face it. And happy programming.

Note: This article is also posted at The Code Project. Refer to this link. There are quite interesting discussions going on there.

The .NET framework 4.0 CTP has just been released and I think it’s a good time to explore the new features of C# 4.0. In this post, I will introduce about the following features: dynamic lookup, generics covariance and contravariance support, optional and named parameters.
Read more…

I have worked with so many architects in my career, including those who have the “Architect” word in their business card and those who play architect role in their projects. And while I had good fortune to meet very talented people, I am frequently disappointed by poor architects who put their ego, arrogance, fanaticism (and sometimes, ignorance) before anything else. Recalling the memories I have about the poor architects, I come up with the following grouping. Read more…

A fictitious story about a fictitious “hope-driven” developer… In a sense, it’s fictitious because there’s probably no one single coder exposes all these behaviors of being hope-driven. On the other hand, it’s not hard to find one who frequently displays one or more of these behaviors. Anyway, let’s now travel into the mind of our fictitious hope-driven fellow…

Unlike others, I don’t write unit test for my code. I hope my code will work right because I’m so good at coding. Even in the rare cases when it doesn’t, the QA team should be able to catch the defects easily and I will immediately know what happen to make necessary fixes. I hope I will never have to touch most of the already written code again and if I don’t have to revisit it, what would unit tests help anyway?
Read more…

Finally, I could manage some time writing up the follow-up post about other interesting features of db4o, specifically about client-server feature and transaction & concurrency support. You can read the article here: http://www.codeproject.com/KB/cs/oop_db4o_part_2.aspx.

This write-up also gives me a chance to learn about some cool new features of db4o 7.2 (currently development version) such as LINQ integration, transparent activation and transparent persistence. These are really big changes from the previous version I tried (6.3). Hope that I can find some time writing about all these features. But don’t wait for me though, just go ahead and try them yourself…

Unit testing can be difficult sometimes. In some cases, you need to refactor your code-under-test to make it more testable; in other cases, you need to apply some special techniques into your test code so that it can do what you want; and in the worst cases, you can’t think of any such techniques nor are able to refactor the production code and thus, don’t write any test at all. It’s in my experience working with many teams applying unit testing that they often have troubles writing tests for the data access layer (DAL), UI layer, service interface layer, and multi-threading code, mostly because they are not aware of the techniques for doing that. That is not surprisingly difficult to understand though, business logic is much more intuitive and straight-forward to be tested and every single article or book out there will have examples writing test for the business logic firstly.

In this blog entry, I will explore some techniques of testing the data access layer. While it won’t be very comprehensive (I think an entire book can be written just to explore in details all facets of database unit testing), I hope there is enough of topics covered for you to explore more. Read more…

I can hardly believe that there is any Java developer who never reads a Java book, or “agile developer” who never reads a book on XP, Scrum… Unfortunately, there are just so many many of those. In fact, many people I know/interview have very fundamental gaps in their knowledge and in most cases I discover that it is partly due to the fact that they never spend time learning things from books. Reasons provided often are: not enough time, internet resources are more than enough etc. In most situations, I don’t think it’s a good mindset to develop software. Read more…

I can’t tell you enough about how much surprised I was when some developers applying for senior .NET development position, when being interviewed by me, could not answer very fundamental questions about a specific technology or programming language as well as were not aware of any trends in the field. What I found out was that usually this had something to do with their attitude towards “learning on the job”. Read more…

I’ve come across the latest paper from Ivar Jacobson (yes, one of the “Three Amigos” who invented the RUP and UML) about development processes (Enough of Processes: Let’s Do Practices Part I and Part II) and so much as I admire Mr. Jacobson and his contribution to the software industry, I just do not find anything he wrote in this latest essay new or provoking, especially to those who have been working with agile processes like XP, or Scrum. Read more…