Archive for January, 2016
I’ve been in IT for quite a long time and had my fair share of interviews from the perspective of being the interviewee and interviewer. I’ve dealt with my fair share of interviews where the interviewer came from on high with a with their favorite Computer Science question. Some of my favorites, design a B-Tree sorting algorithm, write code to solve this polynomial equation, write a compiler. My worst interviews by far were from Amazon and Intuit, B-Tree and Polynomial respectively.
My favorite question after those is, how often do you do that day to day? The answer 90% of the time, never. Most of the time, although the companies don’t like to admit it, they ask Computer Science level questions like that are a form of ageism, once your out of the CS program for a while and not exercising that knowledge day to day (like most high level business programmers) you loose that knowledge. CS questions are great at finding people who a.) studied an algo book before the interview or b.) are reality right out of collage. There is the case where the person has been in their career for years and can answer the question without issue too, but in my experience that’s more exceptional for Line of Business developers.
Which is why I’m proud about the interview process at Paylocity. We give you a coding challenge that reflects the work you will be doing day to day at the company and let you show us what you can do. We then spend around 45 minutes having you walk us through the project asking questions and getting your thoughts and having you show us your thought process.
Occasionally if you don’t show us a skill in your coding project we ask some normal technical questions. We try and keep it relaxed, we ask you what your skill is on a topic (1 being novice and 10 being expert) so we don’t bang you with questions you may not know the answers to. Is our process perfect, hell no and every single week we work on improving the process.
Which is why when I saw this Glassdoor review I was completely thrown for a loop. Now some points are valid, the lag in not hearing a result and the recruiter blowing him off are unacceptable. But I have never had a job interview where after the tech portion was done they told me the result, there is always some lag but not having someone get back you is not good.
Interview questions should be well thought out, be meaningful and be respective of the job and functions the person is applying for. You don’t need to give someone a deep CS question to see how they work through a problem. If you enjoy stumping candidates, you probably should recuse yourself from the interview process. That’s not saying we can’t have our favorite questions, but we would be asking them for the right reasons, not to sling mud after the interviewee has left.
Do you need a technical genius at every component in your stack? If your answer is yes, your looking for unicorns and you probably should re-evaluate your needs. In my career I can count the amount of truly amazing developers I’ve worked with on one hand, and still have fingers left over. But they aren’t crazy good at every tech/system/language used in the company. Because of this I like having questions for different skill levels and I feel it’s worked very well. If you’re going to tell me you’re an expert in something you better back it up.
Personally I interview for culture fit and personality first and foremost. After that it’s their ability to learn new things and adapt followed by passion. Interviewing is a hard and imperfect process, no one has a 100% solid interview process and when we work on improving them we should try and rid elitism in them.