Landing your first web developer job is not easy as a self-taught programmer. (At least for me.) You might get a few interviews after sending out thousands of resumes. Interviews are challenging but valuable experiences. You can improve your programming skills with the technical interviews. Here are five tips I usually do after the interviews.

Go over JavaScript

If you are a web developer, you must have learned JavaScript. When you are about to apply for the jobs, however, you might have forgotten many javascript concepts. Let’s look at the questions I had to solve recently.

(function () {
  console.log(x)
  var x = 5;
  return x * 2
})()

// undefined
// 10

(function () {
  console.log(x)
  let x = 5;
  return x * 2
})()

// ReferenceError: Cannot access 'x' before initialization

(function () {
  console.log(x)
  const x = 5;
  return x * 2
})()

//ReferenceError: Cannot access 'x' before initialization

I will pinpoint a few things to solve this problem. There are three IIFE(Immediately-invoked Function Expression) and everything is the same except how the variables are declared: the first one with var, the second with let, and the last one with const.

• All variables declared with var, let, and const are hoisted to the top of the current scope.
• Variables have a life cycle: Declaration, initialization, assignment.
• If a variable is declared with var, it is automatically initialized. So you can access the variable before its declaration. Console.log(x) is ‘undefined’.
• Accessing a let/const variable before its declaration will throw an error. They are in TDZ (temporal dead zone) and they are not accessible until initialization.

Understanding Javascript concepts in depth is crucial for web developers. It is a good time to go back to Javascript and review the grammar again. Those variable questions can be really tricky, too.

Understand the mechanism of your main library or framework

When we are learning a new library or framework, it is recommended to build small projects in order to understand how they work. Let’s look at the following question. It asks what the value would be after pressing the button.

import { useState} from 'react'

export default function App() {
  const [loading, setLoading] = useState(false)
  const [names, setNames] = useState([])

  const startLoading = () => {
    setLoading(true)
  }

  const showNames = () => {
    if(loading){
      setNames([{name: 'Charli'}, {name: 'Mickey'}])
    }
  }

  const handleClick = () => {
    startLoading()
    showNames()
  }

  return (
    <div className="App">
      <button onClick={handleClick}>Load names</button>
      {
        names.map((name) => (
          <div>{name}</div>
        ))
      }
    </div>
  );
}

1. If you click the button, the handleClick() function will be evoked.
2. handleClick() function contains two other functions: One is startLoading() and the other is showNames().
3. startLoading() will be evoked first and it will change state ‘loading’ to 'true'.
4. showNames() will be evoked next. If loading is true, two objects will be replaced to the state ‘names’.
5. Finally, the code will show two names. Right?

Actually, this is wrong. If we want to render two names, we need to click the button twice. Why? After the startLoading(), the showNames() will be evoked right away. It does not wait until the state ‘loading’ gets updated. This is one of the core concepts of how react works.

When we build projects, we usually don’t think about this process. We just play with code and make sure a user can get what they want with one click. Yet, understanding the mechanism of the library is critical so it is a good habit to review it after the interview.

Code refactoring with your project

I was assigned to make a simple card game. During the technical interview, the senior developer went through my whole code. This was the first time that someone gave me any kind of feedback on my code. These are what he advised.

1. Less useState is better. Less useState, less rendering.
2. Make a function for repeated code.
3. Try not to pass down className as props.
4. Always give a button attribute type. Otherwise, a button with no type attribute behaves as type="submit" by default.

Also, he asked me what I would do if a user wanted to retract the cards. I had to explain how I would write the code. In my opinion, this is the most practical part to improve my coding skills. After the interview, I refactored my code based on the advice. If you are given code reviews, do code refactoring.

Research new words or methods learned during the interview

There are going to be questions you simply can’t answer because you haven’t learned them yet. In my case, I was clueless about the questions related to TypeScript and GraphQL. Somehow I remembered one question I was not sure I answered right during the assessment test.

I could have researched and learned about it. Well, I didn’t. Guess what? The senior developer asked the exact question during the technical interview. I gave the exact wrong answer. The question was what typescript would infer the type of x.

const numbers = [1, null, 3, 4, 5, null, 9]

numbers.filter(Boolean).map((x) => x)

I answered x was to be ‘number | true.’ In fact, if you run the code, the result is [1, 3, 4, 5, 9]. The question is, however, that it is asking what typescript infers the type of x.

I thought typescript infers only numbers, not null. But typescript does not narrow down the type. Shocking. I am still new to TypeScript but I was able to learn about type guard and type narrowing through the interview.

Try to do the interview again

Finally we are at the last tip. This is more about the next interviews. During the interview, you might give wrong answers even if you understood the questions perfectly. It just happens and this might bug you in the night. When you are about to sleep, those questions pop up in your head and you want to hit your head.

Like coding, interview skills are all about practice, practice, and practice. Write down all questions you can remember and do a mock interview by yourself. You have to explain the code usually during the interview and this is not easy even if the code is very simple.

import "./styles.css";
import { useState, useEffect } from "react";

export default function App() {
  const [loading, setLoading] = useState(false);
  const [name, setName] = useState("Mickey");

  useEffect(() => {
    const timer = setTimeout(() => {
      setLoading(true);
    }, 3000);
    return () => clearTimeout(timer);
  }, []);

  useEffect(() => {
    if (loading) {
      setName("Charli");
    }
  }, [loading]);

  return (
    <div className="App">
      <p>{name}</p>
    </div>
  );
}

If you see the code above, what would the name be on the first rendering? Obviously, Mickey. Unfortunately, I answered ‘Charli’. I really don’t know why. You may have written similar code like this a lot but when it comes to explaining the code, you will experience brain freeze. The solution is to eat more ice cream and practice!

If you are a self-taught developer, it is very crucial to take advantage of the technical interviews. You might learn more things while talking to senior programmers. I usually write down anything I can think of right after the interview and go through the steps I mentioned above. Let’s leverage the technical interviews in all respects and improve our programming skills.