How to Become an IBM Garage Developer

The IBM Garage is a highly dynamic, multi-disciplinary consulting practice working with clients and partners of any size across all industries. We combine design thinking, lean startup, devops, extreme programming, and cloud native development into an awesome package of client success and staff satisfaction. Our clients include both startups and household names, and help them innovate, modernise, and find a new way of working. Not surprisingly, the people in our team who do this are pretty special.

What we look for in a Garage developer

Our developers are customer focused, highly communicative, flexible, adaptable and know how to empathize and effectively work with in teams. Because our technology landscape is so dynamic, we focus more on attitude and aptitude than specific skills or certifications. Having said that, experience of agile variants, lean, pair-programming, or TDD is helpful.

Cloud native development is full-stack, so experience with front-end development, back-end development, devops, testing, and working with others is also helpful. Experience with the cloud platforms and the preferred languages is a bonus, but not essential as long as there’s evidence that the candidate can pick up new skills effectively.

Our developers are always looking to improve their skills. Many of us do activities such as attending meetups, presenting at conferences, taking part in hackathons and contributing to open source. (Is going to meetups essential or contributing to open source essential to getting hired or succeeding in the Garage? Absolutely not — we all have different circumstances, and the agile principle of sustainable pace is one of our core values).

More generally, we value diversity. This includes gender, ethnicity, age, disability, culture, sexual orientation, gender identity, gender expression, and background. Equal opportunity is important (and has proven business benefits).

The most important thing we look for, though, is someone who is curious, a lifelong learner, and loves co-creation.

The hiring process

The goal of our interview process is to try and accurately predict who will do well as a Garage developer, so that we can bring them into our team. Predicting has two parts; identifying the characteristics of a great developer, and then measuring them in an interview. We want to try and measure things that matter, while not being influenced by things that aren’t predictive of job performance — we want to do our best to avoid both false positives and false negatives. We constantly re-evaluate our interview process and criteria to make sure we’re evaluating the right things and maximising accuracy.

We want to be respectful of your time, while making sure we both get enough information to make a sensible decision about whether you and the Garage are a good fit. An interview is a two-way thing; you should be evaluating us, figuring out if you’d enjoy working with us, and deciding if the Garage will be a good environment for you.

The process will vary by exact role and level, but in general the developer interview process has four steps:

• CV screening
• Discussion with Garage developer(s)
• Pair-programming interview with Garage developer(s)
• Discussion with the Garage hiring manager

Interviews can be stressful, because there’s a lot at stake for both parties, but we work hard to keep the interviews as collaborative and enjoyable as possible. I love it when a candidate leaves an interview saying “hey, I enjoyed that and learned something today,” and it’s even better when the interviewer also says “I learned something I didn’t know, thank you!”

The pairing interview

In our pairing interviews, we assess the things Garage developers do every day — coding, solving problems, debugging, communicating, and learning. We do a lot of pair-programming in the Garage, so we want to see how you work in a pair. We want to see you at your best, so we’ll work in a language of your choice. It’s ok if you haven’t done pair-programming or test-driven-development before — not everyone who joins the Garage has had an opportunity to work in an environment which follows those practices.

We assess all candidates in 5 areas:

• Communication: Are you able to tell your pair what you’re thinking & why you’re choosing a particular approach? Do you listen to your pair?
• Simplicity: Are you able to break down the problem into simple tests? Can you write just enough code to get the tests passing?
• Feedback: Are you able to create and make use of quick feedback loops that support your assumptions?
• Courage: Are you able to tackle a problem head-on, even when you’re well outside your comfort zone? Are you able to see when your approach is wrong and correct course?
• Learning: Do you have the curiosity and ability to acquire new skills? Are you able to transfer the knowledge they have to different domains? An ability and a desire to learn is the most important characteristic of a Garage developer.

Writing code correctly the first time — or the second time — is not part of our assessment. Finishing the exercises or having an encyclopaedic knowledge of programming languages are also not part of our assessment. You are encouraged to use any documentation that you are comfortable with during the interview. Knowing how to find answers to questions is more valuable than knowing it all.

If you like, you can use your own laptop, so that you know all the keyboard shortcuts. We definitely don’t want to see good candidates tripped up by unfamiliar keyboards or development environments. We want to see you work, but we’re not trying to test whether you can find the ⌘-key on a mac. Since we’ll be doing coding, you’ll need have a development environment set up for your language of choice (e.g. Eclipse or Visual Studio Code). We’ll also be exploring Test Driven Development, so you should have a unit testing framework available (such as JUnit or Jest or whatever you prefer). If it’s easier for you, you can also use a Garage pairing machine. We’ve had candidates turn up with borrowed laptops, which wasn’t the intention of inviting them to bring their own machine!

Whether the interview results in a job offer or not, we hope that it’s an enjoyable experience and an opportunity to explore new ideas for everybody involved.

Related reading:

• How to run Garage-style interviews
• You Suck at Technical Interviews by Seldo (some strong language)
• Engineering a better interview by Heather Whyte
• How to interview job applicants fairly by Anna Shipman