How NOT to interview Pythonistas

This was originally posted on blogger here.

There are a lot of firms who complain that all the experienced Python people are taken, and wonder if they should choose a different toolset. On the flip side of the coin, I've heard a growing  number of developers/engineers complain about horrible hiring practices they encounter. So which is it?

I think it is a mix of both. Compared to the current need, there is a shortage of experienced Pythonistas. On the other hand, I've seen really stupid mistakes by otherwise professional firms, stupid mistakes which are NOT caused by recruiters and don't just cost the firm a possible hire, but hurts their reputation. This is because people will complain to each other on IRC and in users groups about how your firm hires people and all of a sudden your firm has a bad reputation.

So that this stops happening, here are three really bad moves I've seen by companies:

1. If cold calling, don't EVER ask technical questions.

Recently I keep hearing about this one and it even happened to me about 8 years ago.

A pythonista is doing something, maybe coding, driving, sleeping, or eating when they get a call. The pythonista answers and are asked if they are interested in working for Company X. The pythonista gives a positive answer. Then the interviewer asks if they could answer some technical questions.

At this point the interviewer has failed. In fact, they have failed hard.

Odds are that being on the spot, the Pythonista will agree. And then, without a day to prep themselves for doing an interview, they are answering questions. There are no metrics for this one but I bet 90% of developers will fail questions they normally could answer in a heartbeat. Afterwards, the developer/engineer will kick themselves because they knew the answer, but because they were flustered they got things wrong.

And then, to really seal the deal, because the developer/engineer has failed the interview, the interviewer will inform them that they are not the sort of material that Company X wants. So not only did the pythonista mess up easy questions, now the lack of respect for their skills and person has been made abundantly clear.

The interviewer is completely at fault here.

The real problem for the interviewer is that if that potential hire that they just rejected talks about it, experienced developers/engineers will hear about it and it will be a unspoken black mark against their firm.

Lesson learned: What the interviewer should have done is email first, or if they called, ask if they could schedule a technical interview, either in person or on the phone. There is no exception to this system.

2. Make it clear that an interview is an interview.

Imagine there is a company you respect and admire. You meet the founders or the senior technical lead at a social event and they invite you to visit their firm. You arrive at the office expecting a tour and instead get handed to the technical staff for a challenging interview. Unprepared you don't do so well, and unsurprisingly the company doesn't hire you.

This is so full of wrong on the part of the hiring firm I don't know where to begin.

Lesson learned: If you are bringing someone into the office for an interview, make it abundantly clear you are interviewing the prospect. Say it in person and confirm it in email.

3. Make crazy requests in the technical interview

A few years ago a very capable friend was asked to provide a list of Fibonacci numbers, but he wasn't allowed to use a function and need to use a database. When he solved that one his effort was then criticized for 15 minutes by four developers. Then he was then asked to do it again, only this time in ECMA script.

Well before node.js existed, someone else I know was asked to use browser JavaScript to write a multithreaded HTTP server. When my friend asked "why would you ever do such a thing?", he was told not to ask that question but to solve the issued problem.

In all these cases the interviewee left annoyed, if not angry. Years have gone by and they still complain about these firms.

Lesson learned: For the hard questions, make them meaningful

---

6 comments captured from original post on Blogger

Tucanae Services said on 2011-04-17

In the main, of the three cases provided, you could make that complaint regardless of language considered. I have been faced with all three for C, Delphi, and even ancient dBase. During the dotCom boom a cold call from a head hunter was routine -- "Company X has an opening for Y at Z salary. Interested?" I would invariably say no and hang up. When someone is baseline filtering on salary right up front, that is not the company to work for. Their focus is merely cash and product is secondary.

Venkat said on 2011-04-17

#3 - i think this is the "norm" in many interviews. People come up with some questions that would 'never' be implemented in the reign of that company, but their defense is : 'we are testing how good the candidate has mastered the fundamentals'.

Also, one more aspect, #4 - Questions asked that the interviewer doesnt master. For eg. once i attended an interview wherein, just the previous day i had worked on something related and hard facts; but the interviewer kept on contesting the results.

Most of the interviewers in BIG companies like Google, Amazon, Y!, M$ are egomaniacs; who think that working for such 'cool' companies is great ; neo-colonialism i say!

pydanny said on 2011-04-18

@Venkatraman - The problem with #3 is that:

In the first case his work was a crazy edge case that was then publicly criticized by his potential peers AND then they wanted it again but in a different language. It was extremely disrespectful of the interviewer team.

In the second case, the developer was being asked to turn an absolutely unsuitable tool (browser JavaScript) into something extremely complex and potentially dangerous. When he questioned it, he was told to not worry about it and solve the problem. Again, a lack of respect by the interviewer team.

The real issue is that these questions weren't fundamental questions - they were challenge puzzles that had absolutely nothing to do with anything but... well... puzzles. Challenge puzzles like this don't begin to touch on real-world work. They are just used to stroke the ego of the interviewer.

Better than stupid interview puzzles are real questions. Like the difference between inheritance and polymorphism or the definition of a Mixin. In a job touching relational databases, SQL questions about JOINs are a must. MapReduce is handy for anyone involved in that sort of thing. And of course, variations of fizzbuzz are good enough to weed out 90% of the buzzword kings.

Greg said on 2011-04-20

"Is it that these firms are in NYC/ATL/SFO/SJO/LAX and not everyone wants to live there? Is it that the managers are so insecure they can't believe telecommuters might actually be more productive than folks who just "show up at the office"?"

Amen

pydanny said on 2011-04-20

Telecommuting is a really powerful option, but so is having your team all in one place - especially with people you've yet to actually meet or work with previously. If I weren't a technical person and had a technical team, that they were local would be scary. And I've seen telecommuting groups fall apart on this issue.

easyrevolver said on 2011-05-16

I whole-heartedly concur.