It upsets me greatly, since there is no immediate or obvious solution to an interviewing scheme which will fit every company. Some companies seem to find processes which work for their size and culture, while others struggle to do so. Human resources management is a complex subject, and it’s hard to get right.

I have experience with only a small subset of interviewing techniques, but none of the following interview components I employ seem satisfactory.

Screening

Screenings are usually done by recruiters, employees whose skills are in seeking and evaluating prospective assets to the company. The first problem here is that recruiters are not team members. Recruiters might do a really good job at, say, finding good recruiters - since this is their domain, and something they are inherently good at. But they don’t develop software. Recruiters don’t work with tech leads and team members, they don’t have the slightest real life idea what managers and leaders want from the potential hire. Hell, the problem is - most team leads don’t even know what kind of person they need. And if they do, they don’t have a slightest idea on how to communicate this properly to the recruiters.

In an ideal world, software engineers and team leads would do recruiting themselves. But this way they would not have time to do their own job, and would thus become recruiters. Boom, the company lost a good software engineer. So you end up hiring recruiters, who have not the slightest idea what a team needs (“person has to be proficient in Blah-blah-blah” is like saying that a writer has to be an expert at writing about red cubes).

Is there a solution? Probably, maybe, I don’t know. Maybe recruiters and software engineers have to communicate more. Set up meetings to discuss team needs, go through training in regards to identifying key traits in prospective engineers. Teams of engineers have to communicate their preferences better. Engineers are hired to fit the culture, not to be a “rock star”. Geniuses don’t go through the HR process, future team members do.

Interview with another engineer

This, even though it has a good intent, is a big whopping failure. What this originally is meant to do - is have a potential colleague evaluate the candidate. Sounds like a fantastic idea in theory, and sometimes it even works the way it is intended to.

Most of the time, however, you end up with a competition-driven technological fanatic bombarding an interviewee with smart-ass obscure trick questions they discovered that one time browsing their favorite language’s mailing lists from the year 1990. In the worst-case scenario, the candidate is not able to answer any of those terrible questions, satisfying the interviewer’s ego while she cranks out a negative report to a recruiter.

In a slightly better version, an engineer will give a candidate a set of hands-on tasks which rarely have anything to do with the real job responsibilities. One version of this: pair programming segment, on the engineer’s machine, under stress and with shaking hands. Are we hiring contestants for a hackathon?

When it comes to software engineering, everyone suddenly forgets that writing code is the smallest portion of the day. This might not be the case for junior programmers, but they are not the ones companies are wasting their hiring resources on. It’s the mid-level and senior workers who weren’t even evaluated on half of their job responsibilities. How are their human interaction skills? Are they pleasant to work with? Will they have issues with company policies? Will they fit? These questions are as important as one’s ability to put together a few lines of code.

Maybe interviewers have to spend less time checking how well candidates write code under pressure, and more time evaluating if they will be a good match for the company’s culture. How do they react when you point out their mistake? Can they communicate concepts clearly? Are they good at marketing themselves? You hire people, not code generating machines. Unless that’s what you need, of course.

Home assignments

Home assignments are something I personally like and despise and the same time. And I find it sad that there are a number of big fat minuses with this approach. First, one might find it insulting. “What, I have to write code for you in my own time? Couldn’t you evaluate me on an interview or something?” This method can turn a lot of people off, and unfortunately the ones that stay are not typically the best quality.

As my co-worker wisely pointed out, if you have a choice between two overall equal companies and one requires you to do more work before being considered - you will naturally pick one that accepts you easier. Any job seeker would feel more appreciated and trusted taking that route.

The honesty factor doesn’t play much role here, since you usually can tell if the person did not write everything herself during the one-on-one followup. But the cost does play a role. The interviewer has to come up with a relatively unique assignment, spend time reading and evaluating the written program, give feedback on a follow-up interview. This adds up if you have many candidates.

This technique does make sense when the list of candidates needs to be narrowed down, or when you’re at the top of your domain. Who wouldn’t complete a day-long homework for Google? Many people will happily spend a sleepless night for an employment opportunity. Even more wouldn’t, especially if someone has a number of options lined up in front of them.

What about other methods?

There is a large number of various interviewing techniques out there. Some companies combine the above specified methods to have a bare-bone hiring template. Some make candidates do paid work for a few weeks before being accepted as a new hire. Some don’t bother and just decide to wing it.

This is still a developing area; I am afraid the solution has to be obtained through the method of trial and error. There seems to be no success recipe which works for everyone. There are, however, a number of alternative solutions. I don’t think most companies put enough resources in finding a successful technique, instead opting for whatever method is in season at the moment.

You might wonder what an English language style guide from 1918 is doing in a software engineering blog. You might even get angry at me for pointing this book in your face. But I have a strong affection towards this guide; I believe everyone who has to write more than a sentence in English should read it. I like to emphasize the communication aspects of a software engineering career as much as coding or management skills.

English is not my native language, and I often struggle with the writing style. I found a number of style tips online and in the books I read, but lately I noticed a pattern: most of those tips referenced “The Elements Of Style”. The book is available online free of charge (copyright has expired; it is now in public domain) and takes only an evening to read.

What the book gives you is invaluable writing advice. The author provides concrete style rules targeted at increasing the appeal and comprehension rates of your text. Here’s my favorite piece of advice:

13. Omit needless words.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that he make every word tell.

“The Elements Of Style” is a timeless classic; it should be mandatory reading for every speaker or learner of English out there. I immediately applied the rules to technical documentation, email communication, and even this very blog entry. I will probably have to read through the guide multiple times over the course of the following months in order to ensure maximum retention. If you care about being understood by another human being, you should read it too.

Recently, I’ve been trying to read at least one book every week, and this week’s pick was “Expert Python Programming” by Tarek Ziade. Besides its few shortcomings, I found it to be useful - Python is a language of choice for me, and I found some valuable tips I could add to my arsenal.

The best thing about this book is that it covers a very wide range of topics: syntax recommendations and code profiling, testing practices and project management, technical writing and design patterns, package distribution and version control… My favorite chapter covered writing technical documentation: I am very interested in writing in general, and the tips Ziade provided turned out to be very useful for documenting code, writing design documents, and even posting to this blog. Not much else caught my eye, but I had a number of “Aha!” moments such as, “Oh, I never used that!” and “That’s an interesting topic to look into!” scattered throughout the book. This book is very useful for filling in little gaps in knowledge which programmers can have: the author covers an extremely wide variety of Python development aspects.

Unfortunately, I found the book to be poorly written. Weak writing style, typos in the text and code examples - it looked like the book was put together sloppily, in haste. Reviewers did not do a very good job evaluating this book. “Expert Python Programming” gives you the feeling that the author tried to fit in as much content (and code) as possible in his book, with no consistent style. Many chapters go into unnecessary details, and the author has tendency to paste completely useless chunks of code, such as a page-long output of an installer. As I have mentioned, the book hops from one topic to another, and covers a wide variety of subjects: this is both a key strength and the biggest weakness of the book. There is just “too much stuff” and it’s too scattered across the topics.

“Expert Python Programming” will be of best use to, you guessed it, an expert. I found it best to scan through the content and seek out interesting bits of information. Beginners, however, might be completely overwhelmed. While advanced and intermediate Pythonistas will get the most out of this book, it will probably be too hard (and painful) to read to be of real value.

Today I received in the mail a copy of Steve Krug’s “Don’t Make Me Think, Revisited: A Common Sense Approach To Web And Mobile Usability” (oh, that’s a long name). I went through the whole book only in under a few hours, and I am so glad I’ve read it. It’s a very quick read, but the book is full of concrete and valuable tips and advice about usability.

“Don’t Make Me Think” contains practical advice on a large number of topics: web and mobile usability, design, and writing for the web. The advice can be easily used and incorporated into your daily workflow; and the author provides concrete guidelines for applying his tips in the real world.

The biggest thing I’ve learned from this book (and want to apply in practice) is individual usability testing. I actually performed my first usability test just three days ago, just before reading “Don’t Make Me Think”, after I found that Donald Norman’s masterpiece mentioned observing user interactions with your product (I’ll get to the similarities between two of these books in a moment).

I asked two of my colleagues, one after another, to visit a website I was working on, and I silently watched them navigate through it. They had never seen the website before, and the results were very shocking to me: they ignored the things most obvious to me, but attempted to click through things which are not even meant to be clicked. I carefully wrote down all of my findings, and delivered the patches with enhancements to improve the biggest areas of struggle these particular users had faced.

Usability testing turned out to be invaluable: it pointed out actions that I, as a developer, did not anticipate, and highlighted parts of the system ignored by the users. I now plan to run usability tests regularly, grabbing colleagues from the hallway, and asking them to use my application for a few minutes.

Steve Krug’s book is very much like “The Design Of Everyday Things”, but stripped from the extended theoretical part. The book references Norman’s work quite a lot, and seems to be heavily influenced by it. It focuses on practical aspects of designing easy to use and understandable user interfaces. It successfully explains why you should be thoughtful of user experience, accessibility, and understanding the way users think. I would recommend reading this book after reading Donald Norman’s masterpiece first, since it provides you with the reasoning behind many decisions Steve Krug makes throughout his book.

Unfortunately, I have not been reading as much as I would love to lately. In the past year I have only read two books, one of which was a technical manual. Don’t get me wrong, I still had a lot of personal and professional growth going on: reading blogs, articles, guides, watching keynote talks… But I did miss the feeling of holding a good book in my hands, turning the pages with the tips of my fingers, seeing the texture of the paper under the print. A few weeks ago I went ahead and ordered one of the books on my reading list: “The Design of Everyday Things” by Donald A. Norman. I just finished reading it a few hours ago and am eager to share my impressions of the book.

“The Design of Everyday Things” turned out to be one of the most eye-opening books about design I have ever read (alright, alright, I haven’t read any design books before). It’s mind blowing to think that I have never considered the points brought up by the authors. Hell, (and I will probably have rotten tomatoes thrown at me for this statement) but I didn’t even think design was a “real” job. Oh dear, how wrong I was.

Norman’s masterpiece talks about the psychology of everyday things (which was actually the initial title of the book, but was changed to “Design” after the first release). The author explains how users make decisions, use objects, make errors - and so many other factors which should go into the design process. Norman explains fundamental basics of the psychology of human-object interaction, something most people never think about. How hard could it be to design a door? Turns out the answer is - very hard. And every time you see someone pulling the door instead of pushing and vice versa - it’s a result of a poor design. So many everyday frustrations could have been avoided if designers would have put more thought into usability of their product.

I build software for living, and I was skeptical if I even needed to know anything about good design. I mean, how hard could it be to put together a few pages and forms? “I tackle complex software problems, I don’t need any of this liberal arts bullshit!” - I thought that way, and I know many people who still do. Well, Norman’s book is a great starter for people like me: he does a great job explaining why the design process so important. By the time I finished reading it, I had a pretty solid set of ideas why there are so many things wrong with our industry, and how good, thoughtful design is a way out. The funniest part is - the book itself is published in the year 1988, over twenty-five years ago. It doesn’t talk much about computers, concentrating on objects more common at the time: cars, telephone systems, even stoves and dish washing machines. And here I am, reading this book in the year 2014 - and the situation did not change at all. Expensive laundry machines are as hard to operate, computer programs are as clunky.

“The Design of Everyday Things” compels the reader to become a part of the solution to this enormous and bulky design problem the world is stuck with. In the everyday world, for every good case of design out there, you will face a hundred faulty, frustrating, and downright insulting design attempts.

The book is very easy and pleasant to read, and I went through it in under a week. Most of it is a set of rants about poor design decisions, with suggested improvements and solutions. Throughout the reading process, I had to revisit the systems I built at work and rearrange the components, add more feedback to user’s actions, and do many other little and big improvements in order to make make the system image much more transparent to the user. Norman taught me the most obvious truth: a designer is not your typical user of the system. This changes so many things, makes you doubt and rethink a number of design decisions you made along the way - all in order to build a product that is easy and pleasant to use.

I now consider myself to be blessed with an understanding of the importance of good design, and admitting there is a problem is the first step to fixing it. And believe me, there is a problem. I will now continue learning about the best practices in building systems that are easy to understand and pleasant to operate for the user. My next stop is “Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability” by Steve Krug. I’ve heard a lot about this book, and I will be sure to share my impressions here.