Interviews

This is actually why (or saying the trigger) I create a website and begin blogging.

Recently I was preparing for changing job. Inevitably I have to prepare for the coding interviews. It was funny that the recruiters from all of the companies I interviewed with suggests online coding websites to get prepared, and first ones of every list is leetcode.com.

During these 3 months in preparing, I was discussing with my teammates/friends about what we want to see from interviews as interviewers. We agreed that the thought process is most important one, and then it’s the problem itself, since it’s possible to get stuck, or go some circles if you first met this problem. No one will need those and thus and practice on those algorithm problems in daily work.

But I think I’m wrong, or at least not that accurate on the percentage of characteristic they would like to see from you during the interviews. Let’s list what areas we should have as a developer:

  1. thought process: the way you approach a new problem, and how you solve it
  2. communication: can you make others clear about your thought
  3. algorithm and data structure: basically CS knowledge
  4. coding style: naming, methods, spaces
  5. result correctness:
  6. tests cases: how do you want to test your program to ensure it’s correct

I think I put too much weight on 1 and 2 because I thought that’s the part that shows how a person works in real world, and whether a person is a good cooperator. But yes, that’s my thoughts, or the thoughts from the people I know.

In a 45 or 60 minute interview, it’s hard to express all of the area listed above, which you have to, so how? In my opinion the part I can work on, and improve is the speed of writing coding. So that I could write code so quickly enough to still keep the time and effort I will use to communicate and explain, to test and walk through the algorithm. It’s not because it’s a mandatory in work (and my friend and I thought it’s kind of ridiculous), but it’s for the interview to be perfect(无懈可击) (as much as possible) that people won’t have something bad to put on their feedbacks.

Why? because you don’t know the interviewers, it’s possible some people want perfectness of code, some people think communication and collaboration is the most important thing, while others like to see clean code and meaningful names. The bad thing is that you don’t know what they want, so all you can do is give them all.

This blog comes an action item of my reviews the interview I’ve been through. I will keep working on the algorithms as a long lasting background job to write down my journey on this. I will try to dive deep on the algorithms, complexity analysis and do clear explanations.

You are not guaranteed to succeed, but you are guaranteed not if you don’t try. Do my part, and accept the rest.