Big Data/Analytics Zone is brought to you in partnership with:

I'm an experienced systems/devops engineer, looking for contract work in Central London or anywhere, actually. I've been working on so many technologies over the years, Puppet, Python, Linux, HPC, Cloud computing to name but a few. Check out my website for the latest information what I've been doing. Tom is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

The Tech Interview: One Size Does Not Fit All

03.26.2013
| 2749 views |
  • submit to reddit

The tech interview process is broken.

Fundamentally.

About a month ago, I wrote about how I've had some terrible interview experiences over the last 6-odd weeks or so. 

I also just read this, and agree with everything said there. I think there's more to say.

I'm disheartened to find that these aren't the exceptions, they're the rule. 

The thing is, companies seem to have one type of interview, The Developer Challenge.

That works fine, as a whole, if you're looking for Developers.  

But I'm not a developer.  Not really, anyway.  I can write code in a variety of different languages, I can pick up most sane languages without too much trouble.  I still struggle with functional things like OCAML, F#, Haskell (and for different reasons, Erlang).

But Python, Ruby, Java, C#, C++ and that ilk, I'm generally fine with.

I know lots and lots about how python datastructures are neat, and why dictionaries are awesome, and how you can play with a string as if it were a list.

I know why polynomial-time algorithms are bad.

I know things like how you find DNA sequence alignments (I used to be a bioinformaticist).

I was explaining to a friend of mine (an engineer at Google), that if I was asked to make a search engine as part of an interview question, then I'd do the following:

1: wget --mirror

2: load that data into Elasticsearch

3: build a noddy webapplication with Flask and PyES to search the Elasticsearch index

Done.

Because for me, a very pragmatic individual, I'd rather be building on other people's working code, functioning libraries, assembling building blocks to make one large system out of the component parts.  

If I need systems-glue, I'll typically break out Python, or in extreme cases, Java.

If I want to search a list of words in better than O(n) time, I'll use a Trie.  This I know from having read books, and wikipedia, and StackOverflow and so on.  

What I won't waste my time doing is trying to implement my own Trie library, because I know of at least 2 perfectly good, generic(ish) libraries, in a variety of languages, for doing what I want to do.

Doing things this way means that someone else (someone far better at datastructures than me) has tested it, found edge cases, written documentation, fixed bugs and maintained the damn thing.

Interesting side note: If I’ve had to resort to using a library from PyPi (or Github) for a Trie, it’s fairly indicative, to me, that Python needs one in it’s standard library.  That’ll piss off the interviewers for sure.  Next thing you know, we’ll have to do everything in x86 Assembly.

I don't see my approach as anything other than realistic.  It's how I'd solve the problem for work.  I'm not aversed to reading through the library (and looking for insanity), or fixing bugs and sending them upstream, but in a real-life situation, I'd rather not spend my life whittling a log into a wheel.  I'd rather use an existing template for a wheel. 

It occurs to me that there aren't that many problems that people come across which aren't a copy, or subset of an existing, solved problem.  If you wanted to clone a sheep, you wouldn't work everything out from first principles, you'd read the research from the team who cloned Dolly, and work from there.

And another thing.. We need to stop with the whole "Here's a challenge, come back in X amount of time with a solution." That approach is LAME.  

I like to discuss things with people.  I don't like waiting for a day to get an answer, by the time my question has gone through the recruiter/HR/tech-lead.  
Just do the thing in a skype session with me, or TeamViewer, or something. 

Whilst I was discussing a particular problem with my Google friend, he basically suggested that even without getting a decent answer to the challenge, but by explaining my thought processes, it's as good as a win from the hiring point of view.  You just don't get that kind of interaction with a "go code this and come back" challenge.  

Sure, it's more time consuming for the interviewer, but surely they're already at the point where they want to spend time with you.  I mean, having passed the phone screen, it's  time for something a little more in depth.  I get the whole, "we don't know you, come to us with this challenge" spiel, that Facebook used to do (remember the challenges page?).

Actually, why not just check out my github/bitbucket repositories?  There's loads of stuff I've written there.  

In a similar vein, I'm brought back to interview questions (and scenarios) where I've been told that searching the web is out of the question.  

I'm always left wondering whether searching the web for an answer to a problem is also disallowed for the other developers (who do work there).  If it is, I'm 99% sure I don't want to work there anyway.

It's effectively saying: "We don't want you to learn from other people's mistakes.  You have to make them yourself.".  That's not a realistic expectation, IMO.

Some of the best interviews I've ever had have taken place in a pub, in a coffee shop, in a cafe, over lunch.  

During one of the best technical challenges I've done, I said to the interviewer: "It's been a while since I did this, I'm gonna see what the ServerFault community says".  In this case, this was an acceptable answer, and worked perfectly.

TL;DR [1]: Stop asking interview candidates to reinvent the wheel. Ask them questions about why they've chosen the tools they have.

Moving on:

Interview challenges should be closer tailored to the actual job title.  This "one true developer challenge" thing works fine for hiring developers.  God help the candidate if they get sent the same challenge as a software engineer, if they're a front-end UX engineer.  

The challenge set should probably be related to a real-life problem that fits into their job remit.  

For developers, fine, ask them to write algorithms.

For QA engineers, ask them about Selenium, or Cucumber.

For Sysadmins/DevOps/SRE/Systems Engineers/Systems Architects, then ask questions like the ElasticSearch one, or "How would you aggregate logfiles from a cluster of N servers", or "How would you allow a cluster of N servers to share an assets directory"? or "How would you check database replication lag?", or "Why are 2 switches at the core better than one?".

For Designers/UX/JS/CSS engineers, ask them something like: "Design an interface for an ATM to make it more user-friendly.  Bonus question: Make it more user-friendly to disabled users." or "How would you make this site look awesome on a mobile device?"

Hopefully you can see the difference between the different class of question, and the different class of job.  
It's no good asking a greengrocer which is the leanest cut of beef, just like it's not terribly conducive to ask a sysadmin to solve a problem that might require the use of a Red-Black Tree.  

It's possible they'll know the answer, but I sure as hell wouldn't fail them for not knowing. 

TL;DR [2]: Tailor interview questions to match what you expect of the candidate In Real Life.

Interviews are not baseball caps.  

One size does not fit all.

Published at DZone with permission of Tom O'connor, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Barry Smith replied on Tue, 2013/03/26 - 4:49am

Why the focus on algorithms anyway. I've been a developer or similar for around 25 years and I can't remember one time I had to write algorithms. Most business development work is either brownfield, in which case you are mostly required to write new code in the style of the existing codebase, or greenfield in which case you need to pick an appropriate framework and code according to its standards and best practices.

A really useful test for a developer would be to have them code up a new bit of software using your obscure in-house ORM system based on a couple of similar bits of current code. Or perhaps to set up an unfamiliar web framework project and get some initial screens going, because this is what we actually do all day.

Lund Wolfe replied on Sun, 2013/03/31 - 4:08am

Hiring/interviewing is very difficult.  Very few are good at it.  Some are downright lazy, or don't have people in the desired position hiring for the same position, so you get more of a one size fits all process.

Most interview programming questions are checking for analytical thinking, problem solving in terms of low level language data structures or algorithms, which is an advantage to someone with the educational training (oh yeah, I've seen/done that before).  In daily practice, we use language libraries or books or google for algorithms outside of our comfort zone.

You think more like a senior level developer who solves the larger problem in chunks.  You can always assign or ask someone at the language coding level how to code it.  The problem is we usually work our way up from the bottom, coding small features/fixes.  Project failure is probably more likely to be caused by higher level design flaws.  Unfortunately, such interview methods will result in false negatives for someone like you.

The important thing is to know your weakness and be humble enough to ask for help from those more knowledgeable in that area.

Look at each interview as an opportunity to add new problem/solution scenarios to your repertoire.  Eventually, you'll beat your competitors and get the job.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.