Hypothetical interview question: Write a function that finds the distance between two words.
Candidate A: Can recite algos and remembers that Levenshtein distance is the answer.
Candidate B: Has no idea what Levenshtein distance is, writes a brute-force solution with the understanding that it's not an optimal solution. After the interview she spends more time learning what she doesn't know, learns about Levenshtein distance, and sends you an optimal solution via email.
The above is a real-life scenario, so my question to you is - how do you decide who to hire?
That's great for the ones that make that much, but this kind of information is what's causing Bay Area housing and rent prices to sky-rocket. I have worked with multiple engineers in two large corps and most people make anywhere between 100k and 200k.
After going through all the steps with a big corp, I was "offered" to do an additional interview if I wanted to be assessed at my current level (they leveled me lower). I stood my ground and respectfully declined, and eventually they made me an offer for the correct level. What I learned the hard way was that you need at least one more competing offer, otherwise you won't have any leverage.
Personally these days I just buy albums and individual songs from iTunes. I like to "own" my music. They key is to have a budget and try not to exceed it.
I used to work at a valley big corp (social network) and interviewed a ton of candidates. My approach was as follows:
- Review candidate's resume and side projects to get to know more about them. This helped with getting to know their work and finding things to discuss beyond the interview exercise.
- Before diving into the exercise I would out right tell the candidate what I was looking for in regards to the exercise; e.g. "I'm not looking for a complete/perfect answer but I'm looking to have a conversation about the pros/cons and edge-cases. You can write on the whiteboard as little or as much as you want to but either way let's have a discussion. Let me know if you feel stuck at any point, and I'll make sure to let you know if you are/aren't on the right track. If you don't know/remember something just ask me; it' fine, nobody knows everything."
- I didn't put too much weight on whether the candidate gave a complete answer or not, or how much I had to help them. I basically asked myself a simple question: "Do I feel like this person would be a productive contributor here and are they someone I would be able to work with?"
- I always did my best to go into the room with a relaxed and conversational attitude. I was there to pass the candidate and not to fail them for random reasons.
- I passed most people and only failed some when it was somewhat obvious to me that they really lacked some very basic foundational pieces, or when I felt like they weren't someone I would want to work with (for various reasons).
Towards the end of my career there I started to really dislike interviewing because I would personally put so much effort to passing candidates, but they wouldn't get hired because other interviewers left feedback like "I helped the candidate too much" or "they didn't even know what a TRIE tree was" or "they struggled with X" or "the solution had bugs" or "the solution wasn't complete".
They interesting thing was that the same interviewers that failed candidates for seemingly random reasons, were also the ones who left confusing feedback or not enough feedback. Also the same interviewers either treated candidates poorly or they showed boredom and agitation.
Candidate A: Can recite algos and remembers that Levenshtein distance is the answer.
Candidate B: Has no idea what Levenshtein distance is, writes a brute-force solution with the understanding that it's not an optimal solution. After the interview she spends more time learning what she doesn't know, learns about Levenshtein distance, and sends you an optimal solution via email.
The above is a real-life scenario, so my question to you is - how do you decide who to hire?