I mean IQ tests by proxy are pretty universal in intellectual employment. Personality issues and such that might interfere with job success can't really be evaluated in any short amount of time unless the person is so out of it that they are throwing the signals out left and right, but in most cases they obviously hide these issues the best they can. The ratio of bad hires that pass the interview tests for this system are probably lower than that of other interviewing methodologies anyway. Mental health issues will interfere with thinking on the spot and withstanding social pressure, potentially. I think most jobs still have the soft skills portion as well, which probably is more useful for the company than the problem solving, anyway. There's a lot of emotional involvement in problem solving capacity and consistency.
Yet another week and yet another blog on how hiring sucks in software engineering. For whats its worth, I took a phone interview at the company. Their feedback for me and my feedback for them are below
Feedback to interviewer.
========================
The interviewer was knowledgeable, smart but is unhelpful in guiding towards answers. I had started on correct path of using two pointers. When I got stuck, he expected me to resolve it myself. You can view it in two ways. Either he expects interviewee to solve end to end,(Employees must perform tasks on their own so we should not help). or we expect rockstar candidates who don't need any help. Depending on your company's reputation in market place, you need to decide what path you will take. Otherwise, you will be interviewing many many candidates before finding one you like(not one who can do the work). Also, There was no reason to make me compile the whole code. I had adequately demonstrated that I can write Java syntax(or that I cannot write Java syntax, depending on your expectations). When I write an algorithm or code and you want to test it in a interview setting, you must walk the code with me and evaluate a few cases. Or ask me to walk through the code with a few test cases. Its just a travesty if you expect me to use the "run" button. That just introduces additional complexity where I have to write absolutely correct syntax. In a real world job setting, I would have IDE support which shows compile errors as we type. There it is easy to complete compilable code in less amount of time.
Their feedback to me.
=====================
The candidate had some ideas in the right direction, yet it appeared challenging to conceptualize an acceptable solution and implement end to end. The candidate understands CS fundamentals and I certainly see potential in the candidate. To continue practicing, the candidate can continue working with these algorithmic patterns: DFS/BFS greedy sliding window divide and conquer recursion dynamic programming. A popular site to practice algorithms is leetcode.com. To ensure practice conditions close to the interview setting, I encourage 1. Code in a notepad 2. Setup a timer 3. Talk during a practice 4. Create some psychological pressure, e.g. ask somebody to watch you during practice, record yourself on a video, etc.
Almost every week there is some kind of interview post on HN. And almost every time it is about the leetcode-esque riddle interview. The question serves almost like a test of did you read the manual, because the only solution (most performant guaranteed correct version) is the one you aren't going to come up with on your own in a room in fifteen minutes unless you knew it ahead of time. So, in interviews like this, I think of them as more of a standardized test than an interview because that's what it is in reality.
