More Than Coding
Because machines still need humans
5 signs that you should hire a programmer on the spot
Posted by on April 30, 2012
Bringing a programmer in for an interview and a coding test can lead to some interesting experiences, both for the interviewer and the interviewee. Most end up with the hiring manager telling them that they’ll “be in touch,” but sometimes a candidate just nails it. That’s when you consider extending a job offer before they get a chance to leave the building.
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.
Like this:
Web engineer looking for work? Start by rethinking your resume.
Posted by on March 2, 2012
We’re currently hiring web engineers to help build the next-generation of TimeTrade’s online scheduling system. Lots of resumes come my way, but 99% of them look exactly the same, following this format:
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!”.
Like this:
When Outlook Attacks
Posted by on January 6, 2012
Most people have had to deal with awful user interfaces at some point. Cluttered, messy applications are everywhere from Windows to Mac, Android to iPhone. There are already plenty of examples online of terrible user interface design, but there is another problem which gets a lot less attention: unwelcome interruptions.
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.
How to phone-screen programmers and not go insane
Posted by on November 2, 2011
Technical phone screens are hard to do right. Yet, they serve an important role. They are the primary filter that ensures you only bring in appropriate candidates to spend valuable hours meeting your team. If you don’t phone-screen correctly, you’ll end up bringing in some real timewasters who don’t even come close to having the technical chops or the personality to make it through your in-person interviews.
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 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 30th 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.
URI construction: give it a REST
Posted by on September 7, 2011
Picture the scene: you’ve just updated your product’s REST API. You’ve added lots of new features, revamped the URI structure and you’re excited for your clients to start using it.
One of these two things will happen within the hour:
- 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.
- 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:
- 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.
- Sample code and demos aren’t usually provided, leaving clients to figure out for themselves what the “best practices” are for calling their API.
- 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.
