(Definitely look forward to that big article on API and Data here soon!)

Some Prerequisites

A few good things to have installed and ready to go on your computer to get started:

• A little React knowledge

• Some JavaScript knowledge

• A Text Editor (rec. Visual Studio Code)

• Node.js (Nodejs.org)

• Git (optional) (Git)

• A Web Browser (rec. Firefox)

Your OS of choice doesn't really matter. Myself, I use a 2022 MacBook Air, but if you use a Windows environment that's alright as well. No haters here, all coders are different! (:

Where to begin?

Let’s start by creating a React app using my preferred method: [create-react-app].

I realize some people prefer using Vite to get their FE apps up and running, which is absolutely a good way to use it as well. However, call me old school, but I find the best route to setting up a React application from scratch is by using the React recommended method of CRA.

First, we'll crack open the Terminal (or Command Prompt on Windows), and create a new app somewhere that you won't lose it (I prefer my Desktop, but it's up to you where you navigate on your local). Once you're in the directory you want to put your new app into, we are going to enter the following:

npx create-react-app <enter-react-app-name-here>

For my app, I chose the simple name react-fetching-app, but you can call it whatever you would like. Hell, you could call it banana-monkey if you'd like. The only rules are no spaces in the name, and no capitalizations (not sure why on the last one, but it is what it is). But, dashes are recommended for more than one-word app names.

Once that has been completed, you should see these 2 next steps populate like so on your terminal:

So now we will do exactly what is suggested to do! We will cd ('change directory' in terminal lingo) into the newly created react-fetching-app application, and we can get it up and running right from the jump. After you cd into the app, if you press ls (that's a lowercase 'L' by the way, followed by an 's') - or dir if you're on a Windows system - it should display all of the main files/folders that have been created by the CRA package.

Simply enter npm start and you should in just a moment see a new browser window open up with something that looks like this:

Now, we can get into the fun stuff of setting up our application. 😎

Taking out the trash

To start, let's go ahead and open up our Text Editor of choice (again, my ride or die is VS Code), and take a look at how to get to fetching data with React.

Methods for opening the code:

• Drag the folder to the text editor icon

• Open the text editor and select Open Folder

• In Terminal, enter: code . (if you have VS Code setup to your PATH)

Upon opening the editor, you should see the directory structure look something like this:

I am going to make a few cosmetic alterations, which I recommend doing, and this will help make coding a bit simpler for the project.

Before 👆🏼

After👇🏼

This simplifies everything we need for this very straightforward app. No flare, no bs. Just code.

Let's dive right in

Starting with index.js. This is where the app comes into play through the usage of latching onto an HTML element (a div in most build cases) with an id of root. But let's get rid of the fluff in the script file.

We can get rid of all the unnecessary lines of code, to make it only have simply what we need to run properly. Again, no filler.

We will add some CSS just to make things look a bit less plain jane so to speak.

I imported the font 'Source Sans Pro' from Google Fonts

Let's move on to the entire point of this article in the first place: Setting up the App.jsx file, and fetching some data.

Finding some data to use...

Next, we need to find some data that we can retrieve and then implement into our React application. It took me a bit to decide on a fun and simple API (Application Programming Interface), but I ended up choosing The Star Wars API - SWAPI. This one seemed like an easy-to-access API, and the data is cool! I mean come on, it's Star Wars, who doesn't love Star Wars??

And the best part: The API is free, and you won't be needing an API Key ('token') to access it!

I've provided the link above, but here it is as well:

SWAPI: Star Wars API - Click Here

(Should look like this, or similar):

Okay! Onto the fun part: Setting up our App.jsx file to be able to retrieve data from SWAPI.

Conjunction Function

Heading back to our text editor where our code is, let's reopen App.jsx and get started writing a function that will fetch the SWAPI data by using async/await. I will break down what this means to use async/await when mining for data.

The 'Base URL' that is used for SWAPI is:

https://swapi.dev/api/

We are going to use this in a variable called, API_URL like so:

const API_URL = 'https://swapi.dev/api/';

Side note: I've made this variable into all uppercase because it is a global-scope variable. What that means, is that the entire application, not just a specific portion or function, can access it. It isn't necessary to use the all-uppercase method for globals, but it is something I've always done, and haven't found a reason against it thus far in my long tech career as an engineer. However, feel free to write it in any syntax-appropriate way you'd like.

Next, we're going to create a function back inside the App() function itself, called fetchData(). This is going to be the key function to fetching and accessing the API data. To initiate the function, there are 2 ways of doing this, and each method is based solely upon which style of Function you like to use.

I prefer the Arrow Function method, as it is cleaner, but there is also the Standard Function method as well, which works just fine. The differences between these 2 methods when using async/await are as follows:

// Arrow Function
// This will be created by declaring the function by a variable name
const fetchData = async () => {
    // some cool stuff here
}
// Notice the word 'async' is the first item declared as we begin the assignment to the variable named 'fetchData'. This works the same way in a Standard Function definition.


// Standard Function
async fetchData() {
    // also cool stuff here
}
// The same ruling applies to this style of function definition, where the word 'async' must be declared first before the function declaration and naming convention.

Either method works just fine, and both accomplish the same outcomes when doing most tasks in JavaScript. There are however, some key differences between these 2 types of functions when it comes to coding overall in JavaScript and especially TypeScript, but that is a topic for another article. If you'd like to learn more about Functions, or anything JavaScript for that matter, I highly recommend the gods of Frontend coding: The MDN Docs

Let's break down real quick what async means, and why it is used here.

Async full of variables

The keyword async is a shortened version of the word 'asynchronous'. What this means is that an item is called not at the same time as another item. For example, if you have 2 items that are set to go off when something happens, an 'async Promise' means that the items will not fire off at the same time. Take for a more detailed example, the 2 function calls in the test environment from MDN Async Function Page

// This is technically the First function to be called, but it only fires after 'awaiting' for the Second function call.
function resolveAfter2Seconds() {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve('resolved'); // Third return
    }, 2000); // Second return part 2
  });
}

async function asyncCall() {
  console.log('calling'); // First return
  const result = await resolveAfter2Seconds(); // Second return part 1
  console.log(result); // Fourth/Final return
  // Expected output: "resolved"
}

asyncCall();
// Output in Terminal:
> "calling" // Happens immediately
// A pause of 2000 millisenconds (2 seconds)
> "resolved" // Happens after the pause

The async keyword declares that any items being returned inside of the function will fire off separately from one another when the function is called.

We've seen the async keyword in action, but now we're going to see the await keyword and what it means to use it in an asynchronous function call.

Await off of your shoulders

The await keyword compliments the async keyword, by telling the rest of the function that it is waiting for the data to come back from the source. It's kind of like you're in a group of friends on a hike, and one of your friends falls back a few paces to tie their shoes, so you pause and wait for them to get back to you, while the rest of the group continues onward.

Typically, inside of an async function when using Promises (unless you are using .then() promise chaining), you'll find that the await keyword is used twice. Once with the fetch() keyword call for the data, and again for what to do next with the data that has been retrieved once it has been 'fetched'.

Getting back to our SWAPI (Star Wars API) data, let's create that new function called fetchData and set a single parameter inside of it called url, inside of our App.jsx file. Then we can call it directly beneath the declaration, using the global API_URL variable we created earlier as the argument for the function.

For anyone that needs the full code to simply copy and paste, here it is:

import React from 'react';
const API_URL = 'https://swapi.dev/api/';

const App = () => {

    const fetchData = async url => {
        const response = await fetch(url);
        const data = await response.json();
        console.log(data);
    };

    fetchData(API_URL);

    return (
        <div id='app'>
            <h2 className='title'>React Fetching App</h2>
        </div>
    );
};

Go ahead and save the file, and then pop open your browser window that has the React app open. Once you do, open up the DevTools (Chrome or Firefox are recommended, but Safari and Edge work as well), and click on the tab Console.

This window is what you should see, and if not, simply refresh the page (cmd+r / ctrl+r), or go back to your editor and make sure your code looks correct.

If you see the above screen, success! You have officially fetched some data from an API call, using fetch and async/await.

Now, you've done the fun part of fetching the data using async/await. But if you stick around, we are going to actually put that data to work and make it functional! That's where the real fun stuff comes into play.

No, not 'Jason'...JSON

So far, you've learned about fetching data, async and await keywords, a little bit of function knowledge to get you by, and what it all means to use it in practice. But now we're going to put that data we've just retrieved to good use.

We are going to map through the data, and filter it all out by like items/content (or**, key** and value pairs).

This data we've just ported over has been configured into what is called JSON format. All this means is that the information is broken up by an 'item name' and an 'item value'. In programming, we call this a key/value pair. It looks something like this:

[
    {
        "id": 1,
        "first_name": "Tyler",
        "occupation": "Web/Software Engineer",
        "cool_person": false
    }
];

Let's break this down real quick:

• Key: The identifier (or title) of a piece of data/content.

• Value: The content matching the specific key.

• Example:

  • Key: first_name

  • Value: Tyler

So, in essence, when we 'pull' this data from the API, we are then converting it into JSON. This data then becomes fragmented by key identifiers and corresponding values, so that we can read it and filter (or map) through it properly on our end of the code.

Okay! Onto the mapping through all of our new Star Wars API data.

Don't forget the Map on your journey

If you have used JavaScript (or really most programming languages) for longer than a couple of hours, then chances are you're already familiar with what is called mapping. In JS specifically, there is a predefined method called .map() that allows you to (as the name states) map through whatever data it is that you're working with while using .map().

Let's see this in practice.

First, let's change up the url path of the API data that we're fetching currently. If you notice inside the object of the returned call in the DevTools, you will see different sections/areas such as people, planets, films, etc. We are going to pick one (in this case, people), and retrieve that specific set of data from the API.

Going back to our fetchData() function, we will alter the fetch call just a bit on the first line of the function.

For the copy-and-pasters of the world:

import React from 'react';
const API_URL = 'https://swapi.dev/api/';

const App = () => {
    const fetchData = async url => {
        const response = await fetch(`${url}/people`);
        const data = await response.json();
        console.log(data);
    };
    fetchData(API_URL);
    return (
        <div id='app'>
            <h2 className='title'>React Fetching App</h2>
        </div>
    );
};
export default App;

Now that we've logged that new section of data from the API, we should see something like this in the DevTools: (if it doesn't work, remember to refresh the page)

From here, you can see all of the cool new data we can pick through and use for our app. So, let's start with setting up a div container and inside of it, making a ul element (unordered list as compared to a numbered order list) that can list all of the data information.

For future note, you can essentially put this data however you'd like on your future apps like a table for example. But here, I just simply want to get you - the reader - to the comfortable point of fetching data and then learning how to use said data properly.

Go ahead and underneath the h2 element, create a div with the class name (or in React, className on HTML elements) of container. Then inside that container element, create a ul element and an li element inside of it, like so:

...
return (
    <div id='app'>
        <h2 className='title'>React Fetching App</h2>
        <div className="container">
            <ul>
                <li></li>
            </ul>
         </div>
    </div>
);
//We are going to alter the information going inside of that li element

Now, we can start mapping through the data we've pulled, but first, let's go ahead and use a little neato React Hook called useState so we can actually set the data up into a scoped variable, and then implement that variable as a container for the data.

The useState of the Union

At the very top of our App.jsx file, we are going to import the useState() Hook from the React library.

import React, { useState } from 'react';

// ... rest of the App.jsx file ..

So now we can go ahead and create 2 variables: one to set the data, and one to hold the data. And to make it simple, we'll just call it person, since that's the section of the SWAPI data we're going after for our app.

Directly on the first line of the inside of our App() function, we will create this person variable along with its counterpart setPerson, using what is called 'array destructuring' in JS. It will look like this:

const [person, setPerson] = useState([]);

Notice that when we initialize these 2 variables with the useState() hook, we are using a base value of an empty array []. What this means, is that at the core value for the variable - if nothing is used or returned with it - then simply an empty array will be returned. useState is a very straightforward React Hook, and it can be used in a myriad of ways, like pulling text data, for example, would look something like this:

const [myName, setMyName] = useState('tyler');

What this tells the app, is that the initial value of the destructured variable is 'tyler'. This can also be left as a blank string like useState(' ').

The camelCase naming convention when it comes to state is seen everywhere, but it's only because it's a trend that was first started when the React team initially designed and pushed out the useState hook convention. I've been known to use underscores or justlowercasestyle before, so it's dealer's choice really. But again, typically, you will see a lot more of the camelCase styling than anything else.

Back to using the variables we've created, we want to use the secondary variable called, setPerson as a 'setter' (topic for another time) for our person variable. We are going to set this person variable inside of our fetchData() function and use the data that we've retrieved as the filler.

const fetchData = async url => {
    ...
    console.log(data);
    setPerson(data.results);
};

Remember, data is the whole return of the API, and results is the selection (key identifier) for the SWAPI data. So, to get this section of the data, we need to chain down to it by saying, "Enter through data, and then grab everything under the results key with all of its values".

Now, so we can get this fetchData() function up and running every time we refresh our page, we're going to use a cleaner method instead of just calling it at the bottom of the App() function. We will use what is called the useEffect React Hook.

For good useEffect, use this...

The useEffect Hook is used to do almost exactly what the name implies, "use an effect". Some examples of good effects are, fetching data (duh), manipulating the DOM, and setting timeouts for specific sections of code to fire off when they need to do so. Here, in our case, we will be using it to fire off when the page (or, in most use cases, the data itself) is changed/refreshed. Typically, you will see this used for Backend data being altered now and again, depending on the app and the API(s) being used. Again though, a topic for another time.

And, if you'd like to learn more about the useEffect hook, I highly recommend checking out the React docs themselves on their newly fashioned and updated website React.dev.

Link to the React - useEffect Hook

At the top of the App file, inside the curly braces for the import React line, we are going to also import useEffect, like so:

import React, { useState, useEffect } from 'react';

Now, back to inside the App() function itself, underneath the fetchData() function, let's implement the useEffect hook, by calling fetchData() inside of it, using an initial function call.

useEffect(() => {
    fetchData(API_URL);
}, []);

Notice the empty array at the end of the initial function call. What this is used for, is to set a 'changing state variable' that will be relied on from the useEffect() function.

Currently, since we don't foresee any new Star Wars movies coming out any time soon, or any new data being altered or changed, we do not actually need to implement the person variable there at this time. But, if your data variable was to have current/continuous changes happening, it would be good to place that inside of the square array brackets. For this app, however, we're good to go as it stands.

This is what your App.jsx file should look like, currently:

Okay so now that we've got that up and running, let's make sure this works. Head over to your browser window where you have http://localhost:3000/ open, make sure your DevTools are up on your screen with the Console tab displayed, and click refresh on the page. If you see the data still being populated inside the Console tab, then you're on the right track!

A quick geeky side note for all of my network speed junkies out there: I have also noticed that the SWAPI (Star Wars API) does inherently have a - very brief, but still somewhat noticeable to the trained eye - lag as the page is refreshed. Unfortunately, this is not my API, it is free and open-source, but I can assure you it is not an issue overall while coding along with this article. You're gonna be just fine, I promise. Just don't look at your Network tab in the DevTools, and pretend the short 1.98-second lag doesn't exist. It can't hurt you so long as you forget about it. Unlike the monsters under your bed.

Last Person in is a rotten variable!

As I'm sure you have noticed, if you have a good linter in your text editor of choice, or are using VS Code, your variable person has a weird pseudo-error squiggly line underneath it. This is simply because we have not provided it with any TLC as of yet, which we are about to do.

So, let's put our person variable to good use, inside of our unordered list element. We are going to .map() through this person data, and then return/display said data as an <li> element, along with giving each one a specific key as a sole identifier for that piece of data. I realize to someone new to this, it may seem a bit confusing, but code along here and I guarantee this will make sense by the next part.

Inside of our <ul> element, let's get rid of our already created li element, and open up a pair of curly braces like so:

<div className="container">
    <ul>
        {}
    </ul>
</div>

Here, in this set of curly braces, is where the real React magic happens. We can put things like variables in here, mathematical equations, or simply a bunch of nonsense, so long as it's related to JS in some way. In React though, we typically use this for either inserting variables, data, or setting up a pre-created function. In our case, the usage will be for mapping through the person variable data that we set earlier inside of our fetchData() function.

To start, we will call the person variable, chain the .map() function to it, and give that .map() an initial function. Inside of this function setup, we are going to give it 2 parameters to use: item and index. The item parameter will be used as the pinpointer that maps through the data, pulling what we want from it, and the index parameter will be used as a key identifier (or, an index) for each li element.

Let's see this in action.

<div className='container'>
    <ul>
        {person.map((item, index) => (
            <li key={index}>{item.name}</li>
        ))}
    </ul>
</div>

If you'll notice, unlike a regular function that will open up with curly braces like { ... }, here we have used parentheses ( ), because we are explicitly returning something like HTML. If we were let's say also computing some other code inside of it, then we would use the { } instead. But as you can see, the only thing we needed the mapping call to do, was to return our data in a cool and HTML-friendly way.

By now at the final checkpoint, your App.jsx file should look something like this:

Go ahead and open your browser window for localhost back up and hit refresh (it should already be refreshed after saving the App.jsx file, but doing it for good measure doesn't hurt). You should see a list of all the cool names of people from Star Wars being displayed!

Success! Great job Coder

And that's all there is to it. Fetching data, mapping through the data to find what we need/want to use in our apps, and then producing it for the view. It really is quite simple when you break it down step by step, and it can be a lot of fun when it comes to making your own CRUD apps using large-scale APIs or even making your own data to manipulate and filter through for an app.

Hope you enjoyed it, and I am currently in the process of writing a full breakdown of Data and APIs and what it all means to use them in a full-stack application in both Web and Software.

If you have any questions, feel free to reach out to me. I'll be trying to post about once a week if not once biweekly from here forward, so keep an eye out for the next installment. As always, thanks for taking the time to read my article, and I hope it was educational for your future coding/programming endeavors!

~ Tyler is a Web & Software Engineer with 10+ years in the tech field. Dad, Book nerd, React & TypeScript Advocate.

"You will never, ever forget your first. It's going to be the biggest learning curve that sets the tone for the rest of your experiences. Even if it sucks." ~Sloner Nitsly

Hit the ground running.

Like any field where you are required to know more than you need to, your first time actually being entered into the job field will always come with deep reverence and fear. You will feel as though, this is it, you've made it. That is truly an amazing feeling, and there will also come a want to impress and showcase what knowledge you have, especially as a Junior Dev on the team. The idea that you can maybe not just empty your cup and learn a lot, but also that you may be able to bring something fresh and exciting and new to the table. Heck, you may keep growing and be the youngest and coolest Senior Engineer by the time your work is done here!

But, as we Developers and Engineers all soon come to find out (some quicker than others), there is almost nothing ingenious or inventive or new that you could realistically bring to the table, and you need to learn to pay your dues, as it were.

Today, I am a Senior Web/Software Engineer, with nearly 10 years of experience in the tech field. I have been a Front-End Engineer (my focus and passion), as well as a Full Stack Engineer, and in the end I have learned that you learn to wear a lot of different hats no matter what company you work for, now or in the future. This, I promise you, is a good thing to experience.

Let me share some knowledge and answers to questions you may have for your first job. I'm going to give some sound advice that I wish I had been told when I was still new to the game. Advice that has gotten me from a Junior Dev too green to remember how to call an Object property, all the way to helping a tech startup blossom, as a Senior Engineer and Manager.

The best advice I can truly give you though, before we start, is do not ever feel like you are not good enough. We all started off with very little knowledge, a passion to code, and the insurmountable suck that is the Imposter Syndrome. Just know that you are good enough, and if you stick with it all, you can be great. And remember, don't sweat the bugs. They come and go.

First Day Jitters

Your first day/week on the job at a new company can be daunting, to say the least.

You are in and out of meetings, greetings, and handshakes, and you're simply too busy to even remember the Senior Back-End Engineer's name even though you just met them a couple of hours ago. The interviews and the TCI that you went through, along with all of your studying/project-building has trained you for this experience. You've got this, you know what it is you're supposed to be doing.

So there's no reason to be nervous, right?

The scary parts all happen during your first week, at any company. Knowing this is half the battle, honestly. As long as you're expecting to be busy as hell, and learning even more about the company's tech than you ever thought possible, then you can get through the actual work of it all.

My First Job: Front-End Software Engineer

My first actual position in the tech field was - working remotely, from home - with a national recycling company, that had built a software application to help large-scale companies manage not only their waste, but their recycling as well. I was tasked with editing and creating the full Front-End (and UX/UI design) of the software app. By myself.

The team consisted of: 1 Senior Back-End Engineer, 1 DevOps Engineer, an I.T. Tech, and me on the Front-End of it all.

The previous FE person before me, had apparently told the company that they had built a full-scale prototype app that was ready to go live, which turned out to be an outdated Bootstrap Admin template that they had secretly purchased and did not in fact know how to implement anything. My job was to un-screw the FE situation, and build them an actually usable and decently designed structure, so that the DevOps and BE can send data with our APIs to display properly for our large client base. The clients this company took on were some big brand names, so this isn't something that can look like or run anything short of amazing. I tried the best that I could do.

One random Monday, approximately 2 months into the job, I get a Slack notification about an immediate all-hands meeting at 9am. It was currently 8.30am, so I was a bit panicked. I had only ever been in one of the all-hands meetings so far, and it had ended with us being told of a 'change in management'. So I did not have high hopes for this one. Turns out, that our Senior (and only) BE Engineer had decided to quit for unspecified reasons. So now it was up to me to, as quickly as humanly possible, become a Full Stack Engineer, with only mild education in anything BE or how to even manage something like SQL table data, for example.

via Giphy

Instead of giving up, I stood my ground and told management that they needed to not only immediately hire on a new BE Engineer, but also to give me time to continue not only my own tasks on the project, but also to educate myself on being a Full Stack as soon as possible. They were luckily enough respectful of that, and we pushed our next live production version of the software back an entire month and a half. No, I did not get paid the job of 2 people, I just worked my butt off and took on more hours (I was hourly not salary at the time) to salvage the MVP for the company. I was thankful that this was not all magically on my shoulders, but that I had a fantastic and brilliant team to work with every day.

In my professional opinion, this is not the worst way to learn something - by expediting the learning process - but, it can be used as a good trick for further down the line when you need to gain knowledge on something new for work or a personal project. Don't get me wrong, taking a lowly Junior FE Dev, and giving them Mid-Senior level tasks as a Full Stack can be extremely difficult. But, it can also be very rewarding, aside from the stress it will ultimately give you.

My point in bringing this up, is that sometimes in companies we work for, we are brought on for one thing, but behind the curtain are pushed to wear different hats in our employment. The idea behind this, is that immersing yourself in a few different things such as new languages or seeing how fun it can actually be to help construct a data schema, these things can actually be extremely beneficial for Devs/Engineers. You will fail, a lot. But that is very normal for this field. We all fail, encounter bugs that make our brains implode, or simply run into a problem we have never seen before. The trick, is to know how to walk through the failure step by step, fix it the best way you can find how to do, and learn from those mistakes.

In summary, having your first real job in the tech field can be life changing, not just for your career, but also for you as a person. Now, whether it is a good experience, or a not-so good one, is all dependent upon you, and how you learn from mistakes and triumphs. Don't ever feel like this job you have or want is going to make or break you as a Developer. Companies come and go in your life, that's why you'll almost never see a person's resume with just one place of experience, if they have been in the field long enough that is. Learn everything you can every day, and hope to give the company your very best work, also because you learn about yourself and your work ethic by doing so.

A funny little note I'll leave this section on before I get to some advice for Juniors in the field, I will tell you that I have watched the most badass of Senior Engineers fumble and fail miserably. Do you know what most of them do when this happens? They laugh, and get to work tracing back the steps, and searching for a better answer to solving the problem. Failure is common. It's what you learn from it that counts towards your future.

Here's to the crazy ones, the misfits...

"I am the wisest man alive, for I know one thing, and that is that I know nothing." ~Socrates

Interviews can be scary, and outright terrifying. Whether you're prepared or not, the feeling that you are about to be (let's call it what it is) judged for the next 45 minutes to an hour, can absolutely become gut-wrenching. But, the best part is, they truly aren't scary at all. We're just led to believe they are.

I'm going to give my personal top 3 best interview tips, and I truly hope they help you along your Dev journey.

Interview Tip #1: No matter what, be honest.

If you are asked to answer a question - during the interview or at your job - that you feel is out of your wheelhouse, feel free to be upfront and honest with your response. Realistically, speaking from experience on both sides of that table, the simple fact that you are admitting you are not a Jedi Master of a subject matter can actually be viewed as a good thing, showcasing that you have room to grow, along with your willingness to learn. The tech field is one of the many difficult job fields where a lie pertaining to skills/knowledge can be almost immediately brought to light. So don't fake your skills or experience, study hard and tell the truth.

I have seen some of the smartest people I've ever met completely fumble a simple question in an interview. Your skills are based not only what you've learned, but your practice and dedication to the craft. Make sure that you're not applying for a job that is out of your range, just because it's a job in the tech field. Remember that it's better to be a T-Shaped Person instead of a 'Jack of all Trades'.

Interview Tip :2: What to do, about a Tech Interview

Tech interviews are notoriously difficult. Google for example, has a multitude of videos on YouTube dedicated to showcasing the process of interviews at the company.

Going through the interview process can be daunting, but easily the part of the process that has the most notoriety is the TCI (Technical Coding Interview) test(s). This is a specific interview that is solely dedicated to testing how well you know your stuff. There are 2 main ways of doing this part of the procedure:

• Code Sharing
• Test Project(s)

Code sharing interviews unfortunately happen more often than any other type of TCI. They're not always high-stress, but they sure as heck can be, so be prepared and study like a crazy person before the interview. Always try and analyze the technical question being asked, and take your time (while being respectful of everyone's time) on finding the best route for the answer. In interviews like this, the interviewer is not necessarily looking for whether you got the answer 100% correct or not, but more the process of how your brain thinks and works on a problem. Do you get frustrated easily, do you process more verbally or internally, etc. Just bear that in mind during these, and remember to breathe.

In my personal opinion, I thoroughly appreciate the test projects, not only because you don't have to bum-rush to solve on the spot (which is not realistic anyway), but mainly due to the fact that if I am trying to accomplish a certain task but I don't have all the answers, I can go and study up (read some documentation) about how better to resolve the issue at hand. I've found that giving your brain the time to focus on a problem - without the feeling that someone is breathing down your neck waiting for the answer - allows you to formulate not an immediate response, but the best response to the question.

Interview Tip #3: Tell me more, tell me more

A fantastic thing to do during any interview process, is to ask good questions. The more questions you ask (without sounding over-eager), the more it shows that you're interested in the company itself, and maybe not just a paycheck and some benefits. All companies want someone who is not just going to work hard, but truly care on some level about the future potential of it all.

If you find that you can't think of a lot of good questions, think about these main points, and expand on them:

• The Company/Team
• The Daily/Current Rundown
• Goals/Ideals

Questions about the company itself or the team you'll be working on is very important, because it allows you to learn about how the company operates and how the team works/manages itself in the coding process. You can even ask questions about previous workers and why they left/were asked to leave. I don't fully recommend this one, but I've seen it done and it's a fair and valid question to be asked at some places.

The Daily life of a Dev/Engineer on the team is especially crucial, so that you can see what the inner-workings of the team are all about. What kind of tasks are taken up usually, is there an All-Hands meeting every morning, once or twice a week, etc. This will keep your head in the game on what to be prepared for if you do end up working on the team.

Good goals and ideals are the founding basis for any great company. Without knowing what your company has come from and where it's going, then you will not have much of a future. The prospects and origins of a company are great to find out for yourself as the potential team member, because it can display what trajectory the company is planning to go in, and whether or not you see yourself being a part of that road.

Interview Tip #4: Bonus Tip!

via Giphy

Always, always, always, be sure to practice what you preach. If you swear that you are a JavaScript Master, then you had better have the skills to back up that claim! The job you apply for, should be what you're comfortable with doing. This sounds stupid and obvious, but the reality of the situation is that there just too many companies out there in the wild that have zero clue the difference between a Front-End Web Developer and a Full Stack Software Engineer. This is why we need to educate ourselves on what exactly we can do best, and practice it until we're writing for() loops for arrays in our sleep. So that when it comes time for a job interview, and the application says Front-End Engineer, you don't have to freak out because you know you've got this in the bag.

If you find an area of coding/programming that truly speaks to you, whether it's in the AI and Data Science side of the arena, or you simply found out that you love building web apps with React and SCSS all day, you need to do yourself that big favor and dive head first into that area with as much go-getter attitude you can muster. Remember,T-Shaped Person..

Necessity: Portfolio

Your Portfolio is so very important to the process of getting in the front door of any company, let alone interviewing with them. Companies across the world, when hiring for anyone in the tech field, care a lot about your previous works and work experience.

Having a website or a GitHub account, showcasing the places you've worked, and the level of commitment to greatness and projects as a coder/designer is seen as not only a right of passage, but your ability to tell the world how you work and what kind of expertise and skill-set you as a Developer/Engineer can bring to the table at any company.

The main point with a good portfolio, is that you need to make it your own. Design and develop it in your own style, or a style that you have found to be what can represent you as a coder/programmer.

Personally, as of 2 weeks ago, I had decided it was time to get rid of my now year-old portfolio and start coding up and designing a new one. I think it's good to change up your portfolio at least once a year, and to try doing something new or using a different framework than you did the last time. I've been a React and TypeScript coder for years, I'm faithful to both, but this new portfolio site will be coded entirely in Next.js and straight vanilla JavaScript.

So try something new and have fun with it! Push yourself to learn a new language or framework/library that you've never tried before, or even just something similar to what you have been wanting to learn.

Just remember, your portfolio is like your house: When people show up, you want them to be impressed with what they see. Is it a little vain to have a large focus on the aesthetic and design? Maybe. But you need an outlet for showcasing your skills beyond coding another new web app or some mock-up design work, so why not make it look the best you can make it to be!

In Summary...

This has been a lot of fun writing this, but the better feeling is the hope that someone out there can learn something from it all. If you have any questions, or want some general advice in the tech field, I'm always up to helping people get where they need to get going - that is, if I can help.

TL;DR - Don't sweat the small bugs, ask a lot of questions, dig deep to be a wealth of knowledge, and do not for a single second let Imposter Syndrome get to you. Know your worth, and show your worth.

~ Tyler is a Web & Software Engineer with 9+ years in the tech field. Dad, Book nerd, React & TypeScript Advocate.

#4articles4weeks #week1 @hashnode