I just picked up a very interesting article on the never ending specialisation vs generisisation debate over on Ted Newards blog. It’s an interesting argument. Can you be a good developer unless you specialise in one technology and know it inside out and stick to that language?

I think the answer is emphatically yes, you can. In fact, you can’t be a good developer unless you understand the stack and related languages.

You can not be a good ASP.NET developer without understanding how to administer your server, how HTTP works, how HTML works, how Javascript and CSS work.

You don’t have to be a guru in the world of semantic, CSS driven HTML markup. But you do have to understand HTML and be competent at hand rolling it. You have to recognise bad HTML and good HTML. Most importantly, you have to understand your limits in those areas and how and where to get help to get that perfectly semantic, CSS driven layout working. You should be pushing your knowledge in those areas.

Looking at the learning progression of unconcious incompetence through to unconcious competence, you need to be somewhere on the path from concious incompetence to concious competence. You don’t need to be someone who can always get it right in the other languages, but you have to know where you will get it wrong. Understand your limits.

Essentially, you are not an ASP.NET developer. You are a web developer, and that’s about more than a specific language and framework, it’s about the entire development eco-system. You’d want to read about and know about what’s going on in Python (including IronPython), Ruby, PHP etc. You don’t want to be missing out on the new techniques that sit in that area.

If I was talking about people who work on products like Microsoft Word in C++, then they’d also need to know about UI design, the shell, the underlying operating system. Basically, Point 5 in Ted’s article:

Learn to be at least self-sufficient in related, complementary technologies. We see laundry list ads in “clusters”. Case in point: if the company is looking for somebody to work on their website, they’re going to rattle off a list of five or so things they want he/she to know–HTML, CSS, XML, JavaScript and sometimes Flash (or maybe now Silverlight), in addition to whatever server-side technology they’re using (ASP.NET, servlets, PHP, whatever). This is a pretty reasonable request, depending on the depth of each that they want you to know. Here’s the thing: the company does not want the guy who says he knows ASP.NET (and nothing but ASP.NET), when asked to make a small HTML or CSS change, to turn to them and say, “I’m sorry, that’s not in my job description. I only know ASP.NET. You’ll have to get your HTML guy to make that change.” You should at least be comfortable with the basic syntax of all of the above (again, with possible exception for Flash, which is the odd man out in that job ad that started this piece), so that you can at least make sure the site isn’t going to break when you push your changes live. In the case of the ad above, learn the things that “surround” website development: HTML, CSS, JavaScript, Flash, Java applets, HTTP (!!), TCP/IP, server operating systems, IIS or Apache or Tomcat or some other server engine (including the necessary admin skills to get them installed and up and running), XML (since it’s so often used for configuration), and so on. These are all “complementary” skills to being an ASP.NET developer (or a servlet/JSP developer). If you’re a C# or Java programmer, learn different programming languages, a la F# (.NET) or Scala (Java), IronRuby (.NET) or JRuby (Java), and so on. If you’re a Ruby developer, learn either a JVM language or a CLR language, so you can “plug in” more easily to the large corporate enterprise when that call comes.

It’s fine (and good) to want to be an adept in one language. But, technology moves, and to really apply that language, you need to understand it’s ecosystem and competitors. Or you will hit your edge far too early.

Popularity: 39% [?]

Having said only the other week that there is no correct answer to the question of what should go in your résumé, Steve Yegge has chimed in with his article ten tips for a (slightly )less awful resume.

Steve starts out, much like I did by pointing out that what he says only relates to recruiting people for the kinds of places he works, and may not apply outside of the recruitment of technical people for companies that produce their own software, and even within that niche, may not apply to everyone:

I’m just talking about software engineer resumes today, and specifically just the subset intended for applying to companies that build their own software. I have no idea how much (if at all) this stuff applies to resumes for other kinds of positions, or companies. Maybe not much. Sorry!

It seems the companies he’s worked for take a different approach to reviewing CVs to any company I’ve ever worked for. It seems they have a large CV screening panel, phone screens (possibly multiples) and multiple panel interview sessions. We do it differently.

Steve’s first point is right, in bullet form, no-one cares about you yet, but he also suggest stripping out anything with personality in it. Which I disagree with strongly. I do want to know what you’re like other than as a professional software engineer. I recently came across a candidate who was a Reiki healer and psychic reader. Who offered his services for £25 an hour over MSN or email. This information was gleaned from “personal interests” on his CV and listing his personal webpage address. Valuable information saving me from interviewing a total fruit-cake.

Steve’s point 2 asks for unformatted ASCII CVs. This is because where he works they pump them through automated manglers. That is not true anywhere I’ve applied for a job or worked in my life. It’s true that Pimps screw them up, something I was planning on writing about soon, but, in general I’d prefer to see a nicely formatted word doc, that has had some care and attention lavished on it than a nasty plain .txt file.

Points 3, 4 and 5 have merit. Don’t set off my bullshit detector with too much weasel and wank talk. Make sure it’s spelling and grammar checked, if it’s a word doc, and a UK install f Word has put a red squiggle under anything other than an obscure techie term, you’re a moron. But, don’t rely on the spell checked, I’ve seen far too many CVs with spell-checking mistakes.

However, my biggest contention is point 6, certified looser. If you are a contractor, get certifications, do them in your own time, it shows your skill, gives me more confidence you have at least a basic level of understanding of the subject and technology. A safety net. it’s also quite common for UK companies to put people through certification courses to ensure their staff have that rounded skillset, that they know the right way of doing things, and to give the employee something back to move their career on. Certification is great.

But, just a few things there, the certifications, the format of the cv, the lack of personal information. Submit a “perfect for Steve” CV to me and I’ll reject you. Submit a perfect for CV to Steve and he’ll reject you. It’s impossible to get this right. The single best tip in Steve’s article?

You can apply for 18 jobs, but you should send 18 different resumes, each targeted at that job, and you shouldn’t send them all at once.

Tailor it for the job. It’s web development? Emphasis your experience in that area, and trim down the references to the Linux Device Driver work you’ve done. And try and get a feel for the company you’re applying for. If it’s a Big One, like IBM, Microsoft, Amazon, Google etc, there is plenty you can find out about what the recruiters are looking for. Talk to the Pimp, ask them what kind of CV the recruiting managers like to see.

Do your research first, it really helps.

Popularity: 23% [?]

A very popular question people ask is “what should I put in my C.V?”, the problem is, there is no correct answer to that question. There are a few consistent formats I see to the documents I see, but no set pattern I can figure out behind what has caused people to use that pattern.

Two of the guys I’ve worked with in the past and have equally successful careers, following similar tracks, who are of similar age and position in their career, have totally different approaches. Clive goes for the “everything in a good level of detail” approach. Pete’s CV is two sides, and he thinks it needs trimming down.

I think Pete’s CV comes from the approach that it seems a number of managers take, they want to get the details quickly and don’t want to wade their way through a load of self-promoting rubbish to get to them. Clive’s approach comes from the desire to give all the information so that every base is covered and people won’t miss any of your brilliant skills.

Personally, as a recruiting manager, I like to see a good level of detail on a CV. I want enough to really know whether it’s worth seeing the candidate or no. I want to get a feel for the candidate in advance. I want a chance for them to make mistakes.

But not all managers want that. They follow the Pimp Path, they want to find a few keywords, such as 10+ Years C++ experience on Windows Drivers. Or whatever. If they can’t get this information, they’ll reject the C.V.

The big problem is you don’t know what kind of manager your C.V. is going to.

I’m starting to come down in favour of a hybrid approach. The first page of the C.V. should be a totally lightweight highlights and basic facts page. With detail to follow.

Something that is also important to understand is what information you do need on the C.V., what order and level of detail to present it, and unfortunately that changes based on where you are in your career. For a graduate, clearly education history should come first, it’s the most relevant information. For an experienced engineer, the education history gradually becomes less and less important. But I still feel it’s necessary to include that information.

I think a front page should probably detail personal details, in a small contained area, current role and a brief statement of what you’re looking to achieve in your career. If there is room, a brief summary of key technical skills. Brief please, and the key ones. Not an exhaustive list of everything you’ve ever worked with.

Then, follow this with a career history, education history and some personal stuff.

With the later part, people are rather conflicted on too. Some people think a bit of “personal interests” adds something to a CV, others think it’s a no-no. Which seems odd, because technical skills are not everything, you also need to know if that person is going to fit in with your team and company. Are they going to have the right attitude to work? All information that can be indicated very roughly from the information given there.

So, summary, and then a set of detail. Attempting to keep as many people happy as possible. Really, an example would help. But I don’t have one to hand. And this is the worst article I’ve written ever. I’ll try and come back to it when I’m more alert.

Popularity: 29% [?]

I don’t know what it’s like round the rest of the world, but, in the UK most recruitment is done by asking recruitment companies to find candidates. The recruitment companies place the adverts, find CVs that are relevant and submit them to the hiring company.

This makes them salesmen. A typical recruitment company will charge anything from 15% to 40% of the candidates starting salary as a finding fee. That can be a lot of money. The role tends to attract younger people. It’s very high pressure as well as high margin. Very competitive. This all means that your recruitment consultant is worse than a double-glazing salesman.

They are much more like Pimps.

So, that is how they are referred to in my world. I deal with a lot of different agents. They all give you the same spiel, they’re different from the other agencies. They work this way and that way. Not like the others. Which is always a lie. They are all the same at the base of it, they are salespeople. They all work in much the same way. Their ethical boundary is slightly off from most peoples.

That is not to say they are all the same. Some agencies are better than others. Some agents are better than others. The larger agencies tend to work on volume. They want me to give them half a dozen keywords, some as “essentials” some as “Nice to haves”. They plug this into a propriatory keyword search engine and blast you everything they find without speaking with the candidate. Other’s actually take time to understand what you are looking for and try harder to find them.

But, once you’ve shown interest in a candidate, nearly all of them will do anything to close the sale. They’ll miss-represent me to you and you to me. They can see the sale just out of reach and go for it.

Take a little while to read up on hard-sales techniques. Then see how many you spot after an interview where the company was interested, but you weren’t. It’s shocking really.

You must remember, this is your career, the wrong job for you could send you down a dead-end, or a path you don’t want to take. Of course, you might not be too bothered about switching technologies or career path. But if you were then you wouldn’t be reading this.

Popularity: 14% [?]

The single most important document you will ever write is your Résumé or Curriculum Vitae (C.V.) . That bears saying twice. The single most important document you will ever write.

Ok, maybe your Will seems more important to you as a family person. But I’m not convinced. Your CV gets you the next job. The next step up. It enables you to be in a position to write a better will.

There will always be people who never ever need to write a CV. That just network from role to role. But that’s an edge case.

I’m talking about applying for software engineering jobs. So hopefully you reading this are a software engineer. I’m sure you therefore understand the importance of accurate, complete and up-to-date documentation for any software you are working on.

And if you don’t, go away and find out and don’t look for a job until you do.

Your CV is the same, only the accuracy and attention to detail of your CV is far more important to you. Forget to update the entry for your previous role so the “to date” says “present” and things like “My current job is” in a job 4 jobs back, then you look like a Muppet and won’t get an interview for any role that needs attention to detail on documentation or otherwise. i.e. a job as a software engineer.

Get a collegue, ex-colleague or friend who is a software engineer to read it through and make sure you’ve not messed anything up. I’ve seen CVs where people are proud of working on three tire systems (that would be tier then), sequel server and various other blatantly stupid things.

Your CV is the only tool you have to get you through the door. Sometimes there is a covering letter, an email to send it in, an online application form to attach it to. Make sure that what you write there has the same level of attention as the main document. Don’t let your CV down with a poor submission of the CV.

Pay attention to detail.

Pay attention to detail.

Popularity: 14% [?]

I have been recruiting for my company for two years. We had 6 software engineers in 2004 in my department. We now have 45. During the last two years, 2 of the original 6 have left and I have had 3 new hires quit. One of the 45 wasn’t recruited by me. So doing the maths, that’s 43 people that I have hired. Add to that the 10 contractors. 53.

But to hire 53 people, I have interviewed over 100 people. To interview over 100 people, I have seen over 500 candidate submissions. I’m dealing with at least 10 different recruitment agents. Candidates referred by existing staff. Candidates applying via our web site.

And on top of that, I’m managing the development of a major software product. On the support rota. One of the key firefighters on issues that arise. Sorting out office logistics. Buying development servers and software. Recruitment is not my full time role.

I got involved because they needed a technical person involved in the recruitment and ended up running the show. I have it down to a fine art. I can tell with a great degree of accuracy whether or not it’s worth interviewing someone from their initial application. We follow up with a technical test to be sure, then an in-person interview with me and someone else. But I would say at this point, I’d be 75% certain that I could say yes or no from the application and skip the rest.

So what I’m going to set out over the next few weeks is basically going to be how to get me to hire you.

The fundamental problem with all this advice is I can only be sure it applies to me. Every company has it’s own methods of recruitment. My advice might also work with other small to medium software engineering companies that rely on the technical managers to do the recruitment for the technical teams. But it certainly will not map to applying for a major company such as a massive multi-national bank.

So, before I start on anything else, perhaps we ought to look around and see what else is there to help you outside of my field. Because if you aren’t looking for a job in a company like mine, no advice I can give you is going to help. Because it’ll be too specific to working in a company like mine. Hopefully it will be in the right direction, and will help, but there will be some other different stuff.

So where else to go? There are numerous websites around with advice on your application and so on. Google them. There is a lot of information around about how the Google Recruitment process works. A lot of information about the Microsoft process. But, that’s all written from the point of view of giving the applicant generic advice. My advice is to look at it from the other point of view. Find articles about “How to recruit effectively”, written by people who do the recruitment for other recruiters. Find the inside track on how they’re being advised to find people.

When I started recruiting I looked for this kind of advice first and foremost. I started with Joel’s Guerilla Guide to Interviewing. I found this to be essential reading for me. I respect Joel as an expert on software. He’s an engineer leading some great development, and he needs to find more great engineers to provide that development. I’ve taken on some of his core points. I’m looking for Smart People who Get Things Done. I’m ensuring there is at least two people in every interview. If anyone says no, it’s a no.

But I’m not taking it all on board. Some of it doesn’t, and will not, work for my situation. His article on Phone Screening also has good information in it. I don’t phone screen however.

He also has a number of articles on your side of the fence too. I’d start with Getting Your Résumé Read.

Anyway, the point is, figure out what we’re trying to figure out. How do we ensure we find and recruit good engineers. Know your enemy. That’s a starting point.

Popularity: 12% [?]

The intention I set out with was one blog entry a week on my core subject, a real case of developing a new web application from scratch following a very professional approach and documenting it all. Essentially replicating what I do for a living as a hobby project and documenting what’s done en-route to show people what it’s really like to develop an application from scratch, properly, in PHP.

I also thought I’d make the odd post about other technical issues that came up in passing, tools I ran into that were not directly related to what I was doing, and articles I’d read that set me thinking.

Only, in early July work got very hectic. Stress levels up and I was wiped out by the time I got home. My wife thought I was on the computer too much and we had a row about it. So I’ve got no-where since then.

I still intend to carry this on at some point soon. Meanwhile, I’m going to get back into the habit of writing one article a week on development and software engineering as a career.

Right now, at work, I have a team of 45 engineers working for me. I’m recruiting for more. My experience reading CVs and interviewing lots of people has made me realise that people really don’t know how to write a good CV or to handle an interview. My experience running a team of engineers for the last two years has also shown me a lot of stuff about what makes a great programmer and what makes a great team member.

So, I’m going to shift focus and write about that for a while instead. I hope that’s of use and interest to some people.

Popularity: 17% [?]