So, You Want to Hire a UX Engineer?

Picture this- you've got the best product ever. Life changing! Truly, yours is the company that will shift the very foundation of software engineering itself. Your backend is impeccable, and your branding is gorgeous and catchy. So… why do people visit your site, then leave after a few minutes without signing up? No matter how good your underlying service is, user experience can make or break your company. If the flow on your website is broken or just confusing, most users aren't going to stick around to figure it out. A task as vital as this really deserves proper attention and expertise- and this is where hiring a UX Engineer comes in.

We've recently built out a team of accomplished UX engineers at Render. As this is a specialized role, we needed to create a new interview process in order to find people truly suited to the job. This post outlines what we learned in the process, so you can build a great UX engineering team yourself!

UX Engineers: What Do they Do?

Before you start crafting an interview process, it's important to know exactly what you're looking for. The title of "UX Engineer" can imply different skillsets depending on the company, so it's important to assess what you actually need from the position and make your job posting clear about what the job will entail. The heart of this role is in creating a polished frontend experience for users, but there are many skills that need to come together to accomplish this goal. To start, let's consider some tasks that different UX Engineers may be responsible for. A UX Engineer may be expected to:

• Write HTML, CSS, and JavaScript
• Use JavaScript frameworks such as React, Angular, or Vue
• Use web frameworks such as Rails, Django, or Laravel
• Create prototypes to showcase user interactions
• Develop design systems
• Conduct user research
• Ensure product accessibility
• There are a lot of skills that go into all of these, so most UX Engineer roles will only focus on a subset of these. This role's duties can range from user interaction designers to frontend engineers, and often something in-between. Consider what your company needs most when writing job descriptions, in order to find the best people for the position and to put them in roles they're actively excited for.

For Render's UX Engineers, we wanted them to be able to work closely with both designers and full stack engineers, in order to really focus on the user experience while implementing user interfaces. Since our stack uses React, proficiency with JavaScript frameworks was a must for us. Design systems, prototyping, and user research are all also things we expect our UX Engineers to work on. We used this as guidance for what we asked for in terms of candidate experience, and in how we shaped our interview process.

Tailoring the Test to the Task

There are three main things you should always have in mind when developing an interview:

• What tasks should this person be able to perform in this role?
• How can we gain confidence that they'll be able to perform those tasks?
• Am I respecting the candidate's time?

That's all that really matters. Throughout this blog post, I'll describe our specific interview process for UX Engineers. However, it's more important to answer these questions than it is to follow anybody else's preexisting interview process. Because of these goals, we don't think that whiteboard style coding questions work well for interviewing UX Engineers. You know the type- reversing a linked list or balancing binary trees come to mind. One could argue against these for many engineering job positions, but especially so for UX Engineers. These questions test algorithmic skills, and although designing algorithms is sometimes part of the job, it doesn't match well with what their daily tasks will be.

Screening Question: A Quick First Pass

Because UX engineering is a bit of a hybrid role, it can be beneficial to interview people with all kinds of career backgrounds. A screening question ensures that they'll stand a fighting chance at the rest of your interview process, and therefore won't waste their time with a longer project. So, if you do opt for a screening question, what should it focus on? In our case, since we do expect framework knowledge, we ask the candidate to write a small component in a frontend framework of their choice. The frontend ecosystem is large and in constant flux, so we don't require a specific framework. Candidates are also free to use any online resources they like. The goal here isn't for the challenge to be too challenging, but just to check that the candidate is comfortable using a framework to solve a problem using code. It's important to limit the scope of this question- we aim to keep screening questions under an hour, with some time left over for the candidate to ask questions.

Team Fit

While many engineering roles are collaborative, UX Engineering is even more so, because it needs to serve as a bridge between design and engineering. You should talk to people in these respective teams to ask what's most important to them when working with a UX Engineer. Prepare questions you can ask the candidate about how they have worked with different groups of people in the past. We also include a portfolio review section in our interviewing process, which can be useful for asking about prior team experiences. What was it like working with design teams for a specific part of a past project? Did they work on any projects with complicated interactions between frontend and backend? Having concrete past work to point to can be helpful in these conversations.

Put it into Practice: The Main Project

One of the best ways to learn how someone will perform on the job is just to see what they do when actually working on a project. To best measure how suited a candidate is for the role, the project should be similar to the kind of work they would actually perform in this position. It can be helpful to think of some user flows that your product already supports, and come up with scaled down and modified versions of these flows to see how your candidate would implement them. You want them to show that they can create something nontrivial, and give them a space to show how they think about user experience in a real world scenario. The key to getting good results out of a project is to give enough guidance that candidates can showcase their skills, but leave enough unspecified that candidates will be able to discuss with you the pros and cons of different solutions. For example, in our UX Engineering project, we provide some starter code to help candidates get started, but end solutions can (and should) vary depending on how the candidate decides to approach the problem. Since this project should resemble real life, make sure someone is available to answer questions if the candidate gets stuck. You shouldn't have to hold their hand through every step of the process, but it's also not helpful to let them be stuck on one detail for too long. For our project, we also provide candidates with a GraphQL API to work with. This helps to imitate the kinds of endpoints they'd be working with in real life, and it gives us a lot of control over the kind of issues that candidates will have to face during development. For example, in our interview API, we intentionally throw in some error states and require candidates to work around that. This shows more realistically how candidates deal with things not following the ideal flow, while still showing a respect to a user's experience of these errors.

While developing the criteria for an interview project, try to still remain respectful of your candidate's time. Although it's true that asking your candidate to create their own version of Twitter would give you a lot of good data, your candidates are people with lives and other responsibilities. Don't give them a project that will demand more than a day of their time.

Back to the Drawing Board

By this point in the process, you should have all the tools you need to interview your prospective UX Engineers. However, you still aren't done. Interview processes should be continuously improved upon, and each interview should be looked upon as a learning experience. Before you run your interview process on any actual candidates, you should test things out by interviewing people who are already at your company. It's alright if they don't have the right skillset for the role- if they did, you'd already have filled the position! Instead, use this to see if there are any questions that are confusing or poorly defined. You can also make sure that your time estimates for how long it would take someone to answer your questions aren't too far from reality. This phase of the process can also be a good time to start developing a rubric, and you can use this to help determine whether your test interview would have passed or failed. Interviewing actual candidates will also reveal shortcomings in your process. Offer candidates the ability to share feedback after their interview, and actually take their critiques into account to try to improve future interviews. If parts of the interview were unclear or confusing, maybe you need to rephrase parts of the prompt or give more resources for the candidate to work with from the start. A large change that came about from our actual experience with interviewing UX Engineering candidates was in switching from a full day project to an optional take home project, depending on the candidate's preference. We originally started with an interview where the interviewers and candidate would stay in the same Zoom call for four hours, with the intention that the interviewer would always be available for questions and to help out the candidate. However, we received feedback that our interview process was too long, and candidates didn't end up having as many questions as we expected once they got to work. Because of this, we switched to having an intro session where the candidate would instance type out their project collaboratively, then allowed them four hours on their own time over the next couple days to complete the project. They would then meet with their interviewers again to showcase the work they accomplished. This seemed to work better for candidates, as they had the opportunity to make their own schedule and take larger breaks, or even interview over the weekend if they wanted.

Hired!

It will likely take some time to perfect this process and to flesh out your UX Engineering team, but with persistence you can create an interview that is both bearable for candidates and helps your team fill these crucial positions. Interviews can be a stressful experience on both sides of the table, but we've even had some candidates describe our UX Engineering interview as "fun", and we've received gratitude for how our interviewers are genuinely supportive throughout the process. The interview process isn't just for evaluating candidates - the entire experience gives candidates the opportunity to evaluate your company as well, and judge what it would be like to work there. Keep this in mind as you perfect and improve your interview process- the results will all be worth it when you're able to hire your own UX Engineers as teammates.