First, we’re going to pick out the material for the kitchen counter and the glass for the windows. Let’s just guess the amounts of each to buy for now.

Then we’ve got to buy some of that new concrete everyone’s been talking about. I suppose a truckload will do it for now, but we could always order more later. I just can’t wait to try it out!

After putting the beams in place we should decide how many floors the house should have. And right at the end we should decide what style the house will be. Sometime before you move in we should get planning permission, and I’ll probably contact an architect for some drawings after you’ve settled in.

It sounds ludicrous because there’s a well-established method for building houses, and it’s based on common sense. You start with a vision, get a set of plans, pour a foundation, build the framework, fill in the internal stuff, and finally finish all the little details.

Putting any step out of order would cause complete chaos. Finishing the walls before the electrical would mean you’d have to punch holes in all your walls in order to run wires around the house. Cleaning it before it is completely finished would be a wasted effort given the amount of dust builders cause while they work.

However many coders build their systems backwards. They become enamored with the latest whizz-bang framework or charmed by the reportedly speedy performance of the newest database. And they lead their thinking with those choices as they build new features, whether those technologies are appropriate or not.

More importantly, using a technology-first design typically means that the user experience (UX) will be left until last. And if you put your users last in your order of priorities, it will unfortunately be very evident in your system’s lack of usability.

UX First

The first order of business in application design is deciding what its users will experience. This should be a high-level vision sketched out on paper or in simple digital mockups, and it should express the flow of the system from the user’s perspective.

It doesn’t matter if you’re building a web application for senior citizens or a system-level tool for serious computing nerds. The UX must be designed first.

Then Comes The Architecture

Once the UX has been designed and the vision of the system has been defined, an architecture should be laid out to make sure that the code that eventually gets written will actually meet the needs of the users. The choices made in the UX design radically shape and inform a system’s architecture.

A good UX design will cater for less obvious things that might be part of the overall user experience. A well-written specification might include requirements such as “the overall load time for page loads must be less than 200 msec” because the designers know the consequences of slow page load speeds. It might also call for close-to-zero downtime, so the architecture might end up requiring a multi-datacenter deployment.

Last But Not Least, The Tools

Now it’s finally playtime! Once the UX has been defined and the architecture has been laid out, the process of picking the right technologies, frameworks and libraries can begin. The crucial point is that now the tools are being chosen with the UX and architecture in mind, so any tool that doesn’t fulfill the needs of either can be quickly disregarded.

This Does Not Mean “Waterfall”

If you think that this design sequence requires an outdated Waterfall-like approach to accommodate it, think again! This is completely appropriate for Agile development. The implementation of a whole new product, an epic or even a single user story should follow the UX -> architecture -> tools sequence. When beginning the development of a product or epic, spikes should be used to design the UX and the architecture. And individual user stories should include enough details for the engineer to know what the UX for that story should be once it is fully implemented, and the engineer should also estimate enough points to cater for architectural planning to be done once work on that story begins.

Tools are great fun to research and to experiment with. Programmers love discovering new ones and finding “The Next Big Thing” in the framework jungle, and having lots of tools at your disposal is wonderful when the time comes to build a system that satisfies the UX and the architecture. Just don’t begin the entire design process with them. So remember: UX first, then architecture, then tools.

• We enjoy being constantly interrupted by them
• We love to repeatedly try out every feature available they have, including things we will never need
• We believe it’s worth spending hours re-wiring our brains to deal with their unconventional design choices

How do you know if your application is just as vain? Here are 3 signs of design narcissism:

1. Being Too Noisy

Imagine you hired a babysitter who called you every few minutes during your night out to say:

“Hey, everything is OK! I’m still here and everything is fine! I’ll be calling back every 2 minutes whether you want me to or not! Bye!”

Nobody in their right mind would be happy with that kind of nuisance, but many software applications behave similarly. We somehow convince ourselves that it’s normal, and we put up with it. We even let it cause us some major embarrassment.

Applications with a singular purpose (for example, automatic backup programs) have historically been built by developers who felt they had to repeatedly show the value of that one feature to you. So every time they successfully performed their only important task, they would notify you. They would scream over emails and dialog boxes: “Hey I just backed up your files for the 3,716^th straight hour!” That’s the narcissistic approach, and it assumes that the user wants to hear that noise on a regular basis.

And of course, no customer wants to hear it. There’s no value in telling users that nothing is wrong and that the application is working just fine. Instead, they want to hear about things that are not typical. They want to be told about events that require immediate attention.

For example:

DropBox is an application that is not narcissistic. It knows not to bother me, and I love that about it. It sits very quietly in my Mac’s status bar, its tiny logo remaining unobtrusive and its noise levels almost at zero.  When I save a file to my DropBox folder, it quite happily synchronizes it without requiring any clicks, acknowledgments or action on my part. When it’s finished, it doesn’t presume that I am waiting with bated breath for the final confirmation of success, so it stays quiet. If I really need some reassurance that it is healthy then I can make the choice to look for the “green tick” on the icon.

Microsoft has also been doing better with reducing interruptions recently. Their latest versions of Office have drastically reduced the number of annoying “informational” message boxes shown to the user, but they still have a few more to go.

A user’s attention should be considered valuable, and any software that tries to grab more of their brain’s time than it deserves will likely be quickly uninstalled.

2. Being Too Helpful

It’s impossible for every single feature in an application to also be the most important one for the user to select. However, most software gives every feature similar amounts of real estate on your screen, regardless of their relative importance. A good example of this is in Microsoft Excel’s toolbar (click the image to enlarge):

It’s basically a “Where’s Waldo?” of features. Since I’m not a financial professional, I never use most of these features. It always takes me far too long to find the “Σ” symbol to sum up data, and that’s because it’s right next to icons for completely unrelated things like Copy, Paste and Undo.

The importance of different features changes over time for each user. Wouldn’t it be nice if an application were smart enough to hide icons from you if you hadn’t used them in a few months? I’d also love to see an application react to the way I use its features. For example, I always use keyboard commands to Copy and Paste, so I would love if my applications would automatically realize that and would just make those wasted icons disappear and give more room to the things I’m working on.

Many developers try to meet everyone’s needs partially but end up meeting no one’s completely. Users are usually faced with the results of design-by-committee interfaces that never seem to meet the needs of each individual. It’s like trying to order a meal at a restaurant that has far too many things on its menu from a waiter who never stops offering suggestions. Time and time again, customers must adapt to the application’s need to offer them every possible option all the time, when all they want is the same dinner they ordered the last twenty times. If you take all users across your install base, chances are every feature is used by someone. But that shouldn’t mean that every user needs to see every feature.

So, before any more Paperclip Assistants are conceived, let’s make sure the software world knows that their customers just want to get their work done, not to have vast numbers of irrelevant features presented to them on a never-ending basis.

3. Being Too Different

Narcissistic software developers will regularly assume that users will be happy to use an application that completely disregards UI design conventions and interaction guidelines. This is usually done to make an application really “stand out,” but in reality the developer’s vanity often makes their application unusable.

There are plenty of examples of terrible user interfaces to be found. One thing they all share is a complete disregard for consistency with established standards. Making a user re-learn how to perform basic operations would normally be a recipe for the application’s total failure in the marketplace, but some lucky products lack any competition, leaving the user no alternative. For example, most of the peripheral hardware devices that I’ve purchased over the years (sound cards, printers, etc) came with proprietary software that look like they were designed as an April Fool’s prank (click the image to enlarge):

Developers should have the humility to respect established UI and UX standards unless they can truly show significant value by breaking the mold. But be prepared for an initial backlash if you don’t manage that change well enough.

So, to every software developer out there: remember, if there’s anyone who has a right to be a narcissist when it comes to UI design, it’s not you, but rather the user.

Here are some of the many ways that a call to a distributed system can fail. It’s not an exhaustive list by any means, but it’s a start.

Failures of Infrastructure

These are the most basic of failures, usually experienced at the network level.

DNS Lookup Failures

The GoDaddy failure of August 2012 caused millions of DNS names to be unreachable. It’s likely that your application code expects healthy, speedy conversion of domain names to IP addresses, but if DNS doesn’t respond then it won’t get past even the first hurdle.

Lack of Network Access

Skilled mobile developers assume that their code will communicate over a cellular network that may not be always available, and handle its intermittent nature gracefully. How many developers assume the same unreliability when creating an application intended for deployment within a data center? Routers, cables, switches and power supplies fail all the time, and a failure of any of those devices could leave your system without the ability to reach the outside world right when you need it most.

Loss of Data Center

Amazon’s popular and affordable AWS services are used by a significant number of SaaS providers. Their EC2 uptime guarantee of 99.95% entices many developers to build Web APIs to be hosted within it. While that SLA sounds good, the 2011 failure of Amazon’s US-East availability zone showed the technology world what happens when during the 0.05% period. A vast majority of the systems hosted there were completely unreachable during that time, causing a major disruption for many. Importantly, those that followed Amazon’s advice to build redundancy across availability zones (such as Netflix) were able to handle the outage without interruption.

SSL Certificate Issues

SSL certificates are the backbone of secure web communications, but they can be the cause of a lot of frustration. If a server’s domain name changes and the certificate presented by it doesn’t match, the SSL handshake will fail (with good reason).

Should a certificate on either side expire, the SSL handshake will fail too. Web server administrators usually do a good job of preventing server-side certificate expiration, but client-side certificates – while required much less frequently – are sometimes deployed by users who are not very tech-savvy and who don’t keep track of when they expire.

Failures in Communication

Even if your application has basic network connectivity, a variety of errors can still be experienced as it tries to communicate with the target Web API.

Timeouts

A web service that is experiencing greater than peak load might take many seconds (or worse, minutes) to respond to your call. A query resulting in a huge amount of data retrieval and analysis might take just as long to process even on a lightly loaded server. Both of these scenarios could lead to your client giving up and throwing a timeout error when it fails to receive a response. Even if your client call is configured to never time out, a firewall in between your application and the server might decide to kill your connection if it looks idle for so long.

Origin Restrictions

If you’re building a browser-based application and expect all your Ajax calls to reach your server, you’re in for a surprise if you ever break one of the same-origin rules as an attempt to make a call to another endpoint will be blocked by almost all browsers. Even changing something as innocuous as the TCP port number in your URL could prevent your call from working, so make sure you only make Ajax calls to your origin web server.

Syntax Errors

Products that implement older middleware technologies such as SOAP, CORBA and DCOM provide stubs that take care of encoding the entire payload for you, as well as transmitting it to the server and decoding any response. However using newer architectural approaches like REST can mean that the management of the media types and payload formats will be left to the application programmer. While offering great flexibility, that approach does place a bigger burden on the client developer to ensure that it transmits and understands data in the form the server expects.

Redirections

A number of RESTful Web APIs use a redirection technique to instruct the client to resend their original request to another URI, and the HTTP standard offers response codes like 301 and 302 for that purpose. But if your client code hasn’t been built using a library that handles them automatically then you’ll have to add redirection logic for all API calls to prevent surprises when 300-range response codes are returned. And when you’re working with well-designed RESTful APIs, you should expect them to be returned.

Credential Expiration

Almost all OAuth tokens and server-side account passwords expire after a limited lifetime. It can be easy to forget this fact when you are in the heat of rolling out your application to production, so make sure that you mark your calendar ahead of their expiration dates, and that you build behaviors into your application to handle a credential failure if it occurs (perhaps by raising a system alert or emailing your IT team).

Unexpected International Content

If your application makes any assumption that the server will always send back ASCII or ISO-Latin-1 characters, you be in for a rough day when the server sends back Unicode content and your code has no idea how to decode it. Using data formats that natively support encodings like UTF-8 (for example, XML and JSON) should help somewhat but it doesn’t mean that all your work is done. You’ll still have to handle multi-byte characters and store or render them appropriately.

Proxy Servers Getting in the Way

Using a hotel or airplane’s Wi-Fi connection can cause some really interesting behavior for your application. Most pay-to-surf hotspots use an HTTP proxy server to intercept web traffic and ensure that payment is made, but sometimes those proxies do more than just ask for your money. I’ve seen some proxy servers force all HTTP 1.1 traffic down to version 1.0, causing difficulties for applications that relied on features in the 1.1 protocol. Thankfully, most invasive HTTP proxy server behavior can be bypassed by moving to HTTPS (because proxies can’t decrypt that kind of traffic between client browsers and the server as long as the server uses a properly-signed certificate).

Enormous responses

Most web services do a good job of truncating huge query result sets before transmitting them to the caller, but some do not. If you accidentally run an enormous query on the server side, it might cause a failure for your client application. Receiving a huge amount of data requires at least as much memory to store it, and (depending on the quality of the parser) might even need to be temporarily duplicated in memory in order to parse it. Make sure that you use any pagination or truncation features available in your API to prevent your application from being slammed with a gigantic result set. If those kinds of features are not available, try to craft your queries to prevent enormous responses.

Failures in Conversation

Even if your application successfully communicates with a web service API at first, failures can still occur after that point.

Throttling

This is one of the most common reasons for web service API failure. If you hit an API hard enough – even one that you’re paying for – you might discover that the vendor offering it has just cut you off. Of course, this could very well happen to your system at the worst possible moment. Some APIs have no traffic limit when they’re first released but apply them later (something Twitter API developers realized recently, much to their surprise and disappointment).

Keep in mind too that an orchestrated DDOS attack on your system (or even an innocuous load test of your own) could lead to you quickly reaching an unexpected limit with the Web APIs your application depends on.

Time Differences

February 29^th. Daylight Saving Time. The International Date Line. The Leap Second. Time zones with partial-hour offsets. Even if you believe your application isn’t time-sensitive, any of these temporal oddities could affect the results you get from the Web APIs you are calling. Testing for them ahead of time might be difficult, but it could be time well spent.

Subscription Expiration

When you sign up for an API on the Web, make sure you set your calendar to remind you ahead of the renewal date. Forgetting to renew an API account subscription will leave egg on your face – and nasty errors on the screens of your users.

The API Disappears

It’s rare, but it happens: vendors pull their API out of your market area, or they go out of business completely and shut down their services without notice. Either way the net effect is the same, and you’ll have to quickly scramble to find an alternative service.

Unexpected Payload Format

Yahoo! recently made an unannounced incompatible upgrade to their popular Placefinder API, moving it from version 1.0 to 2.0 overnight. Normally a move like that would be orchestrated in such a way to provide both old and new API versions side-by-side, but the company offered users no way to keep using the older 1.0 data format while they made the switch.

Instead, their API users woke up one day to find that Yahoo! had completely broken their applications, and the only options on the table were to either quickly move to the 2.0 format or to switch to a different service. Worse still, some users quickly made the switch to 2.0, only for Yahoo! to realize their mistake two days later and switch the API back to 1.0 – two incompatible changes in as many days.

If vendors as large as Yahoo! can make accidental incompatible changes to their API services, you have to assume that all vendors could do the same.

What You Can Do

While there are innumerable ways for Web API calls to fail, protecting your application against problems with them can be done by following a few simple guidelines:

Assume that every Web API call you make will fail. Always check that you get a response (and do so within a reasonable timeframe) and that you parse the returned payload carefully. Code very defensively when calling what are essentially unreliable functions. Build monitoring and instrumentation into your system so that your IT team gets called when remote APIs stop responding. And if you’re really confident, inject failure into your production system.

Know what your users will experience when a Web API fails. For core services that you are completely dependent on (for example, PayPal for payment processing) make sure that you fail gracefully and tell the user something useful instead of just throwing a stack trace on the screen. For secondary services (for example, Google Maps for showing store locations) consider having an alternative service available that you can fall back to, especially if you hit a traffic ceiling with your main API provider due to high traffic.

Simulate the failure of each Web API you depend upon. Testing for failure is by far the best way to defend against future surprises. If you can do it in an automatic fashion then all the better, but simply changing your hosts file to make the hostname of your remote Web APIs fail to resolve to a usable IP address will probably uncover a ton of issues that you might not have expected.

Web APIs are great, and developers love mashing them up into something exciting. But if you don’t plan for the failure of those APIs, you’ll just end up frustrating your users and driving them away from your product.

• Know nothing about it

• Know enough to successfully pretend to know it during lunch

• Know enough to be dangerous with it

• Know enough to be employed to be dangerous with it

Intermediate

• Know enough to ask intelligent questions about it on stackoverflow.com

• Know enough to answer n00b homework questions about it on stackoverflow.com

• Know enough to ridicule n00b homework questions about it on stackoverflow.com

• Know enough to contribute to open-source projects written in it

• Know enough to be disgusted with the state of open-source projects written in it

Expert

• Know enough to start writing a compiler for it

• Know enough to abandon writing a compiler for it

• Know enough to invent an improved version of it to create The One True Language

• Know enough to get bored and find another language to obsess over for a decade or so

Maybe it’s a web API that has just been modified without proper concern for backward compatibility, breaking your existing application in the process. Or perhaps you’re trying to use two middleware products together, only to find that the communication standard they implement is horrendously complex, causing each vendor to interpret it ever-so-slightly differently and making them completely useless when brought together.

For all of the many painful incompatibilities of the past, there are plenty of wonderful success stories of software and specifications that enabled collaboration and integration in myriad ways. You just don’t hear them praised that often.

Here are some examples of technologies that do their job, and then get out of the way.

HTTP

“It’s way too simple.” “It should be a binary protocol.” “It’s far too slow.”

HTTP has had all kinds of criticisms leveled at it over the years, and yet it prevails. It’s the basis for all web traffic and the vast amounts of secure e-commerce conducted over it, and a whole lot more besides.

A lot of its power comes from incredible simplicity: both computers and humans can understand HTTP commands and headers. Whether you’re a proxy server or an overworked systems admin, HTTP is easy to deal with. A proliferation of tools have been built to support it, further strengthening its foothold.

Dig deeper into its details, and you’ll find a lot of very sophisticated and smartly-designed features: encoding negotiation, authentication, encryption, caching, resumable downloads, redirection, compression, locale matching, and hooks for easily making custom extensions.

And heck, it must be good given that after 20 years it’s still only at version 1.1.

TCP/IP

Without the adoption of TCP/IP as the network protocol of choice for the Internet, the world would be a very different place. Coming up on nearly four decades of existence, the ubiquitous packet-switching protocol that is used in almost every server, desktop, laptop and mobile device has become synonymous with the word “networking.”

When was the last time you had a network issue that could be blamed on a deficiency of the TCP/IP specification? Or the last time you had one vendor’s TCP/IP stack fail to correctly implement the protocol?

The world loves IP addresses (well, maybe it loves DNS names more), and they’re here to stay. Why? Because a group of very smart people engineered a beautifully flexible and truly usable technology. And while there are some very compelling improvements being made (or proposed) right now, this outstanding work from the mid-1970′s still benefits us all today.

JSON

I’ll admit it: I can’t read XML. My eyes simply glaze over the never-ending stream of < and > characters and the duplicated start and end tags. At its basic level, it’s a reasonable language for handling unstructured data, but the awful complexity sometimes laid upon it (XML Schema and SOAP come to mind) can make it very tiresome to deal with. For many years, it seemed like every new software standard that appeared just had to be specified in XML, regardless of its suitability for the problem at hand. It looked like we were going to be stuck with it forever. And then along came JSON.

JSON evolved within the world of JavaScript but quickly won favor with engineers everywhere as a tremendously useful and simple data format. For one thing, it is completely readable, certainly more so than XML, at least to my eyes. It is also fast to parse because it doesn’t have to go through a secondary validation step to ensure compliance to some overbearing schema. Instead, semantic validation can be performed at the application level, if desired.

Now you’ll find JSON as the underlying syntax in most popular web APIs. It’s even being used as the storage format for new databases. Every modern web browser has native and efficient support for it. And when was the last time you found that your browser or parsing library failed to process valid JSON? Certainly I’ve never encountered that problem. Thank its wonderfully concise grammar for making it so easy for parsers to be created in so many different languages.

There are more…and we need even more

There are plenty of success stories to be found related to well-designed interoperability standards that have spurred innovation by being interoperable. Specifications like the Java Virtual Machine and the CLI are prime examples of hugely successful standards. But why do many other standards find it hard to get an adoption foothold?

The answer is simple. Or, to put it another way, the answer is: simple.

Interoperability standards succeed when engineers are able to adopt them en masse, and that is most likely to happen if the standard is as simple as possible. Specifications that try to boil the ocean will solve little of value because their complexity will lead to less acceptance in the developer community.

Good engineers will usually take the path of least resistance in their work, so if a standard is too complex it can quickly get ignored in favor of an alternative grassroots-driven solution or even incompatible vendor-driven extensions. Conversely, if useful tools exist that lower a developer’s barrier to entry (for example IDE support, SDKs, etc), a standard can be adopted more rapidly.

The software market cares about getting stuff done easily and quickly. If an interoperability standard helps in that regard, it will likely get adopted – regardless of whether it was designed by a committee or a community.

At TimeTrade we run a coding test during interviews that, for the majority of programmers, should take about 2 hours in total to complete. The whole test is comprised of a number of small problems to solve, each harder than the one before. That gives us a good initial gauge of performance based purely on completion time: if everything has been solved in under an hour, we’ll be smiling. But if two hours pass and even the first problem still hasn’t been solved, the candidate will most likely just be shown the door.

Above and beyond just solving test problems quickly, here are some signs that a programmer is truly awesome and should be handed a job offer before they leave your building:

1. They present multiple solutions

I recently interviewed a programmer who solved an entire set of tests twice: once with iterative solutions, and again recursively. I quickly made him an offer. Finding multiple solutions to a problem is a skill that engineers will need to use every day.

2. They write full documentation

Last year I interviewed someone who was so diligent, so detailed and so professional about his work that he created full Javadoc and comments for his code before he considered the solution complete. He even wrote fully automated unit tests and checked their coverage percentage. When I came back into the room at the 2-hour mark and found him typing furiously I initially thought he was having trouble with the test, but he was actually in the process of adding HTML formatting to his Javadoc. Engineers who do this intuitively are the kind you’ll want on your team.

3. They improve the test

We deliberately create tests that have some minor issues lurking within them, purely to see if the candidate (a) spots them and (b) is willing to fix them. It might be an inconsistent usage of quotation marks for strings, misleading variable names or anything along those lines. Candidates that look at all of the provided code as the test — not just the pieces we’ve asked them to write — are the ones who will do the same in our real product once they join our team.

An engineer who is willing to tell a potential employer that the supplied test contains problems shows that they consider the quality of their work to be more important than just agreeing to do what they’re told. Hire them and they’ll likely work wonders for your product, going above and beyond their assigned areas to make improvements where they are needed.

4. They refactor smartly

Most candidates like to get a solution working, then sit back and breathe a sigh of relief that they finished it successfully. That’s good, but rarely good enough to justify an on-the-spot job offer. The candidates that solve the problem but then jump right back in to refactor it are in a different category entirely. Their choice of algorithm doesn’t feel right, and they can’t ignore the feeling that it could be more efficient. Their code has some duplication in it, and that burns them up inside. These are the candidates who refactor, rewrite and improve their solution until it’s been crafted.

This can be a double-edged sword, though. If the candidate just keeps rewriting because they’re not happy until they reach a mythical point of “perfection”, there’s a chance they are one of those programmers who doesn’t know when to stop (and similarly, ship). However if they watch the clock carefully and are able to both solve the problem and refactor their solution before their time runs out, that’s a really good sign that you should consider an offer.

5. All other signs point to “hire”

Sometimes there are plenty of non-technical signs that you’ve found the right candidate. Your other team members take you aside and tell you, “We have to hire this lady.” Their personality feels like a great fit for the team. They have relevant and recent experience in what they’ll need to do. You know some people who have worked with them before and they tell you they are wonderful to have on a team (and that they’d hire them again in a second). The candidate is excited about the company and the opportunity and is hungry to start contributing.

If the candidate passes technical muster and all other signs point to “hire,” why wait? If you do, you may lose the candidate to another employer who knows how to read the same signs faster than you can. Instead, be decisive and make the offer fast, thereby telling the candidate how much the company wants them on board. It will help start the whole relationship off on the right foot, for both parties.

So the next time you’ve got a wonderful candidate in your building, don’t assume someone even better will arrive the next day. Make them an offer and get yourself – and the candidate – back to work.

Summary

“I’m a web engineer looking for web engineering work”.
[No link to an online portfolio. No effort to craft the objective to match the position for which they're applying. Typically describes only what the engineer wants to get out of a new position, rather than what she or he will bring to the company that hires them.]

Skills

HTML, DHTML, XML, CSS, JSON, REST, SOAP, AJAX, PHP, CGI, VI, EMACS, …

[A boat-load of technologies, old and new, sprayed onto the resume as one enormous list of acronyms. No effort made to describe which technologies they are expert in versus what they've spent 5 minutes playing with on a boring Saturday afternoon. Alphabet soup.]

Experience

[A lengthy dissertation about every place the candidate has ever worked. Yawn-inducing descriptions of how they worked there. No URLs for me to see the web applications they built.]

…and that’s usually all I get.

Is there a factory somewhere that churns these out on a conveyor belt? Should I blame Microsoft Word’s built-in resume templates? Or perhaps it’s the fault of tech recruiters who encourage this kind of lazy resume format in the name of “consistency”?

There are plenty of great engineers who could use their experience creating awesome web applications to build incredible resumes for themselves but ironically, never do. These programmers work in a world of aesthetics, creativity and technical artistry and yet advertise themselves with the passion of a 40-year accountancy veteran who enjoys working in the windowless basement of a bank and whose favorite color is gray.

So let’s fix that. Here are some tips that will help you rise far above the crowd.

Completely rethink your resume format

Why submit a typical resume at all? Check out these really creative online resumes that were found on Pinterest. This kind of out-of-the-box thinking might not get you anywhere with old-fashioned employers, but I’ll be blunt: a submission along those formats will get you noticed here, and will very likely put you far ahead of the pack with many other employers.

Build an online portfolio

One of the fastest ways for an employer to figure out if they want to interview you is to show them what you’ve already built. Web engineers have a massive advantage over server-side engineers because their work is visible by its very nature, and very often publicly accessible online. If you’re writing a old-fashioned resume, at least list the URLs for your proudest work at the top.

If your work isn’t public (because it’s only available on pay-per-use sites or hidden behind corporate firewalls) then see if you can get screenshots of your web applications in action and submit them along with your job application.

If possible, build a personal website to host your work samples and advertise yourself using the technology you work in every day. I’d be more than happy to receive a set of URLs to personal sites on a daily basis rather than a bunch of 7-page resumes.

Focus more on the “what,” not the “how”

Technology skills are important, but they’re really a means to an end. Employers want to get things done, and the technologies used to build new features and applications simply aren’t as important as the effort itself. So tell us what you’ve built in the past, the impact it had on your customers and business, and why it should matter to us. Then – and only then – tell us what whizz-bang technologies you used to do it.

Prove that you’re a human

If you’re working in the web applications space, you probably have passions in life beyond HTML5 and JavaScript. Do you hike in the hills behind your house every morning at 5am? Did you build a working life-size tractor out of Lego? Are you someone who likes to run marathons for charity while wearing a Darth Vader costume? Then tell us about it. Personality can mean a lot to hiring managers, especially with a position that centers primarily around creative and visual elements.

I’m happy to review any wonderful out-of-the-box resume sent my way and give constructive feedback. Those who follow the suggestions above are more likely to hear the words, “You need to come and work here!”.

Microsoft Outlook is possibly the worst interrupter of all. As the application that receives and manages all of your private email messages, it makes an astonishingly concerted effort to completely ruin that privacy on a regular basis. When you first install Outlook, it enables – by default – one of the worst user interface components ever conceived: the “Desktop Alert“.

From what I can tell, the Outlook Desktop Alert feature was designed to:

• Show the contents of your incoming emails to anyone looking at your screen while you’re giving a presentation, demo or web conference
• Completely interrupt your train of thought and distract you when you’re in the middle of important work
• Turn your email management experience into something more like an instant chat session

Studies show that a single new email notification can break your concentration for more than a minute, but that’s not the most egregious problem caused by this dreadful feature. The real issue is one of privacy.

Let’s imagine that you’re having a very busy week as a manager. It’s a tough time for your company and you’re helping your boss reduce the costs incurred by your team. You also happen to be meeting with one of your employees and going over some documents with him using your laptop, and both of you are reading intently from your screen. That’s when your boss happens to drop you a line:

The next day you visit a customer who is on the verge of signing a deal with your company for a significant product license. You’re in the final stages of negotiation with them and using your computer to show them an Excel spreadsheet with a pricing breakdown when this appears:

You get back to the office to interview a potential new hire. All is going well, and you’ve convinced them that it’s a great place to work. Sadly, while showing them your company’s software product on your laptop, this is what they happen to see:

Dejected and depressed, you hope that your last appointment of the week will cheer you up: you’re due to present your company’s product to a local user group. But just as you start your PowerPoint presentation and begin projecting your slides onto a 10-foot wide screen, your friendly boss sends you another quick email, which everyone in the room can now read:

Of course, Outlook isn’t the only offender. Skype also has a very noisy default, telling me when each of my contacts have crawled out of their beds and opened up their laptops. Every week, more and more applications offer interruption notification services (and Growl on Mac is making it even more common).

If you’re a software developer responsible for creating a communication tool, please consider carefully how noisy you want your features to be. There’s a really good chance that your users would prefer to focus on their task at hand rather than be constantly bombarded with information that doesn’t require immediate action on their part. Just because a user has graciously installed your product doesn’t mean it’s a good idea to interrupt them over and over again.

More importantly, please remember that a computer screen isn’t always a private work area. Until features like the Outlook Desktop Alert are turned off by default, users who want to maintain their privacy are forced to either turn it off or get rid of it completely.

Your hiring process is a classic funnel and the phone screen phase is near the top of it. That means that a ton of resumes will land on your desk (along with a boatload of eager emails and voicemails from your recruiters), and at each stage you will cast aside a very large percentage of them.

We just finished hiring for four engineering positions here at TimeTrade. Here are the metrics we saw at each level of the funnel:

• 120 resume reviews
• 53 one-hour technical phone screens
• 22 four-hour first-round interviews
• 9 four-hour second-round interviews
• 4 actual hires

As any sales or marketing person will tell you, the more you put into the top of a funnel, the more results you’ll get out at the bottom. That’s just as true of recruiting, too. Your challenge therefore is to figure out how to do lots of phone screens without compromising their quality or your sanity. Here’s how.

Schedule Efficiently

The seemingly simple act of setting up the phone screen is usually where you will find your free time disappearing, and fast. As a hiring manager, you almost certainly have a calendar full of existing meetings and commitments, and trying to get dozens of extra appointments with candidates requires a lot of calling, emailing, chasing and waiting. Sometimes the recruiters or candidates will get things wrong and end up double-booking you, causing even more hassles for you to reschedule around the conflicts.

But that’s not everyone’s experience. In fact, it takes me all of 30 seconds to set up an entire two weeks’ worth of phone screens.

It’s not magic that allows me to do that – it’s technology. Instead of me doing all the negotiation and scheduling, I simply use TimeTrade’s online appointment scheduling tool to share my open times for phone screens (for example, 2-4pm every weekday) and it gives me back a single URL that I can email in bulk to all my potential candidates and recruiters. That email might look something like this:

I’d like to phone screen you for the engineering position here at TimeTrade. Please click here to choose one of the available times to speak with me.

- Brian

The product is integrated with my Outlook calendar, so the moment a candidate chooses a slot it drops onto my calendar without any effort on my part (and they can add it to their own calendar too, of course).  I’ll admit I am biased since I work for the company, but I can’t imagine going back to spending hours scheduling appointments the old, manual way I did before.

Be Prepared

Now that you’ve scheduled your phone screens, you need to run them efficiently and learn as much as you can about the applicant’s skills and personality. Unless you’re extremely experienced in this area, you won’t be able to “wing it,” at least not without sounding like you aren’t very prepared. Having a list of potential questions and areas to probe is an absolutely necessity, and it will give you more confidence to run the phone screen properly if you’re new to doing them.

Importantly, you should make sure to have a number of alternative questions available for each area you would like to probe, and use different ones each time. It’s quite common for friends or colleagues to apply for the same position, and they might share their questions to give their buddy a better chance of being brought in for an interview. If nothing else, it can bring a bit of variety to the process that keeps you interested in it when you’ve just completed your 30^th phone screen in 4 weeks.

Code Online

The most important thing to test with a software engineering candidate is their ability to solve problems by writing code. After all, that’s what they’d be doing if they got hired.

Sadly, most phone screeners never tackle this area because they believe they’re limited to questions that can be asked on the phone. That means lots of questions about the details of software (such as, “What class library would you use for socket I/O?”) but almost none that would help you gauge their problem-solving and programming abilities. Of the few people out there who do make people code over the phone, some of their proposed methods (like having the candidate write their code on paper and dictate it back to you) are pretty clunky.

Enter the free and simple online collaboration tool TypeWith.Me. Problem solved.

Right before the phone screen starts, I email the candidate a URL to a new “document” hosted on that site. When they click on it, they’ll see an empty document in their browser, but anything they type in it will be immediately visible to me. In addition, anything I type will show up on their side too. Think “Google Docs without any registration required”, and you’ve got the idea.

I’m able to paste in a few lines of text from my script that outlines each problem I’d like them to solve (reverse a linked list, compute the Nth Fibonacci number, etc.) and sit back and watch them code in real-time. Since they’re also on the phone, we can easily discuss their overall approach or I can interrupt them to tell them to reconsider that if (a = 0) statement they just typed in.

To make sure this whole process works, you need to inform your candidates ahead of time that they’ll be asked to use this kind of tool because they’ll need access to a speakerphone and the Internet. All of these instructions are visible when you click on my TimeTrade URL so each candidate gets to read them before picking their appointment time.

You’d be amazed at how many candidates refuse to even start writing code, indignantly claiming that their years of industrial experience mean that they shouldn’t have to perform these types of tests. By claiming as much they will have self-selected themselves out of the process, and I’m always happy to inform them of that fact.

Sell Something

Always take the time during the call to sell the company, the team culture and your products. Do this even if the candidate is terrible and would never, ever get hired for your team. A phone screen is as much of a marketing and networking opportunity as it is a chance to make the right hire. You never know when your paths will cross again, or what friends your candidate might refer to you.

Running a screen efficiently using the tools and techniques described earlier shows that you and your company are professional about hiring and take your phone screens seriously. Don’t underestimate what this kind of first impression means to a candidate.

Track Your Progress

Now that you know how to schedule and run phone screens properly, the last thing you need to do is figure out how to track the workflow for each candidate as they make their way through the funnel.

I’ve used a variety of tools for this (Excel, Outlook and good ol’ paper) but they all were all lacking in some way. Recently I stumbled upon Trello and discovered that it is a complete – and free – solution for my hiring tracking needs.

Trello finally gives my team and I the ability to track where each candidate is in the hiring process and to move them effortlessly through the funnel. We can also store their resume there and avoid having to email it around all the time, and since it’s an online SaaS tool there’s no chance of some team members seeing stale information.

Technical phone screens are hard to do right, but the tips above should take them from being a sanity-draining chore to become a regular, enjoyable and effective part of your hiring process. You’re welcome.

One of these two things will happen within the hour:

1. Your support line will ring off the hook with angry customers screaming about how none of their applications are working anymore, and how they’re going to wring your neck for breaking their systems at the worst possible time.
2. Everything works great and your customers send you chocolates in gratitude for the new features.

The problems in #1 will occur if your customers do any kind of URI construction in their REST API client applications. That innocuous “revamping” of your URI structure has just broken all the clients who were tightly bound to the exact format and layout of your old URIs.

Imagine an API for an online entertainment company (let’s call them Fun.com) that streams both movies and music. Thankfully, the folks at Fun.com have learned enough about REST that they only guarantee a long life for the top-level URI (https://api.fun.com). That means that well-behaved clients will hard-code just that single entry-point, and will only follow other URIs that are returned to them as part of their normal interactions beyond that point.

In their API documentation, they say that to get a listing of the available movies on their site you must first GET the top-level URI, and then look for the link listed as “Movies” in the returned payload (defined by its media type). They don’t say what that link’s format or value will be, but they are very clear that it’s the one to follow if you want to get the list of movies:

So far, so good!

Now the team at Fun.com decides to branch into lots of diverse markets, so the API designers start to organize the URI structure a little to prepare for the new services. They move both movies and music into their own “entertainment” area and deploy the new API. Thankfully all the well-behaved REST clients are unaffected, because they don’t care about the URI formats at all – they always start at the entry-point and navigate their way around:

Unlucky for the folks at Fun.com, one of their biggest customers used a hacker coder to write their API client, and he broke the URI construction rule. He saw the original URI format and thought to himself, “Why should I waste time always going to the top-level and asking where the movie listings are when I can see the URI for them already? I’m just going to hard-code in the movies URI and that will make the application run way faster!”

Sadly, his application is now completely broken:

He made the mistake of directly coupling his application with the structure of the URIs and ended up breaking his system in the process.

Why is URI construction a common problem?

Encounters with hard-coding hacks like this are not rare, for a number of reasons:

1. Plenty of RESTful API vendors don’t do a good job of discouraging URI construction in their documentation. Typically, they list all the URIs for their resources rather than focus on the media types which will contain them.
2. Sample code and demos aren’t usually provided, leaving clients to figure out for themselves what the “best practices” are for calling their API.
3. URIs have a human-readable, well-understood format and programmers are used to typing them into browser address bars. That leads to an understandable inclination to do the same with RESTful URIs. If clients had to instead deal with MD5 hashes, UUIDs or long hexadecimal numbers, this problem simply wouldn’t exist. Nobody expects a C++ pointer address to be the same every time a process runs, but unfortunately the same understanding isn’t usually applied to RESTful URIs.

What can be done about it?

You can’t prevent URI construction attempts. What you can do, however, is:

• Document the correct usage of your API through its media types rather than its URIs. Explain that URI structure is a convenience that benefits the providers of the service more than the programmers who consume it.
• Provide sample code which demonstrates best practices (and don’t forget that your sample code will likely go into production).
• Talk to your clients and educate them about your API before they build applications with it. REST APIs aren’t magic, and can still be misused.

If coders out there could give URI construction a REST, everyone could rest easy when the APIs evolve. Let’s make it happen.