Category Archives: technical recruiting

Why Job Descriptions Are Useless

Posted on by
Reply

I wonder if companies ever wonder why the hell they get so many crappy resumes for the jobs they post. Part of it may have to do with job hunters simply taking a shotgun approach to their job search and throwing resumes out to see what sticks. For sure, I’ve done that in the past, but over time, I’ve learned to dig into the job descriptions, which leads me to the crux of this article. I’m not sure if classes are given on writing job descriptions, but especially in my recent experience, most that I’ve seen have been rubbish.

A lot of this probably has to do with the recruiter of the company being left to write the job description, and they don’t have the innate knowledge nor perspective of the role that one who is in or managing the position has. But frankly speaking, it’s not the recruiter’s job to come up with the job description. It’s the hiring manager’s. Then perhaps, we have another quandary, and that is that the hiring manager hasn’t been very clear nor precise in what he or she is after. Either way, the end result of a bad or inadequate job description is that companies get a lot of misaligned resumes, and waste a ton of time having to sift through them to find the gems.

I realize that many companies have methods and procedures for publishing job descriptions, and it usually starts with the hiring manager writing something up, then turning it into recruiting. But how many job descriptions are actually proofread for more than grammatical or spelling errors? Considering the plethora of what this author feels are crappy job descriptions, probably not much.

That said though, it’s not difficult to write an effective job description. One simply has to keep a couple of things in mind:

  1. First and foremost, a job description is sales collateral. Your buyers are your candidates. Instead discussing this point at length, let me ask a question to get your gears turning: If you were trying to sell a high-value, luxury product, would you package it in newspaper? So the job description should have some polish and have language that evokes a positive emotional response that will compel job hunters to dig deeper into the details of the job.
  2. The job description is also like an invitation to an exclusive club in which certain criteria have to be met. I’ll get into this point in detail below, but clarity and precision are key because you want to attract the right individuals and make it clear that only those who don’t meet the criteria don’t bother to apply; respectfully, of course.

The first point is pretty easy to accomplish, though I have found that you have to be careful about not coming off as too “snobby” in the job description. That’ll turn people off. The trick is to word the job description such that people will feel as if it would be a privilege to work at your company, but then balance it with points that will make them excited. A phrase such as,

We take great UI seriously, from visual and interaction design to engineering, and the people we have working on our UI are as equally passionate. We’re looking for people who share that passion, and want to be part of a team that creates “kick-ass” UI.

…is extremely effective in not only stating the value of working at the company, but appealing to people’s sense of ownership and passion.

Point 2 is all about focusing your requirements. Most job descriptions lump all the requirements together into a single section. I have preferred those that tell me the must-haves in one section, then the nice-to-haves in another section. Also, don’t list things that are NOT part of the job. For instance, most UI folks know very little about Java, but lots of job descriptions for UI list Java programming as a requirement; something along the lines of “3-5 years Java experience.” Don’t know how many times I’ve seen that, and when I inquired about it, the hiring manager says it’s really not that important. What would have been more accurate would be something like this: “3-5 years experience writing UI on top of a Java platform,” which is typically what that “3-5 years Java experience really means.”

In a case such as the Java experience, not only will scare off potentially great UI talent, you’ll attract the wrong people who may be great in Java but simply mediocre in UI. So with your requirements, you need to have laser-like focus with your must-haves, and don’t be afraid to say something to the effect of:

Only candidates who fulfill the following requirements will be considered…

This won’t prevent what I call resume spammers from sending you a resume, but it will help to reduce the glut.

Advertisement

Keys to Finding and Evaluating Great UI Engineering Talent

Posted on by
Reply

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.