How I Hire Programmers

Posted in: Software Development Team Leadership

There are three questions you have when you’re hiring a programmer (or anyone, for that matter): Are they smart? Can they get stuff done? Can you work with them?

Aaron Swartz

Multiple Online-Personality Disorder

Posted in: Personal Branding, Social Networking

With the increased hype and focus on social media and social networking, many people are struggling with trying to keep their public/private lives, or their professional/personal lives separate. And for those people, I have some bad news – there can be only one You in social media!
Continue reading »

Should You Use Recruiters?

Posted in: Consulting & Entrepreneurship, Software Development Team Leadership

There has been a good debate on the Los Angeles Java Users Group mailing list this week about working with recruiters, both from the job seeker side and also from the employer side.

In my career I have worked with recruiters on both sides of the fence and I think the argument boils down to the same issue no matter which side you are on – working with good recruiters is a good idea and working with bad recruiters is a bad idea. Apologies if you were expecting something more earth shattering!

Many recruiting houses are simply glorified keyword matching services and they all function almost identically. If you visit their offices you will find a large room with two large tables, one designated for “Hardware” and one for “Software”. All the folks around the Hardware table are working to fill Hardware related positions and the Software folks are doing the same for Software positions. There will be 4 to 8 folks at each table, each with a computer and a phone permanently strapped to their head. At the end of each table will be a large white board with the “Hot Jobs” listed with the keywords to try and match, plus salary and commission rate (not surprisingly the higher the salary and commission rate, the hotter the job miraculously becomes). The main purpose of the folks at the table is to process the highest number of resumes as is humanly possible (from active job board postings, from their DB of past resumes etc.) and bring the resumes with the best keyword match to the top of the pile, then do a bare bones phone screening interview (ie. does the person actually exist) and then pass the pile of resumes off to the employer. The employer then has to process the resumes all over again, screen out 80% of them because while the keywords are there, there is an obvious problem elsewhere and then interview the other 20% to find out if any are even close. Most of the time you can achieve the same results as an employer by paying the fees to and doing the search yourself – it might even be quicker.

But as a job seeker you do need to be in contact with recruiters because many positions are never posted widely/publicly (at the request of the employer). In this scenario the employer is engaging the recruiter to get at their pool of contacts that are hopefully pre-screened etc., some of which may not even be in the active job market, but are known to the recruiter. This becomes increasingly true if the position being filled is higher up the corporate ladder (manger, director, VP etc). However, a bad recruiter will waste a lot of your time if you are not careful.

As a manager, these keyword matching recruiters are the bane of my existence and 50% of the reason I never answer my phone at work (the other 50% of the reason is software sales guys, but that is another post). The endless cold calls just trying to present me “a really exceptional candidate” they have found or “just wanting to know” if I have any open positions. These guys are really the sleazy used car salesmen of the IT industry.

As a job seeker it will be pretty obvious if you are working with one of these houses. Firstly if you ever get a phone call in response to a resume you submitted and it sounds like the person on the other end is sitting in a room full of people talking loudly, then they probably are. I have even been asked to hold the line when talking to one of these guys and while I was waiting I could hear another recruiter at the table talking to another candidate on their phone about the exact some position!

One of the other classic traits of these organizations is their incessant need to keep the job seeker and the employer at arms length from each other – the theory being that they need to control the communication stream so as the employer and the job seeker don’t reach their own agreement and the recruiter misses out on a commission. This is a symptom of the fact that the recruiter and the employer are not closely engaged with each other and do not have a strong working relationship. This also just hurts your ability to present the best of yourself to the employer. You are the person who knows your skill set and experience the best, and yet you are letting a recent high school graduate with 2-days in house training represent you. Another tactic is for these houses to take your resume and rebrand it with their logo and add their contact information and remove all of your own contact information. This involves a cut-and-paste from the resume you submitted and invariably ends up in a less than professional looking document. Just wait until one of these guys takes it upon themselves to actually edit the content of your resume “on your behalf” without asking you and you will very quickly realize that these guys are probably hurting rather than helping your job search.

Also, just be a little wary about the employer if they are using these kinds of companies. Its probably not a deal killer for you as the job seeker, but just pay close attention to what else your employer might not be paying close attention too.

But! There are good recruiters too, they are just a little harder to find.

I have worked with good recruiters on both sides of the fence as well. From an employer perspective a good recruiter who knows your industry and knows the local talent pool can be invaluable. They can help you shape the job description and salary of an open position to align it with what is happening in the rest of the industry and so attract the type of candidates you want. They can find candidates that are not in the active job market because they have built up a high quality contact list of candidates they have placed in the past or have met during prior searches etc.

These recruiters are usually smaller shops with a smaller focused recurring client base. Many work on a mix of retainer and actual placement fees, so they are not all about placing as many people as possible, they have an incentive to establish and keep long term relationships with employers by providing exceptional candidates.

From the job seeker side you will have to do your research to find these kinds of good recruiters. They probably won’t be posting hundreds of jobs on because they simply are not filling that many positions at one time. All of the ones I have dealt with in my job searches have found me, not the other way around. When they call you, the background of their side of the conversation will be quiet, because they are not working in the bull pen, they actually have an office! They will likely want to talk to you for a while and have an actual conversation. They will want to determine if you are an all around good candidate, not just a good keyword match.

If you are presented to an employer by one of these trusted recruiters, you are going to be going into that interview with a lot of credibility already on your side. Plus you already know you are one of just a few folks that are going to be interviewed, because that is what the employer is paying for – to not have to do hundreds of interviews.

So in the end, a good recruiter is someone you want to be in contact with, no matter if you are an employer or a job seeker. A bad recruiter on the other hand can waste a lot of your time and also actually hurt your chances of finding a job or filling your position.

Better the devil you know

Posted in: Software Development Best Practices, Software Development Team Leadership

It seems nearly everyday a new technology or pattern or paradigm bursts onto the scene. Lately we have seen things like AJAX and Ruby and other web-oriented technologies getting a lot of buzz and plenty of people jumping on the bandwagon. And don’t let me get started on SOA!

But what about the trusted tools we already know. Do we need to be ever pursuing the mastery of these new technologies and applying them to each new project and retroactively applying them to existing (already functioning) projects? What value does that bring? It really only makes sense if the benefits of the new technology outweigh the costs of adoption – these costs can be higher than you think.

To illustrate the point, lets take a team of engineers working for an internal IT shop. They have worked to identify a core set of tools and technologies that they are going to specialize in. They have recruited for those skills and their training dollars have been spent to improve those skills. In addition they have wisely created coding style guides, they have documented their own best practices they have chosen to follow, and best of all they have a continuous integration server set up, that is building and testing their code as fast as they can commit it. All in all, they are quite comfortable in their chosen domain and are working to maintain their skills appropriately.

Now for some reason they are asked to consider technology “X”. This could happen for a bunch of reasons – maybe somebody writing the functional requirements was over zealous and mentioned it in those documents, or a customer has heard of “X” and simply wants to have their project developed with it for no other particular reason except that they have heard of it and want to “contribute” to the process.

Assuming the team is a reasonably mature team with a good mix of senior and junior talent and have a grasp of fundamental engineering principles (quite rare possibly?) then what is the cost of using “X” on the new project instead of their existing tools?

As in most organizations that practice some form of waterfall process, they start by asking the engineering team for a detailed estimate of how long the new project will take to implement. Ignoring the fact that this is a gross error to attempt such an estimate at this stage of the project, the team dutifully works to create the estimate. But now they are faced with the problem that they are not really sure how long it takes to do things with “X”. They are comfortable with their current set of tools and could probably come up with a good estimate if given enough time, but now they are really going to struggle. So they scramble to find some documents, but of course “X” is the new sexy technology with a lot of buzz but no solid documentation or best practices defined. The team’s only true choice (assuming the estimate is needed quickly) is to SWAG it and then likely pad the SWAG to allow for the unfamiliarity of “X”.

So the first issue we have is a wildly unreliable effort estimate due to a lack of experience and confidence with “X”.

Now its time for design. But of course the team has no inherent knowledge of “X” so they get nothing for free in the design phase and have to start from scratch on every detail. So the design phase progresses and the team is able to make some progress, but there are some nagging questions that the team simply cannot find answers for. The team identifies these issues and decides that the only real way to resolve them is to engage some external help from the only people who know “X” – the vendor that just launched it. The vendor is of course more than happy to help, but since they are in great demand (because they are the only ones with any skills in this area), their rates are astronomical. The team reluctantly engages the external resources and embarks on a Proof Of Concept to help finish the design phase.

So the second issue we have is a design phase that takes an incredible amount of time, most of which can be considered more “learning” time than design time and we also have a huge cost outlay for professional services.

Time to implement.

The team is trying to be as agile as possible within the bounds of their company’s tollerance so they are quite commited to unit testing and continuous integration, but pair programming and other practices are still just “crazy talk”. Unfortunately “X” dosen’t have a good toolkit for writing unit tests. The vendor says they are working on it, but it is not on the release calendar yet. Looks like unit testing is out. The team starts implementing, but their preferred IDE dosent support “X” so now they have to run 2 large IDE applications on their (already underpowered) machines at the same time so they can creat the “X” parts, while still having access to the rest of their projects. Additionally, the team has been committed to creating repeatable builds and strict release processes for a while now since some code slipped out to production a while back without being tested or put into there code versioning system. Technology “X” builds fine within the customized IDE the vendor has provided, but there is no support for compiling from other command-line based build tools. So the team assigns resources to write the necessary build tool plugins so that they can appropriately build, tag and release the project.

There is a lot of additional overhead in the implementation phase when using a brand new technology. Over time these overheads reduce on each subsequent project, but the cost on the first few is quite significant. The lack of integrated tools really does hamper the team and the costs incurred because of the extended development time will add up quickly.

Eventually the team finishes implementing, but since no automated unit or integration tests have been running, the quality is questionable. Never the less, the QA team comes along and wants to test the project. But once again, “X” is so new that there are no tools for the QA team either. But even if there were tools available, the QA team would have never used them, so there would be a training and ramp up cost involved. So QA is going to be a manual process. As a result, some of the regression testing is not applied consistently and a lot of bugs slip through the cracks and make it to production.

The cost here is of course an extended QA time line. But possibly more costly is the low quality of the end product.

The project finally goes to production, but of course there is the immediate flurry of bugs and feature enhancement requests that are associated with a 1.0 release.

So the team starts again with the requirements gathering phase. But when it comes to the design and implementation phase, it turns out that in hindsight the code wasn’t really architected as well as it could have been now that the team knows more about “X”. So it is difficult to add the new features because of this. They hack the new features in, and so begins the downward spiral of building more and more features on top of an constantly degrading base. Technical debt increases exponentially.

This cycle of adding features and then fixing the bugs the new features introduced continues for a while. But now 2 of the team on the project are leaving for greener pastures (its surprising they lasted this long really). So the HR person comes by your office and gets a detailed job description from you, which includes all of the skills from the other technologies but now also includes “X”. The HR person not knowing any better says thank you and goes off to do the best keyword matching process they can.

A day or two latter they come back looking frustrated. They are having trouble finding anyone with the mandatory skills you described. Turns out that the two skill sets you must now support are really not common bedfellows and so recruiting is going to be an issue. You really only have one choice – recruit for one skill and spend the money and time to train them on the other.

So here is an ongoing maintenance cost that will be higher than before. Recruiting for skills that don’t usually show up together can be a big issue. If you are lucky enough to find people with the skills, they are likely to be higher priced just because they have that uncommon combination.

So before you choose to adopt the latest sexy technology because all of the weekly e-newsletters you get are mentioning it, think about what it is truly going to cost your team and company. Is it worth it? I propose that in the majority of cases, it is not.