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?

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.

I’ve been a Republican since I registered to vote 32 years ago, and though I’ve had my ups and downs with political involvement over the years, I always have been an apt observer. This coming presidential election has especially piqued my interest because it has been amazing – and horrifying and even a bit amusing – to observe the Republican strategy in the race up to the election. This amazement comes from having been a coach of various sports over the years. I have a winning record in all the sports I’ve coached, and have four championships under my belt for my high school roller hockey team.

Not to say that I’m a great coach – everyone has room to improve – but I did learn quite a bit from studying successful and arguably great coaches such as Bill Walsh and Herb Brooks. From what I observed, a huge part of their success was simply teaching what it takes to develop a team with a winning attitude. We could talk about collaboration and cooperation and such, but there’s one thing that I learned as a coach that you never do: Ever mention or plan my game around the word “lose.”

And from that, I don’t mean don’t play the game to not lose, but also don’t play the game to make the other team lose. What? Not play the game to make the other team lose? What’s THAT about, you might say. Basically it’s this: If you plan your game around the mindset of making the other team lose, what you’re doing is projecting onto the other team your own idea of what it means to lose. Ultimately, your mindset will be your undoing. We can’t possibly know what the other team thinks with respect to losing, so if we project our sense of losing onto the other team, we essentially end up focusing on what will make us lose, and ultimately play a game of “not-losing vs. losing” as opposed to winning vs. losing. The best we can hope for in that scenario is a draw.

A good example of this comes from a Star Trek: The Next Generation episode “Peak Performance” where Data plays a rather arrogant opponent in a game of Stratagema.

When I saw this years ago, the one thing that struck me in Data’s explanation of beating Kolrami was that he was playing to a draw. But I looked at it the other way. Kolrami had projected what his “values” of he believed would make his opponent lose onto Data. Data didn’t just didn’t play the game that way, and though he technically did not win the game, he played it in such a way to force Kolrami to withdraw.

And this is EXACTLY what I’m observing in the GOP right now. They’re playing the election game very much like Kolrami, and frankly, with all the absolutely STUPID stuff the leadership is spouting, such as John Boehner’s repeated claims of the “unconstituionality of Obama-care” though the US Supreme Court ruling completely blows that out of the water, they’re doing a great job of it. We have also had to hear every single Republican representative say in the press, “Our goal is to make Obama a one-term president.” Every time I hear that I have to laugh because that is exactly the kind of rhetoric Obama wants to hear. The GOP has essentially stated their entire strategy, and it’s working in Obama’s favor. His job approval ratings (Gallup) are starting to trend upward. The GOP will state that his job approval ratings are historically low as compared to other presidencies. But the only thing that matters is where they’re at in this current election year, and should they press above the 50% mark, the GOP can kiss the election goodbye.

The net result for the GOP? Since they’re all partaking in the same strategy, the GOP presidential nomination is frankly, still up in the air. Though Romney won Florida, his lead of 31% vs. Gingrich’s 26% isn’t significant enough for him to claim victory. Plus, 31% is not really a number about which to be ecstatic. If the numbers were in the 40′s that would be a different story, but as the numbers don’t lie, it is easy to interpolate that the Republican Party is generally fractured on who to follow. Not good.

And based upon those numbers, I’m apt to yet again vote outside the party. I have zero confidence in Romney, whom I see as simply buying the election with his riches and well-funded super-PACs. I was hopeful that Gingrich would fare better, but he has his own skeletons in the closet to deal with, and makes me seriously doubt his ability to lead the country. As such, there’s really no one in the GOP race that appears to me to be an outright leader. I realize that the number will go up as more candidates leave the race. But I also see that as those supporters settling for the remaining candidate(s). I would much rather see someone who’s garnering support organically rather than through inheritance.

Obama, on the other hand, has been quietly going about his business, and no matter what the hyperbole of the GOP may state, his policies have had success. Do I like the fact that he didn’t act much stronger on the Wall Street executives? Not at all. Do I like Obama-care? I’m a bit on the fence with that, but it has not killed jobs as the GOP keeps touting, and it has cost FAR LESS than what idiots like Michell Bachmann, Glenn Beck and Sarah Palin have made so many believe.

I never did dig the bailout, but understand why it had to happen, though I’m hopeful that legislation will pass that will prevent institutions from growing too big to fail. And mind you, those institutions were allowed to grow that big due to the rescinding of regulations under the Clinton and Bush administrations. Obama inherited a shit sandwich, and though I’m a Republican, I have to say that he’s done okay given the circumstances under which he took the presidency.

In any case, I believe that the only way for a true GOP leader to surface among the mediocrity that’s present in the race right now is for one of the candidates – and perhaps the party as a whole – to stop playing the game of “not losing.” They need to start volunteering their leadership on issues that are important to americans – all americans – and not just the financial elite and lobbies. Until they stop playing the game the way they’re playing, Obama has nothing to worry about.

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.

In essence, the “free market” basically gave those Wall Street bastards the freedom to gamble with other people’s money. And the worst thing about that “freedom” is that after the Wall Street boys completely screwed up the economy where we saw millions of foreclosures and millions of jobs lost, they had nothing to worry about. The American taxpayer came to their rescue! You can’t tell me that it is more complicated than that. The freedoms those people enjoyed allowed them to act in such a way that they collectively brought the global economy to the brink of complete failure; they were all essentially acting as huge, interconnected hedge funds and they eventually became too big to fail. If one went down, they all would go down. So what did they do when they realized that they’d completely fucked up? They cried for help and they got it in the form of a $700 billion bailout!

Think about this: If anyone of the “little people” did what Wall Street did, they’d be ruined, if not jailed. You see anyone go to jail? Not at all. In fact, a year after the collapse, Goldman Sachs awarded billions in bonuses to its employees. No one learned any lesson. Perhaps the ultimate victims in this – the rank and file American public – learned a lesson: That those in the upper echelons of the financial community are simply above reproach and in reality and sadly, above the law.

The financial crisis just proved that a free market that is also free from moral responsibility does not work. With this coming election, I’m actually deathly afraid that my Republican leaders will simply allow Wall Street’s trend of fiscal irresponsibility to continue. Thus far, all I’ve heard from the candidates is not how they’re going to protect against the 2008 crash; instead, they’re making this a class war and taking the side of the crooks who got us into this mess in the first place; calling them “job creators.”

Frankly, I don’t really give a shit about politicians’ rhetoric on how they’re going to create jobs – especially within the context of this particular economic environment. I believe that they first have to find a way to keep Wall Street in check. If that means creating some sort of oversight or regulation, so be it.

To me, a free market is a market where everyone is free to prosper. But in order to make that work, there has to be some sense of responsibility and accountability. There was neither in this latest saga in our economic story, and all that’s going to happen if this continues is that we’re bound to have another collapse.

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.

My brother and I have always wondered what was up with our father and many of our ultra-right-wing conservative family members, puzzling over their seemingly blind support of candidates or anything Republican for that matter; all this on top of their absolutely annoying criticism of Democrats. On the other hand, one of my closest friends has been a staunch Democrat; staunch to the point of getting angry if I didn’t agree with his political ideals.

This morning, I read an article on the Romney aides attacking Newt Gingrich’s reliability and trustworthiness, and essentially calling him an anti-Republican, and just falling short of calling him psychotic. But the thing that one of the aides said struck me:

I don’t think Newt Gingrich cares about conservative principles…

I then realized that statements like the one above are the root of the problem that I’ve been having with BOTH sides of our political landscape. Each camp has been very effective in polarizing the masses and debating on ideology, not the issues. If an issue does come up, it seems – at least from what I’ve been reading – that the legislators don’t argue the merits or the problems with the issue itself, they argue the ideology.

The net effect can be akin to brainwashing. Anytime you bring ideology into anything, you bring in emotion. Push the right emotional buttons – especially the anger buttons – and you can instantly move thousands, perhaps millions, towards your point of view. Today’s politicians have been extremely effective at that. Take a look at the GOP: Their resounding, practically single-minded battle-cry has been to make Obama a one-term president. My question for my fellow Republicans is simply this: What do you stand for that will be for the good of the American people?

Oh, they say all the right stuff to address the issues on their websites, that’s for sure. But the news they make has been all about political ideology. As a Republican, I anguish about this as it makes me extremely reluctant and actually confused about who would be best suited to run against our current president. As it stands, I believe the one who refuses to engage in the ideology debate will be the one I vote for; that is, if they don’t drive me away as a Republican voter due to their ideological squabbling.

So that is why in the end, I will vote my conscience, and vote for the candidate whom I believe believes in “by the people for the people.” That may be Republican – and I’m hoping it is – but it may not be, and as in previous elections, I will cross party lines.

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.

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.

I’ll just say it plainly: Just because someone happens to know a particular MVC or OOP framework doesn’t mean they actually understand OOP. No matter what framework you use, OOP is all about design, all about understanding the relationships and interactions between objects. Go ahead and make all the objects you want. But unless you have a clear idea of how they relate and interact, then you run the risk of doing A LOT of extra coding down the line to compensate for your lack of design. Mind you, I’m not just throwing this out as a matter of opinion, I’m coming from a position of experience.

Circling back to the crux of this article, that’s not to say that there haven’t been some great interview questions or exercises that cover OOP. There have been. But one in particular stands out above the rest, and it will be an exercise that I will use going forward. I got this from a great interview with a little company called Urban Mapping with which I interviewed a few weeks back. It was the first time I felt that a company “got it” with respect to object-oriented design. And you know what? The exercise had very little to do with JavaScript. Their thinking behind this exercise is that it’s more important to know the architecture behind what you’re building before you build it. AMEN TO THAT! So without further ado, let’s get into the exercise:

Let’s Build an Animal Kingdom

Given the following animals:

Dog, Cat, Eagle, Duck, Python, Anaconda, Iguana, Salmon, Lungfish, Frog

Build an object hierarchy that can describe this set of animals. After you’re done we’ll discuss. There isn’t necessarily a right or wrong answer to this. But we’re going to take this time to discuss your object-oriented awareness and acuity.

Here’s a possible solution to this hierarchy:

Once they’ve finished the diagram, you get into the application of the design. Note that this is not to be confused with implementation, but rather, providing a context to the design to see if there are any holes in it. But first, some questions:

1. What was your reasoning behind building the hierarchy in this way?
2. Would there be another way to approach this? (Another possibility would be to break it down by number of legs, but that is actually not optimal based upon the follow-up exercise of creating a world for the animals)

So the context we’ll use is this: Building a world to place the animals. So on the board, draw out an area that has a body of water, some trees, maybe a cloud to represent air, and some rocks. After  you’ve drawn it out, then say that we’ll instantiate these animal objects in various places on the board. The idea is to reveal if the design will support the constraints of the environment. If they broke down the hierarchy according to number of legs, they may have missed the functional level. This is something that can be suggested and will almost immediately be revealed once you start going through instantiation.

If they did break it down by function, then chances are they will have missed the multiple inheritance. For instance, an anaconda can be created either in water or on land; same with the dog. You can lead them through this with some questions:

1. Is it possible that an animal can be instantiated in different locations? (You’ll especially look to see that the duck can be instantiated as a swimmer, walker, or a flyer). That last bit was a little evil on my part.
2. Given that animals can be created in a couple of possible locations, and that there constraints as to where they can be created, where would you place the method that would check for the location? The correct answer would be at the second level, so that those animals that inherit from two parents will inherit the location constraint from both.

Summary

So in this exercise, what are we trying to accomplish?

1. The obvious answer is to see if they get object-oriented design at all.
2. The second thing this reveals is how well the candidate can communicate and justify their ideas.
3. And just as importantly as the other two, this exercise reveals if this person has the ability to work with the team.

Note that this exercise is best done with a couple of people in the room – probably no more than three – especially to address item 3 above.

Based upon my experience on the receiving end, doing this exercise was literally a breath of fresh air. Personally, I wouldn’t pull this on a junior developer, but this is something that I’d definitely use for senior front-end AND back-end developers. Remember, it’s not about the code with this exercise, it’s about the design thinking. Do a separate coding interview following this.