Size Matters: Improve Productivity with Cheap Screen Real Estate

It's hard to hire developers, and technical resources are expensive. Everyone is trying to figure out how to attract top talent, reduce turnover, and increase productivity of existing staff without reducing their work/life balance.

Early on, I decided that if you're going to spend 8 hours a day 5 days a week for almost 50 weeks a year doing something, everything about it should be as pleasant as it could be. I bought a new Macbook pro and two thunderbolt displays. Those investments very quickly paid off.

Until recently, the benefits of large technology investments were just intuition. Last week, I realized how much more productive I was working remotely than when I'm onsite with the client. One reason is that when I'm remote I get a lot more flow, but another reason is that when I'm remote, I have a lot more screen real estate so I can see a lot more information at once.

I decided it was time to be more productive onsite too. This time, I wanted to have more concrete justification.

Screen Selection

A friend of mine and I did a fair amount of research picking out monitors that gave us the best bang for our bucks. I'm really happy with my Thunderbolt Displays. They're IPS and they're quite high PPI. This time, I wanted to try something a little cheaper and a little larger and I wanted to try a VA panel so I ended up getting a BenQ BL3200PT. This monitor, I think, has the same panel as the Samsung S32D850T, which has a slightly smaller price tag.

Screen Real Estate

When I talk about screen real estate, I'm not talking about the diagonal size of the screen; I'm talking about the resolution of the screen. Having a larger screen doesn't do anything for you (at least not in the sense of a computer monitor) with regard to how much information you can fit on the screen at one time. The difference between an HD 1080 screen at 27" vs. 32" is just stretching. Resolution, however, is how many pixels the screen has. The more pixels there are, the more options the computer has to present data (provided you have the visual acuity to perceive the data without scaling).

These displays are 2560 x 1440 or WQHD and are the same resolution as my thunderbolt displays, albeit over a larger surface area. Thus the resolution is not quite as crisp as my thunderbolts, but still these are very high quality screens. If you're into lower pixel pitch and higher PPI, I don't blame you. Higher pixel density screens are much more pleasant to look at, but they do come at a cost.

Comparing Resolutions

There are two very common resolutions in offices these days. An older WSXVGA+ which is an 8:5 aspect display at 1680 x 1050 pixels. HD 1080 is also quiet popular which is the 16:9 display at 1920 x 1080. The HD 1080 has about 17.6% more pixels than the WSXVGA+. By comparison, the WQHD, also 16:9, has 2560 x 1440 pixels (sometimes called 1440P). It has about 77.8% more pixels than HD 1080 and about 110% more pixels than WSXGA+. That is to say that if you have 1 WQHD display, you have more pixels than a dual screen WSXGA+ setup.

Benefits of Screen Real Estate

The benefits of additional screen real estate, unfortunately, are easier to experience than they are to describe. Having additional real estate may mean that you will sense more data at the same time, but does not necessarily mean you will perceive these data. Similarly, having the ability see multiple windows does not mean that you won't just continue editing one file at a time in a full screen editor. On the other hand, not having the ability to optimize your workflow guarantees that you will not.

Anecdotes

I do have a few anecdotes that buttress my belief that having more screen real estate is inherently valuable. One time when I'm particularly keen to the benefits of higher resolutions is when I'm developing responsive designs. I'll often dock my browser's DOM inspector on the side and I'll slide the split pane to different responsive breakpoints watching the HTML/CSS changes flash in the inspector. The additional real estate means I can see meaningful data in the DOM inspector and the responsive design at the desktop breakpoint at the same time.

Another time I notice the benefits of having additional screen real estate is when working on native mobile applications. Native development often involves simulators and emulators. Scaling during emulation isn't always well supported. Thus, the additional pixels allows you to see the entire simulator at once.

Another example that I found particularly fascinating happened shortly after I took over a new project. I had been working on the project for a few weeks from the client site. One day, I was working remotely and I had my terminal window off to the left and I had the application in a browser to the right. This is a usual screen configuration for my workflow on my cinema displays. I had changed some code and the application reloaded. When it did, I noticed dozens of queries pop up in the log. None of the ORM queries had been optimized to prevent N + 1 queries. I spent a few hours fixing those, but may never have noticed them had I not had enough room on my screen to comfortably view the browser and the terminal at the same time.

Summary of Benefits

Typically on HD 1080 and especially on WSXGA+, I have only one window visible at a time. That's why I didn't notice the N + 1 queries until I was remote. There may be myriad other benefits of the additional screen real estate when considering looking at code in multiple panes, test driven development, debugging, guard and live reload, etc.

Costs

High quality screens can be expensive! The thunderbolt displays are almost $1,000 each. The BenQ was $550. The Samsung is $500. It's hard to imagine pulling out all of your existing displays and replacing them with displays that cost several hundred dollars. Heck, I spent hours justifying buying only one.

That's why it clicked. At some point I realized, it doesn't take much before the investment in display technology pays off. According to several job posting / salary research sites, the average developer in Atlanta makes about $120K per year. To keep the math easy, I'll call it $100K (also because I like lowballing estimates like this). Normally, overhead on a W-2 employee is roughly 25% - 50% of annual salary. If you have a very modest benefits package (and not a lot of PTO), then an average developer in Atlanta will cost about $125K per year.

Even if your organization buys these screens the same way I did (i.e., no sales tax and no bulk discount), then it'll cost about $550, or about 0.4% of the cost of an average developer. That means that if you bought 100 of them, it would cost less than half of the annual salary of your average developer for a year. Thus, if you have 100 developers and you get 100 screens and each developer is 0.5% more productive for the year, then you actually make money on the investment.

If the cost still seems too high, you don't have to get VA panels. In fact, 32 inch screens are pretty big (they take up a lot of desk real estate too). These 25" Dell U2515H IPS panels were only $350 at the time of writing. 100 of these would be less than 1/3 of the underestimated developer annual cost.

Recuperating Costs

The average American works 1,780 hours per year. To recuperate 0.28% of a developer's cost, the developer only needs to produce about 5 hours more per year. That could be working an additional 5 hours per year because work is more fun. It could be 5 hours saved by not having to tab between windows and the cost of brief context switches. It could be 5 hours not spent tracking down performance issues in production because some N + 1 queries sneaked through.

It could be 5 fewer hours spent recruiting great job candidates because the technology makes the company a better place to work. Developers with neat technology are more inclined to passively as well as actively recruit for you. This can bolster your recruiting efforts, also saving money. Similarly, developers with a satisfying work environment are less likely to leave their jobs reducing the high cost of turnover.

Studies on worker productivity show that American workers tend to have about 6 (and some studies show as few as 3) productive hours in an 8 hour workday. Better screens may improve ideal hours per day. That means if all of your developers show up Monday morning and find their brand new screens, and in their excitement they're productive for 8 hours on Monday and Tuesday (rather than 6) and 7 hours on Wednesday, then in the first 3 days, the screens have paid for themselves. I could be completely wrong about everything else and your net could still be more valuable somewhat liquid (they have good resale values) assets for free.

Remember, you only need 5 additional productive hours per year to cover the cost of 1 high resolution display … and that's if you buy new screens every year. If you plan on keeping the displays for 5 years, it's just 1 hour per year.

Incredulous?

Let's consider a more pessimistic case. Let's say your staff, on average is pretty junior (and you're using technologies that aren't particularly backend heavy. If that's the case, your developers may cost you an average of $80K salary and per year and $20K in benefits, taxes, recruiting efforts, etc. Let's say they also take no vacation or sick leave and thus work a full 2,080 hours per year. Further, your staff is productive 100% of working hours.

In this case, you're paying an average of $48 per productive work hour. If you buy very nice displays at say, $960 each, then you need 20 additional productive hours to cover the cost of one display. Even in this very unlikely case, that's less than 1% per developer. And they don't need to work 2,100 hours in a year per se. They can be 1% more efficient. That means if they're writing 100 lines of perfect code per day, then to cover the cost of a new display, they only need to write 100 lines of perfect code per day (and on the tenth day, perhaps they write 10 extra perfect line of code . . . or better yet, they delete a line or two).

More likely your average developer is closer to $125K per year, they work 1,780 hours per year, and they are productive fewer than 6 of every 8 hours. Thus, their cost is $94 per productive hour. Also, it's very reasonable to get smaller IPS WQHD panels for $350 each (especially if you have a large team and get a bulk or corporate discount). So, you need fewer than 4 hours per developer or 0.3% more productivity. An average developer contributes 10 lines per day to the codebase (Mythical Man Month) so to break even on your investment, your average developer only needs to net an additional 3 lines of code every quarter.

n.b., I don't support using lines of code as a measure of productivity. It's merely illustrative of the relative scale of the cost of a display to the cost of a developer. Try your own calculations using bugs sent to production, mean time to defect resolution, etc.

Recommendation

I recommend making an investment to replace low resolution displays for developers and pairing stations (and I would consider broadening the reach really to non-technical employees as well) with high resolution displays. I think that the cost of the hardware would be recovered very quickly by improved developer efficiency and performance. The investment is low risk because the cost is relatively low and the displays are a moderately liquid asset.

If you have 100 developers on your team, it may be hard to get approval for the capital to buy $35,000 worth of displays. In that case, you can always hire another developer (well, you can try at least) for $35,000 per quarter.

Display Options

Dell P2416D 24 Monitor with QHD 23.8-Inch Screen, Black
Dell UltraSharp U2515H 25-Inch Screen LED-Lit Monitor
Dell UltraSharp U2715H 27-Inch Screen LED-Lit Monitor
BenQ BL3200PT 32-inch WQHD 10-bit USBx4 HDMI Monitor built for Creative Class
Samsung 32" WQHD LED Monitor (S32D850T)

Remote Interview Pairing Challenge with Cloud9

My interview process typically involves just trying to get to know someone to see if we're a good match culturally. After all, if you have a good mind for development, I know you'll be great if we can put you in the right environment with the right culture. As a result, I tend to spend a lot more time talking about what kinds of problems a developer finds interesting, what sorts of roadblocks she finds frustrating, and what technologies we have in common.

There is, however, still the necessary evil of seeing how far along the candidate is on the programming journey. To that end, I usually try to do a very basic code challenge. Normally it's something simple enough that we can still have a healthy conversation while we solve it together as a pair, and it's not so academic as to be useless in real life. Mostly, I just want to pair together to solve a problem.

I give the candidate the opportunity to select the language of her choosing and typically I'll know it well enough that we can pair to solve the problem. I explain the challenge, we set up unit tests, write a failing test, and make it pass. Sometimes, if I don't feel like I know enough, I'll change it a little and we'll try to adapt to the changes together.

This has been such a positive experience for me (and for the candidates I've talked with after their interviews), that I've spent a fair amount of time practicing the process. As I recently discovered, it's such a fundamental part of my interview, that I was completely unprepared when a client asked me, at the last minute, to step into an interview to do a pairing challenge with a candidate . . . who was remote!

Remote Pairing Interview

We tried to come up with a few options for doing the code challenge. After all, our shop pairs pretty much all the time and we try to be supportive of remote work. I mean, we've solved this problem before; however, it's seldom without hiccups. I know that candidates are usually nervous in an interview and I feel a lot of responsibility to help set their minds at ease. To that end, I like to appear calm, collected, and organized.

We considered using tmate and vim. We talked about screen sharing with TeamViewer. We also thought about just letting this candidate work on a harder challenge, maybe something from Hacker Rank or Project Euler, and email us the solution.

Shortcomings

Each of these had a downside. Tmate would give the dev access to my machine and I wanted to let them do whatever they wanted without putting my machine in his hands. Alternatively, his machine could host but I wanted to be able to get to the solution later. Screen sharing with TeamViewer isn't as responsive as I like when pairing, especially if I want to be able to help out rapidly. Also, I type in Dvorak and sometimes that's an issue (turns out he does too . . . by the way). The async challenges, while good, don't let us know if we'll enjoy pairing together.

Enter Cloud9

I remembered, a while back, running across Cloud9 and playing with it a little bit. I thought, "hey, what if we just try this?" Cloud9 would give us a sandbox that we can work in with a full ubuntu virtual machine. The candidate can do whatever he wants to it, we can code, install tools, whatever. I said, "hey, give me a second . . . I'm going to try this Cloud9 thing . . . go ahead and get your account set up and I'll invite you to a project."

In about 5 minutes, the candidate, my co-worker, and I were pairing and running tests on our Cloud9 workspace. There were no security concerns, communication was simple, we still installed and used tmux and vim, we had a sandbox, I was able to save the code. It was a really great experience. Not only did we offer a position to the candidate, but the candidate has been happy on our team ever since. I consider it a sign of a good interview when a candidate takes a position and I think that Cloud9 had a lot to do with this one.

Next Steps

I've not used Cloud9 (or any web based IDEs for that matter) on day to day work. Unfortunately, I'm not really in a position to try it out on the free tier. At some point, I want to go ahead and get a subscription and see how well it works out for me. I certainly see the value of cloud based IDE services and I like the idea that the most expensive development hardware you need is a Chromebook.

Okay, so maybe that's a little hyperbolic, but not for long. We have pairing stations that we treat like cattle rather than pets. We can wipe it completely clean and have it up and running again ready to go in just a few minutes. The hardware isn't commodity, but it could be. In fact, it could just be a web interface to a virtualized instance and why couldn't that be accessed from a Chromebook, pairing station, laptop, tablet, or . . . maybe in a pinch . . . a phone? Personally, I like it and hopefully I'll get a chance to push Cloud9 beyond "hello world."

Elon University has #1 MBA Program

Elon University's part-time MBA program deserves a lot of credit for the success of Autopilot Consulting. Bloomberg Businessweek recently gave the Martha and Spencer Love School of Business (LSB) much deserved recognition.

In The Best Business Schools of 2011, Elon's MBA program was ranked first among competitors like UCLA, Carnegie Mellon, UC-Berkley, and Rice.

When I was looking for an MBA program to attend, I compared Elon's program with Duke University's and UNC's programs and was blown away by the comparative quality of the LSB program; the experience, friendliness, and helpfulness of the staff and faculty; and the extraordinarily low price tag.

Congratulations to the Elon LSB Faculty, Staff, Students, and Alum on a job well done.

Your Field -- How to Land a Job as a Software Engineer

Well. This is it. My last post in the How to Land a Job as a Software Engineer series. I spent a lot of time deciding whether this would be the first post of the series or the last.

I thought about making it the first post because it's really the first step to becoming a software engineer, but I saved it for last because I wanted to make sure I gave these thoughts plenty of time to ripen. If you've been following the series, you probably know how this series came about in the first place.

Emerald Software Group has been interviewing programmers in search of new development talent. I've used a lot of examples (both good and bad) from real life interviews I've conducted in the past few months. This particular story is one of the most important lessons I've learned in my career, so it's really important to me to tell it correctly.

I know that my style and sense of humor can be pretty sardonic and I know that many would be readers find that off-putting, but I will do my best to convey my sincerity in this post.

A few months ago, I interviewed a candidate who had a masters degree in computer science from a relatively prestigious technical university in Georgia. I expected great things from this developer and was excited about the interview.

I went through my standard series of programming questions and was disappointed by his lack of understanding of the technologies he had spent the last 6 years studying. After a while, I started feeling bad for the kid and decided to move on with the interview. After all, like I've said before, just because you don't know the information doesn't mean I'm going to assume you're incapable of learning it.

I decided to ask him a little about himself. I closed my notebook, leaned back in my chair, and asked, "what kinds of things do you program in your spare time?" He said, "I don't really program in my spare time."

I was pretty surprised, so I asked, "Do you read programming blogs or books? How do you learn about new technologies and techniques?"

"I don't really bother learning it until I need it."

I was fundamentally confused. I didn't understand how he had spent 6 years in school studying computer science and was looking to begin a career in the field, but that he neither knew anything about it nor had any interest in learning it. I thought for a minute and I asked him, "Why are you here?"

He said, "I'm looking for a job."

"No, I mean, why do you want to be a programmer?"

"Because it pays well."

"Do you like it?"

"Not really."

I was dumbfounded. I asked him a few more questions so that I didn't have to end the interview abruptly, I told him we'd be in touch, and I walked him to the door. If you want to write software for a living, you need to love it. It's not just a job; it's a craft. If you're not doing it for the love of the field, then you're committing an injustice not only against yourself but also against your employer, your teammates, and the customers.

To be sure, I don't just feel this way about software engineering, but about all careers. Whatever it is you do, do it for the love of your field. If you don't like what you do, let alone love it, you'll be miserable for most of your life and there is no amount of money that will make up for a lifetime of misery.

Now, I know that there are plenty of people out there who would be perfectly happy spending 5 days a week doing something they don't care about so that they can have more fun the other 2 days of the week. You cannot be great at what you do if you don't care enough to try and I will not tolerate mediocrity, especially intentional mediocrity.

So chose your field carefully. Don't get a degree in software engineering if you don't like it. Obviously, don't get two degrees. Think about the things that you love to do. What would you like spending your weekends doing? Take those things and find a way to make money doing them. If you make your living doing what you love, you'll always love what you do, you'll always be proud of your work, and you'll be in the top of your field.

Your Communication Skills -- How to Land a Job as a Software Engineer

At long last (due to some intense deadlines), I'm getting around to the fourth installment of the How to Land a Job as a Software Engineer series. This concludes the job application sequence starting with your resume and ending with your interview.

This post is about maintaining good communication skills throughout the process. A very close friend of mine named Ryan LaFevre, who is a Ramblin' Wreck from Georgia Tech and a hell of an engineer, once mused to me, "I don't write good; I are a engineer." Obviously said in jest, I bring that up because I know a lot of programmers who feel like even a cursory grasp of language arts is completely unnecessary for anybody in a technical field. My former English teachers would probably be pleased to see me say that communication skills are of fundamental importance.

Do you ever watch those court room shows? If so, you've probably seen scenes where one attorney makes a damning argument or the witness breaks down in an emotional display, at which point the other attorney objects. The judge says, "sustained" and instructs the jury to ignore the preceding outburst and has the text stricken from the record. Now, imagine being on that jury. Could you possibly ignore that? Even if you don't make your verdict based on said event, could you possibly remain unbiased by it?

It's the same thing with your communication (both verbal and non-verbal). While I'd rather claim that I focus primarily on the skills you actually need to do your job, and while I can ignore your communication inefficiencies, I cannot ignore the feelings I had when I communicated with you.

For example, I'm not going to refuse to hire a candidate just because he's 25 years old and still can't discern the difference between they're, there, and their; however, there's a pretty good chance I will assume she's not all that bright. Thus, when I sit down with the resumes and my notes from my three favorite candidates to compare them side by side for selection, ceteris paribus, he'll get eliminated first because I won't feel like he has as much potential as the other candidates.

Here are some actual excerpts I've received from job hopefuls:

Hello Mr. Caldwell, I just wanted to touch base with you to see how your doing.

What about my doing? You leave my doing out of this and I won't say anything about your dumb.

The sample project I sent you is very simple on the front end, but it's back end is where all the magic happens.

I just read your email and its dumb is showing; it is back end is where you are not getting a job. Thanks.

I know what you mean about taking your work home with you. I've spent a lot of time with my computer in my underwear coding until the middle of the night.

First of all, gross. Second of all, your computer codes by itself? Third of all, what was your computer doing in your underwear?!?!?

Thank you very much for meeting with me today -- I really enjoyed talking with you -- If there's anything else that you need from me, please feel free to ask for it -- I'm available by phone most of the day and I'll get back to you as soon as possible

WTF? The period exists for a reason; please use it. If, by some chance, your period key is broken and you can't find a working keyboard with which to send your email, please hold alt and hit 0046 in lieu of the double hyphen.

i'll be available tuesday afternoon around 1:30 or so. is there anything i need to bring to the interview other than my resume? i'm really excited about the opportunity and i think emerald software group will be a great fit for me

i hate you (alt + 0046)

Also, sometimes it's not what you say, but how you say it (or, how often). Don't nag me please. I will get back to you; I promise. If you email me every day asking about the status of the job, on your third try (or second if I'm in a bad mood), I will simply let you know that you have been selected out of the applicant pool.

Written communication isn't the only place you can make silly mistakes. Oral communication is replete with its own difficulties. Sure, you less often misspell things orally than you do in written communication, but there are some things you're unlikely to get away with. For example, I really don't want to hear your stance on the adult entertainment industry, I don't want to hear a story about a time you were drunk, and I really don't want to know what crimes you've gotten away with. Keep it on a professional footing — please!

Here are some other hints for oral communication:

• Don't swear a lot; I'll just think you've insufficient vocabulary.
• Don't tell me a dirty joke you heard a few days ago. Let's get to know each other a little first
• Don't opine on politics or religion. Chances are you won't offend me, but on the other hand, chances are I know someone at the office you would offend.
• Don't tell me my school sucks. For that matter, don't tell me any school sucks. I don't care if you're just kidding and I don't care if you went to a rival school. If you say something disparaging about any school, I'm either going to think you weren't smart enough to get in or you're pompous. Either way, I don't want you on my team because I may later want to hire someone from that school.

Finally, it is worth mentioning that not all communication is verbal. There are plenty of ways you can non-verbally tell me you're not ready for the position in question. For example, don't be late. Don't smell bad. Don't wear your favorite pair of tattered jeans and raggedy flip-flops. Don't be over-confident. Don't be under-confident.

By all means, be yourself and try to have some fun. If you have fun, people are more likely to enjoy talking with you. If you have fun, the worst that can happen is you have a good time, meet some good folks, and learn some new skills.

Your Interview -- How to Land a Job as a Software Engineer

This is the third installment of the How to Land a Job as a Software Engineer series. Now that you've submitted your resume and completed your prescreening, you've been called in to interview.

It's a pretty safe bet that you'll have several interviews to go through including talking to someone in HR, some management folks, and some technical people too. I do the technical interview around here and there are some things I've noticed interviewees do that consistently irk me. Here are things you shouldn't do on a job interview (in no particular order):

• Don't tell me you don't need to answer my question. I've actually had several interviewees tell me that they don't need to answer my question because it's obvious that they know the answer. If I've asked you the question, it's because I want to know how you're going to answer it. Especially if it's obvious you have no idea WTF you're talking about.
• Don't bother going if you embellished on your resume or cheated on your prescreener. If you tell me you're a 7 out of 10 with SQL and you can't tell me the difference between an inner join and a left join, I'm not going to hire you. If you tell me you're a 3 out of 10, then you have a fighting chance.
• Don't ramble. I've only got so much time to talk with you. Most of the time, I enjoy interviewing and I enjoy the conversation, but I really do need to get back to work. Just answer the question I asked and move on.
  
  Also, as a side note, when I was in graduate school, we talked a lot about interview techniques. The business oriented interviewers are likely to ask you questions like, "What's your biggest shortcoming?" or "Tell me about a time you had a conflict with a co-worker." These are cheesy questions and you're going to have a canned response, so you probably wonder why they even bother asking the question. Keep in mind that these folks have a lot of experience interviewing . . . much more than you do most likely. They ask the question because if you have a canned response, they can catch you off guard.
  
  Here's the technique. I ask you a question, you give me the canned response, and I just look at you waiting for you to say more. In only seconds, the silence becomes deafening and you start talking again. Now, you're out of your comfort zone and you start telling the truth. The more I nod and keep my mouth shut, the more you confess. Moral of the story? Don't ramble. Just answer the question and then STFU.
• Don't make things up. If you can't answer the question and you can't make an educated guess, don't just make something up assuming I won't know. I very seldom ask questions in an interview that I don't already know the answer to. If you make something up so that you don't have to say, "I don't know," I can almost guarantee that I'm going to know you're full of it.
• Don't say you don't know the answer to a question unless you're absolutely sure you know nothing about the topic. Most of the time, I'm trying to figure out where you are in your professional journey. I don't expect you to know everything. Chances are, if you can give me a starting point, I'll prompt you until you get the answer. I just want to get a feel for how well you understand programming concepts. If you simply say, "I don't know" then I have nowhere to start and you don't get partial credit.
  
  For example, if I ask you the difference between an interface and an abstract class, and you say, "I have no idea" then I have to operate under the assumption that you indeed have no idea. If you say, "well, I know they both define contracts for classes" then instantly you have partial credit. Then I'll ask you, "why would you use them?" You say something remotely intelligent about why you'd want to do this and you have even more partial credit. I'll keep asking you questions until I'm convinced that I've given you as much credit as you can possibly get.
  
  By the way, this doesn't contradict the previous item. If you make something up and present it like it's fact, I'll assume that you're making things up. If you look at me and say, "you know, I'm not sure, but it sounds like . . . " and then you make your best inference drown from past experience . . . even if you're way out in left field, you still get partial credit.

Your Prescreening -- How to Land a Job as a Software Engineer

My How to Land a Job as a Software Engineer series has me inspired and this is the third post I've written today. If you've ever applied for a technical position, you've probably met the prescreening questionnaire before. For software engineers, it generally comprises a set of questions about the language you'll be using and a few puzzles or programming tasks.

My company has something of a prescreening questionnaire and we're working on a more robust one. I've done them in the past and I have several friends who have done them for the companies they work for now. It's a common tool to assess your goodness of fit with the requirements of the position being filled.

So, you get the email from the HR department that says, "Thank you for your resume. You've been selected to move to the next stage of the process. Please complete this prescreening questionnaire and return it. You have one week from today." Sometimes the questionnaire will be online in quiz form and other times it'll just be a list of problems. Sometimes you're allowed to use the internet to help you and other times they ask you not to. In any case, my suggestion to you is to follow whatever rules they give you. Don't cheat! In my post about what hiring managers are looking for in a resume I kind of harped on the whole honesty thing.

Well, I'm about to do it again. Some people have their friends help them with the test or the coding problems or they Google when they were asked not to. Sure, this may help you get the job, but you are setting yourself up for failure. If you cheat on the test, they're going to find out when you go in for the technical interview. If they don't find out in the technical interview, they're going to find out that you're ill qualified once you start working. In any case, you're just gonna disappoint them and there's very little good that can come of it.

Work the problems and do it with integrity. If you don't get the interview or you don't get the job, it's for the best; that job was not for you and you're now better prepared to move on. After you submit your results, study the questionnaire. Learn everything you didn't already know. Then, learn more about what you know. Next time you have a prescreening task, you'll actually know the information you need. When you do get called into that interview, you're going to impress them with your knowledge and capability instead of disappointing them.

Your Resume -- How to Land a Job as a Software Engineer

This is the first post of a series I call How to Land a Job as a Software Engineer. I chose this as the first post because it's really the first step in the process; however, I do not think it's the most important step because I believe that accolade belongs to selecting the right field in the first place. Also, from your perspective, finding a job to which to apply is the first step; however, I'm writing this series from the perspective of the person who makes the ultimate decision about who is and who is not worth hiring.

That being said, your resume has to be your foot in the door. Let's say that for a given job opening, we receive 100 resumes. At least half of those will be screened out before they even get to me. I'll eliminate at least half of the remaining resumes before we start inviting people to interview.

I've worked with resumes from every angle I can think of. I studied job applications and resumes when I was getting my MBA, I've been a job applicant, and I've reviewed dozens of resumes of job hopefuls. In graduate school, I read chapter after chapter about how a good resume is structured. As a job applicant, I perused every online resource I could find for hints and tricks. As a hiring manager, I can tell you what makes a difference to me.

But, before I get to my tips and tricks, I think it is worth pointing out what happens when a job opportunity opens up. First, the organization has identified a need. Second, the organization publishes that need. Third, many people apply. Fourth, one person is selected.

When you apply for the job, you feel like the organization is trying to hire the best candidate; well, they're not. Don't worry though because they think they're trying to hire the best candidate too; but they're not. In reality, they're trying to eliminate the worst candidates from each phase until there's only one left. I know it's something of a pedantic distinction, but it is important.

Why? Well, when I start looking at resumes, I'm not looking for reasons to hire someone. I assume that if you've sent me your resume, you feel like you'd be right for the job and that the job will be right for you. Therefore, when I look at your resume, I'm looking for reasons you're wrong. I'm trying to eliminate you because I don't want to waste your time and mine by having you in for an interview if I can tell it won't work out.

Sure, there have been times that something really stood out on a resume. Usually, it's a bad thing, but sometimes it's a really good thing. Just, keep in mind that things that stand out don't always stand out in a good way. So, in all forthrightness (and at the risk of seeming petty), here are some of the things that I find to eliminate you from the applicant pool:

• I don't want to read your 5 page resume. In fact, I won't read your 5 page resume. I'll look at the first half of the first page and the last half of the last page. If you cured cancer in the middle of your career, chances are pretty good I'll never even know about it. If there's something you want me to know, put it in those sections. Even better, keep the whole thing succinct so that I don't think you're verbose.
• Don't have grammatical or spelling errors in your resume. Ultimately, you're talking about a two page report about a topic you're the only living expert in -- you. If you're writing a doctoral dissertation about a topic you previously knew very little about and a few grammatical or spelling errors slip into the first draft, it's one thing. It's another thing altogether to write a two page paper about what you've been doing for the last 10 years and to make grammatical or spelling mistakes in your final copy. What does that say about your attention to detail?
• Be factual; don't be boastful. I don't care if you think you're a great communicator or if you think you're an excellent problem solver with 12 years of experience leading successful teams. I just want to know how long you've been at it and what you've done. I'll figure out on my own if you're a great communicator or an excellent problem solver. Besides, how do I know that your definition of a "successful team" isn't one where no more than half of the team quit and 10% of your projects were on time and on budget? In fact, if you put this in your resume, I'm going to tailor your interview to prove you wrong.
• Tell the truth! I mean, seriously . . . in the name of all things holy and good, don't lie on your resume. If you tell me you have 10 years of programming experience but you really only have 5, I'm probably going to figure it out. As soon as I figure it out, I'm just going to tell you to leave. I'm not kidding; end of the interview. If you tell me you have 5 years of experience and I need a 10 year programmer, you didn't want the job anyway because you're probably not ready yet; however, I'll think, "man, that person was honest and I'm gonna save that resume for the next junior opportunity."
  
  Most of the time, I just need a programmer of any sort. So, if I'm just looking for a programmer and you say, "I have 5 years of programming experience," and I can tell that you're being honest, I may still hire you; I just won't pay you as much. So, just be honest. If you're honest, the worst that can happen is you don't get the job and everybody's happy (or at least at worst mildly disappointed). If you lie, the worst that can happen is you take a new job, everybody suffers, and you get the ax after your 90 day interim.

Now, here are some positive things I look for in a resume:

• I actually do care what your hobbies are. I'm not going to hire you based on your hobbies, but if you're up against someone who is exactly equal to you in every way except that your hobbies are cooler, more relevant to the field, or are similar to my own then I'm more likely to hire you. In fact, I once invited someone in for an interview because I wanted to know more about his hobby. Came to find out that he was a very capable engineer, but was just a little too expensive for us. If I had the money, I'd have hired him on the spot.
  
  It also makes you a real person. I look at a lot of resumes and none of them are real people, but if I know you're into underwater basket weaving, then I'm likely to remember you. In fact, I don't even look at the names on resumes. I just look at the resumes, chose the ones who seem capable, and hand them to my boss saying, "call these in please." If I see that you're into underwater basket weaving, I'll be like, "heh, what's this person's name?"
  
  So, unless your hobby is rolling your poop into little balls, then go ahead and include a hobbies section on your resume. (Not that there's anything wrong with rolling your poop into little balls; I just don't want you touching company equipment.)
• I want to see that you stick with jobs for a long time. While I know that contractors will have a lot of short term projects and few long term employments, I really like it if you consolidate your contract work into one item on your resume. Then, you can list the contracts you've worked on under that line item rather than listing each contract as though it was one job. It helps me rapidly review your work history. If nothing else, at least specify that the position was a contract position or I'm going to assume that you can't keep a job longer than a 9 months.
• Apply for a job that's appropriate to your experience. If you've been programming for 10 years and still consider yourself a junior developer, I'm probably not going to call you back. I know that in most cases, one of two things will be true. Either you're not progressing at your craft and thus aren't worth the investment or you're better than the job you're applying for and you're just going to quit as soon as another opportunity comes up and then you're not worth the investment either. If you should be a senior developer, be a senior developer.

How to Land a Job as a Software Engineer

My company is hiring again. It's a bittersweet process for me because I love meeting new people and getting new perspectives (and God knows we need the manpower -- er, person-power); however, it is a very frustrating process to endure parsing all of the resumes, selecting the first round for interviews, interviewing, rejecting, being left empty handed.

I started working with Emerald Software Group about three and a half years ago, and have been responsible for evaluating the technical capabilities of our job applicants for the last several years. Sitting on the other side of the table has given me some insight that I'd like to share with job seekers (especially, my fellow software engineers in need of gainful employment).

This is actually the first post in a series of posts about landing the perfect job for you. Nota bene, I didn't say "landing your dream job." I said, "landing the perfect job for you," because your dream job may not be the perfect job for you. For example, my dream job is to drive a Hog for the USAF, but alas the perfect job for me is as a software engineer. I just wanted to make this distinction now because the topic is going to come up again (and again).

Your Resume

I'll be starting with a post about resumes. After all, a majority of our applicants are eliminated before I even see their resumes. Then, I eliminate a majority of the remaining candidates before we invite anyone to interview. I know there are thousands of blog posts out there about resumes, but I want to be completely frank about it. Learn more about what a hiring manager looks for in a resume.

Your Prescreening

Next, I'll discuss the prescreening process. For those of you who don't work in a technical field, you'll probably find this a little foreign. A lot of technical industries have developed prescreening processes to establish your technical capability before you ever set foot in the building. For software engineers, these tend to be basic framework / language questions and some cute and clever programming tasks. I will give you hints to get the most out of your experience with the prescreening questionnaire.

Your Interview

Here's a great place to make an impression (or a great place to really screw it up). A good interview is a precipice. Keep in mind that your interviewer is not looking for a reason to include you in the next round of interviews; your interviewer is looking for reasons to exclude you. The ultimate goal is to eliminate all but one applicant and you want to make sure that it will be you if it should be. Here's how you make sure your job interview goes well.

Your Communication Skills

Communication skills are important even in technical fields. The way that you communicate says a lot about what kind of employee you'll be. People want to know that they'll be able to understand you, that they'll enjoy working with you, and that you'll bring something to the table. We can tell a lot about a candidate by the way they communicate with us. Learn how to communicate effectively and land your software engineering job.

Your Field

I thought long and hard about whether this should be the first post or the last post on the "How to Land a Job as a Software Engineer" topic. It's really the first step, but I've been saving it for last because I have a lot to say about this. I love writing software; if you don't, it'll show. In the post about selecting a field, I'll discuss what we look for when we interview job hopefuls. Selecting the right field for you is the only way to ensure that your perfect job is, in fact, your dream job.