DEV Community: Vinicio Vladimir Sanchez Trejo

The Secret of a Successful Code Challenge Interview: Having a plan

Vinicio Vladimir Sanchez Trejo — Mon, 14 Jun 2021 15:57:38 +0000

You know; I used to think I could show up to an interview and ace a code challenge without any extra preparation; besides my computer science studies and my daily coding sessions.

I was...greatly mistaken. After very disappointing interviews, it was obvious something was wrong. I knew I could code, so what was the problem? Well, I discovered several problems, but one of the biggest ones was that I didn't have a process!

Over several years I developed an interview process that allowed me to:

Feel more confident during code challenges (and...avoid panicking as much haha).
Increase the chances of arriving at a working solution.
Showcase my skills even if I can't produce working code.

Today, I want to share my process with you :)

The Big Picture

You are going to:

Understand the problem
Experiment by solving several examples
Identify an algorithm
Optimize your algorithm
Write code (Notice how this is step 5 out of 7)
Discuss possible improvements
Be proud! We did it!

Let's add more detail on how this system works; but before that, two important points:

This is a flexible process; play with it and make it your own. As a general guideline; the more confused I am in an interview, the more I rely on the process.
You can download a nice cheatsheet of the process by clicking here!

With that said. Let's do this!

1 - Understanding the Problem

This is the most important step in the entire process. It was born out of my biggest interview mistakes. Many people start writing code as soon as the interviewer finishes describing the problem.

I think that's one of the worst mistakes you could make in a code challenge. Here's why:

If you misunderstood the problem, you are going to waste precious time whilst getting back on track.
You are trying to solve the problem as you code, and, what's worse, you didn't give your brain enough time to come up with a solution.

What do I do then?

Luckily for us, there is an effective way to avoid this pitfall: carefully examine the problem and identify some key details:

Goals
Inputs & Outputs
Scope
Assumptions
Constraints

Ask a healthy amount of questions if anything seems unclear. These details will allow you to create a solid algorithm without annoying bugs blindsiding you as you code.

Re-stating the problem

Before moving to the next step, it's useful to re-state the challenge to the interviewer. Think about this as a final chance for you or the interviewer to catch any misunderstandings.

2 - Experimenting with Examples

Is it time to think about for loops? Nope. It's time to visually solve 1-3 regular examples and 1-3 edge cases.

...Why? I need to get to the code dude!

Here is the thing:

Your brain is already an amazing problem-solving supercomputer.

You may be doing yourself a disservice by immediately thinking about loops and variables. You could even end up coding a faulty implementation.

By spending some time visually solving examples, you are going to give your brain enough time to recognize patterns that can be used to solve the problem. These patterns are harder to see if you are already thinking about how to name your variables or other implementation details.

Also, if you have absolutely no idea about how to solve a problem, you are doing something much more productive than just staring at the problem and thinking really, really hard.

Notice how I'm asking you to equally divide your time between regular cases and edge cases. Regular cases are used to identify patterns and edge cases are used to make sure we have a solid algorithm. I often see interviewees neglect one or the other. They are equally valuable!

3 - Identifying an Algorithm

Take a look at the previous step. Think about the process your brain followed to solve the examples. What are the common steps? Can you think of a way to express those steps in a way that can be 'mechanized' by the computer?

Notice how I didn't call this step 'Identifying an Optimal Algorithm'. For now, I'm asking you to focus on finding something that works, and later, you'll focus on optimizations.

How do I keep track of my algorithm?

I recommend that you document your thought process using English as much as you can. However, if you identify the most complicated (or confusing) part of the problem, you could use pseudocode to give yourself a little more clarity.

Having said that, I do recommend that you stick to English since you are going to optimize your algorithm in the next step.

What happens if I can't identify an algorithm?

I can (and will) write several more articles about what to do when you are stuck, but my go-to moves are to try to divide the problem into smaller problems or to reduce the problem into a simpler version.

Don't worry. I'll come back soon with more material about what to do when you are stuck.

4 - Deciding on an Algorithm to Code

Now that you have a solid algorithm, it's time to think about optimizations. I recommend you start by noting your current time and space complexity (also known as Big O).

Once you have that, brainstorm data structures, algorithms, and functions that could improve performance. Have a conversation with the interviewer about whether they want you to optimize for time or space.

Notice how I didn't say 'Finding an O(X) solution' or 'Finding the most optimal algorithm'. Finding the best algorithm is the goal, but don't panic if you can't find it.

Spend a healthy amount of time here, select an approach, and then move on. A working solution is more valuable than an incomplete challenge.

How much time should I spend here before I move to step 5?

That's a great question! I like to give myself 10-20 minutes to write code and discuss improvements, so I recommend you spend 10-20 minutes here. (This assumes a 1-hour interview with only one problem)

I'll write an article with a breakdown of recommended times by interview step, but I hope this is enough information for now.

It's finally time to (maybe) use pseudocode.

As I said before, I don't recommend you always use pseudocode in code challenges, but I recommend pseudocoding areas that are particularly confusing or complicated.

Why? Because pseudocode allows you to think about your algorithm from a high-level perspective; without dealing with the lower-level detail required by code. Keep pseudocode to a minimum though, and use it only to answer specific questions about your approach.

Now it's time to...

5 - Writing Code

FINALLY. Finally!? What great wisdom can I share with you about the "most important step" in the interview process? You'll have to go back to step 1 since that's the most important step. Here, we'll just write some code.

Writing code should be the most boring part of the interview. All of the uncertainty of the challenge should have been clarified in the previous steps. If you have a lot of questions at this point, we have failed at successfully navigating the code challenge.

I do recommend two things for this step though:

Consistently double-check your examples to make sure that your code is not missing a vital step or edge case.
Don't forget to state your code's performance. Often the interviewer will remind you about it, but you can't count on that.

6 -Discussing Improvements

Now that you are "done" and the interview is about to end, mention possible improvements to your algorithm:

What would you change about your algorithm if you had more time to work?
How would you build a unit-test suite for your algorithm?

7 - YOU DID IT!

You did it! High Five! If everything worked out you should have had a successful code challenge interview. Maybe even a job offer in a couple of days!

Of course, it's easier said than done. In the next several months, I'll be going deeper into each step of this process. In the meantime, head over to cadejo.dev and grab your interview process cheatsheet! Also, reach out on social media to let me know how you like it!

Before I go though, I want to thank all the students and teachers that helped me build this process over several years of my career. I'm standing on the shoulders of giants and I couldn't have done it without you all!

JavaScript: Var and Let

Vinicio Vladimir Sanchez Trejo — Sat, 13 Mar 2021 22:53:27 +0000

Today I want to take you on an adventure where we'll discover the key differences between var variables and let variables. Many introductions to coding (in Javascript) usually start with var variables, but I believe you should move to let variables as soon as you can. You'll have fewer bugs, and a better programming experience. Let's do this!

First, I want to introduce the concept of Scope. A definition I love to use goes like this:

Scope is the area of code where you can access a symbol

A symbol, in this context, can be a variable or a function. We say that a symbol is 'within scope' when you can safely use it without any errors. For example:

var variable = 'Hello'; 
// We can log variable here because is within scope
console.log(variable);

Things become a little bit more interesting when you are dealing with functions:

console.log(variable); // This will not work

function thisIsAFunction() {
    var variable = 1; 
    console.log(variable); // This will work
}

console.log(variable); // This will not work

thisIsAFunction();

Notice how the logs outside of the function will not work (i.e. the name variable is not within scope), but the log inside the function will work.

Why is that?

var variables use what we know as Function-based scope. If you declare a var variable inside a function, the variable will be within scope everywhere inside the function.

Hoisting is going to slightly complicate where you can access your variable. In general, It's safer to use your var variable only after you declare it. We'll talk about hoisting in an upcoming article, so get excited!

Now, let's add an if statement inside our function:

console.log(variable); // This will not work

function thisIsAFunction() {
    if(true === true) { // This is a simple if statement to avoid confusion
        var variable = 1;
        console.log(variable); // This works
    }
    console.log(variable); // This works
} 

console.log(variable); // This will not work

Our var variable is only within scope inside the function where it was declared. Notice how even though variable was declared inside an if statement, you can still use it outside the statement. That's function-based scope at play!

Now let's go full power and change our var variable into a let variable:

console.log(variable); // This will not work

function thisIsAFunction() {
    if(true === true) { // This is a simple if statement to avoid confusion
        let variable = 1; 
        console.log(variable); // This works
    }
    console.log(variable); // This will not work
} 

console.log(variable); // This will not work

thisIsAFunction();

Notice how as soon as we change var to let, one more log stops working.

What's the difference between the log in line 6 and the log in line 8?

The difference is that they are in different blocks. If you are thinking 'Well, what's a block?, I've got you covered my friend.

If you want to get super technical, a block is a "lexical structure of source code which is grouped together", but I like to introduce the concept as:

Block - whatever is contained inside curly brackets: functions, loops, if statements, etc.

Objects are a funny exception to the definition I just gave about curly brackets, but that's the only exception I know of.

Let's think about the blocks we have in our current function

console.log(variable);

function thisIsAFunction() { // Start of block A
    if(true === true) { // Start of block B
        let variable = 1; 
        console.log(variable);
    } // End of block B
    console.log(variable); 
} // End of block A

console.log(variable);

thisIsAFunction();

Since variable was defined inside block B, it can only be used inside block B (here comes the important point) and inside every block contained within B.

Technically Speaking, variable is inside block A Right?. Why is the console.log breaking?

Great point. Block B is inside Block A, so technically variable was declared inside block A.

However, the scope resolution rule let uses is going to look for the closest enclosing block (that would be block b) and allow you to use the variable everywhere inside that block and every other block within it.

Blocks containing that 'closest enclosing block' won't have access to variable

So what would happen if we move variable before the if statement?

console.log(variable);

function thisIsAFunction() { // Start of block A
    let variable = 1; 
    if(true === true) { // Start of block B
        console.log(variable);
    } // End of block B
    console.log(variable); 
} // End of block A

console.log(variable);

thisIsAFunction();

It would be accessible everywhere inside block A as that would be the closest enclosing block. Since block B is inside block A, it'll also be accessible inside block B.

This seems like adding a bunch of rules on top of var. What's the point?

Great question! Blocks tend to be smaller than functions. Basing our scoping rules on smaller scopes will mean that a variable name is 'available' on a smaller area of code.

A smaller area of code means it is less likely to change that variable by mistake.

I get it! Anything 'else?

One last thing. let also has built-in protections to avoid re-declaring the same variable by mistake.

let kali = 'is cute';

// LOTS OF CODE IN BETWEEN

let kali = 2; // This will break

As soon as you try to re-declare the name kali, you'll get an error along the lines of redeclaration of identifier kali.

On the other hand:

var kali = 'is cute';

// LOTS OF CODE IN BETWEEN

var kali = 2; // This works just fine

var variables will let you re-declare the same name over and over without any complaint. You could end up overstepping on someone else's (or even your own) variables without even realizing it. That's another big reason to use let variables as much as you can.

In Summary

Scope is the area of the code where you can access a name.
var variables use function-based scope. They can be used inside the function where they are defined.
let variables use block-based scope. They can be used inside the block where they are defined.
let variables will not let you re-declare the same name.

Thanks!

Thank you very much for reading my article! I have a youtube video covering these topics if you would like a more interactive demo: https://youtu.be/kIJ2Jh7Qwso

If you like my content and would like me to help you in your coding journey, you should join my newsletter: https://www.cadejo.dev/free-updates/