Hacking ThoughtWorks recruitment revisited (Graduate Code Reviews)

For various reasons, I’ve been doing more than my usual number of code reviews recently, including three graduate code reviews on the same problem in Java over the weekend.  One of the reviews I thought was relatively poor, one was average and one was quite good.

And it occurred to me that it wouldn’t have taken much for each of the lower submissions to be much, much closer to each other.  Many of the ways in which their code fell down are quite simple to address, hence this blog post.

Note: As with the other times I’ve written on our recruitment process, I don’t think I’m giving the game away with anything I write.  In fact, the people who read this post are probably already self-selecting to proceed through our recruitment process quite well 😦

Anyway, here are the quick ways for giving your graduate code review solution the best chance to shine.

1. Made your README worthy of reading

From the perspective of a reviewer, I want to minimise the amount of time between when I first get my hands on your submission and when I can run your code.  This means the following tasks need to be as frictionless as possible:

  • Installation
  • Build/package
  • Run

The things likely to become roadblocks in these activities are:

Not having an easy way to build your application: although I’ve long moaned about Maven’s way of working, I’ve come to really appreciate its ability to let me build/package code solutions in Java without really needing to think about it.  Likewise for those projects that use Ant, Gradle, make or any one of a number of other language specific or agnostic build management tools.

Not knowing which version of the language to use: Java 7?  Java 8?  Ruby 1.9.x?  Ruby 2.x?  I can find the right version by trial-and-error compile/run cycles until I have no errors… or you can put the versions into your README and put me out of my misery.

Looking for good examples of README files?  Try any one of a number of the most popular libraries in Github to see what their authors have chosen to include.

2. Do out-of-the-box testing

There are sets of test data supplied with each of our coding problems.  By all means, make sure your solution works according to this data, but don’t consider this data to be exhaustive!  Try another couple of variants of the test data to see how your application behaves in these cases.  This sort of testing might well expose limitations in your assumptions that result in unexpected behaviour in your code.  Whether you choose to address these limitations in the code, or simply state them in your README is then your choice.

3. If using an IDE, listen to the IDE

If you’re writing in a compiled language like C# or Java and using an IDE (something like IntelliJ, Eclipse, Visual Studio instead of Text Mate, Sublime Text, Vim or Emacs), you can make a vast improvement on the first impression people have of your code just by turning on the IDE warnings around code quality and addressing them where needed:

  • If your IDE highlights an unused variable or method, delete it.
  • If your IDE highlights a statement that can be simplified, simplify it.
  • If your IDE highlights an unnecessary initialisation, remove it.
  • You get the idea!

None of these warnings are critical, but all help remove code that will just become a distraction to people reviewing your code.

Good luck with your submissions!


Why Enterprise IT is failing our universities


, , , ,

I spent quite a lot of time with people responsible for tertiary IT education in 2014 and I feel for them in terms of the pressure they are under from the IT industry, the primary consumer of the principal “product” of universities – graduate students.

Be Prepared!

It’s become part of the collective consciousness that the role of tertiary institutions is to “prepare students for their careers”.  But the definition of “prepared” in this context is driving misguided behaviour from universities in an effort to reach a goal which is frankly unachievable given the constraints under which they operate.

The working definition of “prepared” for graduates leaving university and entering the IT industry seems to be:

Prepared: Capable of contributing to their employers’ business from Day 1.  Requiring little/no ongoing training or mentorship.  Knowledgeable in all current technologies and techniques used by the employer.

In pursuit of this goal, universities build degrees and populate them with a vast range of subjects across the fundamental principles of development, operating systems, networking, databases and softer skills around communication.  But very little of this knowledge will “prepare” graduates as defined above.  So what do universities do?  Into the precious little free space left in most degrees, they add subjects around “modern” computing topics like web development, cloud computing, big data, mobile applications and the like.

While presumably appealing to uninformed students and university marketing teams alike, none of these subjects will cover their respective topics in sufficient depth to appease employers when these graduates arrive in the workforce.  And while these topics are currently trending within the IT industry in general, not every employer has a need for mobile development or big data, for example.


So I propose a new working definition for “prepared”, one which could change the expectations industry have on IT graduates and allow universities to spend more time on what I see to be the really core skills a graduate needs to have.

Prepared: Enters industry with a passion for application of technology.  Accepts and embraces the lifetime of learning ahead.  Understands the benefit of strong mentors and is capable of growing these relationships.  Accepting that there is no “one right way” in most cases.

Under this definition, universities can focus their efforts on sparking and nurturing that passion.  From there, impress on students how dynamic this field is and how much it is likely to change by the time they graduate.  And from there, place emphasis on how many solutions there are to so many problems, some of which may be completely non-technical.

Preparation: Redux

So how would this approach be reflected in a typical IT degree?

There a variety of ways you could skin this cat, but some of the ways I would consider are:

  • Make attendance at local community groups in relevant areas compulsory for several subjects.  Arrange with the community organisers to put aside one community event for student presentations.
  • Wherever there are leading technical candidates with different emphasis (e.g., OO versus functional approaches to development, RDMBS versus NoSQL databases, teach both simultaneously to help students appreciate the similarities and differences
  • Continue the good work many universities currently do regarding industry based learning, internships, students projects, guest lecturers, etc, etc.
  • Stop trying to build subjects around trending topics because (a) they’ll age quicker than soft cheese on a summer’s day and (b) they’ll inevitably leave students with a poor idea of how that topic is used in industry.
  • And finally, resist further attempts by industry to neglect their duty in continuing the education of their graduates and other employees.

DevOps Melbourne 2014: A Year in Review


, , ,

At the end of 2014, I’ve stepped down from organising and hosting DevOps Melbourne.  I had the honour of holding this role for 18 months after it was gifted to me by the previous host, Evan Bottcher, and I look forward to seeing the community continue to thrive under the stewardship of the new host, Andrew Jones.

So how was 2014 for DevOps Melbourne?


As is our relaxed tradition, we continued with bi-monthly meetups in 2014.  As an organiser, this frequency mitigates the major stress of having to run around chasing down presenters and topics.  Having two months between meetups makes this a far more relaxing activity.  Furthermore, I’ve never had the community ask for increased frequency, so I happy I’m not being completely selfish on this front.

We have also settled on a “last Tuesday of every 2nd month” schedule, which seemed to fit nicely with our community and also had the minimum of clashes with other meetups that might share our members.  Finding a good quiet spot in a meetup calendar is key to getting a regular and healthy number of people along to these events.

Within each meetup, I try to arrange for a single “headline” session (30-40 minutes plus Q&A) to finish the night, with one or two “support” acts (lightning talks or 10-15 minute talks).  Given people are generally attending after a full day’s work and are probably already getting tired, erring on shorter rather than longer presentations is a good idea.

Ideally, we ran from 6:30pm to around 8:30pm with a break in the middle for food/drinks/chatting.


Here are the titles from all the sessions in 2014:

  • “Server provisioning with Ansible”
  • “Microservice architecture and DevOps – does one imply the other?”
  • “Tomorrrow’s legacy, today.”
  • “Case study: Application of Digital Signal Processing techniques to simplify system data.”
  • “Which conferences should I go to this year?”
  • Datensparsamkeit”
  • “Experimentation at RedBubble”
  • “Navigating the minefield.  Implementing DevOps in a large organisation”
  • Docker + Microservices
  • “Commercialising Free & Open Source Software”
  • DevOpsDays Brisbane: Review
  • “The Ops Dojo
  • “24 Months (at Infoxchange)
  • “Getting Devs to own their Ops at IOOF”
  • “Docker – Containerize all the things!”

Given the People/Process/Tools holy trinity of successful DevOps, I think we struck a good balance between each of these foci.  We are helped tremendously by the presence of the local Infracoders Meetup, which not only gives a specific outlet for those who cannot get enough of Docker the tooling, but also runs each month with good attendance and many presenters.  I dip my hat to Matt Jones and David Lutz, tireless organisers of Infracoders and regular DevOps Melbourne attendees as well.

But organising is not without the occasional conundrum: an issue which crops up regularly is how to handle request for outside commercial involvement.  This involvement normally consists of either:

  1. Offers from companies presenting on their own products/services
  2. Offers to host the meetups at company offices and/or sponsor food or drinks

This first of these issues is sometimes tricky to deal with.  Regular community surveys show that vendor product presentation are not received well, so I feel a responsibility to keep these types of presentations to a minimum.  I try to express on these presenters the need to focus on the tools at a level that will interest the audience and stay away from blatant self promotion.  I also try and limit these types of sessions to shorter durations, especially if I don’t personally know the presenter.

Requests to host DevOps Melbourne at different venues are met with a gentle but firm “thanks, but no thanks”.  We have no good reason to move from our current location, and the extra organisational overhead of doing so is not worth the benefit.

The one time we had another group sponsor drinks this year was a last minute offer by the good folk at Chef, who were in Australia for DevOps Days in Brisbane.

(Full Disclosure: My employer, ThoughtWorks, covers the costs of food at DevOps Melbourne meetups and provides products and consulting services in the DevOps space, so I’m always aware of the potential conflict of interest this puts me at as both a ThoughtWorker and a community leader.)


Since inception, DevOps Melbourne has been completely monogamous in its choice of venue.  The Apartment has been our home for over three years now and provides a good-sized space, fabulous decor and comfortable seating and a large projector screen for our presentations.

Hosting these types of events at a corporate offices (the choice for many community groups) usually results in free drinks and food for the attendees, but I’ve yet to see an office with the ambiance to equal a lounge bar like the Apartment.  As an extra bonus, there’s no need to worry about security for people entering the venue (a non-trivial problem with accessing some offices after hours), or cleaning up 🙂

So thank you Sunny, Danielle and the other good folk at the Apartment who keep our community ticking along!


Firstly, the size of your community on meetup.com doesn’t mean squat.  I got a bit of a cheap thrill when our official membership ticked over 1000 people late in 2014, but typical physical presence at meetups hovered around 30-50 throughout the year.  This is a good number given the size of The Apartment and my desire (on behalf of my employer) to sponsor nibbles during the night.

I usually start each meetup with a straw poll of where the current audience sits on the DevOps spectrum.  Normally there would be roughly equal number of people who primarily identify themselves as “dev” or “ops”, with a handful of “other” for good measure.  This is a good thing; an audience dramatically skewed in either direction means the content is not being curated correctly.

Interestingly, there would also be a large percentage of people who were attending the meetup for the first time.  This suggests to me we have a highly dynamic audience, many of whom might come along to kick the tyres, or are perhaps motivated by a single topic that is being discussed on that evening.  Given the diversity of the topics presented this year, this is perhaps not surprising.

Sadly, no women presented at DevOps Melbourne in 2014.  Not surprisingly (but equally sadly), the number of women in the audience were low: perhaps only a couple each meetup.  For all the talk about the lack of women working in software development roles, this imbalance is far more harshly evident in the operations/DevOps spaces.  I have some thoughts on how to help address this issue in the DevOps world, but these plans lay elsewhere and not in the meetup community, at least not initially.

Looking forward

With the DevOps Days conference coming to Melbourne in 2015, I look forward to seeing how DevOps Melbourne can get involved and what impact the conference will have on the community.

I suspect the 2014 trending themes of containers (hopefully, more than just the D word) and microservices will continue to be strongly represented within the community.

I hope we get a chance to talk security in 2015.  It’s a topic that seems more and more pressing to have a broad understanding of with each passing high profile breach and I would like to see more representation from the security community within the DevOps world.

I’ll be attending DevOps Melbourne regularly during 2015, and am looking forward to being able to focus on the presentations rather than the organisation.  Perhaps i’ll even try and put the presenter hat on at some point during the year.



Public Speaking in 2014


, ,

I enjoy public speaking.  Not so much the extemporaneous, seat-of-your-pants stuff  but more the organised, formal activity where I have time to prepare and rehearse.  This passion took root in my previous life as a teacher at university before I took my professional vows as a developer.  It’s also something that I don’t do anywhere near as often as I would like to, so I made an extra effort this year after a quiet 2013.

As I’ve completed all my speaking events this year, it seems like a good time to reflect.  Firstly, the roll call:

  • January: Microservices & DevOps  (DevOps Meetup, Melbourne)
  • March: Functional Programming (Functional Programming Meetup, Melbourne)
  • April: Functional Programming (ASWEC Conference, Sydney)
  • April: Microservices Architectures (ThoughtWorks Live,  Melbourne)
  • April: Microservices Architectures (ThoughtWorks Live,  Sydney)
  • May: Functional Programming (YOW West Conference, Perth)
  • August: DevOps workshops (ThoughtWorks Internal Conference, Sydney)
  • September: Agile Fundamentals (LaTrobe University Guest Lecture, Melbourne)
  • October: Riemann (Clojure Meetup, Melbourne)
  • November: Riemann (Client brownbag, Melbourne)
  • November: Riemann (Infrastructure Coders Meetup, Melbourne)

What went well


I’ve long maintained that the key to doing a large number of events in a sustainable fashion is to increase the return on your investment (i.e., preparation time) by repeating the same talks on multiple occasions, either the exact content or variations thereof.   Not only does this approach lessen the cost-per-talk, but it gives you more attempts to deliver the material, which generally improves the result.

To that end, I’m glad I managed to deliver my Riemann content three times (slight variations on each), my Functional Programming content three times (variations on each) and my Microservices Architectures content twice (more or less identical).


Four conferences (three public, one internal), four meetups, one client brownbag and one university lecture provided a lot of variety; some required/demanded lots of preparation and rehearsal, some were more casual and needed less upfront preparation.

All talks were solo affairs, apart from the Microservices Architecture one, which I paired on with my colleague Zhamak Dheghani.

Session length varied also from 10 minutes (ASWEC conference) through to 45 minutes (ThoughtWorks Live conference), with an average length of 30-40 minutes.


As ex-organiser of the DevOps Melbourne meetup, I’ve become reasonably adept at nudging people into doing presentations.  Sometimes the people just need a little encouragement, sometimes the ancient black magic of “voluntelling” comes into play.  Most happily, I’m excited to give colleagues at ThoughtWorks a chance to step onto the stage and present.  in one such case, a DevOps Melbourne session was also chosen to for the DevOps Days conference in Brisbane.

What didn’t go so well

The ones that got away

I had three conference submissions rejected over the course of the year (the DDD Conference in Melbourne, DevOps Days in Brisbane and Functional Programming India) which was disappointing.  I bear no ill will towards the programming committees of these conferences who need to balance a variety of needs to build a compelling event, but like most people, it’s hard not to feel down when the rejection email arrives.


When it comes to submitting ideas for conferences and larger scale events, it helps to know as far in advance when the relevant dates are for submission.  Sometimes this things crept up on me and it was only a stray email from a colleague or a tweet that alerted me to the impending deadline for submissions.

What to do differently next time


I have the beginnings of a plan that should give me lots more opportunity to present during 2015.  It’s not yet finalised (in my own mind, let alone that of my employer), but if successful will allow me to get even more mileage out of fewer topics than this year.

Multi-channel distribution 🙂

I’m also looking for other mediums through which I can deliver this content.  Blogging and podcasts/videocasts come to mind, but I don’t get the same adrenalin rush from the “performance” as I do when speaking live.


ThoughtWorks is very encouraging of people wanting to present publicly and I appreciate this support in the various forms it manifests (e.g., a receptive audience for rehearsal, time off client work for high-profile presentations, financial support where conferences are in other states).  For all these reasons, I am grateful.

Should GitHub be part of a developer’s resume?


, , ,

Like many, I’ve counseled developers that their public code repositories like GitHub/BitBucket are most certainly ripe for examination by potential employers.  Yesterday, I had an interesting conversation between a recruiter and a colleague about the potential dangers behind this, both from the perspective of the employer and developer.

Continue reading

Coding for Kids: Workshops and programs in Australia

Similar to a previous post around free online tools to encourage more kids to learn how to code, this is the results of some research I did last week into what “bricks-and-mortar” avenues exist for kids with a programming bent around Australia.  I’m sure I’ve missed lots of these, so please comment and help me fill in the gaps.  I’ve also included prices where available, but made no attempt to determine availability where places are limited.

Continue reading

Coding for Kids: Free platforms, tools, videos and games


, , , ,

Yesterday, I spent a couple of hours looking into what freebies the internets have for kids wanting to learn how to program.  Thankfully, there are options a-plenty for this sort of stuff, but it does take a little Googling to undercover them all, so let me save you the trouble.

There are quite a few broad categories of these tools: lets look at each in turn, roughly in order of age/experience appropriateness.  I’ll start with the tools best suited for the younger developers with little experience with coding and move up to the platforms that really require a solid programming background to appreciate.  The level of software-based hand holding will decrease through each of categories, as will the reliance on primary colour palettes and kid-friendly animal avatars.

Continue reading

Agile versus Security


, , , ,

Ah, there’s nothing like using a false dichotomy to build a blog premise around, is there?

This post is to share some of my thoughts and findings from the research I’ve done into Agile security of late.

Agile and Security are not an either/or choice, but some aspects of typical Agile implementations can lead to insufficient attention being paid to security requirements:

Continue reading

How technical community groups fail the technical community

Like many software developers, I could easily spend every single night of the week at different user groups dedicated to areas of my profession I’m interested in.  Meetup.com has made organising and publicising these groups a far simpler task so there are usually a couple of new group announcements floating past my inbox each week.

However there is a common problem I see with so many groups that I wanted to call out:

Continue reading