Case study: How to write executable code in 45 minutes session?

Sept. 11, 2019

Introduction

It is the topic I like to work on, research and talk about. I had 45 minutes session to work on one algorithm. My goal is to learn how to write executable code in less than 45 minutes.

Case study

I experienced the pain to work on algorithm problem solving last month. I did write down my mistake, the algorithm is related to binary search. And there is another one is related to word ladder II. And there is another one related to DFS algorithm.

So I learn that it is important for me to warm up algorithms to prepare. I spent three hours to study 10 algorithms related to coach sessions I had in 2018, I was so surprised to learn those algorithms since I had no idea what those algorithms are in detail until I read my own blog and source code. Most important is to document my learning, and those mistakes and error usually will repeat itself in my performance.

Also, I learn from those interviewees I met after August 20, 2019. Here are a few things I did today.

1. Go over the example, spend at least 3 - 5 minutes to work on test case, step by step, work on test case, and explain my idea, what I should design in terms of time complexity, variable names.
2. Work on solution using the test case, explain what I think, explore. Make sure that I fully understand the problem. Also the interviewer knows what my idea is.
3. Ask permission to code. The interviewer said that I can code pseudo code or executable code. I choose to write executable code.
4. Because I work on test case and warm up, I can write very clearly and I explain to myself as well.
5. Once I finish coding, I immediately say that I like to test code using the following test cases.

I start from simple test case, "", "a", "aa", "baa", and make sure that every line of code is executed. I also added comment to explain the code.

General advice

It is a good idea to learn to solve as many hard level algorithms as I can. Since the hard level algorithm takes time, it is better to work on easy level ones, break into easy level ones. Make sure that I can solve those easy level ones without any bug.

Recently, I worked on word ladder II, 126, and I started to work on easy one, ask interviewees to work on interviewing.io.

Another thing is to work on my communication skills. Most important is to go over a test case, step by step, make sure that I understand the problem, and also solve the problem using my hand first.

Next thing is to code the solution followed by a few basic test cases.

I think that in general I should learn how to test my own code, learn how to break the code, and evaluate the solution again and again.

Crafting skills are so important, and I should always do my best. No matter what I write, either a blog, a discussion post, or an algorithm, comment, make sure that I can express myself clearly.

Actionable Items

I did not review my algorithm practice last weekend. Today I was surprised that I only spent 3 hours, what I reviewed is 10 coach sessions, a few mock interviews on pramp.com.

I should take thing seriously. Usually I should review around 100 - 150 algorithms in order to cover all basic topics.

Here is the transcript.

Lessons learned 

I like to document lessons learned from my own experience. I should stay humble, and also work hard like sprint 100 meters to test my own code using as many test cases as possible, question every possible things to break the code.

Case 1: Binary search - index-out-of-range, missing else statement for if case. Here is the discussion post.
Case 2: DFS - brute force solution, do not exhaust all possible option. Nice and clean solution, simplified word ladder II is here.
Case 3: Use extra space, worst thing is impossible to implement in five minutes for extra requirement. Implementation is here.