Originally posted here
I studied computer science at Stanford. You probably would’ve expected me to be swimming in job offers. In my sophomore year and first-half of junior year, I got a lot of interviews, and I failed every single one of them. And not in a, “this person is qualified, but other people are better qualified” type of way. It was more like a, “Why did we ever bother interviewing this person?”
For example, I would stumble on simple questions like generating all permutations of a set by writing a recursive program that wouldn’t even terminate (even though it was something you would learn how to code by the second intro to CS class).
About halfway through the interviews, the interviewer would seemingly give up in frustration. A few days later, I would receive the dreaded, “Thank you for your interest” email.
“Maybe this just wasn’t meant for me,” I would tell myself. I was a straight A student, but that would only get me to the interview stage, where I would inevitably fail in a spectacular fashion. All of my friends seemed to be killing it, getting internships at the standard Google/Facebook/hot silicon valley startup. Maybe people were “handing out” jobs, but they certainly weren’t handing it out to me.
By the time I reached the end of my junior year, there wasn’t any more time for me to complain about how the technical interview was unfair or how I was behind because I never did competitive programming. I started working through CTCI (Cracking the Coding Interview) and EPI (Elements of Programming Interviews). In the beginning, I would always read a question, then inevitably flip to the answer because I didn’t know how to solve it. Eventually, I could do the easy problems, then the medium problems, and so on.
Finally, this came in the mail. 
Over time, I’ve learned that interviewing is a skill. If you treat interviewing like a skill, and not an inherent capability, then you have the agency to improve enough to get your dream tech job. It’s easy to lament the state of software engineering interviews, but it’s harder to accept it and create a plan for success. But would you rather complain and feel good about yourself or have a job?
Takeaways
- Interviewing is a skill that you can learn
- Set up a system for studying for interviews (Listed below)
My study system
- Every day, do at least one problem from a book/website listed below. As you get closer to the interview date (e.g. 2 weeks away), I would recommend doing 3-5 interview questions a day.
- Get a whiteboard (or a pen and paper). Make sure to talk out loud or write down what you’re saying (it’s not enough to work through a problem in your head)
Tips for working through a practice problem
- Time yourself to test if you can really solve a problem in an interview setting (I usually give myself 30 minutes)
- As you work through a problem, think of questions you would ask to clarify the problem statement/constraints
- Sketch a general approach for solving the problem before writing code.
- Once you write the code, think of test cases and run those cases through your program
- Finally, compare your program against the reference solution and see what’s different
Books used
- Cracking the Coding Interview
- Elements of Programming Interviews
Websites used
- InterviewBit
If this post has helped you in any way, please subscribe to reginaldlong.com
Top comments (18)
Who really wants to work for a company that asks you to whiteboard basic CS nonsense that you can google in less than a minute? That's a sure sign that the people who hire you are in no way connected to the people you will work with, because those people would have questions actually relevant to the job. I got my degree, but if a company asks me to balance a tree on a whiteboard for the interview, I leave. There might be some positions where such knowledge is actually what you do every day (if you like that kind of stuff), but for most jobs it's not worth your time: Nice to have seen it once, but if you don't remember it, who cares?
I agree and disagree - I agree that whiteboard interviews are usually useless, but I don't agree that it's a sign the people giving the interview aren't the people you'll work with.
A lot of the places I've worked, the technical people brought in to give interviews alongside HR or management have no idea what they should be asking, and so instead of asking the sort of questions they'd have liked to have themselves, they fall back on generic whiteboard or tech test questions because they think that's what everyone else is doing.
It's not necessarily a deal-breaker for me, but it would make me super-probey when they get to the "do you have any questions for us" part of the day.
Ok, agreed. Been there, done that, when someone asked us to create a meaningful coding test. Personally, we didn't go for whiteboard tests, but our idea wasn't that much better ;-)
Sometimes it's more about seeing someone's problem solving skills or how they approach a problem than the problem or solution.
I do agree that problems like these do not reflect what majority of the job will be after getting hired. This is especially true for SDM's who are getting asked to do this type of interviews.
Yaaas. All of this.
Technical interviews are a very cold-damp-intimidating space. There's so many bad practices that can come out of left field, (thank god riddle problems are dying).
But treating it as a skill is 100% great advice. I'm glad you didn't give up and kept at it.
Congrats!
This is why I wrote this:
linkedin.com/pulse/bs-hr-part-1-st...
They interview developers as if it was "Who wants to be a billionaire" show.
Talking out loud when practicing something you have to talk out loud for is seriously underrated. Yes it feels awkward, but it will multiply the effectiveness of your practice.
Welcome to Amazon :D
Reminds me of university, where I learned how to do exams. In the end I was good at exams and not at the job I wanted to do, lol
I should have read something like this months ago. Congratulations for you new work!!!.
@reggylong can you name the authors of this books, i found a few books entitled 'Cracking the Coding Interview'. Thanks.
The author is Gayle Laakmann McDowell.
Congrats and thanks for sharing!
Well done sir :)
I'm still amazed that the technical interview thing is such a hurdle in some places and I wonder to which extent it's a cultural thing.