It is old news that we at hedgehog lab are on the lookout for great developers to support the growth we are experiencing. It is also old news that recruitment is probably the toughest challenge facing any company.
This series of posts is intended to be an insight into our recruitment process (specifically the pains) and some tips to developers who want to make their prospective employers go “wow”!
Part 1 (this post) covers the humble CV and the common mistakes that we find developers make in writing and sending them out.
Sending your CV in Word or PDF format when our ads specifically mention the format of CV we would like (plain text, hResume or LinkedIn profile). This is a classic case of the “serial applicant” who has not made the effort to read the job ad and decided to apply when they saw the word “developer” in the ad.
Having a one line or no covering note. Just because you are sending your CV in e-mail does not mean that you do not need to write a covering letter (or note). Where there is a covering note, “Please find my CV attached” just does not cut it. Show some enthusiasm for the role and take the effort to summarise your CV for the particular job. If not, at least have a generic covering note which will seem a lot better than a blank email.
Having a covering letter which targets a role that has nothing to do with the job advertised. This sounds ridiculous but we actually received 3 applications from people who were looking for a tech support role, 1 from a sales manager and 1 from a real-time embedded systems developer. All this when they clearly responded to a job that said “web developer”. Even when the application is speculative, it indicates that you have not done your research on our company and you do not have a clue what we do.
How about the CVs that we did read but decided to not take it further?
Having a generic CV with a lot of noise irrelevant to the role. This is the biggest problem with a majority of the CVs we receive (even people we decide to interview are guilty of this). Please take the time to customise your CV for every role you apply for. Not doing so will only make it easier for the employer to mark you as a “serial applicant”. Your CV is the best sales pitch you can make and if you cannot spend more than 5 minutes tailoring it for a role, then it is not worth wasting either of our time.
Putting your list of hobbies/interests/fetishes on the CV (Note: This point is debatable as some employers prefer it. We do not!). I am sorry but we are absolutely not interested in your Karate skills or white water rafting in the weekend at this stage of your application. We expect all of our candidates to be interesting and if you really do have some unique interests, you can be sure we will talk about them in an interview.
Listing every programming language, operating system, database and desktop tool you ever heard of. We are not testing your general knowledge here and are not in the least bit interested how many programming languages you can name. What we are really interested in is the actual skills you gained and used in your previous roles.
Listing every job you have had which has no relevance to the role. It might be cute that you were a lifeguard at your local pool 10 years ago but trust me that it has no bearing on how good you are as a developer. Try and keep your job history relevant to the role. Where your experience is limited, try and focus on the company and year you worked there rather than the role, if the job has no relevant skills.
Although some of these might seem a bit far-fetched, these are real samples of the kind of CVs that a majority of developers write. One could argue that CVs are not really that important because the really good developers do not need a CV. Unless you happen to be in the 1% of really good developers, you have to sell yourself to prospective employers.
In the next part of this series, I will use more samples from our recruitment to talk about the Interview process and where we think developers get it wrong and finally wrap it up with a few general tips (the dos) and a healthy dose of links to essential material for any developer that is job hunting.
(Disclaimer: Please note that there will always be exceptions to every case I have presented and I completely accept there is no one right way of doing things. The methods and tips apply only to our recruitment at hedgehog lab and might not be applicable to other employers.)
Javascript is now part of a list of mainstream technologies on which the latest web applications and Web 2.0 is being built. Yet, it is surprising that a majority of Javascript code and developers seem to be stuck in the procedural paradigm where endless functions follow one another without any code organisation.
This is not an inherent problem in trivial systems but when we are heading towards SOFEA (Service Oriented Front End Architecture) and more applications are becoming browser-based, it can become a nightmare trying to maintain all the Javascript code. This essentially means that even where there is good use of object oriented Javascript, you could end up writing a large majority of code to just load, instantiate and configure objects.
However, while developing fixx (though we use some cool frameworks like jQuery), I noticed that we ended up writing endless amount of code to just instantiate objects and wiring up dependencies in these objects.
In a recent eureka! moment, I decided to do something about this on our last “lab day” and write an IoC container in Javascript. The result of this is Squirrel. As you guessed, it is “an IOC container in javascript”.
The current version of Squirrel is designed to ease the development of fixx client-side Javascript, allowing a greater decoupling between the complex objects that make up client-side code in fixx and resulting in code that is easier to test, maintain and extend.
A word of warning that Squirrel is currently in it infancy, but provides enough of an implementation of IOC to work with simple client-side applications.
As a software company without any external investment and focused on organically growing at this moment, hedgehog lab faces the constant dilemma of balancing revenue with driving innovation and the development of our products. Although we like to think of ourselves as a “product company”, all our current revenue stems from service work on client projects. The need to deliver on client projects while catering time for our in-house products creates a lot of pressure on the schedule available for our products. This is apparently not bad, as many good software products were created with the same constraints. However, the key difference is that we are a start-up that needs nurturing and has high cash demands.
Given these constraints, it is no surprise that getting our product delivery schedule right has been a painful learning process. We have had to constantly revise deadlines, reduce scope and re-visit our estimates. There is nothing wrong with our estimates; we usually get these spot on in client projects. However, the demands of client work means that scheduled product tasks get postponed indefinitely and without working over-time (which is evil), there is just not the possibility to squeeze a set of tasks into a time period. The result of all this is that we were never able to accurately predict our product milestones and the elusive launch date.
In light of this, the article by Joel Spolsky (our un-official mentor) on evidence based scheduling comes as a breath of fresh air. Being able to estimate an approximate release date based on evidence is not a new thing. In fact, it is common sense. What makes this method the crown jewel in scheduling is the fact that it combines facts with a clever algorithm and probability theory to deliver some interesting probabilities of when you can expect to deliver a version of your software. The coolest feature of this (in Fogbugz) has to be the slider that allows you to predict a date by selecting the priority of the features you want to ship. It just makes sense.
Although EBS (Evidence Based Scheduling) has been built into Fogbugz, you don’t necessarily need Fogbugz to implement this. The method is relatively easy to even implement on paper and I presume would be pretty accurate even if you do not take the complex algorithm and factors like velocity into account.
This is something we will be trying at hedgehog lab (we might even customise it to suit our approach) and who knows, it might even turn up in fixx in the future.
