Evan Campbell recently wrote an informative article for employers at WebdesignerDepot titled “How to Find the Perfect Web Developer“. In this article, we will share a few tips with you to help you ensure that you’re the kind of developer that Evan and his readers would want to hire.
1) Avoid becoming a “specialist”
Trends on the Web move quickly. If you spend five years exclusively fine-tuning your knowledge of Drupal only to find that suddenly overnight everyone wants a WordPress site (or vice-versa) your prospects will be limited.
2) Stay in school
Related to the above point, you need to ensure your qualifications and skills are always relevant and up-to-date. We don’t mean literally going back to college, but there are so many free or low cost courses available in every Web technology you can imagine, it’s a good idea to invest a little time in learning a new skill every month.
3) Be a good communicator
The stereotypical geek is lousy at human interactions, so if you are a good communicator you are bound to stand out favorably. Being a good communicator requires a number of attributes:
Be prompt and punctual. Nobody likes to be kept waiting. If you have genuine time issues, communicate them. Most employers will be willing to accommodate your schedule if you discuss it with them first. When something happens that causes a delay, communicate it as soon as possible.
Be polite. An old saying goes “Good manners cost nothing”, and most of the time this is true. Strive to always give the people you work with positive feelings about you.
Be concise. Communicate everything clearly and simply, using as few words as you can reasonably use. Also try to limit the use of jargon, because jargon doesn’t make you sound smart, it makes you sound incomprehensible.
4) Make code easy for non-coders
If you submit any code to a prospective employer as an example of your work, strive to ensure that it’s really easy to understand what each section of code is meant to accomplish.
Use verbose comments. Unlike in your general communications, where it is a good idea to be concise, comments in your code should be descriptive.
Avoid commenting every line. That’s just annoying! Put descriptive comments at the start of a block or function, and use in-line comments sparingly. There are cases where in-line comments are vital to comprehension, so use them only in those cases.
Use verbose variable and constant names. Something like rf=250 may make sense to you, but rocketFuel=250 makes sense to everyone.
Use a consistent naming style and coding style. Most non-coders find 1TBS the simplest form of “braced” coding style to understand, while variable and file names are simple to understand when camel case is used, and camel case is better looking than snake case.
Spend some time making the code layout look good. While this doesn’t improve functionality, it does help to make the code look tidy and easier to read.
Make sure your code samples include a comment with your name as the developer. Without this, how will the employer verify that you are the author of the code sample? Beware that if you do plagiarize somebody else’s code and pass it off as your own, you would be breaking a number of laws. This is the only assurance that a prospective employer has.
Obviously you should never submit minified code as an example of your work, because minified code contains no comments, and even skilled programmers can have a difficult time reading it.
5) Code isn’t everything
It’s important to impress employers with your amazing technical knowledge and coding skills, but any employer worth working for will be looking for much more than that. So really what you should focus on talking about is your creativity.
What does that mean? Well certainly not things like CSS and layout design, although it’s cool if you can do those things too, and you should mention them. But creativity for a coder means being inventive. It means finding innovative ways to overcome problems.
So think really hard about projects you’ve worked on and the challenges that were presented, and what you did to solve the problems. Then articulate that information in a way that a non-coder will understand what you’re talking about.
If you’ve never worked on a real world work project before and you’re just jumping straight into freelancing, then use examples from your training instead. Or develop a few personal projects and use them as examples.
Another thing that is good to demonstrate is how you have added value to the projects you’ve worked on. For example, if you did more work beyond just the coding, such as writing a user manual, then that adds another string to your bow.
6) Show off your project management skills
Even though you may be just getting hired as a developer, being able to demonstrate how you approach and manage a project from start to finish is a really valuable attribute. These skills include things like:
- Organizing your time
- Creating deadlines and milestones
- Implementing solutions
Just be careful with the last point, because if you show too much delegation, it might look like you’re just lazy!
7) Avoid criticism
This tip actually covers three different things:
Avoid criticism of a former employer, even if they deserve it. Your new employer doesn’t want to hear sad stories or excuses, and it’s not a good idea to portray yourself as disloyal or a troublemaker.
Avoid being too critical of the prospective employer. This one may seem way too obvious, but in fact sometimes prospective employers invite you to be critical of them. Don’t fall for it.
Avoid self-criticism. Again, employers often attempt to lure you into doing this, and it is one of the most damaging things you can do. Always find a positive spin.
And finally, just before we wrap up, here’s one last piece of advice…
8) Never work for free
This is a big one. There’s nothing wrong with employers asking for a free sample, but the free sample you provide should not actually be work. In other words, it should have absolutely nothing to do with the project you’re hoping to be hired for.
Otherwise you run the risk of being just another sucker contributing a free component to a larger project. It’s also not ethical for an employer to ask for a sample that is closely related to what you’re being hired to do.
Another reason why you should not work for free or sell your skills too cheaply is that it hurts the entire industry when you do that. The only exception is when you do something for charity. Don’t confuse charity with non-profit organizations, as there are many organizations that are non-profit and milk that status to get something for free that they don’t really deserve.
Doing charity work can be an excellent way to build up a portfolio and also do some good at the same time. As long as you’re not being taken for a sucker.