| There are three things I'd like to share with you. First, I've hired dozens of people in the last year, and the main piece of advice is this: I'm rooting for you. Seriously. I spend a TON of time sifting through resumes, doing phone screens, checking Github repositories, and on-site interviews. I really, really don't want to do it. Ideally, the first candidate that walks through the door is perfect, and I don't have to even talk to anyone else. Done. Finished. Now I get to do real stuff at work. I'm rooting for you. Honestly. Second, the answer to your question is "No". You don't have to know how to invert a binary tree or re-implement quicksort. For good interviewers, the point isn't for you to reinvent or regurgitate complex computer science problems in 30 minutes, but rather to allow you to demonstrate your thinking. Can you write code? Can you walk me through your thought process? If I throw a curve ball, can you adapt your solution to that? You don't need to know all of those things you mentioned, but you should be able to demonstrate that, given enough time, you can do those things. We only get 30-45 minutes with you. The goal is to figure out what you do know quickly, and then gauge your capacity to grow beyond that. Look, there are some things you must know to get a job with me, and there are some things that aren't important. "Can you write code?" is the bare minimum. I wouldn't hire a carpenter who doesn't know how to use a hammer, but just knowing how to use a hammer doesn't make a carpenter good, either. There are an infinite number of skills out there that you can learn. I don't expect you to know them all. I expect you to know SOME of them. I expect you to be able to write code, but I expect you to do a little bit more than that. Most jobs I've ever had required on-the-job training. I have to learn how the new job does code deployments, how they structure their code, maybe a new programming language. I have to learn how they do standups (if any), code coverage (if any), and one-on-ones (if any). I have to learn what's in this database and how it connects to that API and what framework they're using. Everyone uses frameworks differently, so I have to figure out the quirks and esoteric choices that this particular company made. The point is this: you don't have to know everything. You need to demonstrate that you can code (the bare minimum of the job), you have to demonstrate that you can learn and ideally learn quickly, and perhaps most importantly, you are hopefully someone that I would like to sit next to for the next six months. I'm not going to tell you not to stress out, because that's perfectly normal. But what I will say to summarize are these two things: 1. We are rooting for you. 2. You don't have to know everything. Just be your normal smart, enthusiastic self and do the best you can. Keep those in mind and you'll be fine. |
I mean, you should leave the qualification verification to those entities who are more qualified to do it, and who have much more time - I guess if the university awards a degree after 4 years of involvement with the candidate says much more than you can deduct in 30 minutes during the interview set up.