Interviewers who … do not know how ask code questions

This is a first article in the series of “Interviewers Who / Recruiters Who” articles that will include random rants on past experiences during interviews or conversations with recruiters. These rants inspired by Ian Douglas’s Headhunters … who posts I enjoyed reading.

One of the common exercises during an interview is writing code. It is often the difference between hire/no-hire vote and is a good way to avoid the Hotscripts.com copy-pasta crowd. Here are a few amusing stories of what not to do when asking a candidate to write code. At the end of article I included some tips on how to make such exercise a worth while experience for both the interviewer and the candidate. And now, the funny stories …

Interviewers who verbally ask you to write code on paper … with a pen and leave the room

Importance of proper tools for a developer can not be understated. Here is a list of such tools sorted by priority, mine: great chair, good sharp monitors (at least 2), whiteboard, debugger, test runner, document generator, IRC, google. Caffeinated drinks are not on this list cause they lives in a category of its own. Going down this list and applying it to the interview setting you’ll see that whiteboard would end up number one since you won’t really need a chair or dual monitors during an interview. Whiteboards to this day remain the best tool to work out details of the idea and communicate it to another person. Here is what happens when you do not have it …

One interview I had was in a completely new space the company just rented. I was asked a fairly easy, but twisted question on how to parse log files. The question included a few quirks such as line skipping entries, special characters and what not. It was also hinted that the log format might change. What was I given to solve this? One piece of paper (thankfully double sided) and a pen.

I do not know about you, but when I write code I continuously re-arrange and tweak code blocks. I also write it in multiple passes. First pass is the base functionality, then come the refactors, then the clean ups and finallt chopping it up into multiple functions that could be more easily unittested and documented. And not necessarily in that order and not just once.

There was zero chance of me doing that on paper and and showing my skill. During my first pass I scribbled and crossed things out on paper until when I could not read them anymore. On top of that I had questions for the interviewer about how many assumptions should I make, such as, “hey are you processing a few megabytes or a few terabytes, so do I worry about memory?”. After 10 minutes I ran out of writing space, had to step out and find locate the interviewer and convince him to lend me his laptop. I also had difficulty keeping him in the room for at least 5 minutes so I can ask a few clarifying questions. By that time, however, I already knew I would not be working there. I guess bringing my own laptop should might have helped … maybe.

Interviewers who ask the for the same code over and over

Another important thing to do when interviewing is to keep track of who is going to ask what and how. For one it lets you cover a much larger ground. Keeping a list of questions asked and passing it on to the next person with some notes assists them in a quick start. It also helps you avoid looking like you are not prepared. Such list would have certainly helped another company I interviewed with. Here is how the interview went.

Guy #1 comes in, says hi, asks me how I am, and immediately throws me a question on how to create a set of elements on a page. I wrote the following on the board and it turned out to be the answer what he is looking for.

var i, div;
for (i=0; i < 10; i++) {
    div = document.createElement('div');
    div.innerHTML = 'Element #' + i;
    document.getElementsByTagName('body')[0].appendChild(div)
}

After a few more questions on getElementById and the board gets cleared and I am told to wait for next person.

Guy #2 comes in, says hi, asks me how I am and immediately throws me a question on how to create a set of elements on a page. I rewrote the above on the board and it again it turned out to be the answer what he is looking for. I mention that I have been asked before. After a few more questions on getElementById and the board gets cleared and I am told to wait for next person.

Guy #3 comes in, says hi, asks me how I am and immediately throws me a question on how to create a set of elements on a page. Again I mention that I have been asked before but do it one more time. After a few more questions on getElementById I am told to wait for next person.

At this point I am starting to feel like the ground hog in the awesome movie “GroundHog Day”, trapped in a cage with the same day repeating over and over. This time I made sure the board did not get erased.

Guy #4 comes in, says hi, asks me how I am and immediately throws me a question on how to create a set of elements on a page. I point to the board and say I’ve been asked this 3 times. Still I am asked to walk over it one more time.

As it turned out they had a script they were given by their most high ranking tech person and asked cover a part of it. Since they did not communicate with each other they all started from the top. To this day I have no clue why none of them mentioned to the person after them where they stopped. I guess their while loop did not cnt++.

Interviewers who ask for code over the phone

Phone screeners are an important part of an interview process. During a phone screener you can ask basic questions like “Tell me about your last job?” and “What is a SQL join?” as well as get a feel for candidates personality. They are both a time saver and if you not careful a really good way to lose potentially good candidates. Here is a really strange one I went through.

When you look for job while having a job phone screeners can get frustrating to schedule since you can not take time off and people who are phone screening you do not always enjoy doing them during lunch hours. Since most screeners are at least 45 minutes you need to plan to run out to your car or somewhere outside to answer questions.

One hot summer day I had a phone screener for a Python job. After basic introductions and questions I was told we are getting straight to the point. It sounded like this: “Can you please tell us in detail how to implement a quicksort”. I do my best, taking approximately 5 minutes to describe in detail how it works and mention that is available as a utility function in most languages. The follow up conversion blew my mind.

Interviewer: We were hoping you could show us the code for an in-place quicksort.

Me: I can send you the code when I get back to my computer.

Interviewer: No, we would like to see if you can do it right now.

Me: I am not sure how well I can do it over the phone.

Interviewer: Just dictate it and I will write it down. Use Java please.

A Python job where I have to do quicksort in Java? On top of that Java is a strongly and statically typed language and is really picky about syntax and declarations. At the time, I did not actually mention Java in my resume though I have done it a few times, since I am not in any sense qualified to be a Java developer without at least a 2 week refresher course. The next 10 minutes was the worst phone screener time of my life, especially since the interviewer did not seem particular technical.

Me: I-N-T arr, open square bracket, open square bracket, open square bracket … the letter to the right of letter “P”

… five minutes later …

Me: public function swap …

Interviewer: Hold on, still typing it down, can you please spell that for me.

Me: S as in Sam, W as a Warren, or … as in Will, … yes like Will Smith in “Man in Black”.

Honestly I do not know if I came up with anything that made sense at all, since I could not look it over. To this day I am pretty sure it was not an in-place quicksort. Still the whole ordeal was over and I got back to my desk. In a few hours (yay, for not waiting for days) an email pops in.

"I have passed on your quicksort implementation to one of our developers for evaluation. Based on feedback we want to thank you for your time but we are sorry to say you do not meet our requirements."

O_o … Call me strange but I still think that dictating code of the top of your head into the phone to be evaluated later is not the right way to interview. Reminds me of some variation of this job ad.

The following is an example of what a good code exercise during an interview should include.

  • Use a whiteboard.
  • Ask the candidate to write pseudo code first, to see if they can think in abstract terms.
  • Make sure they talk through all the code step by step, so they can demonstrate understanding. This also helps with figuring out if a candidate has a typo or lacks some basic understanding of concept.
  • Give the question in stages, so they can write only small parts and not get frustrated. This can also show if the candidate is able to refactor code.
  • Make sure the exercise can be solved within 20 minutes (maybe by giving it to someone you know) so not to turn this into a painful protracted exercise.
  • Provide some hints and keep them talking so the can overcome the nervousness of presenting off the cuff.

The importance of asking good question can not be understated. It is an important of interviewing. Please make it fun and clear for your candidates.

Tumblr Theme Modification

This blog uses Brutal Simplicity theme by Kevin Burg. The theme however had constrained width for post areas. Its been updated to allow for maximum real estate and the sidebar has been moved to the right. See CSS below.

#content {
    width: 94%;
}

#header {
    width: 90%;
}

#sidebar {
    float: right;
    width: 12%;
}

.postcontainer {
    float: none;
    width: 90%;
}

.post {
    width: 95%;
}

Success Judging Thunderdome: My Opinion vs. Other Leading Brand

Outrageous and Vague Statement Time:

Success is applied passion … just think about the best job you’ve had and how much more productive you were.

A smart business person will growl “You ARE a dev monkey, you do not understand anything running a business, my business got to payroll and bills and the bigger the number of sales the better off I am”. I agree with you random business person, I do not know anything about running YOUR business and am not qualified to judge.

To be frank, numbers are important. To be even more frank, short term numbers and long term numbers are equally important. In one job I had [a consumer facing business] only measured success by the amount of sales. Customer service department was ignored, untrained and unrewarded. A few years ago their sales were up. Now the business has 1 star rating in Google, on Yelp and every other major rating site and all of nearly a hundred reviews speak about “the worst customer service ever”. Maybe they would not have survived without pushing for sales then … on the other hand they do not seem to be doing well now as their website looks EXACTLY like it did 8 years ago, including typos.

But lets get back to technology projects and what makes them a success …

People who are not jerks

No matter how smart they are, unless you they are here to avert that asteroid that lands on Manhattan, do not let them be on your projects. However, be careful not to label introverts as jerks … just cause they do not bounce up and down with ideas.

People who persevere > geniuses

Smart people who continuously contribute level are more important then your 1-2 resident geniuses who do not. They get things done.

People who contribute quality

Its the people, who contribute quality. Probably the easiest example of that are bug submitters who take time to document how to reproduce a bug, and test the fix when available vs. the it does not work on my system where is fix!!! crowd. Excited and dedicated n00bs are great, you need them, you want them since they are your future help. However, it will take a few weeks/months/years to get them to contribute quality.

People who contribute to your project

Folks who contribute are more important to your project than your user base. In an open source project this becomes very evident as it 95% of them are powered by volunteer labour. Contributions will come in many forms many that will surprise you and make you really happy. For example, I love nothing more a graphic designer with skill (which is pretty much everyone except me) makes everything look better. It helps everyone on the project to look at their UI and go …. “ooohhh, pretty”. (say what you will about Apple, but they got that part right)

By the way, on commercial project people even more important since there only those who work on it are interested in making it better and there are usually very few of them.

People who use your project

One of the main goals for any project is keeping users happy with what they are doing. Technology changes every few years. SourceForge was all the rage then, GitHub is on top now (though watch out, I think Mark Ramm and crew has done wonders with SourceForge recently). So a large user base might be an indicator of project being managed well. Kinda …

Inspiration:

Joel Spolsky’s The Guerrilla Guide to Interviewing

Don’t boil cold water.

I don’t get much time to watch TV very much, but I manage to squeeze in an episode of different shows here and there. One of the most memorable moments was on the show Hell’s Kitchen where chef Gordon Ramsay was screaming at contestant Wendy, who was trying to boil water. The dialog was something like this:

Chef Ramsay: Wendy, is the water boiling?
Contestant Wendy: No chef, it’s taking forever.
Chef Ramsay: Did you use cold water?
Contestant Wendy: Yes chef.
Chef Ramsay: Why did you top it off with cold water?
Contestant Wendy: I thought that cold water was supposed to boil faster than hot water.
Chef Ramsay: What?!

You may be every bit as appalled as Chef Ramsay but if you’re managing a software team or a project, you may fall victim to the same issue as Contestant Wendy.

Friction is like ice in the water you are trying to boil.

Friction can take the shape of many things in a project. It could be a clunky tool, lack of flexibility in your process or even a blocking business issue. The immediate effect is the delay in your project,

  • Bigger issue is effect on developers
  • Constant struggle - fatigue, just have enough time/want to finish
  • Low friction - developer can spend time on improvements, developer can be more creative which can lead to better solutions and even more valuable features in the future
  • Spark positive effect on other developers productivity/creativity explosion

Reduce friction by

  • Giving them good tools to work with.
  • Providing them with resources they need.
  • Let them imagine on their own.
  • Let them work without being disturbed.
  • Be flexible

In cooking, when you want water to boil quickly, you should give it all the help it can. Use hot water or add salt to lower the boiling point. In software, when you want your development to run well, reduce friction as much as possible.

{bob} The brilliance of Pyramid [framework] creeps up on you like a stealthy ninja in clown shoes. You don’t realise it’s coming, and then suddenly it’s right there staring you in the face, and you’re like “Holy shit!” and then you realise he did it in *clown shoes* and your mind gets blown just that extra bit more. — freenode, #pyramid

{bob} A very angry and likely drunk dude was walking through the parking lot, punching cars.

{ted} was he a Django dev?

{bob} No.

{ted} Are you sure?

— irc … 

Fantastic Unittest Presentation

A talk, by Ned Batchelder, creator of Coverage, about how to get started testing your Python code. This is designed to be useful for complete beginners, and to provide some meat for people who already have some testing underway. 

http://nedbatchelder.com/text/starttest.html

Uniformity in Development Environment

Much has been said about uniformity in production environments. Recently more great tools have sprung up, tools like Chef, Puppet and other.

Time has come to to about “Uniformity in Development Environment”.

UniDev-ee (last e is just for fun) - Uniformity in Development Environments (collaborative ones) on Prezi

Fun Python Statements

> > > from __future__ import braces

  File “<stdin>”, line 1

SyntaxError: not a chance