I've been on both sides of the interview table, and have seen a number of candidates fail through poor preparation.
Try a few simple strategies:
If applying for a J2EE position, research the technologies (e.g. JSF, Spring MVC, Struts 2 etc) and say so on your resume. Same applies to any other technology stack.
If you get an interview, bring along a working example on your laptop, and do a SHORT demonstration. If its a PHP job, the demo should be in PHP/MySQL etc. If its J2EE, JSF, Hibernate and MySQL would a good combination.
Explain what your demo does at a business level. Forget that whizzy feature that you spent days developing - if the audience can't understand what you are doing, they won't be at all impressed. As developers, we have an unfortunate tendency to assume that everyone knows the high-level design, and are interested in the minutae. But generally, employers are looking for people that both program and communicate with non-technical types. A lucid explanation at the business level will earn you brownie points.
Keep it simple - a pizza ordering website might be a good example. Even our HR people eat pizza.
Explain the functionality, not the detail (e.g. "Pizzas can be ordered by text message" rather than "I used an activeX control from Bloggs Technology to implement SMS ordering")
Read widely, follow newsgroups, and keep your skills up to date. You may not know the details, but if someons asks if you know what something is, it is good to be able to answer along the lines of "thats an emerging programming language. I'm no expert, but it looks it may be the replacement for Java in a few years time". For instance, can you give an outline of what the following are (excuse the Java bias and a few obsolete technologies): Scala, Ruby on rails, Apache Cocoon, AJAX, JQuery, STRUTS, B2B, EAI, COBOL, DMA
Research the firm's technologies. An inside contact would be invaluable, but if you are applying for a web programming job, a few minutes on the company website should tell you if they use J2EE, ASP, ASP.NET or PHP. If not, then maybe the job is not for you.
Take a good look at what the company does, and make sure it fits with your personal values. It will show through at the interview if you are bored by or opposed to the company direction. Having lost parents to lung cancer, there is no way I would work for a tobacco company.
Listen to what the interviewers are saying, take time to digest it, then give a reasoned answer.
Be prepared for the standard HR questions (e.g. "What would you do if you could not agree with a co-worker's decision on something imortant", "Where do you see yourself in 5 years time" etc). There are lots of good websites that will help here.
Be yourself - thats what is being hired.
Even if desperate for the job, try not to show it. Hiring people is a two-way process. The company wants someone who fits in, and will make a long-term positive contribution, not a low salary "doormat" that will leave as soon as a better offer turns up.
It always impresses me to find that a candidate has outside interests. I personally landed a job on the strength of having some accounting knowledge. This came from being a club treasurer for several years. There are those who hire geeks, but most firms want real people.
As an engineer that writes lots of specifications and business cases , I offer the folowing:
To many of your readers, poor grammar, spelling and punctuation is a turn off. After all, if you cannot express yourself well, why should the reader believe that your technical skills are better than your English writing skills?
Assume your audience has a short attention span - use bullet points that say what you think, and move the (sometimes turgid) technical detail to appendices and/or sidebars.
Take a course in the most common abuses of the English languages. Many writing problems can be fixed by a short course on correct use of the apostrophe, common spelling and usage mistakes etc. It is just an area that engineers tend to avoid.
Have your writing proof-read by another skilled writer. We all make mistakes that are not immediately obvious to ourselves. (Caveat - this post has not been proof read)
Learn to take constructive criticism, and act on it.
When rubbishing other opinions, do so with tact and logic - you need to convince people to accept your views, not to alienate them
Start with a conclusion, amplify and expand on your reasoning, then end by emphasising your conclusion. Always assume that you are trying to persuade someone to agree with your line of reasoning
Above all, practice makes perfect. Even your coding comments should be easy to read. Remarkably, one can come to enjoy writing - even if it was seen as a chore early in one's career.
Slashdot Mirror
Try a few simple strategies:
Above all, good luck.
- To many of your readers, poor grammar, spelling and punctuation is a turn off. After all, if you cannot express yourself well, why should the reader believe that your technical skills are better than your English writing skills?
- Assume your audience has a short attention span - use bullet points that say what you think, and move the (sometimes turgid) technical detail to appendices and/or sidebars.
- Take a course in the most common abuses of the English languages. Many writing problems can be fixed by a short course on correct use of the apostrophe, common spelling and usage mistakes etc. It is just an area that engineers tend to avoid.
- Have your writing proof-read by another skilled writer. We all make mistakes that are not immediately obvious to ourselves. (Caveat - this post has not been proof read)
- Learn to take constructive criticism, and act on it.
- When rubbishing other opinions, do so with tact and logic - you need to convince people to accept your views, not to alienate them
- Start with a conclusion, amplify and expand on your reasoning, then end by emphasising your conclusion. Always assume that you are trying to persuade someone to agree with your line of reasoning
Above all, practice makes perfect. Even your coding comments should be easy to read. Remarkably, one can come to enjoy writing - even if it was seen as a chore early in one's career.