There are plenty of books and articles out there that talk about finding and maintaining technical talent in a generalized way, but very little information exists in the published word or on the internet regarding finding, hiring, and keeping great UI Engineering talent. Hiring managers across many industries have been stymied time and again in bringing in great UI Engineering talent and as this article by Patrick Neeman at JobVite indicates, it’s only going to get worse. I agree with most of the points Mr. Neeman makes, but his first bullet point, “Attention paid to the user experience,” in my mind, could be the crux of the whole problem. You see, to me, it all boils down to having the proper perspective, and the first point raises serious issues about companies’ perspectives on UI Engineering.

Not the perspective of the candidate, mind you; but companies’ perspectives on what makes a great UI Engineer. I’ll just say it plainly: Most companies’ expectations and perspectives on evaluating UI Engineering candidates is flawed. To understand this, we have to look at some key traits that make up a great UI Engineer.

• Most UI Engineers did not start out in UI or UX. They come from varied backgrounds; but especially from non-technical, non-engineering backgrounds. The engineering they’ve gleaned over the years has been much more of an organic process.
• Adding to the point above, these individuals are highly self-motivated. They may not have knowledge of a particular subject, but once they realize that, they have the drive to educate themselves AND apply the ability to add the techniques to their arsenal of tools.
• Building on the two previous points, the best UI Engineers don’t have a CS background, though they practice the critical, high-level engineering such as creating class and sequence diagrams, or some other formalized method of technical design.
• Most UI Engineers are pretty chill folks and I mean super-mellow. It’s a trait that I have observed in the best UI Engineers I have both hired and worked with over the years. They quietly go about their business and continually ROCK THE HOUSE with the things they create. Unfortunately, this chill demeanor often gets mistaken for a lack of motivation. Couldn’t be further from the truth. To a person, I’ve observed laser-like focus in the best with whom I’ve had the privilege to work.
• The best UI Engineers have the uncanny ability to take designs and wireframes and express them in code; but more importantly, code that is backed with a solid technical design.
• UI Engineers hold a special place in the development process because not only do they have to have great technical acuity, they have to understand the user experience, the product, and the marketing behind the product. I think adding to the chill factor, many are chill because their minds are constantly working in parallel processes to evaluate the appropriate way to express a visual design.
• Great UI Engineers also have a certain underlying ferocity about ownership of the UI – believe me, it’s a good thing. They are acutely aware that what they build is how the customer will view not only the application, but the company as well. They know they have a huge responsibility, and they take it absolutely seriously.
• The best UI Engineers I’ve worked with or have worked for me aren’t motivated by UI frameworks. They use the tools at hand first, and if a particular framework makes their job easier, but without affecting the user experience, they will learn the framework as necessary. The point here is that they are extremely quick studies.

The list above constitutes what I believe are the most important traits of a great UI Engineer, though I do realize it may not be complete.

Evaluating UI Engineering Candidates

Wait a minute! I skipped finding the talent. This was on purpose. Before we can get into that discussion, it’s important to not only know the traits of a great UI Engineer, but also how to evaluate for those traits. We’ll get into finding that talent after this discussion.

Before I answer this question, I need to point out flaws that I’ve observed over the years – from both personal experience as a hiring manager and as a candidate – in the perception of the UI Engineer. Because there’s not really a good understanding of what makes up a great UI Engineer, as I mentioned above, most companies’ perceptions are innately flawed. So I need to point out a couple of important points about what a UI Engineer is NOT:

• A UI Engineer is not a visual designer. While he or she may have a good sense of aesthetics, they are not UI designers. Some can do visual design, but that is not their focus.
• Many of the best UI Engineers I’ve run across never received formal computer science training. So many companies throw algorithms at UI candidates during the interview process that have NOTHING to do with building great UI. This is way too low-level. If you’re going to effectively evaluate UI Engineers, you’ll remove this from your evaluation process.

With those points in mind, let’s proceed with a process that I have found to be highly effective. What I will be outlining below is the process, not the actual questions, though I will suggest context of your questions.

1. First, start out with personal motivation and team fit. Many companies do this as a last process. I prefer to do this up front. My thought behind this is to not waste both the candidate’s and the team’s time if there isn’t a fit from a motivational, philosophical and cultural perspective.
2. The next stage of the interview process needs to focus on object-oriented design acuity. This is the first part of the technical interview that focuses on high-level technical design. Don’t mark off points for a candidate that may not know UML; but great candidates these days should be familiar with object-oriented design to some extent. One way to test this would be to have them come up with an object hierarchy based upon some arbitrary set of objects. Here’s a great example that I ran across in my own interview process.Now mind you, diagramming can be taught. So it is of absolute no use to discuss the deeper technical points of UML or relational technology. What you’re after here is getting a sense of how the candidate organizes their thoughts given an environment and constraints within that environment. And you’re getting a sense of their acuity with object-oriented programming.For those who are thinking that this step is superfluous. Think again. Most UI Engineering candidates will list object-oriented JavaScript on their resumes. It’s one thing to know the syntax and how to code, it’s an entirely different matter to know the architecture behind the syntax, and this is what you are evaluating at this stage.Note that most junior candidates will be pretty clueless about this stuff. So if you’re interviewing a junior-level candidate, you need to be gentle, and evaluate the candidate based upon their ability to grasp the concepts AND especially your estimation of how much time you will have to spend in training the candidate.
3. Following the design discussion, get into details surrounding the candidate’s work style. The questions you ask here will give you critical information on how efficient the candidate is when they work. What you’re looking for here is if they follow a process, whether formal or informal, and the closer to SDLC, the better. If they have followed a formal process in a previous position, ask them what they might improve.
4. The next stage will go into specific technical questions around HTML, CSS, and JavaScript.
   • For HTML, ask questions about document structure, semantic HTML, and perhaps have them do a coding example. One effective way I’ve found to measure HTML skills is to give the candidate a sample wireframe and have them list out the document structure they’d use in as few containers as possible while still maintaining semantic HTML rules (be a bit wary if they’re not aware of the term “semantic HTML”).
   • For CSS, understanding the box model is ultra-important, so ask questions around how to solve box model issues among the various browsers. To test for CSS 2 and 3, ask a candidate to write out CSS that will take three divs and have them display horizontally adjacent on the page. In CSS 2, this is done with floats, but with CSS 3, you can use display:table-cell.
   • For JavaScript, there are well-established ways of testing JavaScript syntax knowledge, so I won’t discuss them here. To test for object-oriented JavaScript knowledge, give the candidate a couple or set of objects in a hierarchy (with properties and methods), and have them code the hierarchy. At a minimum, they should be able to use prototype inheritance. The better coders will write their properties and methods in an object literal and return it from within an anonymous function protected by the global scope. For instance: MyObject.prototype = (function() {  return {myMethod: function() {}} })().Please avoid doing classic algorithms like Fibonacci sequences unless you’re doing a lot of work with object hashes or the candidate is CS trained. Most of the time, they don’t have much to do with the core work a UI Engineer will be doing.Also, if you are using MVC in your organization, you should do an MVC exercise. This doesn’t necessarily have to be in code as the various frameworks approach MVC in different ways. But you should ask questions revolving the candidate’s understanding of MVC.

Okay, that’s a lot to digest… But armed with this knowledge, we can now get into finding the talent.

Finding and Attracting Great UI Engineering Talent

To find great UI Engineering talent, it all starts out with a great job description. You can’t imagine how many job descriptions I’ve run across that just won’t get the right people looking at the job. What often happens is that a job description will go out and you’ll get hundreds of applicants; 95% of which are not qualified for the job. What you want to do with the job description is weed out the unqualified candidates. If you’re using a headhunter, giving them a great job description will help them with their weeding out process.

I’m not going to write out a job description here. What I will provide are some important touchpoints that should be included in the job description.

First come the core requirements:

• At least three years of experience hand coding HTML, CSS, and JavaScript (for senior-level and above, this experience should be a minimum of five years)
• Track record of  successfully working and openly communicating with cross-functional teams from design, marketing and engineering (this is more important than you might think).
• Track record of taking visual designs and/or wireframes to completion
• Be able to demonstrate methods of technical design via UML or other technical diagramming.
• Knowledge of and familiarity with object-oriented JavaScript; preferably direct experience, without reliance on a third-party framework.
• Must know semantic HTML
• Must know unobtrusive JavaScript
• Must know how and demonstrate how to resolve cross-browser issues
• Can code XMLHTTPRequest by hand without a third-party library. (This is a good one: Do they actually know the mechanics behind AJAX – it’s only two functions, but you’d surprised how many don’t know this and have instead relied entirely on third party libraries).

Next comes a summary of the above and something that should be either asterisked or bolded:

Qualified candidates will be required to demonstrate and discuss their work in end-to-end UI development, from concept to technical design to application implementation and maintenance.

What I found by taking this approach is that I get fewer resumes, but resumes that are much more aligned with the actual job.

Notice that the core requirements above don’t mention third-party libraries such as jquery or MVC frameworks such as backbone or knockout. That’s stuff you can include below the section of core requirements as nice-to-haves. Remember, a good JS developer can pick that stuff up quickly, or they already know it. What you’re trying to do is actually scare away the dabblers or the backend guys who think they can do UI because they trivialize HTML, CSS, and JavaScript. You don’t want anyone who will say, “It’s just HTML…” or “It’s just JavaScript…”

As for the other stuff in the job description, I’ll leave that up to you, as different companies do different things.

Armed with all this, you should be able to acquire great UI Engineers.