Intro
I've been into many interviews here in Yerevan, Armenia. I get it: Armenians are mostly aggressive people. But should a job inte...
For further actions, you may consider blocking this person and/or reporting abuse
So, where did you put your hidden camera on most of my recent interviews? What you described sounds a lot like the interview process at most "cool" and "trying to be cool" companies around here (Atlanta, GA US). The interview process right now is probably the worst and most broken it has ever been at any time in my 30 year career and that covers the dotcom bust and the 2008-09 recession.
There's also the phone screen Trivial Pursuit round where you get asked a series of obscure language questions or the like. The 'best' calls like this have several people on a conference line where the connection is bad or choppy and several people are talking over each other.
If you're lucky, you might get to do a video conference version of trivia. Not only do you get the same problems as the phone screen but you get to add the additional video connectivity issues.
The very worst are those that put you through an offsite wringer, multiple phone/video interviews, coding tests and the like, then bring you into their office for your interrogation uh, interview. Then, after all that hostility, they rudely send you on your way with an abrupt "NO". That really gives you a good impression of the company, doesn't it?
I suspect that a lot of this newer, hostile, way to doing interviews has passed down from the way Google, Apple, Facebook and other tech giants do it. It's really unfortunate and even the tech giants have come to realize that they're doing it wrong. However, this hasn't filtered down yet.
The better way to interview mid to senior level developers is the old way, just have a conversation. You can easily figure out if the person is someone you want on your team simply by talking about their past projects and development philosophy.
I forgot the phone interview! Good point.
I agree, a simple conversation could do it. But I am also opened to anything besides this "aggressive" approach masked with fake pleasantries and smiles.
Sorry for a second comment, but I have to address something directly.
Not necessarily! Here's a few people we might encounter:
The guy that majorly padded his résumé,
The gal who worked in COBOL for 25 years, but hasn't ever used an OOP language,
The guy whose knowledge is 90% skimming StackOverflow answers and blog posts.
In hiring, you never ever EVER take "most-likely" as a reason not to ask a question. If OOP is part of the job, you have to make sure they actually know it!
Jason, let me tell you about the guy who fools you and all those HR managers and team leads who think like you, no matter how "smart and tried" your procedures you think they are.
This guy has worked in over 8 companies in less than 10 years. This is what he does: he is a C# .NET developer, so he learned all the important concepts of it and then decided to teach it, so he can learn everything it is possible to learn. After teaching .NET for a while, he started going to interviews. Hell, even I interviewed him when he came to our company. He knows his stuff. He studied well.
After a couple of months of working for us, we realized that he was spending more time smoking outside than writing code! And when our team lead checked his code, it was crap! Soon after, I believe that our management gave him like 3 months to go, because in the last 3 months he was with us he was not given a single task. He didn't care though. He was getting paid and smoking all day long.
Then one day, 2 weeks before he leaves us, he says that he got an offer from the biggest company in Armenia, even bigger than ours. More money. He aced yet another interview.
He worked there for a year and a half. Then he went to another company. We know a girl who works in that "biggest company" who told us that while reviewing his code, which is a standard procedure there, she saw coding mistakes that even a junior developer wouldn't make.
Since then, he changed his job even one more time. All good companies.
So HOOOOOOOOW, with your awesome "procedures" and POKER NON-SMILING faces, you are letting such GARBAGE get into the company, but when it comes to someone who knows whatever he knows you reject them? This guy is clearly fooling the hell out of you guys (please don't say that he wouldn't fool you personally, HR and Team Leads here follow the example that you set in USA or Europe).
Jason, all I am asking for is FAIRNESS. Don't let people like that guy FOOL YOU, and don't let people like Burdette refuse to do a task because they feel it is foolish, because YES, OOP concepts for a senior is a FOOLISH question.
And when it comes to Stack Overflow, EVERY RESPECTED DEVELOPER IN THE WORLD uses it! Please don't panic if you see your staff using it! Our team lead copy/paste from Stack Overflow, should we fire his ass?
And most importantly, PLEASE REMOVE THAT STRESS FACTOR FROM THE WORKPLACE! "if you don't deliver this app in 2 minutes we will all DIE!!!" No one is going to die! Even the biggest companies in the world delay a software or hardware for MONTHS sometimes, no one gets killed or anything!
All I am asking for is an OPEN-MINDED approach to the interview procedure, because the old ones are CLEARLY failing.
Hey, calm down. I'm not attacking you. You asked for input and feedback, and that's what I provided, calmly and speaking from several years experience. I am curious what your work experience in hiring has been, as I haven't seen you mentioned actually working HR before.
To address a couple of your concerns directly.
1) I never said our method is perfect - none is - but it demonstrates a documentably lower "bad hire" rate. It is still possible to make a bad hire.
2) Not every respected developer in the world uses OOP. It's one of six major paradigms, and it is perfectly possible not to fully grasp it at many different experience levels. That's speaking from factual observation, not just grasping at straws.
3) Pushing code under a stressful deadline isn't a management decision, it's a naturally occurring circumstance with some projects.
I am calm :D and I appreciate your opinion.
I was present in many interviews along with HR to ask technical questions. That's all. Our whole team participates in the interview process; sometimes its our team lead and me, sometimes it's the team lead and one or two others.
Although, I had some interview experience from a past job which is not related to IT.
In this world today, we have standards almost for anything. I am just asking for one more standard for job interviews (particularly for IT). That's all what I am asking for. You might be a great interviewer, but certainly others are not. An interview standard would make things much professional for both interviewers and interviewees.
As a developer/interviewee, I really do not know what kind of knowledge I should memorize and carry with me in my head to the interview.
Exactly. Some people who aren't good at programming are excellent at interviewing. The best way I've found to expose those that have trained themselves to interview well for the aggressive Trivial Pursuit interviews is to have a "let's-have-coffee-and-chat-about-code" interview. A few "That's interesting. Tell me more about how you implemented a facade pattern in your web service project." type questions and you'll know if they're just reciting Wikipedia or really done the work. (Bonus if you can ask those questions with a Wonka-esque smile rather than a poker face.)
What's more, this kind of question will let you gain some insight into their personality and coding style. For example, a while back I interviewed a senior level C# programmer who would have probably aced a by-the-book OOP, design patterns and Fibonacci-on-a-whiteboard type interview. However, after a simple discussion, it was clear his coding style was radically different from the rest of the team, was rather egotistical and thus he wouldn't be a good fit.
BTW, I have worked at a programming job in medical monitoring where someone might actually die if there was a problem. It was actually less stressful and more enjoyable workplace than most run-of-the-mill business app teams since people put aside their egos to get the job done because it was really important that it be done right.
Although I probably didn't make it clear, I actually purge from my list any questions that job websites recommend people prepare for. I do prefer very open ended questions.
I don't work in any place where we have looming "we're all going to die" deadlines, but I've known a few. If you're running a major website, and a security problem slips into production, there's no denying that is super-urgent.
A disclaimer, first of all: I believe in always treating people with kindness and respect, no matter who they are.
Now, the problem. Look at the interview from the other side of the table. We are having to watch out for some unfortunately common problems:
People who are completely unqualified and are overselling themselves,
People who have egos the size of Texas, making them more of a liability than anything,
People with toxic personalities that would do damage to our existing teams,
People whose idea of a coding job involves copying and pasting from StackOverflow.
People who, while completely hireable, are so busy overselling themselves that we're liable to put them in a position where everyone loses.
In encountering the above, I've learned some things the hard way.
A smiley-friendly interview reinforces "the script". It's a basic principle of communication psychology - when people get positive feedback for a behavior, they continue that behavior.
Literally everyone is acting when they sit down for an interview. No exceptions. It isn't malice; it's survival. We are taught to make ourselves look like what we think the hiring manager wants, but that never matches 100% with who we are. With the exception of crazy HR people, hiring managers want, above all, to see what they're getting! We have a broad range of somewhat flexible expectations. What we don't want is to be bamboozled!
So, if we're sunshine-and-rainbows friendly to someone out of the gate, and persist in that, we are providing positive emotional feedback that will reinforce the current deception.
That doesn't mean that we should be angry or cruel; far from it, as that would provide negative emotional feedback, triggering the other person to switch up their deception. Instead, I've learned to show little to no emotion at all. I smile, shake their hand, and switch off all emotional cues. The result is that nearly everyone I interview, about ten minutes in, clearly goes through an internal thought process of "ah crap, to heck with the script, I can't tell what he's thinking. Either he's going to like me or not." When I started doing this, I actually saw a significant drop in the number of people who turned out to be "not as advertised," and thereby our retention went up, although our incoming hiring stats were otherwise unaltered.
I've been the interviewee as well, and I have learned not to take it personally when I get this "no smiles" treatment. If anything, I take it as a complement: this manager is interested enough in considering me that he's doing everything he knows to do to vet me, and that he's probably done the same with my potentially future co-workers. An all-smiles hiring manager is going to get taken in by a lot of smooth talkers, just as a natural side effect of their style.
By the by, I also have them code in front of me. I've learned that this is critical. Honestly, I don't care if they can make a doubly-linked-list from scratch. What I care about it how they approach the problem. Where are they taking mental shortcuts? What is their coding process? If someone can't write code in an interview, they can't write code that has to "ship to production in one hour or we're all doomed."
Now, I understand that the no-emotional-feedback approach, paired with a position-tailored open-ended question set, and some in-interview coding, is terrifying. Most people I interview are scared out of their minds. And yes, this means they won't perform at optimal quality...I account for that in my assessment. But I've also learned the hard way that the final interview needs to be a bit scary, for one simple reason: only an oversized ego can prevent you from having no nerves in that style of interview.
So far, in five years of interviews, that has held 100% true. I've even tested it out, bringing people on despite a sneaking suspicion that their strange confidence hinted at an ego...and it did!
So, interviews are scary. They're nerve-wracking. They're not friendly, cozy, let's-have-coffee-and-chat-about-code affairs. Nor should they be if you want to build and maintain a healthy, proficient team. It won't kill you, and you can have confidence that you AND your co-workers were hired for yourselves, not for your act.
That leads to my last point: in my experience, people that have to fight through an intimidating interview are less likely to leave the job for petty reasons. Why? Simple emotional economics: it's worth more to you.
Why I don't whiteboard.
I actually had a good whiteboarding session in an interview last week. Unlike other, artificial, whiteboarding exercises like you described in your blog article, I was asked to draw out and describe a web services application I had written. Since I drew upon knowledge I had, it was an easy, comfortable, task as compared to annoying exercises like Fibonacci numbers and such.
I absolutely agree with that style of "whiteboarding". I have candidates write some code before the interview (they have a week on the challenge), and then they send it for us to review 24-hours before the final interview. Then, during the interview, I have them make a change or fix a bug in their own code. It works phenomenally well.