Skills are one of the most important parts of a good CV. As a composite, they reflect your sum of experience and the role to which you would be best suited. Most job adverts will have a listing of required or desirable assets, and the ideal CV will intersect with this requested skill set as much as possible.

Caveat employer

However, an individual's skill set is often hard to describe in one short section - and the quantity of experience doesn't indicate quality of experience. A programmer with a purported ten years experience in a given language could potentially be less able than another with just one or two. This can inevitably pose a problem, especially for employers looking for proficient professionals in a particular area.

Those claimed 'ten years of experience' could consist of superficial, occasional usage of the skill in question spanning the last decade, where only the subject surface is scratched and advanced topics are left unlearned. However, just one or two years of more intense, continuous experience within a given field or with a specific language could mean that the applicant is quite proficient.

Decoding stated experience

The above is hypothetical, of course - generally a greater quantity of experience within a field indicates the more skilled candidate. Nonetheless, it is a hazard for both candidates and for interviewers to rely absolutely on the level of skill stated on a CV - particularly using an ambiguous metric such as 'years of experience', or something equally as soft a measurement (non-qualified descriptions such as 'highly proficient', etc).

To really ascertain the level of proficiency in a skill area the candidate should be put to the test - either through an informal Q&A session with a technically-minded person or with a more formal testing procedure.

Presenting your skills

Problems aside, the skills listing on your CV shouldn't be overlooked. In many cases it is the passport through the first stage of selecting the most suitable candidates for interview. Indeed, in the pre-interview phase the CV is the only indicator of aptitude.

If you're applying for a position that mandates a certain skill set, you should think carefully about how best to present the skills you possess with your CV. Should a position state that '3 years of professional experience is required' within a certain field, and you can only claim 1 or 2 but are otherwise of a suitable proficiency, you should ideally emphasise any other contributory experience.

You will need to be careful not to disqualify yourself at an early stage - if you don't meet any posted required standard you may be rejected at the first hurdle. Ideally, the person responsible for reviewing your CV will be aware of some of the issues facing skill metrics.

On the other hand, you must be careful not to overstate your skills - should you reach interview any lack of supposed experience may become apparent. Balance is the key - you need to fit your applicable skills as best you can to the listed requirements, highlighting your skill strengths while mitigating any apparent weakness.

Ever since .NET burst onto the scene back in early 2002, Microsoft has promoted it as the primary platform for custom applications. For sure it has plenty of advantages, including automatic memory management, a modern programming language called C#, and a rich class library encompassing both Windows and Web development. The Windows Presentation Foundation, touted as the next generation of the Windows user interface, can only be programmed using .NET.

Unfortunately .NET also has downsides. The first is potentially troublesome deployment, thanks to the large runtime required. The problem has not gone away even though Windows now comes with .NET as standard, since new versions appear regularly. The second issue is performance. Although a just-in-time compiler enables .NET code to run at near-native speed, there is still a heavy memory overhead. The result is that .NET applications generally load and run more slowly than native code equivalents.

The trade-off here is that ease of programming compensates for slower performance. It's true; but not all developers realise that the choice is not only between C# and Visual Basic on the one hand, and the intricacies of Visual C++ on the other. Before turning up as Microsoft's chief architect for C#, Anders Hejlsberg worked at Borland on a language called Object Pascal and a development tool called Delphi. There is some family resemblance, particularly if you include Delphi's Visual Component Library (VCL), which wraps the Windows API with a class library that is equally as capable as the Microsoft Foundation Classes, but much easier to code against. Unlike Microsoft's .NET tools, Delphi compiles directly to native code, and it is feasible to create applications that have zero dependencies, run like lightning, and work on versions of Windows right back to 2000.

Delphi's recent history has been unsettled. Borland delivered some unsuccessful .NET editions and messed with the IDE. The Delphi side of the business was then spun off into a separate entity called CodeGear, which was recently acquired by Embarcadero, best known for database design tools such as ER Studio. Fortunately the compiler remained as good as ever, and the signs are that Delphi's new home will be good for the product. The company has just released Delphi 2009, the first version with proper support for Unicode. A companion product called C++ Builder has the same VCL, but uses C++ in place of Delphi's Pascal variant. These releases also introduce language enhancements including generics and anonymous methods.

Delphi is not the answer to every software problem, and its documentation is poor compared to what you may be used to with MSDN, but in the right context it works like magic. Aside from .NET, every corner of the Windows API is open to it, including services, native code DLLs, COM components, and fiddly software like custom actions for the Windows Installer. The Delphi IDE is once again mature. If you have ever looked with horror at the tens or hundreds of megabytes demanded by .NET for your small Windows Forms utility, or found yourself troubleshooting some obscure problem installing the .NET Framework, Delphi is well worth investigating.

If you're in an interview and your interviewer is not so skilled, you may have to prompt the interviewer to ask good questions. Yes, for those of you who dance, this is called "back-leading." I'm assuming you have prepared yourself in Developing Your Interviewing Skills for Candidates, Part 1: Prepare for the Interview.

Here's how this can play out.

I just love the question (not!): "Why do you want to work here?" My non-career enhancing question is, "Why should I? If you manage like you interview, I don't!" But like I said, that's not helpful.

So here are alternative ways to answer that question:

Candidate: "Let me make sure I understand something about the project" or "Let me make sure I understand something about your environment."  You want to make sure you have a similar project in mind. Now, take your first set of projects, where you thought about your non-technical qualities, preferences, and skills, and answer in ways like this: "I worked on a project like that" and point to the project on your resume. "I enjoyed this part." Now, explain your role, how the project proceeded, what happened, and how you succeeded. What you've done is take an open-ended but meaningless question and turned it into a behaviour-description answer. You've talked about your past experience and given the interviewer a place to start asking you more and hopefully better questions.

Sometimes, interviewers ask another of my not-so-favourite questions:  "Tell me about your strengths and weaknesses."

Instead, give a story about one of your successes on a project. If the interviewer says, "That was a great strength, now how about a weakness?" go back to your homework and turn around one of your strengths. One of my favourite ways to answer that question is: "Well, sometimes at the end of the project, I work too hard." Stop there. If the interviewer asks why that's a problem, you can say, "I burn myself out without realizing it." That's actually a huge problem in projects.  But interviewers who ask these questions might not realize that. Sigh.

Your job is to be prepared.

It is time we stopped talking about Rich Internet Applications, the term coined by Adobe to describe Flash-based Web applications, and borrowed by everyone else to apply to their latest efforts to improve HTML. The discussion is not really about rich applications versus, I guess, plain applications; rather, it is about the next generation of the client. Although it is too soon to know what that is, it strikes me that we already have some strong clues:

-    It will not involve wrestling with the Windows Installer every time you need to update an application
-    The same code will run on Windows, Mac, and probably Linux and mobile devices
-    Local data will exist mainly as an offline or performance-enhancing cache of server or internet-hosted data
-    It will most likely run in a web browser
-    It will most likely be written in JavaScript
-    
What fascinates me is the way in which our most influential technology companies are putting their weight behind different approaches to these common goals.

Apple would really like you to write native code for OS X or the iPhone, but for web applications it is backing Safari and JavaScript libraries like SproutCore.

Google and Mozilla are also stretching browser technology, with Google adding offline data support through Gears, and Mozilla determined to out-Flash Adobe by supporting SVG, Canvas, and HTML 5.  Microsoft has Silverlight, one of its most interesting developer products for years, which brings XAML and .NET together in a neat cross-platform browser plug-in and Adobe has Flash, Flex and AIR - all variations on using the Flash runtime as an application platform.

I realise there are other approaches. Perhaps Sun will yet come good with Java FX. But it seems to me that these are the key players jostling for position as developers try to figure out where to go next for client applications.

I also realise that it is early days. A quick search for vacancies on CWJobs reveals just 106 for Flex and 79 for Silverlight, versus 3417 for C# and 2116 for Java at the time of writing. Still, I am betting that figures for both Flex and Silverlight will increase markedly in the next year or so. I also believe that Adobe will be hard to catch, because designers already know and love Flash, and because developers will prefer to target a relatively predictable runtime, even though it is proprietary, rather than trusting browser vendors to stick closely enough to standards to let their tangle of HTML, CSS and JavaScript work reliably across all the platforms.

Silverlight is attractive too, but Microsoft has a lot of catching up to do, especially in runtime deployment, and has not yet come up with anything to match Adobe AIR which takes Flash onto the desktop.

AIR still needs a bit of work - it is silly that the runtime can write all over your hard drive, but cannot launch a document in Word or Excel - but Adobe has time to improve it. Flex works well with both Java and .NET on the server. Finally, ActionScript 3.0 is close enough to C# or Java that it is not difficult to make the transition.

Could Flash really be at the heart of the next-generation client? It is certainly possible.

Once you've started interviewing, you might encounter plenty of interviewers who don't know how to interview. That's ok -don't discriminate against these folks just because they don't know how to interview. They might know how to build great software. If you build your interviewing skills, you can still present yourself in a good light, *and* help the interviewers learn whether you are a good fit.

First, do your homework. When you think about the job you're interviewing for, think back on your career so far. Have you worked on similar products? Maybe you've worked in a similar environment? Maybe you've worked with people on the team before? Think about your accomplishments in the context of this particular job.

Now, think of the qualities, preferences, and non-technical skills you want to showcase as your expertise. (Yes, I'll get to technical skills later.) Maybe you're great at considering multiple options for architectures. Maybe you're great at driving to a finish for a project. Maybe demos are your forte. Maybe you're great at asking questions about the product that make everyone think about what they have to do as developers, analysts, testers, writers. Think about times when those non-technical skills shine. If you need to, make a note of the projects where you shone.

Now, think of your technical skills. I find it easiest to think about the four dimensions of technical skill:

- Functional skill: what you know about development or testing or analysis or writing or project management or whatever your role is.  You started learning these skills in school, and have increased them on the job.
- Domain expertise: solution-space domain expertise is how well and how quickly you learn the insides of a product. Problem-space domain expertise is how well and how quickly you learn about the problems the product solves.
- Tools and technology: what tools and technology you know: Eclipse, Ruby, Java, C#, Unix, any of the unit testing frameworks, and more
- Industry expertise: the expertise people assume when you've been in an industry for a while. For any application involving a database, maybe it's about how you organize and reorganize a schema. For financial transactions, maybe it's security. For online applications, maybe it's performance and security.

Think about how you've succeeded with these skills in projects.

You've got some projects where you've been successful. You've got non- technical qualities, preferences, and skills, as well as technical skills. If you do your homework, you can actually think about how to interview.

Getting a job in IT is a lot more than just ticking the right skills boxes; there are a number of other assets and techniques you can bring to an interview to maximise your chances of getting the position in question. Such 'employability' is essentially a composite of your skills, your effectiveness in presenting those skills, and the manner in which you communicate.

Here I will cover five of the more important key aspects used to assess the suitability of candidates for IT roles - largely stemming both from my experience as an interviewer for technical roles, and on the other side as a interviewee.

 
Education

A good education is a good start, as far as employability is concerned. A degree is not always necessary to break into an IT career, but it certainly helps - treat your degree as a foot in the door, not as a passport to an automatic career.

A key thing to remember is that your IT education does not end with the receipt of your degree - in many ways, it is just the beginning. If you wish to remain competitive, you will need to constantly improve your skills, and keep up with developments in languages or frameworks.

Do not discount additional educational routes either, in particular professional training courses. Microsoft's offerings are well known, and valuable - as are Cisco Career Certifications.

Qualifications alone will not get you a job, though - you will need to round out your education with the demonstration of a little aptitude and a willingness to continue learning.

Experience

Regardless of qualifications on paper, the breadth of experience you have will also be a major factor in your employability. A degree in database systems is one thing; ten years working as a DBA is quite another.

For university leavers, the lack of experience is a hampering factor - many job listings state that they require a certain number of years of 'professional experience', which may seem insurmountable to those who have dedicated the last three-plus years to the study of their chosen art.

If you lack the required experience, fear not - some positions will be more amenable to graduates than others - and the key thing to remember is that years of experience can be trumped with your other assets, whether it is your specific skill set, or demonstrable dedication to a field.

Confidence

This is perhaps the hardest asset to attain, but confidence is a great skill to have in an interview situation. The IT world is filled with introverts, many of whom are greatly skilled, but if you cannot convey your suitability for a role your chances may be diminished.

Confidence does not mean you have to know the answer to every question - but it does mean that you should not be fazed should you come across a query in a subject with which you are unfamiliar. There is no perfect solution to dealing with unknowns, but do not let it throw you - just roll with it and steer your answer back to the areas in which you are capable.

Be wary of arrogance, too - you do not want to come across as confident to the point of rudeness. Your demeanour in interviews should be a balance between confidence, likeability, and a touch of modesty where needed.

Enthusiasm

You do not need to be fresh-faced to be enthusiastic. A passion for IT, or a specific area, is undeniably a boon in terms of getting a job.

Genuine passion for a subject usually shines in the interview - if the interviewer sees that you are willing to talk at great length about a particular subject, they will probably note that as a key interest of yours. Just make sure it is relevant to the role!

It is not just your ability to wax lyrical about a subject that will convey enthusiasm either - extra-curricular activities, such as maintaining a relevant blog on a technical subject or indulging in personal projects, will help in showing your enthusiasm and dedication to a given field.

Such relevant work is particularly suited to the next point, demonstration:

Demonstration

The single best thing you can bring to a job interview is a direct demonstration of your skills. You could talk about how many years experience you have with a language until you are blue in the face, but if you can demonstrate a concrete example of those skills, you will fare far better.

For certain skills, this may be tricky - but in my field (web development / design), a solid portfolio of live URLs that are demonstrable of suitable skills are invaluable. The visual aspect is important - whether it is printouts, screenshots, or live demonstrations - such assets will ably illustrate your talents, and in a much more memorable way than simply discussing such work.