Craft your next design role by designing your recruitment
Forget the incredible machines, the workplace design and the storied history. The greatest asset we have at IBM is our people, and that makes it important for us to be able to hire the best talent around. But what are we looking for when we hire designers? And how can aspiring IBM designers best showcase their abilities to us?
As a UX designer, I’ve been directly involved in recruiting many designers to IBM. Here are a few hints and tips that can help any designer show us their best side.
Design your recruitment
We’re looking for candidates who can take a situation or problem area, deeply understand it, and put that knowledge into practice to create valuable new experiences.
In this case, the situation is your own recruitment. Treat it as a design exercise. This is exactly what you have trained for and in each design exercise there are a few basic things you need to know and do: know your user, know your domain, then plan, create, test, and iterate.
Know your user
Who are you designing this experience for?
Think about the recruiters who will be dealing with your application among many others. Make sure your CV/resume and portfolio are targeted to the job description you’re applying for. Put the relevant information front and center.
Beyond that, think about the assessors. They will be highly trained in design and experienced in working in enterprise-scale teams. But they must be missing something — otherwise why are they looking to hire you? Scour the job description to understand the unique skill that they need you to provide, or the piece of the puzzle they want you to complete.
Your assessors will be highly motivated to find the right person for their team, but they will also be taking time out of their day job to read your application or interview you. How will you best use that time? Cut the waffle and focus on strong words. Ask the assessor for clarification or to understand what they’re looking for from your portfolio. Focus on the outcomes they want.
Know the domain
Design is embedded into the heart of what we do across our products and services. Tacking design on at the end of a project (‘putting lipstick on a pig’) is ineffective or even harmful. But in order to make meaningful change, a designer must have a strong understanding of the environment for which they design. They must grasp its complexities, and from them forge a better future.
In this design exercise, how will you understand the domain of your recruitment experience? Rely on your secondary research skills. The job description will contain information about the products, or teams you will be working on. Explore these in a bit of detail, to understand what problems the area aims to solve. This will help you understand the perspective your assessors are asking questions from.
Be sure to spot the limitations of the available knowledge. Your assessors are highly likely to check whether you have questions about the job, the team, or life at IBM. By asking questions about the role, you will show that you have innate curiosity — a quality to be prized.
Plan, create, test, iterate
Now you get down to the business of putting together your application material. Often this comes in the form of a CV and a portfolio. Draw on your knowledge of the user and the domain to formulate this material.
Think about how it will perform standalone, as your application gets reviewed. But then further think about how it will complement your interview. How might you change your portfolio to present it, compared to when someone is reading it themselves? Which project or projects would you choose to best showcase your skills?
Be sure to test the experience so far. Practice showcasing your portfolio. How long does it take? Can you communicate the same qualities but more concisely? Show it to someone else, and get them to fire some questions at you.
Now use all your findings to create your next iteration, remembering that everything is a prototype.
Show us what YOU did
Designers almost always work as part of a team. When being assessed, it’s important to consider two aspects:
- Your assessors will want to see how you work with others. Talk about the team members involved in design, development, product management and other roles. How did you interact with them? What did they provide you, and vice versa? How did you exploit all the skills they offered to create the best outcome?
- Your assessors will want to see what your contribution is. What was your unique value-add? Where does the line between you and the next designer lie? What did you take ownership of? Show how you are part of a team, but don’t fade into the background.
Tell us a story
Some portfolio projects are highly technical. They are in areas in which I’ve never worked, and have little understanding. Nevertheless, they have drawn me in and left me with an immense appreciation of the candidate.
On the other hand, I have seen portfolio projects in areas I am highly familiar with and interested in, but they have left me cold.
How can this be? What’s the difference between the two? It’s storytelling. The way in which you tell the tale of your project has the potential to keep the audience gripped, to have them empathise with the characters, to have them engrossed through the ups and downs, and finally to be awed by the outcome.
We’re all familiar with the simple storytelling lessons from school. They’re full of all the ingredients you need.
Think about the protagonist of your story. It’s probably you, right? How did you end up in this situation? What are your values and strengths that make you the hero?
Think about the challenge you overcame. Maybe it’s another character, but more likely it’s some limitation or problem of the system you’re designing for, or some adverse feedback you receive. This is vitally important. Your assessors will want to know how you deal with issues that come your way. A perfect project is unrealistic.
Now, write the story. A common way this is taught is to consider the five fingers of a ‘story hand’:
- Opening. Set the scene. What’s the background? What’s your role here? Who were you working with?
- Build-up. The project starts to get under way. Perhaps it’s business as usual. Be sure to show how you work, not just the outcomes! The assessors will be looking at your train of thought and understanding how you work with others.
- Dilemma. Oh no! Something occurs and it’s now no longer business as usual. Explain the potential impact of this discovery.
- Resolution. Don’t worry, you’ve got this! Show how you overcame the issue, and how the result was even better because of what you learned along the way.
- Closing. Time to finish up your story concisely, focusing on the key outcomes. How did you measure success? Show the final result. But don’t make this the biggest part of the story! Your assessors will be more interested in the journey than the destination.
I really enjoy the opportunity to discover new designers, to see them at work, and to learn about what makes them tick. If you’re looking for a design role at IBM or anywhere else, I hope this article has helped you to shape the way you think about applying. Just remember:
- Design your recruitment.
- Show us what you did.
- Tell us a story.
We look forward to hearing from you!
Ben Cox is a Senior Software Designer at IBM based in Hursley, UK. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
