Category Archives: ui engineering

The Unfortunate Lip Service Paid to Design

Posted on by
Reply

I will admit that I don’t have enough natural talent at coding that I can just sit down and code an entire application off the top of my head. So I use UML (and in the past the Booch method) to engineer my applications before I write one line of code. Design has always helped me get most of my issues worked out before I code so that when I’m ready develop, it’s all about execution; rarely do I have to stop to second-guess what I’m doing because I’ve already worked it all out in my head, and more importantly, created a map for myself to help guide my development. This practice is something I just learned on my own after failing so many times. Call me a little anal-retentive about going through this process, but I’ve had nothing but success developing applications in this fashion.

It used to bother me that for the most part, I’d be the only one designing my software before I actually built it. Hell! Everyone around me took their specs or mockups, sat down and churned out code! It used to make me uncomfortable. But it no longer makes me uncomfortable because those very same people are the ones who spend lots of time paying off technical debt. Now I think that if they just invested even a little time working out their design before they code, they wouldn’t have to spend so much time grinding their apps or components into submission. But that’s how it is with most of the software development world.

Getting to the crux of this article, almost every engineer I’ve spoken with regarding the virtues of design agrees that it’s valuable – and I’ve spoken hundreds on this subject. But only a handful have actually adopted the process of designing before you build. That doesn’t hurt my feelings though, because I figure if I can reach just a few, they’ll hopefully teach others. And those of whom I have taken under my wing to teach the process have gone on to be some of the finest software engineers in the industry, and sought after by many companies. The software they produce is bullet-proof, and it all started with design.

Despite the agreement that software design is a valuable step in the development process, overall, I’ve that that agreement ultimately is lip-service. I think many developers see it as a time sink that will take away valuable development time. I can’t tell you how many times I’ve heard something like this: “I have a deadline and can’t take the time to learn this.” But I always contend that if you start simple, the time investment is minimal. For instance, I always instruct people to start with a simple class diagram. That way they can identify the objects they’ll have to build. Doing that one thing can solve so many issues due to not knowing who the actors in your play are. Then, if they’re ambitious they can move into drawing sequence diagrams for the critical object interactions. And for the most part, unless you need use-case or state diagrams, you really only need class and sequence diagrams. In the end, it’s not much of an investment in time.

Admittedly, as with any new thing to learn, velocity will be slower. But as you get better at it, you’ll be faster. And I have found, as have all who have adopted this practice, that not only does design get faster, but development gets faster, and even more importantly, the time spent paying off technical debt is greatly reduced. For instance, I know of a guy who has worked and re-worked the same damn component for 6 months! If he had only taken the time to sit down and work out a design, he could’ve been done in two weeks – maybe even sooner. But he’d release his work, find that it was missing some key features, then rework his code. Talk about wasting time!

I think what shocks a lot developers I speak with is when I tell them the proportion of time I spend on various tasks when I’m developing. I spend about 5% on requirements review, 80% on design, 10% on development, and 5% on debugging and technical debt. Those are fairly loose averages, but I’ve measured these over time. Before I became a practitioner of design, those numbers were more like: 5% on requirements review, 10% on design, 50% on development, and 35% on debugging and paying off technical debt. What’s the implication here? Look at the debugging and technical debt numbers. With a good design, you just don’t make that many mistakes. Most of my bug tickets tend to be cosmetic fixes in nature. I don’t get too many functional error tickets; again, that’s due to having done a thorough design. Also, with the change in proportion, my overall development time, including all the steps has been reduced by 30-40%. What used to take me several days to finish, now only takes me a day or two or even a few hours! But despite sharing those numbers, and people getting fired up about doing design, most simply don’t execute. It’s really a shame.

Eventually people will learn. But in the meantime, there’s going to be a lot of crappy code out there…

Advertisement

Don’t Be Afraid to Scrap Your Code

Posted on by
Reply

I once got this “emergency” project where I had three weeks to deliver a mobile prototype application that was to be demonstrated at a major user conference. I spent the first week creating a UML design for the app – also looking for a back-end guy to build the Java API’s for me to call. Then spent a few days prototyping some assumptions and testing our JavaScript library’s capabilities on various phone-based browsers. Once I proved that out, I had roughly 7 business days – plus a weekend – to deliver the project.

Five days and almost 600 lines of code into implementation, I realized that I was doing a boatload of coding; way too much, writing lots of code that to address things that I hadn’t considered in my design. So I stopped coding, opened up my design, ran through the sequence diagrams and realized that what would’ve helped was having an intermediary object act as a ViewController and manage the various view objects. So went back to my class diagram, inserted the new object with the methods and properties that I expected it to have, re-worked my sequence diagrams then went back to my main JavaScript file and…

…completely erased it…

I mean, Select All -> Delete.

When I redid the code, I finished it with less than 50% of the original lines of code and actually checked it in with a day to spare. During testing, only cosmetic flaws were found, but no functional errors. I fixed those flaws and the prototype was released and demoed live at the conference in front of over 1000 people. The point to all this is that once I had the right design, the coding was absolutely simple and straight-forward. I wasn’t writing any compensatory code or dealing with deficiencies in my design because the design was right.

Moreover, erasing all my original work ensured that I wasn’t influenced by my old code. I had to start with a clean slate. But in the end, I still beat my deadline by a day.

Now, this isn’t something I recommend for huge projects, but as a rule of thumb, if you find that you’re writing a lot of code – especially with object-oriented JavaScript – chances are your design is flawed. At that point, stop, re-evaluate your design, and back up to a place in your code where you can adapt to the better design. Yes, sometimes that means getting rid of all of it, but most of the time, you can back up to a reasonable place without erasing all your code. But in either case, don’t be afraid to scrap code; especially if it means that the final product will be superior to what you originally created.

Want Your Team to Write Maintainable JavaScript? Start Making Them Think Alike…

Posted on by
Reply

A colleague at work today posted a couple of JavaScript/Front-End Development conferences that are coming up in the near future. One of them, the O’Reilly conference has a speaker talking about writing maintainable JavaScript. I did a bit of searching on him speaking about this topic, and the material that he presents is generally pretty good – at least from a coding standpoint. But I think that focusing only on coding won’t solve the problem. From personal experience, nothing can mess up maintainable code more than bad or non-existent design practices.

I know I don’t get too much traffic to this blog, but for those who have read my technology articles, they’ll know that I have a real design focus. Why? Simply because high-quality, easily maintainable software starts with good design, and I have LOTS of personal experience in this. I was able to get roughly 200 front-end engineers at a previous company to code the same way – in a maintainable fashion – by first teaching them good design practices. It all started out with using UML as the way to communicate our designs, then writing good technical design documents to describe and discuss the diagrams, then writing code that followed the designs. Of course, included in the process were both design and code reviews ensuring that the final product that was produced with lots of input and feedback.

Most would think that adding all this onto the development process would tack on more time to development. Admittedly, at first it does. That’s the “learning tax.” But once people are used to doing designs, and going through a few review processes to defend their designs and code, they become faster at development; much faster than they were before they started practicing “design first, code later.” While this also requires an overall organizational acceptance, it’s an easy sell because the overall code quality will shoot through the roof.

Plus, doing design then coding is the fundamental difference between software engineers and code monkeys. I’ve been around long enough in this industry to say that most software developers, though they like to think of themselves as engineers are code monkeys; albeit, with varying levels of experience. The more experienced developers will most likely be able to tackle a problem and get it right a lot of the time, but to me, when there’s not a design to accompany the development, there’s always a risk that problems that could’ve been mitigated and avoided with a design will trickle through. That’s not to say that a design will mitigate all bugs. That’s ridiculous. But you can avoid lots of problems simply by doing a design and following it; that is, implementing code according to what’s described in the design.

To crystallize the point further, let me say this: Code is PRODUCT; design is engineering. And when people are designing in the same way, they will tend to adopt coding practices and standards that are similar and maintainable throughout the organization.

So which do you want to be, engineer or code monkey? If you’re not already doing design, you know who you are…

A Real Pet-Peeve

Now that I’ve pontificated on the virtues of design, I’ll discuss code. The speaker on writing maintainable JavaScript, Nicholas Zakas, is quite an engineer, currently a principal at Yahoo. But in reading through his blog and reading through the conference highlights, plus reading this article that he wrote on the subject, he missed a VERY important point that is one of the very things that pisses me of more than anything else and that is lack of comments. I’m very good about commenting my code simply because once I’ve got it checked in, I want to be able to get a gist of the flow when I return to it weeks, months, or years from when I wrote it. I also do it so that others who may maintain my code after I’ve left know what I’m doing in my code.

I’ll just say it plainly: Commenting code is Programming I; not 101. You should be commenting your code from the get-go. Period. It’s such a key component to team coding and writing maintainable code, but it is often missed in talks and lectures because it’s assumed people do it. Nick, believe me, they don’t. 🙂

A Particular Caveat About Backbone.js Development

Posted on by
Reply

I’ve been developing an MVC application using Backbone.js as my MVC engine. This is a very powerful framework and its capabilities extend beyond a proprietary MVC engine that I helped develop in a previous company. One thing that I absolutely love about Backbone.js is how you can use a third party DOM library such as jQuery. With the proprietary MVC engine I helped develop, we actually stringified our HTML and wrote it all out with innerHTML, and DOM operations were performed with DOM scripting. You might think this is screwy, but it ensured that we followed a fundamental rule: No component could know about another component’s DOM. The net result is that all view objects were completely encapsulated and their DOM’s protected from other objects.

With jQuery and other DOM-scripting libraries, all you need is a selector, and that sort of opens up your views’ DOM’s to be open to manipulation. I even found myself starting to do this in a module that I built where a two-column informational table was actually constructed from four different data sources and four different views. Luckily, I fell back on my old experience and made the conscious decision that my individual views would only know about the specific section of HTML for which they were responsible. But I could’ve easily broken the rule that a component only knows about its DOM and its DOM only.

You might ask, “So what? What’s the harm in that?” There’s actually not much harm of that, but if you have two components competing for the same patch of HTML, you could have some deleterious results. So my advice here is relegate your views to specific sections of HTML on they and only they act upon. This will ensure that you won’t stepping all over yourself and having to deal with resource contention.

If You Adopt a Pattern, Stick with the Damn Pattern!

Posted on by
Reply

This is a bit of rant, but something that I’ve seen time and again in development groups that I’ve worked with over the years: Engineers adopting a design pattern then falling out of the pattern when it’s convenient. The most egregious is breaking out of the MVC pattern when the interaction gets difficult. Don’t get me wrong, there will always be exceptions; but especially in UI engineering, I see a lot of “falling back” on the tried and true DOM-based operations before adequately exploring whether or not it can be done within the context of the particular MVC engine that is being used.

There are several reasons for breaking from the pattern:

  • JavaScript is wide open, and there are lots of ways to skin a cat, so if you hit a bit of a roadblock, there are lots of tools available to solve the problem. But in rebuttal to that, just because you can do something, should you?
  • Because JavaScript is not strongly typed, enforcing patterns is difficult at best. Everyone has to buy into it.

What I see a lot of is falling back on DOM-based libraries such as jQuery. For instance, if you want to show a popup window to display some information from the server when a user clicks a link, the MVC way would be that the view that holds the link intercepts the click, triggers an “action” event of some sort which is intercepted by a controller that would then tell a DAO that would retrieve the information from the server. When the data is available, the DAO would fire a “data available” event that a model is listening to; the model in turn would update itself, trigger a “change” event to which a view is listening. The view updates itself, then displays the results.

This seems a little convoluted and complex but what it ensures is that you have proper separation of concerns; each different component is responsible for only what it was intended to do. The anti-pattern to this is just call a function and use jQuery or another DOM-based library to handle it all, which is totally easy. You make the call, use jQuery’s AJAX method, then display the message with a jQuery modal dialog. Simple.

But here’s the problem with that: Once you go that route, you’re using an external entity outside of your MVC system that acts completely independently of your system. That entity combines MVC and DAO operations. You could argue that that makes it a self-contained MVC. But that would be wrong because there is no separation of concerns, which is what MVC is all about. If you’re going to follow the pattern, there are no multi-roled objects.

Furthermore, the approach that is commonly taken is to make that function globally available because “Hey! It’s a cool function that we could use everywhere!,” which usually means polluting the global namespace. That has some serious security implications when you do that because you’re exposing the function to the world, and because that function is making an open server call, it is possible to expose it to CSRF attacks. Not good.

You see this behavior mostly from developers who are new to MVC. So how do you teach them? Simple. You have to get team buy-in to specific rules:

1. Obey the knowledge barrier. Look at the diagram below:

The solid lines represent direct knowledge from one entity to another. From that we can see that the controller knows about both the view and the model, and the view also has direct knowledge of the model. The dashed lines represent an implicit knowledge in that the only way for those entities to communicate with the destination object is via messages/events.

2. I mentioned this above: No multi-role objects.

3. DOM-based libraries should only be used to interact with the DOM; that is, they’re mostly used as helpers for the views. However, since they also have AJAX capabilities, they can also be consumed for use with DAO operations, but a DAO object should always be relegated to that whether the DAO is explicitly or implicitly declared. For instance, Backbone.js utilizes jQuery’s AJAX for CRUD operations. In that case, the DAO is implicit, and actually obfuscated from the developer as the models and collections interact with the Backbone.sync object which is itself a DAO.

4. Finally, to mitigate shortcuts, developers have to learn and practice good architecture and design; that is, they need to start using some sort of class and object interaction description methodology such as UML.

Those are four simple rules. Having taught this over several years, I know how difficult it can be to enforce and have developers obey them because the temptation is to always go the easy route. But great programs can only be created with a thoughtful approach to building them. Just as in construction, you wouldn’t build a house without a blueprint, and when you’re building you wouldn’t use construction methods that don’t follow the standards. Why would you do this in software?

Wednesday JavaScript Meanderings

Posted on by
1

On JavaScript Parasitic Inheritance

Hmmm…. Not sure that I really buy into all the craze in Parasitic Inheritance the last couple of years. Perhaps I’d buy into it if I heard a really great technical explanation, but thus far, all I’ve heard and read about the virtues of Parasitic Inheritance center around not having to use “this” and “new.” My reaction to that line of reasoning is “So what?” “this” and “new” are artifacts of the JavaScript language. Deal with it. Another line of reasoning used to justify the use of Parasitic Inheritance is the concept of the durable object, which is defined as “A durable object contains no visible data members, and its methods use neither this nor that. Again we return to the non-use of “this.” And again, “So what?” You can achieve something similar this using while defining a custom object in the traditional way:

function myObj() {}

myObj.prototype = (function() {
    function myPrivFunction(myArg) {
       return ...do something with myArg...
    }
    return {
        myMethod : function(param) {
            return myPrivFunction(param);
        }
    };
})();

You can have a whole set of private functions defined above the return that will not be changeable to the outside world. Furthermore, one of my biggest problems with Parasitic Inheritance is that you lose instanceof. Yes, there are ways to deal with it, but most of the examples I’ve seen deal with overriding Object and Function prototypes, or creating some intermediary “helper” function to enable instanceof with Parasitic Inheritance. My thought about this is if you have to make changes to the core of the language, then the “solution” you’re providing is simply an interesting engineering exercise.

On MVC: Put the DOM in Its Place, Dammit!

One of the things I see quite a bit of when working with JavaScript developers who are relatively new to using MVC frameworks such as Backbone.js is that their thinking is very DOM-focused. And while MVC in JavaScript does mean interaction with the DOM through the View, most developers focus their thinking around the View. As a result, their programming is all about direct references. But MVC is about separation of concerns, and each part of the MVC has an important role to play. As such, one of things that I do my best to help “teach” is having developers divorce themselves from DOM-based thinking, and start thinking at a much higher level; specifically, the system or application; breaking the application or system into constituent MVC parts.

Admittedly, it’s difficult for many to make the conceptual leap into MVC thinking because what we as UI Engineers produce ultimately shows up on the DOM. But the DOM is a by-product of MVC interaction. Once you get that concept down, then thinking with a perspective of MVC becomes quite easy.

It doesn’t help matters much when you have examples that are very DOM-focused, as many developers that move over to MVC are expert in jQuery or YUI or prototype.js, what have you. As a result, these developers provide examples that lean heavily on that previous experience. It’s a bit of vicious cycle.

On Agile Development and Why It’s Done So Wrong…

Posted on by
Reply

I’ve been in several organizations where we used an “agile” development process. I termed what is commonly known as Agile Development in lower case and quoted because most organizations I’ve been in practice Agile in spirit as opposed to canonically. Granted, any process needs to fit the particular organization, but many organizations’ idea of Agile is a focus on quick delivery. The end result? Lots of technical debt.

For instance, I once worked with one organization where they split their “agile” process into three stages: Sprint Planning, Development, and Repaying Technical Debt. About 10% was focused on sprint planning (which is reasonable), 60% was spent on development, and 30% was spent on repaying technical debt. When I heard that 30% spent on repaying technical debt, I about  flipped my lid! To me, allocating that much time to technical debt indicates to me that one very specific point in the principles of the Agile Manifesto was completely missed:

Continuous attention to technical excellence and good design

Unfortunately, lots of organizations miss this item, and also unfortunately, this particular item is kind of far down in the manifesto principles list. To me, it should be the first issue. Why? Mainly because in my experience, if you take the time to design, then you actually avert paying a lot of technical debt down the line due to a bad design – or lack thereof.

I understand that one of the major tenets of Agile is “working software over comprehensive documentation.” I totally agree with this. But in my experience, the practice usually translates to zero to no design. It’s not that I want to have rich technical specifications, but especially if you’re doing object-oriented programming, not having at the very least a class diagram and associated sequence diagrams to describe the interactions is well… a crime from my perspective.

Mounting Your VMWare VM on OSX Lion

Posted on by
4

If you have a VMWare VM installed on your Lion machine, and you have set up SSH on the VM, then it is possible to mount your VM as a volume on your Mac using OSXFuse and a client such as ExpanDrive.

For those of us who like to use an IDE like IntelliJ or WebStorm to do development, being able to treat my VM as a volume on my Mac has been a boon to development. But moreover, mounting as a volume allows for easier file management than using the command line. Some folks are fine with the command line, and I applaud them, but I’ve gotten used to using an IDE and having all its conveniences. Call me soft, but a big part of development is being able to work efficiently. If you’re not efficient, then you’re not productive.

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.