After reading this post and the link there on the ‘Feynman Method’, I’ve decided to read Polya’s ‘How to Solve it’ [1]. I say this as someone who did his BSc in pure mathematics, MSc in CS and has worked as a programmer for a number of years. I meant to read it back in university, but I instead decided to keep applying the ‘Feynman method’, which I find for me is less efficient and more error prone due to my comparatively lower intelligence. The principles in the book shouldn’t be too hard to apply to both coding and debugging code.
They say you can’t teach an old dog new tricks, and you can’t increase IQ, but I’ve recently burnt a lot of actually quite simple coding interviews due to things like a missed edge case, and I wonder whether I can discipline myself to do things in a more disciplined and systematic fashion with this book. Not only for Leetcode/Hackerrank style questions, but for work as well.
On the topic of getting burned on edge cases I myself am in the same boat. I’m very much a speedy, excited programmer. I want to build the thing and see if it works afterwards. This can make me a bit sloppy especially in a time boxed coding problem.
What I’ve done to improve this to pretty good effect is follow this rough formula on problems:
- ask questions
- write out assumptions
- come up with a basic solution (pseudocode)
- see if i can come up with edge cases or converse examples that break my solution/assumptions
- code while stopping occasionally to repeat the previous step
- walk through the code manually with some examples
After doing this a bunch I’ve actually internalized a lot of the edge cases or errors I might have missed before. So I think I am slowly teaching myself to be more precise for these types of questions. It’s slow going but decently effective.
It’s hard to balance how much you should write on paper in place of just coding. Coding in itself allows you to explore the problem, but induces its own cognitive overhead, which might distract you from important insights about the direction you’re taking.
I replied prematurely. It definitely looks like we’re in the same boat regarding programming style. I wonder whether I can apply this with measurable results. It would be nice if it were easier to compare your completion time with others on Leetcode and Hackerrank so that the improvement could be measured.
EDIT: Some context about myself so as to not misrepresent myself as some sort of expert. I’ve been prepping while working full time for 6 months. I was really quite bad at doing the problems initially and now can pretty much knock out most problems without too much trouble. Planning to start interviewing in a month or two.
IMO comparing against yourself over time would be more productive. I say that cause it would definitely stress me out personally if I knew I was in the 10th percentile or whatever. And then that negative attitude could snowball into stopping practice.
If you do want an objective measure for FAANG I think Facebook recommends being able to complete 2 Medium level LC problems in 35 minutes. But again, it’s real hard to mimic the real interview environment of explaining yourself, being able to ask questions, etc. I did find mock interviews helpful early on to refine my process before just grinding problems.
They say you can’t teach an old dog new tricks, and you can’t increase IQ, but I’ve recently burnt a lot of actually quite simple coding interviews due to things like a missed edge case, and I wonder whether I can discipline myself to do things in a more disciplined and systematic fashion with this book. Not only for Leetcode/Hackerrank style questions, but for work as well.
[1] https://en.wikipedia.org/wiki/How_to_Solve_It?wprov=sfti1