I believe you must have had the following experience in your career as a developer, sometime in the past:
And you felt helpless afterward and do not know where to go and how to improve in coding challenges so you can do better in the future:
There is a wonderful book written by Gayle Laakmann McDowell called “Cracking the Coding Interview” that I would recommend to you.
Gayle recommended the following steps in her book. Remember sometimes it is not always about technical skills, but you also have to have some communication skills along the way:
7 Steps
- pick an all encompassing test case with input and output (not an edge case)
- explain a brute force asap (not code it), slow but works
- stating time and space complexity for the brute force approach
- Optimize
- choose a good I/O example to cover as many requirements as possible
- think about every data structure and variable you will use
- apply Test-driven-development if possible, but also follow your instinct, maybe reverse engineer it!
Even though you’ve read the book, you could still make the following mistakes:
- begins coding too early before completing data structure brainstorming and thinking about all of the steps along the way
- not using all given conditions / not understanding every detail of the problem
- using the wrong data structure
I am introducing this method of coding in the next few weeks by solving Leetcode problems, stay tuned!
Controversy
- “Software Craftsmanship”: coding on a white paper is not practical because as a developer, you always code in an IDE
- suggestion from Java-8 certification Book: you should try coding on a white paper because in an IDE compiler-, runtim-errors are caught automatically. And you do not have any autocompletions on a white paper so you are basically on your own!
- there is not 1 interview method out there that is fair! Most of the time you only have 1 hour to complete an interview.
