‘Practice does not make perfect. Only perfect practice makes perfect’ – Vince Lombardi, legendary American football coach

My leetcode profile ( for evidence that I know what I’m talking about )

A Templated Structure to Algorithmic Interviewing

Organizing one’s thought process is surprisingly hard, and observations of both myself and others has shown me that effective, clear communication and storytelling matters tremendously. Before I start coding or problem-solving, I tell my interviewers that I like to follow a templated structure to help organizing and crystalize my thought process. Each section usually takes me an allocated amount of time to finish and varies interview-but-interview – whether 30-minutes or 60-minutes in length – but they follow a pattern. Let me show!

Clarifying Questions (5 minutes ):
Category and Approach: ( 5 minutes )
Complexity Analysis ( 5 minutes ):
– Time
– Explicit Space =
– Implicit Space ( function call stack allocation ) =
Unit Test Scenarios : ( 5 minutes )
Coding : (10 minutes – 30 minutes )

Why Follow Templated Structures?

1. Ordering : Templates follow orders, and people psychologically love order and structure.
2. Persistency : Interviewers can copy-paste your writings and reference them later when determining if you pass a stage or an offer letter. Your writings will help interviewers refresh their memories days or even weeks following your interview

Your interviewer asks you to code … but wait, don’t just dive into coding!

Please ask questions! The more the better!

Diving into code is tempting – especially with the time crunch that interviewing is. Most interviewers want to see their interviewees type code, with the ideal being working code that passes all unit test cases ( think of a leetcode medium done in <= 30 minutes ). But solid seasoned developers know that before coding, diving into the question under asks matters more. Let’s touch on common clarifying questions to ask include ( and why they’re good to ask ) :

1. Does the input fit into RAM/memory? Can I expect reasonably sized inputs? Do we need to handle for a streaming edge case?
   • TC demonstrates forwards-thinking of edge case scenarios where algorithms need to be made more time-efficient or space-efficient in the event of running into scalability concerns ( e.g. inputs fitting across multiple disks or near RT streaming systems processing +1 million records/second ).
2. Can I expect well-formed inputs? Do I need to validate the inputs?
   • TC demonstrates thinking of whether to write code to handle for malformed inputs.
   • TC demonstrates real-world thinking of commonly-encountered problems with input validation, transformations, or sanitization.
3. Do I need to handle the null case or empty input case ( e.g. input list = [] or input list = None )?
   • Similar to #2, TC shows forward-thinking of edge case scenarios which can manifest in real-world problems.
4. Are the inputs strictly integral? If so, are they all positive or non-negative integers? If they are floats, do we have to account for precision? If inputs are floats, do they correspond to monetary situations – e.g. USD and cent-denominated billing ( e.g. $100.99 or $200.62 )?
   • TC shows thinking about data types, which have been known to cause major technical disasters, widespread systematic failures, or major losses of revenue for companies ( see Y2K incident ).
   • TC shows thinking about how to modify future approach and scoping down code complexity
5. If the input is a tree, can I expect perfect binary trees where each node has 0 or 2 children? Or can we have trees having nodes with a single child?
   • TC is really thinking about the many forms data structures can take on and how to handle edge case scenarios.
6. If the input is a graph, is it directed or undirected? Does it contain cycles or parallel edges? If so, how should a cycle or a parallel edge be handled? Can I have a single node graph with no edge? Do I operate with one connected component or multiple connected components?
   • Similar to part #5, TC is really thinking about the many forms data structures can take on and how to handle edge case scenarios.

But like, what do I have permission to ask my interviewers?

• Hydration : You have permission to hydrate and drink water.
  Your voice can get raspy and dry in a 5-hour onsite and they can dehydrate you. Let’s get your electrolytes and hydration back to normal, functioning levels 🙂 .
• Use pen-and-paper : You have permission to ask to use pen-and-paper – or a shared online whiteboard/collaborative editing tool – to visualize a problem and diagram for 2-3 minutes.
  I’ve observed in myself and others that we problem-solve best with visuals. Unlike digital-only processing, there’s something subconscious that goes on in physical sensory processing with one’s hands and a pen that enables better performance. And given how many different brains and cognitive styles exist in the world, interviewers will bias towards letting you use the mediums that enable your best thinking to come out.
• To get a pause : You have permission to ask to take 2-3 minutes to think about your approach to “drive the conversation”.
  A good interviewer understands that their problems are hard. Keeping a conversation going in (near) real-time matters, but if you need to think for 2-3 minutes due to processing loads of information, go for it!!
• To drive the conversation : You have permission to ask your interviewers if they want to stop you to ask clarifying questions.
  If you get concerned about driving the conversation by yourself, stop and literally instruct me in the beginning “If you want to stop me and ask clarifying questions, please go ahead and do so.”. I’ll know to tell you when to stop so that I can steer the conversation towards areas of interest or other directions.
• Deviate from templated structures : You have permission to deviate from any author’s templated structure, process “out-of-order”, and focus on the sections that highlight YOUR strengths.
  Some of us are better at reasoning about time-complexity ; others on thinking of unit test case scenarios ; and others on coding. I personally want you to focus on the area that best enable your cognitive style.

YOUR GREEN SIGNALS – WHAT DEMONSTRATES YOUR SKILLS

What are some of the “green” signals that interviewers are really looking for? What makes me hire-able to the hiring table? Something that screams to my interviewers “Oh woah, this candidate is amazing! They’re super experienced and they know exactly what they are doing! I wanna hire them on spot!“. Let’s look !

1. TC talks about implicit space/function call stack space – most candidates will talk about explicit space allocation ( e.g. I need to allocate a O(MN) grid for my problem ). But implicit space shows that a candidate thinks about how deep a function call stack can go. It’s super relevant in recursive settings, such as processing a tree data structure, where a candidate should argue that implicit stack space is O(H), H := height of the tree.
2. TC distinguishes coding style : interview setting versus production setting – I usually expect that more senior candidate naturally write code with more readable variable names (e.g. cases_recorded versus cr ). Nonetheless, a solid engineer can argue that for the sake of brevity and time, they’ll use short-hand names, even though in a production setting, they’d make modifications
3. TC emphasizes functional decomposition – the best solutions involve small methods built around SRP ( Single Responsibility Pattern ). In the real-world, developers bias towards small functions that are quick to review and write unit tests for.
4. TC introduces logging/error handling – real world development requires writing debug output to centralized logging ( e.g. Splunk / New Relic ) returning errors ( e.g. HTTP Status Code, HTTP Response ) from caller to callee. Shows evidence of systems thinking.
5. TC writes unit tests/emphasizes Test-Driven Development – software engineers spend half their time writing good code; the other half writing good tests. Mentions of testing show that TC can handle job duties.
6. TC mentions usage of existing library method – in the real-world, let’s not repeat ourselves. We don’t have to write code to compute factorial if a single one-liner math.factorial(n) already exists as a Python method. It shows the DRY ( Do not Repeat Yourself ) pattern,

Tell me the signs that I’m getting better!

There’s a couple of different signs that tell me if someone is getter better at algorithmic thinking and solving Leetcode-style problems. Lemme review some of them!

1. Spending less time – you spend less time finding solutions. You per averages over time decrease on leetcode mediums : 1 hour – 30 minutes – 15 minutes.
2. Beating the user base – beating others in memory-efficiency and time-efficiency. Sometimes, you even beat 100% of users ( in a given language/runtime ).
3. Higher success rate – you tend to write solutions that work, versus don’t work.
4. Immediate pattern recognition – you can see the patterns quickly. You know when to map a problem to a pattern seen earlier such as Two pointers, Arrays, or Dynamic Programming.
5. You’re solving harder problems – problems that used to be hard no longer give your brain a challenge. You take harder problems as you keep solving problems.
6. You write the unit tests – you write up test cases and run scenarios ahead-of-schedule, instead of executing the RUN or the TEST buttons.
7. You can categorize – leetcode problems are categorized by a set of tags ( e.g. arrays, Linked Lists, Graphs ). You can immediately identify a set of tags to classify problems.
8. Bottom-up dynamic programming is first – when given a DP problem, you immediately think of a BUDP ( Bottom-up Dynamic Programming) approach first. You skip the naive recursive steps or the Top-Down Memoization-based approches.
9. You write the solutions – you can write your solution and post them on the website’s platform.
10. Get unstuck less often – you’ll still get stuck on some problems, but you’ll be able to confidently tell yourself that you’ll soon get unstuck. The solution will come to you in a few days or a few weeks ( after subconscious processing ) .
11. Your solution is better than the official solution – hey, sometimes, you can be scaringly bright and conjure up a vastly different solution that’s significantly better than what’s posted. There are so many different solution paths to a problem !!

In Conclusion

Way to go for making it through this section!!!!
I know it’s a lot to digest and to process, but I think all of this is going to be super useful and helpful. I’m personally wishing you best of luck in your future technical interviews 🙂 !