CSE 300: Professional Readiness

W04 Learning Activity: Technical Interviewing Skills

Overview

In this activity you will learn more about technical job interviews and how to prepare for them.

The Goal of a Technical Interview

In technical job interviews, the interviewer is trying to determine a few important things about you:

1. Do you have the necessary foundation to begin working the kinds of problems they face?
2. Can you think creatively and find solutions to a problem you have not seen before?
3. What is your process for coming up with ideas and evaluating their quality?
4. Can you convert a general idea into enough detail that you could implement it in code?
5. Are you someone they would want to work with?

Notice from these questions that an interviewer is not looking for someone who has memorized every answer in a coding interview book. Presenting a memorized solution does not help them see if you can approach new problems or consider alternatives.

They are also not looking for perfect code or even necessarily a "right" answer. They are trying to understand how you approach difficult problems.

A Bad Approach

Many people make the mistake of approaching a coding interview this way:

1. Get the problem from the interviewer.
2. Ask a few clarifying questions.
3. Think deeply about the problem and come up with a solution.
4. Write code.
5. Ask if they got it right.

Can you see flaws in this approach?

First, and foremost it puts a lot of pressure on the step of "Think deeply about the problem and come up with a solution." What if you cannot think of the right answer? Do you just wait for revelation? This seems to hearken back to the Lord's counsel to Oliver Cowdery:

In addition, even if you do come up with a good solution using this approach, it does not help your interviewer answer the questions they really care about, such as seeing how you think. Remember, they are not interested in the answer nearly as much as they are in the person. They are evaluating you and how you work.

A Better Approach

The following is a better pattern for approaching a technical interview question:

Understand the Problem

When you are first presented with the problem from the interview, take some time to discuss the problem with them. This helps you understand the problem better, and it also helps them see that you can think about requirements and constraints.

Describe the problem back to the interviewer

After they give you the problem, try to repeat it back in your own words. For example, you might say, "Ok, so if I understand the problem correctly, I need to ... but I need to make sure ..."

Ask clarifying questions

After you have a fairly clear idea of the general problem, this is a great chance to think about other constraints or related problems. For example, "Does this need to work with all types of data?" or "Does this need to work for an arbitrary number?"

These questions will naturally lead into the next section of considering test cases. The fact that you are asking these questions shows the interviewer that you can think about potential concerns or problems.

Consider Tests Cases

Once you understand the problem, you should consider some test cases that could validate a solution. This is an important step that will make sure you understand the problem well, and also help the interviewer see that you can consider alternatives, and that you do not think of testing as an afterthought.

Choose a straight-forward, common solution or two

First, begin with an easy, common test case. Think about what the input should be and what the output should be. For example, if you have been asked to write a function to reverse a string, you could begin with an input of cat and the output should be tac.

Choose an edge case or two

In addition to choosing an expected input, try to think of a few edge cases that might cause problems for a solution. For example, in the case of reversing a string, you might consider an empty string, a single letter string, or one that contains all the same letters.

After you come up with each test case and determine what the result should be for each one, you can ask the interviewer if that seems like an appropriate thing to check. This is a great chance to continue to clarify the problem with them, and it also helps engage them in the process with you, almost like a collaborator. This is important, because it helps them see that you are the kind of person they would want to work with.

Write down your test cases

Write your test cases down, so that in a minute when you come up with solution ideas, you can refer back to them.

If you are working on a whiteboard, you can write these off to the side. If you are using a computer, such as in a remote interview, you could write these as comments.

Decide on a simple approach

At this point, you need to come up with a solution. Rather than waiting for the perfect one to come to mind, this is great time to start with a simple, even brute-force, or naive, approach. You can even say that directly to the interviewer such as "Well, a simple, brute-force approach might look something like this..."

Most problems can be solved with a brute-force approach. It might not be a good approach for a number of different reasons, but it helps you start thinking about the problem and it also gives the interviewer a chance to see you think. Showing that this solution can work, but then showing why you know it is not the best solution will help the interviewer see that you can make good judgments.

No code yet!

At this point, you are only talking about ideas. It's ok to write down a few steps, if you want, but do not start writing code yet.

Verify your approach using your test cases

Take a minute to walk through your simple approach using at least one test case from before. This will make sure your solution actually works and also show them you understand the importance of testing.

Explore ways to improve your approach

Once you have talked about a simple solution, you should explore its problems and how to improve them. For example, you might say, "While that approach could work, it is not very efficient" or "It uses much more space that it really needs to." Identifying these issues directly helps the interviewer see that you understand these issues and their impact.

Talk about solution fragments

Even if you are not sure how to solve the problem yet, start talking about solution "fragments" or pieces that could contribute to a better solution. For example, you might say, "In order to make this more efficient, I would need some type of data structure that could store the items in this way..."

If you know a good way to implement your idea, that is perfect. But if not, even the fact that you are discussing it helps the interviewer see your thought process.

If you cannot think of a way to do something, you can even ask the interviewer, "I know I need to do this ..., do you have any suggestions?" Sometimes if you ask for direct help you might "lose points" in their mind to some degree, but it can help you get back on track and make progress again, which is better than staying stuck or not coming up with an approach.

No code yet!

At this point, take the time to write down the steps of your solution. This is a form of pseudo code, but remember, you are still only talking about ideas. You should not write any code yet.

Verify your solution with your test cases

Now that you have a reasonable solution, you should verify that it will work by using all of your test cases. If you are concerned that it is still not a great solution, you might even start by saying, "I think there are ways to improve this approach, but I want to at least verify that it will work."

Explore ways to improve your solution

Now that you have a workable solution and have verified that it will work, you can take a minute to talk about possible ways to improve it even more. This is a great time to talk about the overall time and space complexity of your approach.

Iterate on your ideas using the techniques described earlier in this step.

Ask for feedback

If you have not already asked for feedback as you have been developing your solution ideas, this is a good time to ask for it.

You might say something like, "Ok, this seems to be a reasonable solution. Before I start to write the code, do you have any feedback on this general approach?"

At this point, some interviewers might want to talk through the approach in more detail, and in many cases, the interview might even stop here before you write any code at all. In other cases, the interviewer might tell you to go ahead and try to write the code first to see how it goes. Follow their lead in whatever direction they would like you to go.

Write the code

You are finally at the point where you should write some code. Notice that by waiting until this point, you already know that you have a reasonable solution that can solve the problem. Now you just need to turn those steps into actual code.

Language and syntax

Most interviewers will let you write the code in whatever language you would like. They are not nearly as worried about the syntax as they are that you can turn the ideas into the level of detail that is needed for code. Choose a language that you are comfortable with. If you aren't sure on the exact syntax of a library function, do your best, and say something like, "I can't remember the exact syntax of this function call, but I could look it up if needed. But I believe it requires parameters like this..."

Leave yourself room

If you are working on a whiteboard, remember that you cannot easily cut and paste code around on the board. Leave yourself plenty of room, especially between the major steps of your solution, in case you want to add something else later.

Verify your code with your test cases

At this point, it is very important to use your test cases to walk through your code in detail. Show the value of variables as you walk through each step of your code. This not only verifies that your code will work, but shows your interviewer that you are a careful debugger.

Ask for feedback

Now that you have completed your solution, ask the interviewer if they have any suggestions or feedback. This is an important step to learn about how you approached the problem, and it is also important for you to show that you are eager to learn and accept correction and feedback.

Thank your interviewer

At the end of the interview, make sure to thank your interviewer for their time. Let them know how much you appreciated working with them and getting to know them.

Practice, Practice, Practice

It can be very difficult to stand at a white board or on a zoom session and write code in front of an interviewer. The best way to prepare for this experience is to practice. If you have a friend who has technical skills, ask them to help you. If you do not know anyone with technical skills, you can find a list of common interview questions on the internet and ask a family member to read them to you. Even if they don't know the answer, practice giving your response to them, even all the way through writing the code.

It is easy to think "At this point, if I were in a real interview, I would write the code." But, there is real value in practicing writing the code out in front of someone.

Submission

After you have finished this learning activity, return to Canvas and submit the associated quiz there.

Other Links:

• Return to Week Overview | Course Home