| Sort of surprised to see most of the comments on here actually defending the companies that put so much weight on these types of tests. I think many people assume that interviewers are looking for "thought process" but from my experience as a hiring manager for 6 years, in reality you'll find that most are just looking to "gotch-ya" the candidate. Many interviewers seem to enjoy making a candidate "sweat" as some source of pride. Again, not saying everyone does this, but often times programmer interviewers believe that the harder and more obscure a programming question is the better. We should all agree that coding tests are helpful in assessing a candidate's programming capabilities, but not all coding tests are equal. From my experience, bad coding tests that have little relation to whether a candidate will do a good job are these arbitrary ones. For example: * Implement a merge/quick/radixx sort algorithm that you maybe did 10 years ago in college and have never had to do since. * Implement a linked list/hashmap/some other random data structure in Java even though you would never write on yourself. * Write a program to determine whether a string is a palindrome. * Implement an algorithm to solve this random problem from Project Euler Ones that have been worked better attempt to be comparable to what they actually might do in the company: * FizzBuzz - (While controversial, this helps weed out people who just don't know how to code) * Build a JSON REST API in whatever language you want to manage groceries in a shopping cart. * Write a web scraper in whatever language you want to count the most popular words on a website * Here is a random UI framework that you have never used, use whatever documentation you can find on the web and write a To Do list application with it. Again, YMMV, and depending on your domain certain questions make more sense to ask than others. If you're interviewing as a researcher for Google/Amazon/IBM/Microsoft, then you actually might need to know how to implement some random sorting algorithm because it may be what you will need to implement it in some new SDK/library. But I don't believe that for most companies this makes sense. If you are a hiring manager, ask yourself this: If you had to run one of your current (positive) team members through your current interview process, would they make it through? Would they say they had a positive interview experience? |
What you describe is a horrible approach to interviewing, and points towards dysfunction more than anything else.
In my opinion, the second most appealing non-technical character trait for an engineer is empathy. (Curiosity being #1.) If you have an interviewer who goes on a power trip and actively tries to abuse a candidate, what does that tell you about their company?
Everything is PR, and how we interview engineers tells a lot about how we deal with each other. Would you like to work in a place where being nasty is considered normal - or even desirable?