In this blog post, I share some things I am learning after reflecting on my past experiences that can help myself and others to improve coding for technical interviews and online assessments. Coding for technical interviews and online assessments is different to coding for university or coding on the job.

In a technical interview, you need to meet the bottom line while emphasising how you communicate your thought process in a way that is easy for the interviewer to understand.

In an online coding assessment, there is no interviewer, so you are essentially communicating your idea to yourself while meeting the bottom line. Though, in some cases, you may have to discuss design decisions in the next stage of the hiring process. Therefore, it makes sense to write clear, clean and concise code or as my mantra once was, "Nice documentation and clean code that works".

Objective: Develop ability to solve unseen technical interview and online assessment coding questions quickly.

Bottom Line: Whoever writes the optimal code, passes all test cases and communicates their idea the best, in the shortest time, moves onto the next stage in the hiring process.

The objective is there to keep your eyes on the prize whenever you are practicing coding questions. You should always remember that the goal is not to be able to solve every problem out there. It's like machine learning, where you are given the inputs and outputs and you have to learn the function that maps input to output. Inputs are coding questions and outputs are solutions in this case. Learning the function is achieving the objective and meeting the bottom line.

Given the objective and bottom line, here are some things you can do to change your job hunt outcomes for the better and progress to the next stage of the hiring process more often.

How to approach an Interview?
Types of Technical Interview Questions
Types of Online Coding Assessment Questions
Throughout Solving the Coding Question

Communication
Experience
Speed (Quickness), Distance (Progress), Time (Intervals)
Coding Style and Design
Be Thorough and Rigorous
Be Systematic and Logical
Embrace Prototyping
Avoid Common Mistakes

Before Solving the Coding Question

Choice of Tech Stack
Routine
Problem Comprehension
Problem Intuition
Ask Clarifying Questions
Problem Decomposition
Use Pen and Paper

During Solving the Coding Question

Writing the Algorithm
Translating the Algorithm to Code
Getting Stuck
Getting Unstuck

After Solving the Coding Question

Testing
Deugging
Optimality

Practice and Preparation

Documentation
Simulation

Change Your Reaction
Change Your Mindset

How to approach an Interview?

In an interview, most candidates don't know that you need to present a convinicing narrative that effectively communicates why you are the best candidate for the position. This should be a coherent story that chronicles your contribution to the companies you have worked for in all the roles you have held up to present.

Most candidates are also unaware that they need to show enthusiasm for the role through positive body language and genuine curiosity by asking meaningful questions that demonstrate your level of commitment, understanding and vision of the role.

Finally, whilst preparation is a factor for any serious candidate, remember to be natural and present your best professional self on the day. It's okay to have pointers and prompts to guide your responses and direct the conversation flow of the interview but be a bit impromptu and improvise as this will help you if the interviewer decides to throw a curveball. The plan is just for you to have something to fall back on, you don't have to stick to it.

Types of Technical Interview Questions

This is a list of the different types of coding questions I have encountered in technical interviews summarized into a few groups. Sometimes, the question can have attributes from multiple groups thus having an effect on the difficulty.

Topics: The different types of topics that interviewers generally question entry-level candidates on in technical interviews.

Computer Science Fundamentals (CSF): These questions are about basic computer science concepts from any undergraduate course in the field of study. Usually, they will ask you about the basic concepts related to what is done in the day-to-day repsonsibilities of a technical role in that company.

Internet and Networking: DNS, UDP, HTTP, HTTPS, TLS Certificate, DHCP, TCP, BGP, ARP, etc.
Performance: The different types of memory in a computer, e.g., static, call stack, heap, etc.
Concepts: Repetition (Iteration vs Recursion), OOP, DSA, primitive types vs pointers, etc.
Technical Internals: What is the complexity of python's sorting algorithm? What is the difference between JRE, JDK and JVM?

Coding: This is either a standard leetcode style coding question or a bespoke question that people on your potential team have solved in their day-to-day repsonsibilities before or something similar to it.
CRUD App/REST-API: They can ask you to build a simple CRUD (Create, Read, Update, Delete) app or REST-API from scratch that is a simplified version of the app the company actually uses or they could ask you to build a bespoke version that is taken directly from a challenge they have previously encountered in their day-to-day technical roles.

Format: This point lists the different general formats that the above question topics come in.

QA: This the general format for CSF questions. The interviewer will ask you a question and you will have to give an answer, usually the correct answer, but they may ask you a subjective technical question and look for the reasoning behind your choice.
Multiple Parts: They can ask you a question with multiple parts that may or may not be related.
Dependency between Parts: They can ask you a question whose answer depends on the answer to the previous question. Sometimes, they may even make it so that you cannot move onto the next question without answering the current question. Rmemeber to exploit the fact that current question informs the next question.
Increasing Difficulty: They can ask you questions that increase in difficulty.
Simple Twist: They can ask you a question with a simple and relatively obvious 'twist' that will become apparent after some initial thinking.
Complicated Twist: They can ask you a question with a more complicated 'twist' that will require some combination of thinking, previous experience, knowledge of basic and advanced DSA.
Complex Twist: They can ask you a question with a complex and opaque 'twist' that will test your ability to apply basic, advanced and even uncommon DSA. This type of question requires some previous experience or big hints to solve in time.
Long Question: They can ask you a question that they know will take you longer than the allotted time to solve just to see how you work through it and how far you get.
Known Question: They can ask you a question that you already know. In that case, it will be up to you to use all your experience to solve the question efficiently.
Unkown Question: They can ask you a question about something you have never heard of before. That is, the question is not even conceptually familiar to you. You will need to go into full problem-solving mode in order to come out victorious in this case.
Tricky Question: They can ask you a tricky question where if you know the trick then you will solve the question quickly, even before the time is up. However, if you don't know the trick, then it will take you longer than necessary.

Types of Online Coding Assessment Questions

The types of questions asked in online coding assessments are quite similar to those asked in technical interviews, although they do slightly differ.

Topics: The topics for online coding assessment questions are the same as the technical interviews.
Format: The formats for online coding assessment questions are the same as the technical interviews with the addition of MCQs as a format used for CSF questions as well.

Throughout Solving the Coding Question

Throughout the process of solving the coding question (before, during and after), there are some things to keep in mind and internalise that will enhance your inerview performance. After you have learned how to do these things and build the habits, they will become second nature and you will reap the benefits from then on.

Communication

The short version is that you should say what you are doing. To expand on that, you should voice your intentions, share when you are stuck, explain how you intend on getting unstuck, take any hints from the interviewer into consideration as this information will most likely help you solve the problem. Your statements, word choice, actions and body language when communicating your code to the interviewers should be deliberate, decisive and intentional. You should give the impression that you are sure of yourself, your solution and the tools you have chosen. Be comfortable, articulating your solution at various levels of abstraction leaving no doubt in the interviewer's mind that you are knowledgeable and confident in what you are saying.

Experience

Use your experience with past coding questions to learn from your mistakes, make connections to the current coding question you are facing and reduce the question to an instance of a past question if it fits.

Experience is king and will usually be the source of 'luck' that will enable you to solve questions quickly. It is hard earned but when it pays dividends you should jump at the opportunity to exploit your experience as you have earned that interview 'luck' through all your practice, past interviews and past online coding assessments.

Speed (Quickness), Distance (Progress), Time (Intervals)

The relationship between speed, distance and time is shown above with the DST triangle. We will talk about these concepts in the context of technical interviews and online coding assessments. It's important to keep in mind the relationship between the three and realise how they influence each other so you can maintain some sort of dynamic equilibrium.

Speed (Quickness): Try to move steadily through the coding question. Ideally, you should aim to type with speed, think quickly and make rapid progress through the problem at a steady rate. This is the level of performance we are going for. The faster you can type, the smoother the transition from idea to executable code will be.

Distance (Progress): The feedback loop that drives progress is the cycle of getting stuck and unstuck. The interviewer may have in front of them, some common checkpoints where candidates usually get stuck and have the percentage of candidates who make it that far at each checkpoint. The interviewer wants to see you struggle with the question so it is likely that you will get stuck on something or make a common mistake. Don't worry, it is normal and what matters is that you overcome these challenges in the interview and do yourself justice in the process.

Time (Intervals): It's important to be conscious of time so you can track your progress through the question and know when it's time to switch gears, change strategy or move onto another question. Usually, coding interviews last for 1 hour each with 45 minutes for coding and 15 minutes for you to ask questions afterwards. Important intervals to track are every 15 minutes and every 5 minutes. For the former, you aim to understand the question in the first 15 minutes, code the solution in the next 15 minutes then test, debug and discuss optimality of your solution in the final 15 minutes. For the latter, you should ask yourself if you are stuck every 5 minutes to keep things moving; if you are stuck then get unstuck ASAP.

Coding Style and Design

"Nice documentation and clean code that works."

This is the simple mantra I used for building a solid foundation in coding. The documentation in this context refers to comments in the code that help me and the interviewers understand what I am doing if it is not clear from the code.

Coding Style: You can follow the Google style guide for any programming language you choose to use as an example of how to write clean code. Some more general advice would be to be consistent with your variable names, function headers, class headers, etc. Choose names that are short, descriptive and practical.

Design: Use your OOP principles, design patterns and avoid code smells when writing your solution code. Remember to keep it simple and concise by using incisive syntax. Good design requires little debugging. The winning formula for interview and online assessment code is clean, correct, optimal and short. The questions in these interviews and online assessments are generally not designed to be long and tedious. There are always exceptions but keep that in mind.

Be Thorough and Rigorous

Being thorough and rigorous will help you get stuck less often. This means you will progress at a faster rate and make less mistakes.

Thorough: Don't leave any stone unturned. Address a coding question with mutliple cases with a case-by-case analysis ensuring you cover all cases. During testing, catch the bugs, prevent the errors, cover the base cases, edge cases, corner cases, boundary cases, etc. During optimality discussion, mention the blind spots, weak points, strong points, pressure points, stress points, oversights, bottlenecks, apertures, etc.

"God is in the details."

Rigorous: Be precise and crystal clear about the purpose of every variable, statement, code block and structure (sequence, selection, repetition). Don't include any unnecessary details.

"The devil is in the detail."

Be Systematic and Logical

Being systematic and logical will bring clarity and organization to your approach which will be reflected in your solution. It will allow you to keep track of what has been dealt with and what still needs to be addressed.

Systematic: Have a strategy for tackling the coding question at hand and be methodical and meticulous about how you implement it. This will keep you focussed so that your mind doesn't wander away from the problem and you can be in the 'zone'.

Logical: Coding questions are inherently logical, so they require you to tackle the problem step-by-step.

Embrace Prototyping

You should start with a simple solution first, then iteratively improve it by repeatedly refining it and running it against the available test cases. This method ensures that you don't leave the interview with nothing and fosters a builder's/experimenter's mentality.

Avoid Common Mistakes

Avoid the common mistakes made in technical interviews and online coding assessments. I aim to make a separate blog post about this but for now I will include the ones that come to mind first.

Misspellings/Typos
Incorrect order of parameters in function call
Calling the wrong function
Off-by-one errors
Syntax, logic, compile and run time errors

Before Solving the Coding Question

Before solving the coding question, there are a few things you should do to set yourself up for success.

Choice of Tech Stack

Choose the tech stack you are most comfortable with if the role doesn't enforce one on you.

Routine

Have a routine that makes you comfortable and gets you in the right headspace for the technical interview or online coding assessment. Take all of your preferences into account. If you prefer morning over afternoon and evening then do it at that time of day. If you have a music playlist you listen to that mentally prepares you for these kinds of situations then go with it. If you like to go for walks outside beforehand then do that. Go into the technical interview or online coding assessment with an open and fair mind.

Problem Comprehension

Problem comprehension refers to how well you understand the problem. Try to get to a stage where you read the problem description thoroughly once and are able to know which type of problem you are solving, which DSA are required, figure out an optimal algorithm to solve the problem and then just do it.

To improve problem comprehension, you need to practice reading many problem descriptions and learn from experience. It's not really the answer I want to hear either but it's all I have for now. This needs more research but your problem-solving abilities will improve as you go from coding question to coding question. You are trying to make it so that after reading the problem description, your first few strategies contain the optimal strategy. I suppose what you could do intially is to read the problem description and make sure that the first few strategies are at least correct. This brings us onto problem intuition.

Problem Intuition

Problem intuition is about what your initial thoughts about the solution are after reading the problem description. It sounds like the description for problem comprehension but it is different. This does not involve thinking about the problem at all. It's about your first knee-jerk reaction to the problem and seeing how close you are. You should always trust your intuition but use decision-making as well.

To improve problem intuition, you once again need experience and exposure to many different kinds of coding questions. Then you will begin to realise that these questions have patterns and are in some ways, variations on a theme. Again, needs more research.

Ask Clarifying Questions

After reading the problem description and obtaining an initial understanding of the problem, make sure to ask clarifying questions, particularly about the constraints of the problem. This will break any assumptions, falsehoods, misunderstandings or points left out by the interviewers. Now you have a clearer understanding of what is expected of you.

Problem Decomposition

This is about breaking the problem into smaller and smaller sub-problems until you are able to solve it. Try to be modular about how you break up the problems. To improve this skill, you need to be more systematic, logical, throrough and rigorous. As well as that, you will need to gain experience with decomposing different coding questions.

Use Pen and Paper

Use pen and paper to visualise the problem in front of you. It will help bring you closer to the problem and bring a sense of clarity and organisation to the problem.

During Solving the Coding Question

While you are solving the coding question, the following things will take place.

Writing the Algorithm

You will write the algorithm you will use to solve the coding question in pseudocode with numbered instructions either with pen and paper or as comments before the function header. This algorithm will serve as a guide to help bring you back to centre in case you drift away momentarily.

Translating the Algorithm to Code

This is generally the place where candidates get stuck. Go through each numbered instruction in the algorithm and convert it to code in the programming language you have chosen. For this to work well, you need to be comfortable with your chosen programming language.

Getting Stuck

Getting stuck is normal and part of the process of solving coding questions. The most important thing is that you don't remain stuck and take proactive steps to guide against this. You will repeatedly get stuck and unstuck until you eventually arrive at the solution so understand that it's expected.

Getting Unstuck

There are a few things you can do to get unstuck when you find yourself stuck on a coding question.

Reread Problem Description: Read the problem description again and zone in on the part that is related to where you are stuck.
Backtrace: Trace your steps back from the point where you got stuck and step through it line-by-line until you find the issue.
Research: If it's an error, read and understand the error message then act accordingly. If you are allowed during the interview, google the issue, use stackoverflow and chatgpt to make the source of the issue clearer.
Dry Run: Use pen and paper and do a dry run of an example through your program and examine the output then compare it to the expected output.
Narrow down the Issue: Locate the portion of code that is repsonsible for you getting stuck through process of elimination or in a better informed way if you have that information which can rule out large portions of the code.
Covering all Cases: Check if you have covered all cases to ensure you haven't missed anything.
Check your Assumptions: Ask more clarifying questions to check if you are solving the right problem.
Right Syntax, Wrong Functionality: Sometimes when you are translating your algorithm into code, you can write the correct syntax for what you want to accomplish but get results that were unintended. For example, I once tried to sort a dictionary of objects according to a function of two of the object's attributes. When I wrote the statement to sort the function in python and converted the output to a dictionary, it returned the dictionary unsorted. However, when I just allowed the function to return a list, it was sorted but it was not in a dictionary like I needed it to be.

After Solving the Coding Question

After you feel you have written a correct and hopefully optimal solution to the coding question, don't tell the interviewers that you are finished yet. You need to do the following things to make sure your solution is indeed optimal and correct.

Testing

Do some dry runs as previously mentioned or run your solution code against the available test cases to see if they pass all tests. In essence, you want to catch the bugs, prevent the errors, cover the base cases, edge cases, corner cases, boundary cases, etc.

Unit Test: Test a single unit of functionality.
Dry Run: Run an example test case through your code and trace the values of the variables till you get the output which should match the expected output.
Bug: An unintended or unexpected problem with software or hardware.
Error: An error is an instance of a bug that prevents a program from functioning as intended.

Examples: Syntax error, logic error, compile error, run time error, off-by-one error, arithmetic errors.

Base Case: The problem that we know the answer to, that can be solved without any more recursive calls. The base case is what stops the recursion from continuing on forever. Every recursive function must have at least one base case.
Boundary Case: Handling cases where we enter values outside the given range of accepted values detailed in the constraints in the problem description. This usually handles off-by-one errors.
Edge Case: An edge case is a scenario where the input value is at the extreme edge of what is possible or expected. This could be an unexpected input value or a scenario that is unlikely to occur in real-world use cases.

Example: For example, if a system is designed to handle input values up to 1000, an edge case could be when the input value is a negative number or a non-numeric character.

Corner Case: Corner cases form part of an engineer's lexicon—especially an engineer involved in testing or debugging a complex system. Corner cases are often harder and more expensive to reproduce, test, and optimize because they require maximal configurations in multiple dimensions. They are frequently less-tested, given the belief that few product users will, in practice, exercise the product at multiple simultaneous maximum settings. Expert users of systems therefore routinely find corner case anomalies, and in many of these, errors.

Origin of Term: The term "corner case" comes about by physical analogy with "edge case" as an extension of the "flight envelope" metaphor to a set of testing conditions whose boundaries are determined by the 2n combinations of extreme (minimum and maximum) values for the number n of variables being tested, i.e., the total parameter space for those variables. Where an edge case involves pushing one variable to a minimum or maximum, putting users at the "edge" of the configuration space, a corner case involves doing so with multiple variables, which would put users at a "corner" of a multidimensional configuration space.

Debugging

Whenever you are stuck, debugging is a solid choice of technique to get unstuck quickly given the nature of coding questions is that they are small but tricky in a general sense. Use a debugger, if available, to step through the code you have written and add breakpoints so you can track the values of the variables at different points in the program. If you don't have access to a debugger in the technical interview or online coding assessment then use print statements wisely. Make sure you know which variables you are printing and place the print statements in sensible places so you can compare I/O from different points in the program where data changes value.

Optimality

Computational Complexity (CC): Big-O Notation is what we are interested in as it calculates the CC in the worst case scenario. CC is comprised of time and space complexity.

Time Complexity: Time complexity is defined as the amount of time taken by an algorithm to run, as a function of the length of the input. It measures the time taken to execute each statement of code in an algorithm. It is not going to examine the total execution time of an algorithm.

Space Complexity: Space complexity measures the total amount of memory that an algorithm or operation needs to run according to its input size.

Optimality: Is your code optimal and can you prove it?

Blind Spot: Something the optimal solution doesn't consider or is outside of its accepted values.
Weak Point: A part of the optimal solution that is lacking in some way. "You are only as strong as your weakest link."
Strong Point: A part of the optimal solution that does the 'heavy lifting'. Usually a DSA.
Pressure Point: A part of the optimal solution that is under performance strain.
Pain Point: A part of the optimal solution that is causing a problem.
Stress Point: Similar to a pressure point but is a different term in engineering.
Oversights: Some things like different kinds of input that were not considered in the optimal solution or problem descriptions.
Bottleknecks: Some parts of the optimal solution where computational complexity is high and could benefit from the application of DSA to alleviate some of the load.
Apertures: Types of input for which the output of the optimal solution is undefined.
Improvements: Don't be surprised if you are asked for these. Use your head, I believe in you.

Practice and Preparation

Your practice and preparation should revolve around achieving the objective and meeting the bottom line. If you come across a problem that you weren't able to solve, find the solution and make sure you understand why it works completely. If you hit a plateau while practicing then make sure you rejig your approach. Be consistent and have the mental agility to approach problems from different angles to present alternatives and discuss trade-offs with the interviewers. Increase the difficulty of the problems you solve and time yourself.

Documentation

Note down the technical interview and online coding assessment questions you get, especially the ones you get wrong. Document any essential lines of code, tricks or code snippets that made the difference between you solving the question or not. These will be helpful in the future as many companies in the same industry solve similar problems in slightly different ways.

Simulation

Try to simulate the technical interview or online coding assessment atmosphere as closely as possible. If you know the day you will do the coding question will be on a Monday in the morning at a specific time then prepare that way as well. Practice your coding questions at the same desk and chair where you will be solving the real coding question. Time yourself the way you will timed during the actual coding question and remember to keep track of speed, distance and time using the DST triangle method explanation.

Change Your Reaction

Always be positive, even if you don't make it to the next round of interview with a company as you can always apply again. Once you control your reaction to the events that happen in your life, you will be free from blowing whichever way the wind blows and you will stand as a tall oak tree, upright and strong, weathering even the most furious of storms. They don't get to control your happiness or wellbeing. Remember, it is your life journey. You can react anyway you want to any kind of news. It's totally up to you, so be creative about it.

Change Your Mindset

Every coding question you practice is making you that much better at achieving the objective and meeting the bottom line. Bringing you closer to the role you want. You are never starting from zero. You are starting from experience.

Parting Words of Encouragement

There should be a convincing narrative flowing through your interviews that leaves a lasting impression on the interviewers that you are the best candidate for the role.

The job hunt is a numbers game. It doesn't matter how many times you get a 'no', all you need is for one company to say 'yes', so the logical thing to do is to be persistent and keep applying and interviewing until you get what you want.

The early bird gets the worm. It is better to schedule your interviews early and respond quickly to emails in correspondence with anyone you need to interact with at the company you are interviewing at, even if they are not being responsive. If you move slowly on these things then you will be allowing other candidates to interview ahead of you, thus reducing your chances of getting the role. Especially if the company is hiring on a rolling basis.

'People of accomplishment rarely sat back and let things happen to them. They went out and happened to things' - Leonardo Da Vinci

'Learning never exhausts the mind' - Leonardo Da Vinci

'Start by doing what is necessary; then do what is possible; and suddenly you are doing the impossible' - St. Francis of Assisi

I'm realising more and more that it requires a high degree of initiative, proactivity, autonomy and repsonsiveness to really get things done as you increase your education level and gain experience in industry. You receive less supervision and more expectation as you progress but you also become more experienced in the process so it balances out. It's all about taking ownership and grabbing the bull by the horns. It's your life, chart your own course and blaze your own trail.

How to Improve Coding for Technical Interviews and Online Assessments