Category Archives: Recruitment

Why your engineering department needs a tech blog

If you know me it’s no secret that over the last few months I’ve been looking for a new challenge (stay tuned for more on that later!). While I was doing this I was struck by just how many organisations still don’t have blogs written by their technical department.

At a time where social media is EVERYWHERE this seems almost perverse. With the dependence on the web and mobile almost every company is now an internet company to some degree. An airline is in the business of moving people around in flying boxes but they have an enormous technical infrastructure. Banks are in a similar position and so are pretty much every company that sells something. Okay, not everyone is going to have a large development organisation but almost nobody has zero and because of this all companies will suffer similar issues around:

  • How do you attract quality technical staff?
  • How do you communicate complex technical issues that have a fundamental impact on the business with a wider audience of laypeople?
  • How to inspire and fulfil technical staff?

These are notorious hard problems to solve. High quality tech staff are far more productive than average tech staff and you only want to hire the best. Technologists are notoriously bad at communicating their domain to non-technical people, both internally and externally, and also tend to be driven by different motivations.

So why does having a technical blog help?

  • It’s free advertising for recruiting technical staff
  • Transparency drives quality both in the product and in the engineering culture
  • You are upskilling your technical staff for very little cost and can produce content for talks at conferences/whitepapers
  • You are engaging with your community and raising your profile which is turn means free brand marketing

Examples of the companies that do this best are Twitter, Linkedin and Etsy

Admittedly it’s only my experienceand not a rigorous survey but there does seem to be a fairly strong correlation between companies with a good engineering culture, i.e. places I would want to work at, and having a good tech blog. If your technical staff don’t have a voice what are we to think? That you don’t value or trust them or that the standard of your technology division is fairly low and you don’t want to expose just how bad they are? Either way, my interest in working there is going to be non-existent.

It might sound harsh but if you are in a technical leadership position you owe it to your company to have a blog written by your technology staff. I would go as far as to say that every technical person should have “write a blog post” in their yearly objectives.

If your technical department does not have a blog you might as well be announcing to the world that you are second tier and are happy to stay that way.

So are you?

Screening graduates for technology roles

Graduation time again. Newly minted grads will be taking to the streets looking for a job and many may well have applied or being looking to apply for graduate programs at companies both large and small.

These programs may look to rotate recent grads through the different departments over an 18 month to 2 year period to allow them to find their ideal niche or just be a direct pipeline into a single department. Given the current economy, even a half dozen spaces on a graduate program are going to have several hundred application for each space.

This raises an obvious question for a technology company looking to recruit into their development organisation: how the hell are HR, who we all know lack the understanding of what makes a good technologist, able to winnow this ridiculous volume down to something where developers can get involved? At my current client we would love to be able to interview every candidate. Given that we like to spend at least half a day doing an initial assessment, that just won’t scale. Because of this I was asked to help come up with a solution that could be completed by the candidates and/or the HR folk to generate a way of ranking candidates. So: non-technical people assessing technical people? It’s going to have to be some sort of list.
Continue reading

Developers – You are not just the sum of your technical skills

I’ve been pondering the fact that when I started out on a career in development, I focussed on the technical side of it almost to the exclusion of all else. This was especially true for me since I was coming from a non CompSci background after spending years sticking electrodes in people’s heads and doing biological research. This made me painfully aware that in an industry like programming, if you don’t know your stuff you are useless to your team and your company. Worse, you run the risk of ending up a Net Negative Producing Programmer and reduce your team’s output to less that it would be if you weren’t there.

Thus the first few years of a my career as a developer were spent focusing entirely on technical matters. I fought hard for the expertise in the areas that I worked in: Java, JavaScript and C, web development, back end services and multi-threading… the list is long and mostly distinguished (EJB’s… blergh!). I wanted to be that go-to guy for all thing technical and do my part in making my team the best in the company. As a contractor, my skills were the yardstick for how I was judged for new roles so of course I was interested in keeping them up to date.

After a relatively short time it became obvious that this wasn’t enough. Being technically adept is the foundation of our job but certainly not the totality. Even before you get your first job you realise the importance of communication. Not just in communicating your skills to get that first job but then once you’ve got it, then communicating with the rest of your team including the non technical members. This is especially true in an Agile world where you have to be able to tell others what is going on in a way that they will understand.
Continue reading

My GDC Questionnaire

I’ve been asked to be a mentor to the excellent Graduate Developer Community and before I’m allowed to go an warp the minds of future grads, I was asked to answer a quick questionnaire to give a bit of background on myself and ask how I got into programming. It was an interesting exercise so I thought I would put the results up here too.

Martin Anderson has worked in IT for the last 13 years across industries as diverse as online advertising and news to investment banking and gambling. He came to the industry from a slightly unusual direction since his first degree was a BSc in Physiology. After a brief stint for a pharmaceutical company he went back into academia and it was during his PhD, which involved the computerised analysis of EEG’s, that his interest in computing really took off.

Title – What is your job title?
Software Architect

What is your role about?

The best description I have ever read of what an Architect should be can be found here. The main responsibility of my job is that I am expected to cross the divide between technology and business while being expected to be able to answer all the technical questions. Principally I am a developer but my responsibility to be aware of so many different projects makes it difficult to directly contribute code very often.

What are the best/most positive parts of the job/industry?

That it combines the best of the worlds of startups and big industry. The problems we have to solve are generally the really interesting ones: how do you offer the best service to your customer while balancing the demands of performance, scale, security, regulators but we get to solve them in a way that is not normally seen in a major company.

Your Saturday afternoon becomes very different when you realise that you have up to 4 million customers betting many millions of pounds on your applications and to do this they are hammering them to pieces. For example, we see up to 88,000 requests per second across the entire estate at peak times so your application can’t just work, it has to be fast, reliable and deal with load at internet scale.

What are the negative parts to the job/industry?

How changeable things can be. The industry is at the whim of regulators so some of our solutions have to make compromises that you would never design in if you had complete freedom to do it your way.

There is also the fact that some people see the gambling industry with a slightly negative cast. It’s not for everyone but what is?

Career Path

What is the standard career path/qualifications?

The standard technology career path at Betfair is: Intern – Associate Developer – Developer – Senior Developer – Technical Lead/Principal Developer/Software Architect

As far as qualifications go, we do have a graduate scheme and like most large companies we prefer graduates and respect the amount of effort it takes to get degree but given that some of our best employees did not go to university (or in some cases not even finish secondary school!) we also look for other signs that we think signifies quality.

What are the prospects?

From a company perspective they are as good as you want them to be! Betfair is one of the UK’s sucess stories since it is just over 10 years old and still expanding: we currently serve 140 territories in 17 languages and this will only increase. We deal with cutting edge technologies at a scale that most companies can only dream of and this experience makes you very employable.

From the more general perspective of an Architect, they are also very good. To get to the role normally requires several years exposure to how things actually work. Not just the code or development knowledge but also the knowledge about your hardware and your network can be just as important. The business knowledge is critical too since you have to be able to understand the hot button topics of your company. Luckily the types of issues tend to be similar across all companies: performance, scale, ease of use, cost of development v maintenance, reliability and disaster recovery, compliance, audit and regulatory to name a few of them. This makes architects very valuable for many businesses.

In your experience are you aware of any differences your role has between industries/sectors?

The role of Architect can vary hugely and not just from industry to industry but also within different sized companies within the same industry. In the worse case scenario, you have the ‘Astronaut Architect’ who make technical pronouncements from upon high without actually working closely with the developers who have to turn the abstract into application. In the best case you have Architects who are directly invested in the success of a project, from concept to cash, and who work side-by-side with their developers. The role of an Architect is that of an influencer but in a technology company that means he/she can become very powerful.

Reflection and The Future

What was it like coming into the industry?

I was several years out of University before I started working in IT  so I had no illusions about what I was getting myself into. For me the worry was that as a self-taught programmer I would be missing chunks of knowledge about development. I found that the enormous knowledge area of development meant that everyone is far more collaborative than competitive and this meant that I could contribute immediate while being made aware of what I didn’t know and what I would have to learn. I love what I do with a passion and wouldn’t want to do anything else – except possibly be the next David Attenborough!

Do you have any thoughts on the future of your role/industry?

Cloud is taking centre stage more and more but this is more a reflection of the combination of two things – performance/scale and flexibility. As the industry becomes more mature we now have to delivery faster and to a wider audience that ever before. Cloud allows us to do this in that it allows simple prototypes to be rolled out to a platform that is inherently scalable should the application be a success.

Dealing with teams in multiple locations and in multiple timezones is another topic that is important and becoming more so. The world is a smaller place than it used to be and getting smaller. We are also in competition with a larger population of developers than ever before and in a knowledge based industry like ours, the smartest and hardest working will win.

What advice would you give someone entering your industry?

Follow excellence. It doesn’t matter what you are doing if you are doing it the best it should be done. This more than anything else will define your career.

You should never feel that you become stereotyped as a certain type of developer – it’s up to you to take control of your career and you do that by learning. You should have a hunger for new knowledge and everyone should have a list of things that they want to try or learn.

Have you come across anything or anyone that has helped you move forward in the industry?

Having a great mentor is a must. I’ve been lucky in that I’ve met several people that have taught me so much. Also, you should never underestimate a constant drive to improve.

On a practical note – nothing beats getting involved. Get a github account, fork someone else’s code and get stuck in. Start contributing to open source even if it is documentation but get in the game. Not only is your CV improved for it but you as a developer are much improved for it.

The Characteristics of a Good Developer

The recent rash of interviews have made me think a little more about what makes a good developer and more importantly, which of these qualities can you try to spot during the interview process. After having a conflab with a couple of other devs and one of the few recruiters I know that isn’t a shark, I came up with this list. Of course this is going to be a personal list but some of the points seem to intersect with some other resources out there so I don’t think I’m too far out there:

  • Polyglot in outlook
  • Able to learn quickly, and happy to learn
  •  Open to new ideas but capable of defending their own
  •  Technically able
  •  An Influencer
  •  A Producer
  •  Not too proud to ask for help
  •  Knowledge across a broad spectrum of topics
  •  Determined

Polyglot in outlook
One of the Java devs I work with recently coded up one of the most elegant solutions to a complex problems that I’ve ever seen. When asked how he came up with it, he mentioned that he based it around some of the structures that Make uses internally. Too many developers only live within the walls of their favourite language and never see what else is out there that they could take advantage of. As a Java house, currently I would have to say that anyone with Scala or Clojure on their CV will be seen far more favourably than someone with just Java and someone with half-a-dozen languages is almost always going to be going places. In fact during interviews I will deliberately ask questions on concepts in languages that aren’t on the candidate’s CV since I want them to at least be aware of these concepts even if they have never used them.

Able to learn quickly, and happy to learn
As a self-confessed knowledge junkie, I love learning. In fact I find it hard to comprehend what other developers do not. Given that we are in a knowledge industry, those that do not have a thirst to learn will find themselves going the way of the guys who thought that punchcards and ticker tape would last them a lifetime.

Open to new ideas but capable of defending their own ideas
What is the point of having great ideas if you don’t have the ability to defend them. Developers tend to have robust opinions about how things should be done so you have to be able to defend what you think is right. Otherwise you are condemning yourself to work on projects where you spend your time muttering to yourself “this could be done so much better”.

Technically able
You have to bring skills to the table. You can be the greatest person in the world but unless you have the technical chops to be able to develop you will just be a drag on the rest of the team. Don’t be the Net Negative Producing Programmer

An Influencer
This is the pro-active side of being able to defend your own ideas. You need to be able to change or at least shape the ideas of others and have the communication skills to do so. Especially at the level of senior developer or above, you have to start spending time educating and influencing others. If you fail to do this, all you are doing is making your job harder. You have to be able to prevent small problems blowing up into big ones and if that means you need to sell your ideas, then that is what you do. If you are a Senior Developer and above, I expect you to influence your workplace. For example, if your current employer does not use a Continuous Integration Server like Hudson/Jenkins or Bamboo, you have failed in your responsibilities if you cannot convince them that they should.

A Producer
Seeing someone’s work on something like Github gives me one of the best insights into what sort of programmer they are. Ultimately, it’s the Quarterback problem, it’s practically impossible to judge someone’s ability until you see them in action. The closest thing you can get to seeing them in action is to see the results of previous work and this is why we have a technical test as part of our interview process. And before you roll your eyes, we’ve made sure that the test is directly related to what we do and isn’t just some random logic puzzle. If you are already on a team, make sure that you take time to look at your work and check to see if there is anything your should be doing or anything you should not be doing that would improve your productivity. I knew of an Architect at a recent company who was obviously very bright but was unable to produce anything.  He literally produced nothing but ghosted around on his domain knowledge and reputation when he actually contributed nothing to the teams in his area.

Not too proud to ask for help
If you get properly stuck on something, no one will think worse of you if you ask for help. You will drive your team mates mad if you disappear off and take days with a problem, especially if one of them immediately gives you the answer that would have saved days. Your colleagues will quickly realise that the people who have to cover for you getting stuck is them.  The only time people will think less of you is when you get stuck and don’t even bother to try to figure it out yourself before you start asking for advice.

Knowledge across a broad spectrum of topics
Depth of knowledge demands breadth of knowledge. It is impossible to be an expert in one area without having a degree of expertise in others. The ability to link concepts is hugely important and if you already know something similar, even in an unrelated field, learning something else will be so much easier.

The tired old saw of ‘when the going gets tough, the tough get going’ aside, you have to have a certain cussedness to succeed in programming. Spending hours trying to pin down an elusive race condition or tracking an issue through layers of network infrastructure, web servers, caches, web services and database code means that you can’t be someone that throws in the towel early. Also, there are always going to be times when you are going to have to put in some extra work. Whether it is an approaching deadline or a sudden change in project priorities or roles, no one is going to thank you if you can’t manage your focus. If you are known to meet challenges head on, your team mates will always be there with you and will always have your back. If you have any tendency to slack off, you colleagues will leave you high and dry and I wouldn’t blame them at all.

I should also say that this also applies to situations where management are asking you to do ridiculous things. If the higher-ups have you on a Death March, I don’t want someone that meekly caves in an agrees to late nights and weekends in the office without seeing if it is the right thing to do. Determination is not the same as working insane hours and sometimes people need to remember that.

I was also going to put in something about leadership. This is a hugely important skill but you can be a very good developer without it so I felt I could leave it out without it being to big an issue.

Anyway, that’s my list. What do you think?

Writing a Technical Test..with a little help from the LJC

As someone who interviews developers, I had been looking at ways to improve our current interviewing process. I’m not a fan of written tests or of coding on white boards since they don’t accurately represent the day to day requirements of a developer and I don’t even think they are good surrogate markers.

Knowing Barry Cranford through the London Java Community, I thought I would ask him. Given that he probably sees more interview processes than anyone else I know it seemed a fair idea. After a quick chat over ice-creams (it was a hot day!) I suggested to Barry that I thought we should get potential candidates to do a small technical task before they came in so that we could go through it. That way I could get to see exactly how they coded and how they thought. Barry suggested we could improve it by building on it in a paired-programming exercise during the interview. That way we would be able to see how they worked in a team and in a pressurised environment.

I thought this was great and spend some time coming up with a task that could be completed within 1.5 hours but had some natural extension points for the paired programming exercise. The trouble was, I had no one to test it on other than myself and guys in my team. Again, the guys at the LJC came to rescue by volunteering to take it. I was pretty proud of the test and thought it was quite good as it allowed candidates to showcase their skills without being too hard but it was completely shredded by the reviewers! As one of the guys had pointed out, the task made too many assumptions about the domain knowledge of the candidate and the requirements were too vague for someone outside of the industry.

So I went back to work and rewrote it. The acceptance criteria became much tighter, I removed some of the ‘help’ than was actually misleading and reworded it so that the target goal was as clear as possible. The result is a solid task that is now being used for teams other than my own. So extra kudos for me and better candidates for the company.

Without the community input there is no chance that it would have been half as good. Worse still I would have been stuck with a bad test that I thought was good. I am very grateful for the various guys at the LJC for the time and effort they put in to help a fellow LJC member, so special thanks to Mustapha Hanafi, Martijn Verburg and most especially to Ged Byrne for all the help. Thanks guys.