Interviewing Software Engineers in the 21st Century, the Traditional Way

Anyone who has started a company or worked at an early-stage startup knows it’s a crazy amount of work but also a lot of fun. Perhaps one of the best perks is getting to create your own culture, and as with parenting, you tend to try to do the opposite of what you’ve experienced before.  While you will always pull from your experiences, starting a company gives you the ability to do things your own way from the beginning–or at least try!

When it’s just a couple of you working out of a garage, you don’t have time to think about culture, but as soon as you recruit your first “employee,” your company’s personality kicks in.  As the company grows, your culture becomes a key factor in the recruiting process, and the people you attract are key to defining the kind of company you create. It’s always important to hire the right people at any stage of a company’s development, but early on, it’s absolutely vital.

At Symform, we have been fortunate to successfully attract a certain breed of engineers – the methodical, deep thinkers who possess the “quiet” passion to build something revolutionary and of long-term value that changes the world. One of the reasons for our success has been our recruiting process.  Every candidate who has gone through the process has given us positive feedback, even when we ended up not making them an offer, or when the candidate chose to join another company.  Many have told us that our process is a “refreshing” change.

What we do differently is a reflection of our culture, because we’ve figured out what type of person really “fits” Symform, and we’ve learned that this type of person really shines when participating in an interviewing process that brings out their talents.

Our process is very different from what I experienced for 15 years before starting Symform, when I worked at Microsoft. In the 1990s, as the software company that engineers wanted to work for, Microsoft was regarded as the “gold standard” for interviewing engineers. Most software companies adopted the same process and still use it today.  I made it through this process and had a fairly successful career after completing it, and I used the very same process recruiting engineers while at Microsoft for all those years. But there was something about the interview process that always bothered me, and over the years I became convinced that there was a better way.

What is broken with the traditional interviewing process for engineers?

  • It selects candidates purely on their ability to think on their feet.  While this is not a bad thing, it doesn’t encourage success for engineers who are deep thinkers, and who prefer to think and create in a quiet personal space without having someone breathing down their necks in an interview setting. These types were some of the best engineers I worked with.
  • It expects candidates to write compile-able code from scratch on the whiteboard (I recall being told that I had missed semi-colons on my code!).  I find this process contrived.  Whiteboards are great tools for brainstorming design, algorithms, and data structures, but to actually create a compile-able, testable code, you typically go back to a much more productive tool set.
  • It requires candidates to solve brain teasers or already-solved problems with fairly non-intuitive solutions.  While brain-teasers are great and fun challenges to stew over and push your brain, I’m not sure they are a reliable deal-breaker when someone’s career hangs in the balance.  Most real world problems don’t have black and white answers.  They include design tradeoffs for complexity, performance, scale, and the like.
  • Finally, this process, used for so many years, resulted in the creation of the “Microsoft Interview Question Banks.” Candidates who came in having already studied the answers to the typical “Microsoft Interview Questions” were looked down upon as if they were cheating. In my humble opinion, the popularity of the question banks is not a problem of candidates being deceitful but interviewers being lazy. The interviewer needs to make the effort to identify problems that would enable him or her to do a true evaluation of skills.  Researching and re-using existing implementations should be applauded, as it means that the candidate has done his or her homework, and you want engineers to look at best practices already in existence.

In my next blog, I’ll walk through the process we use at Symform that we’ve found really works!

Posted under Blog, Revolutionary Ideas by
Tagged , , , ,

About Praerit Garg

Praerit Garg is President and Co-founder of Symform. Before founding Symform, Praerit was a Senior Director in Microsoft’s Server and Tools division, where he built and managed the Dynamic Systems Platform and Tools team. Under his leadership, the team grew to over 70 people and drove a broad industry initiative to expand W3C’s XML standards. Praerit also directed the acquisition and integration of a software company developing Group Policy tools. While at Microsoft, he held various engineering leadership positions in the Windows group, ranging from software developer to Group Program Manager for Windows Security. Today, Praerit is a co-inventor on 14 U.S. and international patents and a co-author of IETF RFC 3645, Web Services WS-Trust, and WS-Secure Conversation specifications.
One thought on “Interviewing Software Engineers in the 21st Century, the Traditional Way
  1. Pingback: Interviewing Software Engineers Part II, the Symform Way – Symform

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>