Imagine if, when you show up to an interview, neither you or your interviewer know the question in advance. Maybe the recruiter or another party tells the both of you what is the question or problem to solve at the start of the interview.
What would happen? This is my hypothesis, this is what I think would happen:
- I, the interviewed, would not feel at a disadvantage. I would not feel like I have to impress the person that picked the problem, the person that has a lot of time to think about the solution and probably already has a preferred solution.
- We would both be incentivized to work together. We would both get a much better idea of what would the day to day of working together be like.
- They, the interviewer(s), would get a much more realistic view of what my work style is like. Instead of showing that I can memorize how to solve the contrived examples from interview question web pages. They would now how I learn new things and how I problem solve.
- I would also get a much better idea of what it is like to work for that company and with that team of people. What their expectation is of what I know, how quickly I need to wrap up and how willing they are to collaborate.
A conversation with a recruiter and then the interview
I had a conversation with a recruiter where I explained my hypothesis, they brought up a good point: “I agree to a large extent, but this is the system we have to work with, how else can we standardize the questions and the evaluations”. This makes sense, but it is not really an obstacle, it just takes a bit more work to set up a pool of questions that the interviewers do not know ahead of time.
The recruiter also said: “We know senior developers have not hit the books in a while and do not have these algorithms fresh in their memory, we take that in to account.”.
That company invited me to a class of sorts to help me prepare, and their prep materials are excellent. What I remembered from that class was:
- We want for you to solve 2 medium difficulty problems in 45 minutes
- We want to hear your thought process
- We want to see if you can take hints
- We are more interested in completeness, that your code actually runs. We also look for optimal solutions if possible.
Then I had the interview with the company they represented, and I did not do well, I did not pass the interview. I answered the first question fairly quickly and wanted to go on to the next, but the interviewer asked me if I knew about “Priority queues”. I said I remember vaguely but I did not recall at the moment. I wanted to quickly move on to the second problem before I ran out of time. But we spent maybe 10 minutes talking about how I would implement the solution and/or how I would implement a priority queue, and by the time we got to the second question I was flustered.
At the end you get a few minutes to ask questions of them and what I found interesting is the interviewer’s response to one this question: “I am a generalist and as such I do not go very deep in any area, am I a good fit since I am a generalist?” in their answer was longer than this: “Yes, but I think the heap search is an algorithm everyone should know….”.
My conclusions from that interview
This experience only served to reinforce my beliefs, I am sure the interviewer had already seen the problem and I believe that:
- they already solved the problem them selfs and probably did not take 20 minutes.
- they already had the ideal solution in mind.
- maybe they wanted to find a problem that uses a priority queue. Sometimes they already know what they want to ask and then look for a problem that centers on that topic.
Is that really what they do at your company?
Much later, I conversed with a hiring manager for another company and I finally got the courage to ask something I’ve always wanted to: “Does your day to day work really involve solving problems around data structures, optimizing algorithms that you learn at School and knowing the time complexity of a function?”, “When was the last time you said” ‘Thank God we hired this person that can answer interview questions in 20 minutes and knows the O notation for this problem’?”.
Basically I got the same answer, with a grin : “It is what it is…”.
The interview arms race
I use to say, half kiddingly : ” Engineers should write computer program manuals and documentation in binary! So that the users will need another engineer to get answers! or at the very least will need to buy a tool from us!”… I got this idea from lawyers! I am convinced that Tax and Immigration law is written in such a way that lawyers guarantee them selfs some job security.
The interviewing process has created an industry of engineers training other engineers, know about more than 15 of these: Interview preparation pages.
Much like the military arms race, someone comes up with a better bullet, so someone else needs to come up with better armor. I’ve noticed that in this industry of interview preparation they are needing to find more and more contrived puzzles to disguise the fact that you need to cleverly employ the same tools, data structures and algorithms, that have existed for decades now…I can not think of any truly new data structure in the last decade or so.
Interviewers go to the same pages to select a question, take as long as they need and then expect the interviewed to answer in 20 minutes. That is an ever shrinking pool of questions and not all problems around data structures or algorithms can be solved in 10 minutes or even 2 hours, specially the real-world and really interesting problems.
A friend of mine told me: “I can tell when candidates have prepared in LeetCode® … they start answering all the same way! They take the same approach”.
I found this video of a young engineer that left a FANG company because they discovered their passion for solving puzzles and helping others solve puzzles, well, prepare for interviews. This other video is of a very young, very mature engineer and I liked what they had to say.
My style goes against the grain
I’ve recently concluded that the reason why solving puzzles is so counter intuitive for me: I like to take my time… I like to solve complex problems, that is what makes my job interesting. For example when I was told that the problem to solve was: “How do we track our stuff all over the world, through all the different processes, databases, services, etcetera” or ” How do we scale our infrastructure” or “How can we monitor and restart our services”.
I love to take my time and look at the problem from different angles, think of corner cases, process improvements and documentation. Some may consider these things grunt work, it is not as sexy as solving a problem with a new algorithm no one has seen before.
This reminds me of how young folks that grew up seeing tv shows about police and detectives, they go in to that line of work expecting to have car chases and solve interesting cases using the latest DNA technology… but then really shocks them… the day to day is quite mundane.
I see my self more as a chef than a short order cook. Very different approaches to basically the same thing, food preparation.
Companies do not look for creative people
What are you really know about the candidates?
When you hire an engineer that can solve puzzles in 20 minutes and give you the answers you expect in the way you expect, are you really hiring someone you want to work with? You know very little about:
- how they handle long periods of stress, ambiguity, work that is not very interesting.
- are they easy to get along with or are they toxic? Remember there is also training on how to pass the culture fit questions.
- Their overall work ethic, this is another thing that is hard to gage from interviews.
The success story of someone that studied hard to get hired at google.
What I see in the near future
I have interviewed with companies that contract Karat®, and I like what they do but there is more that needs to be done. To start, they are engineers that are specially trained to interview, not your employee that does interviews on the side. I thinks that is a very good step in the right direction.
They are an independent party, which means that they can be neutral about your approach and solution. They can focus on your approach and seeking out your true level of proficiency, that is their job!
I think there is more that they could/should do, but these ideas I will keep to my self 😉 I may want to start my own business.
https://medium.com/byteboard/theres-a-lot-more-to-engineering-than-coding-f04af63a1ccd
Staying sharp
Some interesting videos
What I learned after tons of interviews at Google
https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
The End.