Bullshit Interviewers
Interviewers - are you getting ready to interview your next engineering candidate? If you are prepared to have your candidate whiteboard something unrelated to the position, asking them to perform ridiculous logic questions, or ready to conduct yourself in a condescending manner, you might be a bullshit interviewer.
I’ve done my fair share of interviewing engineering candidates and also interviewing for engineering positions by people at companies I wanted to join. When interviewing for a job I wanted, I often find I end up having to deal with people who spend less time discussing the things I am good at, my relevant experience, and problems I have solved in the past, and instead focusing on bullshit logic and unrelated whiteboard problems.
How could this be? I suppose the biggest problem is that the people who are conducting tech interviews are often coders who graduated up to a senior level position where they are then tasked with interviewing new candidates for the company. These are people who are good at coding but often have no strategy whatsoever at identifying the characteristics of a good candidate. They just go with the format they think is right rather than seek out candidates who can think on their feet, use good judgement, have decent skills, and have common sense.
I’ve had to deal with this since forever. In my humble opinion, I’m somewhat experienced. I wrote the first ad server Facebook used in 2004. I’ve held senior level coding positions for 13 years. I’ve built products, built teams, and cloud build infrastructure over and over again. You’d think I’d have done better interviewing at some of the top startups over the last 5 years but I’ve had to deal with rejection from as many bullshit interviewers as you are probably are having to deal with right now if you are interviewing.
The funny thing about a bullshit interviewer is that they are actually doing you a service because you probably don’t want to be there in the first place. I occasionally googled for the company names where I was bullshit interviewed and I see stories like this:
I was bullshit interviewed by a CTO who asked me the question at the bottom of this article when interviewing for a PHP Facebook app coding position. Approx 1 year after I was rejected for not being able to answer that question, the company was hacked by a SQL injection attack and tens of millions of user passwords were released into the wild because they were stored as clear text in the company’s database.
Approx 1 year after I was bullshit interviewed by engineers at a prominent social news and entertainment website, they released a new version of their website which didn’t work on several levels and the entire brand was destroyed. They rejected me because I “didn’t have enough experience with OOP”. What?
The good news is that my experience tells me you will find the place that’s right for you. So don’t give up and try not to get discouraged. This might be the best time ever to be doing this line of work. You have a talent that could make you a billionaire.
Up for a challenge? Try our RockThePost SQL coding challenge.
Bullshit PHP Coding Interview Question
There are 25 horses and a single race track. The track has 5 lanes. Your job is to find the fastest 3 horses assuming you don't have a stopwatch and all horses always run at a constant pace. What’s the way to find the fastest 3 in the fewest uses of the track.
Written by Jonathan Block
Related protips
19 Responses
My favorite Real World bullshit interview question involved some "very senior" engineer asking some pointed questions about some C code....which looked like vomit. It was the usual "what does this {vomit-looking} code output?" sort-of question. After staring at the code for a minute, I answered "I think that the output of this code is undefined -- it violates the sequence-point rules of the C standard".
Well now, this was not The Right Answer that Mr. Bullshit Interviewer wanted to hear. "It produces {this} output" he said. Furthermore, he had never even heard of "sequence points" and he seemed to be strongly inclined to believe that I was making stuff up.
I was bitter at not getting the job for a while, but, I guess in retrospect, it was an INTERVIEW -- you know -- an EXCHANGE OF INFORMATION....and I think that I learned far more about this organization than this organization had learned about me...
i love those stories about interviews. until now, i was lucky enough not having to had to experience such bullshit interview. the stupidest thing was "yeah, we really want you but please wait 6 months 'til we hired a senior." -- after 3 rounds of oral and whiteboard tests.
i ended up with my current position without an interview and for the foreseeable future i don't plan to ever have one again. unless "apple calls" and this won't be happening ;)
I don't think it's helpful to even ask questions. To me, it's all about your github account. I'll know if I want to work with someone from what's in their github account alone most of the time. By the time I'd interview someone, I already know if they're a fit technically. At that point, it's just about conversing with the prospective team member to make sure s/he's not an asshole.
I worked for a company for more than a decade before having to interview again. I thought that since I can write code I should be able manage my way through interviews...
I was wrong. I find out technical interviews is a skill set very different from the job I've been doing.
In other fields, an experience skilled person can show their skills by showing what they have been doing for years. If you want to see if a chef can cook, let him cook for you.
In our field, you are asked to write code on a white board. You are also asked to write something irrelevant like 'reverse a linked lists' or 'reverse a string in place'.
This is like asking a chef to cook for you using only a campfire and canned sardines.
But there is hope, I see that a few good companies are replacing the tech interview with pair programming. Basically, they code with the person for a certain amount of time.
To me, this makes sense. If you want to see a programmer can write code? Let him/her write code.
@carlodicelico - Using github only works for software engineers who work in open source projects. You are missing out on a lot of good programmers.
Most BS question that I ever got:
A store sells 3 types of pies but will usually have only 2 types of pies available. If pie A and pie B are available, pick A. If pie B and pie C are available, pick pie B. If pie A and pie C are available, pick pie C.
Question, what if all 3 types pies are available. Which pie would YOU pick?
I asked it was a trick question and they claimed it was not. They were laughing and high fiving each other as I was struggling to figure out what they wanted from me.
By the way, the answer was, pick the pie YOU want.
@carlodicelico, I run my own private Git server. My GitHub account is mostly forks of other's code I want to keep up on. In that sense, it is a terrible metric for my skillset.
@captbrogers, @dvillarama - That's true, a lot of people probably get cut out by that metric but in a very general sense, what I'm saying is that I like to let a person's code do their talking for them. I prefer to look at a person's code and avoid the kinds of BS questions that are mentioned above. The issue then becomes one of verifying that a person's code is really theirs. GitHub (Bitbucket, etc.) remains the best way to do that. It also says a lot about a prospective engineer if they have a lot of pet projects and contribute to open source because that tells me that they genuinely love technology and aren't just in it for a job. I also do pair programming interviews with codassium (http://codassium.com/), and that's a GREAT way to interview. But yeah, to me, code matters more than your ability to solve arbitrary riddles and regurgitate factoids about a given language/framework.
I think the issue is a confusion or a misunderstanding of the goal/purpose of a coding interview. Coding interviews are useless to determine if someone can code, especially if the questions have to do with language specifics, etc. As others have mentioned, look at their github or other public repos, or ask for code samples.
However, coding interviews are useful to see how candidates thing critically and how they communicate. Assuming the interviewer knows this, then the horse track question isn't bullshit, it's a sorting problem. Given 25 values, find the 3 highest with a constraint of only being able to compare 5 at a time (for reference, bubble sort is 2 at a time). The "correct" answer isn't the actual solution, it's being able to communicate that you understand the problem and communicate your thoughts as you consider solutions.
Can't agree more with the comments about a prospects Github account. As mentioned, it speaks volumes about the coding personality and skills of the interviewee, which leaves the interview clear to just decide on whether the person's personality is going to fit with the company/team. Critically, this doesn't waste time of the interviewer/company or the applicant.
My favorite was when I was interviewing for a Linux Engineering position. I was in front of a panel of people, and one of them handed me a laptop with a VM on it. The VM wouldn't boot because somebody went in beforehand and typoed one of the boot parameters in the grub configuration. That was the "Trick" I was supposed to catch. Mind you, not getting the first question whilest sitting in front of three people staring you down is kind of a mind f#&k for the rest of the interview...
@carlodicelico says "GitHub (Bitbucket, etc.) remains the best way to do that. It also says a lot about a prospective engineer if they have a lot of pet projects and contribute to open source because that tells me that they genuinely love technology and aren't just in it for a job."
That's ridiculous. I own, collectively, 4.5% of nothing as the various stock options that were supposed to incentivize me to put my life on hold and put everything into working for those companies ... are now worthless. I AM just in it for a job. I also have a life. I love technology but I also have outside interests. When I am not at work I love working with my hands and not f*cking thinking about computing or anything else much at all.
@kewpiedoll99 It's not ridiculous at all. It's a proven fact that people who love what they do do it better.
GitHub is just one metric to use, not the only metric. I'm sure it's not difficult to build a GitHub account to look like you know what you're doing, but still not be qualified in many respects. How much time does a person have to commit to their GitHub account to make it show what is easily displayed in an hour-long refactoring-type code test? Seeing the end result, doesn't let you question people's choices as they make it, nor does it show how they would collaborate on a project with a team member. Hopefully you can get a sense of that in your follow-up interview, but some folks are really polished for that, which just leaves you in the same spot as before GitHub existed.
I think my next interview question will be:
"User enters web address in web browser. Describe what happens. Assume positive scenario and, modern, web site/application gets loaded. What's Your job in this process?"
I'm a Junior level developer and fairly new to the professional dev world. I am glad to hear even seasoned vets are having trouble with such nonsensical interview questions. Personally, I've been rejected way too many times. It really started eating away at my confidence, to the extent I started questioning my capabilities of ever becoming a software developer. But possibly that was a blessing in disguise, as I've stumbled onto other software dev opportunities which don't restrict me to a cubicle and 9-5hours. Although I don't doubt one day I may need to get a regular job if contracting leads start drying up. Hopefully by then, things will have changed.
"The funny thing about a bullshit interviewer is that they are actually doing you a service because you probably don’t want to be there in the first place. " Very very good point. I see it the same way.
if have to agree with carlodicelico, if you really love what you do then you'll go out of your way to prove it. maybe with talks, code, plugins or whatever. this background information alone should be enough to veto them technically, the interview shouldn't be about getting them to do some obscure piece of code they're totally not prepared for it should be about meeting them in a non-stressful environment so that you can see how they really tick, bring em into an interview environment and they're already not themselves and defensive. whenever i interview someone i do exactly that, invite them to lunch, or get the team to go out for a picnic with the new guy, if they gel then it's a done deal.
In theory, the IT should be an industry laying on top of Maslow's hierarchy of needs, but I've met so many self-titled "professionals" still struggling on the "self-esteem" level that it makes me wander...
And there's also the issue of "everybody has to eat" - there are so many more-or-less-competent people climbing up the corporate ladders nowadays, and some of them have a constant urge to prove they deserve their place. Interviewing other people offers such an occasion.
I, for one, can't imagine how one can pretend to do HR/recruiting/interviewing in an area such as IT - especially coding interviews - without having a sound technical background... and without actually writing code.
Note to BS interviewers, if you write something on the whiteboard for the interviewee to answer make sure its correct and if its not don't get mad. I had someone put a loop that would've crashed a browser in an interview so I thought since it was an infinite loop that I may need to point that out, turns out I was wrong (but I was right, oh so right) and they needed a more seasoned developer...hmmmmm????
Thats why I say no more whiteboard or technical interviews, I ask for a trial period or a contract piece instead. I think that helps out both parties, b/c you can't even know the atmosphere/culture of a company until you actually start. They could have a beautiful lobby and put developers in a broom closet (which is quiet and dark so I like it but sometimes too small). Then the hiring person/manager really gets the real idea of how good you are or could be as well. It has worked well for me the past couple of times that I have taken this route instead of the traditional interview.
I think there is always a trend inside interviews and recruitment strategy. Now a days it is github, stackoverflow, linkedin profiles.
Have a fresh tip? Share with Coderwall community!
