Hiring Software Engineers

We recently went through a round of interviews for software developers where I work. Ever since then I've been reflecting on how to hire software developers. I wanted to outline some of the ideas that I have, and see if anyone has any feedback or other ideas.

1) Where to post job openings?

We have tried a number of different free and paid sites for job postings (state job sites, dice, careerbuilder, etc) , and most of them seem to be pretty hit or miss. We get a fair number of completely unqualified candidates, and only a few that are even worth interviewing. Does anyone have any other suggestions or ideas of where to find candidates? One of our most useful resources has been the local university, but that only works when we are looking for interns or recent graduates.

2) How to filter through resumes?

Many of the resumes we get are for individuals that aren't even experienced or trained in software engineering (Do people not ready job postings?). But after the first pass, here are some of the things I generally look for, other than some of the obvious ones:

• Is the resume just full of keywords, instead of really focusing on skills that the individual has?
• What variety of projects have been worked in recent years (Web, back-office, database, etc)?
• How long does the candidate stay at jobs - are they a job hopper?
• Is the resume well organized and clear - or does it look like a computer generated it?

These kinds of questions help me to see the potential that someone might have as a good employee. What over ideas do people have for sifting through resumes?

3) How to interviewing candidates?

I wrote about a year ago on Job Interviews. I wanted to touch briefly again on some of the techniques that I use, and some of the areas that I continue to work on. Here are the key things that I want to get out of the interview:

• Do they have a solid understanding of software engineering?
• Can they communicate well with others (even non engineers)?
• Can they analyze information and problems?
• Do they fit with the culture and environment of the company and the team?
• Are they dedicated and a hard worker?
• Can they lead a team and mentor other developers?

I find that I can get a pretty good feel formany of these within 45 minutes or so, by covering 5-6 software design concepts, a story problem or two, and a little pseudo code. One of the items that I continue to think about and refine is how to make sure they have a solid grasp of software engineering.

With interns and candidates with little or no experience, I find that it is generally not too hard. Developers with 5+ years of experience seem to be much more difficult to interview. Most of this comes down to my belief that there is a significant difference between a programmer and a software engineer. A good programmer can be given a small to medium sized task, and can be expected to complete it in timely fashion, meet the requirements, and the end result will be decent code. The programmer focuses on getting the job done. A software engineer will do all of the same things, while at the same time taking into account overall business strategy and goals, code maintainability, design opportunities like refactoring, and many other things.

Trying to determine who has the experience, knowledge, and skills to really be a software engineer instead of just a programmer is no simple task. Given a finite amount of interview time, what things can you look for or ask about that can really help determine which category someone will fall into?

Why would anyone buy an iPad

I've been wondering over the last few months why anyone would buy an Apple iPad. They seem to be fairly limited in what they can do. Wouldn't you be better off with just a smart phone or a netbook? It seems like iPad's are trying to fill a niche that isn't there.

But still people buy them. Are they using them as e-book readers, or running iPhone apps for people with poor eyesight. They just seem to bulky for what little they can do. I have to assume that I am  wrong since so many people use them, but yet I still struggle to see the value. Personally, I would even be hesitant to buy a tablet computer, when I could just go with a laptop instead. Maybe I'm just not the "target market," and that's why I don't understand.

ASP .NET Web Forns vs. MVC

I've used ASP .NET web forms for a number of years on some of the websites I've worked on. Recently I've been looking into MVC more in depth, to see if it is something that I should start using. It seems like most people are very adamant, that one approach or the other is the only way to go. Very few people seem to believe that both approaches are valuable.

I have Pro ASP.NET 4 in C# 2010 but it only briefly covers MVC. The only book I've seen that looks reasonable on MVC is Pro ASP.NET MVC 2 Framework, does anyone have any feedback on this book or recommendations for other resources. I'm looking for something that covers basics, but also covers overall design concepts and principals to use in real life applications. Most of the internet resources that I've found just touch on brief topics, but nothing seems to really cover MVC holistically.

I've also been wondering if MVC 3 has anything substantial that I should hold off for. Most people seem to agree that MVC 2 is the first usable version of the framework, is version 3 significantly better?

The Pragmatic Programmer

After reading Code Complete, I decided to continue with another book that had been on my reading list for a while. The Pragmatic Programmer is another excellent resource for developers. When comparing these two books, I would say that Code Complete is probably a better starting point, since it seems to cover more topics, and provide more details. With that said, Pragmatic Programmer is still a worthwhile read. There is definitely overlap between the two books, but there are some items that Pragmatic Programmer covers, that I didn't remember reading in Code Complete.

The book seems to be more humorous than some of the other software books I've read, which makes for easier, more enjoyable reading. The information in this book is what really helps separate the programmers from the software engineers. These concepts are what help make developers more valuable employees, and more productive engineers.

If you haven't ready Code Complete, I would recommend it first, but with that said I still think Pragmatic Programmer is a worthwhile read.

Software Engineering Handbook - Code Complete

I recently finished reading Steve McConnell's software development manual: Code Complete. It is a hefty read, but well worth it. As I was reading I found myself quickly skimming over some sections that I felt comfortable with, while at the same time other sections really made me think about some of the ways that I approach software development. I also found that some of the topics that I read were things that I tend to do naturally, but it was still nice to see formal definition and documentation to support what I do. The book covers all of the major areas that I would expect an experienced developer to be comfortable with.

Many of the topics are only briefly covered, but it is still an excellent source for how to develop software. For some programmers this may be their first exposure to these topics, so it is a great way to expand your knowledge. Some of these brief introductions should trigger further investigation and research for topics that are of interest. Even if the topics aren't' all covered in depth, it is nice to just know what ideas, practices, and techniques are out there.

In the end, I would say that Code Complete a "must read" for all software engineers, especially for those with at least 2-3 years of experience under their belt. It's still useful for the novice software developer, but the quantity of information may be a little overwhelming for beginners.