Retaining great employees

There is talk on the web about retaining great employees and the way some of the articles are written about the subject you would think a lot of companies have a real struggle to get and keep great employees.

Not sure what makes the employees “great” employees other than the fact that if they are the ones leaving the company they obviously have options elsewhere.

So what would I do if I had a company with employees and I wanted to retain them without going over the top and paying them huge salaries obviously …

Allow home working

Allow the employees to work from home as and when they choose to.

Less hours in work day

Expect 5 hours “in the zone” work from each employee each day but pay them for 7.5 / 8 hours.

Allow the employee to revise skills, have breaks / lunch, collaborate with coworkers, work on personal projects, exercise or even depending on your limits allow the employee to occasionally take the rest of the day off in the 2.5 / 3 hours spare.

Alternatively if the employee really wants to, the employee can carry on with his / her workload. It is up to the employee what he / she spends the 3 hours doing each day.

Some afternoons could be spent doing group activities whether work related or fun related.

Also note that the above idea is not an excuse to compress more or the same amount of work into less time. If that happens then the above advantage has obviously been nullified.

More holidays

20 to 21 days holiday entitlement a year? Increase it. I think for every 8 weeks worked an employee should get around 5 days off work.

Lunch around a big table together

Have the whole company eat lunch together every working day around a big table or multiple tables if needed.

Once a month meal

Once a month take the employees out for a meal, paid for by the company.

Every 3 months have an employee activity day

Every 3 months arrange for there to be a fun activity day such as paint balling or some other group fun activity.

Have an open culture

Set the tone of the workplace as a place where people can ask work related questions of their teammates. Work related mistakes should not be jumped on but merely highlighted in a nice way.

These are the points I would implement in my business if I owned a multi employee business. Not all the points would have to be implemented but the more points the better. I would only apply these rules if the staff where regular employees, the rules would not be applied to contractors. Obviously if the workplace is toxic then none of the above points apply and employees will leave anyway but that is a different topic of discussion.

Technical questions on interviews? High standards?

So I have been to a number of interviews now where I have had to answer technical questions and do technical tests. The technical questions are of a high standard and can go deep into the principles of object orientated programming. What baffles me is when I ask to look at some of these companies codebases the codebase is a mess, even the interviewers have admitted that their own codebase is a mess occasionally.

I am talking functions with over a hundred lines of code in them, huge code files, code copied from one place to another with just a couple of minor changes, no consistency in naming conventions, if “classes” where used no real thought about true object orientation was attempted and the class was used just as a place to put some code.

Now the company may state they have high standards during the interview process to weed out the candidates who do not do well in the tests. However this makes no sense for a couple of reasons …

  1. True candidates who do well on the tests may not want to work on such a codebase. Even if the candidate who did well on the tests did want to work with such a codebase how can the candidate who did well on the tests adapt to such a codebase? All the candidates who did well on the tests can do with such a codebase is to follow what is already there for the most part.
  2. Companies with such a codebase do not want candidates who do well on the tests, the companies may claim they do but when it comes down to it the candidates suggestions for improving the codebase will not be taken seriously. Companies with codebases like the above suggested do not care whether someone can code the system in a more efficient and effective way, they just want someone who can work with the codebase they currently have.

Please note, I am not saying there is anything wrong with having different standards of code. I can adapt to different codebases and different standards of code infact adapting to what is there already is probably the best way of working with the codebase. I am merely wondering …

Why the high level technical questions and tests in the interview?

Who knows? I most certainly do not. None of the principles asked during the interview is applied to the companies codebase so why do candidates need to go through these tests and demonstrate such principles.

Earlier in the writing of this article you may have thought I was being harsh and judgemental when I was talking about the mess codebase. Like I say I am not bothered about the mess codebase if the mess codebase is already there and that is what the company has.

Sometimes codebases can become a mess if multiple people have worked on the project and there is no one there to really hold the architecture of the project together. I am not being judgemental in a harsh way, what I am arguing is why hold employees to high standards in interviews when it is obvious the codebase is a mess anyway.

It is like expecting 1 employee to do everything to a high standard on a project that has no standards. So that 1 employees contribution to the whole big project has to be to high standards whilst the rest of project can have no standards at all. Laying the burden on the 1 employee whilst the rest have not done anything to any reasonable standards anyway.

The best interview I ever had consisted of having a small conversation about myself and the company followed by a small task. The small task I had to complete was to demonstrate how I would fix a certain bug with one of the features within their current system. No tricks, no catches. I just had to explain how I would fix a fairly ordinary bug that has cropped up in the current system.

I was shown a screen with the bug on it and handed the codebase. I could determine the starting point to look for the bug via the URL of the screen with the bug on it. After starting at the above point and digging deeper into a couple more files I found the best place to implement the fix and determined what the fix would be.

It would be great if all interviews where like the one described above. The task has got to be something small that demonstrates the programmer can dig into the codebase and fix a small problem.

So in conclusion I believe that interviews should be tailored to represent the actual companny. If your company does not need candidates who do well on interview tests then the interview should not be tailored that way. If your company is adament that candidates who do well on interview tests are needed then the companies current practices and codebase should reflect the level of tests they are giving to candidates at the interview.

Please also note that in a lot of the tests companies give to candidates the questions seem more geared to how much you can remember from a standard “programmers handbook” than actual real world scenarios that might actually happen. That is why the above approach involving fixing a bug is a better approach in my opinion.