DEV Community: willparr

6 Questions to Ask in an Interview

willparr — Fri, 19 Feb 2021 15:50:13 +0000

In this video I go over my top 6 questions to ask in an interview. Interviewing is a two way street - you need to determine if the company is a good fit for YOU too.

A lot of interview guides go over what questions to expect, but not what questions to ask. I capture some of my favorite questions in this video 👇

How to Build a Web Project Like Everyone Else (satire)

willparr — Thu, 11 Feb 2021 16:57:28 +0000

Had a little fun creating this video and poking fun at myself and the web dev community in general 😂 Hope you enjoy and if you want some helpful videos, be sure to check out the other videos on my channel!

My Top Soft Skill for Software Engineering

willparr — Thu, 07 Jan 2021 18:45:21 +0000

Soft skills are just as important as technical skills and it's what makes a well rounded engineer. In this video, I go over what I think the most important soft skill is.

Let me know if you disagree or disagree in the comments below 👇

As always, let me know if you liked this video! If you did be sure to give it a thumbs up👍 If you didn't like the video, let me know what I can do better next time!

Create a Music Discord Bot and Run it in the Cloud!

willparr — Mon, 14 Dec 2020 21:15:01 +0000

Hey everyone! I was inspired by a video from another Youtuber about making a discord bot, and decided to take it a step further 💪

In this video, I teach you the fundamentals of making the music bot and also how to deploy it to the cloud ☁️ Let me know what you think!

First Year as a Software Engineer

willparr — Mon, 23 Nov 2020 20:24:33 +0000

I originally wrote an article here about my first year as a Software Engineer!

Advice to My Past Self (First Year as a Software Engineer)

willparr ・ Jul 14 ・ 4 min read

#beginners #career #codenewbie #motivation

However, I also decided to do this in video format as well!

As always, if you have feedback about this content or what you would like to see in the future let me know!

Arrow Functions Tutorial

willparr — Tue, 17 Nov 2020 15:36:29 +0000

This video is aimed at people learning javascript or new to arrow functions. It goes over reducing a regular function down to an arrow function and also explains how the this keyword is used!

Let me know what you think in the comments below. As always, if you enjoyed this content, like and subscribe for more related content!

Getting Started with Expo

willparr — Thu, 12 Nov 2020 16:31:46 +0000

Video Link here

In this tutorial we will build a full blown weather app. It may not be the most polished, but it gets the job done 💪

This tutorial is aimed at those wanting to get their feet wet in React Native or mobile development in general. This video also assumes you have solid foundations in programming as well.

If you enjoyed the video, be sure to leave a like! If you didn't, let me know what I can improve on in the future to create better content 🙏

Arrow Functions => Explained

willparr — Thu, 01 Oct 2020 16:26:20 +0000

Arrow functions were introduced in ES6, and have made coding in JS more concise, but also confusing to those who may be coming from backgrounds outside of JS.

Let's take a look at a normal function:

function hello(){
    return "Hello World!";
}

//call signature
hello();

//returns 
"Hello World!"

That is what most people are familiar with, and the style is similar to most objected oriented languages. However, we can write it a bit differently:

const hello = function() {
    return "Hello World!";
}

//call signature
hello();

//returns
"Hello World!"

Above, we set the hello variable to be equal to a function. That means that we can call the hello variable like a function as shown above. Now, you might be saying "Hey, none of these have any arrows in them!" and yes, you're correct. However, understanding how we can write those functions will be easier to understand this arrow function syntax.

const hello = () => {
    return "Hello World!";
}

//call signature
hello();

//returns
"Hello World!"

Now this is our first arrow function that we have written so far. You can see it's called the same way as all of the other ones as well. You can see how rather than writing function() { we have written () => { so you can see that the function keyword is no longer needed, because the arrow takes care of that syntax.

Sure, we have looked at some basic functions, now let's look at passing in parameters. In ES5, we would have written something like this:

var multiplyNumbers = function(x,y) {
    return x * y;
}

In ES6, with the use of arrow functions, we can write something even more concise!

const multiplyNumbers = (x,y) => { return x * y; }

These two functions will return the exact same things, but you can see that one of the functions is only one line. This makes it easy to read and saves from developer fatigue. Now, what if I told you we can reduce the above function to a more concise expression?

const multiplyNumbers = (x,y) => x * y;

Notice that we don't have any curly braces this time. Some people like this syntax and others don't because it's not as explicit. This is where coding styles come into play! In the above example, the reason that we can do without curly braces is because we only have one expression. The return statement here is implicit, and the compiler knows that because we only have one expression, that's what our returned result should be. Now that we have looked at two parameters, let's look at one parameter.

//ES5 
var squareNumber = function(x) {
    return x * x;
}

//ES6
const squareNumber = x => x * x;

Here you can see that the syntax is extremely similar, but that we don't have to include parenthesis around our parameters when we only have one. Now that we have looked at one parameter, let's look at no parameters. When we have no parameters, parenthesis are required.

//ES5
hello = function() {
    return "Hello World!";
}

//ES6
hello = () => {
    return "Hello World!";
}

Using the example from earlier, we can see that we must have parenthesis to show that this will be a function. Now that we have gone over the common ways to write arrow functions, let's look at some use cases that make our lives easier.

Let's say we had an array of objects like so:

const energyDrinks = [
    { name: 'Coffee', caffeine: 95},
    { name: 'Monster', caffeine: 86},
    { name: 'Red Bull', caffeine: 110},
    { name: 'bang', caffeine: 300},
];

And now that we have these objects, let's say we only wanted the caffeine content in each of them, so we could take the average of them later, or maybe do another calculation. So to do this:

//ES5
var caffeineContent = energyDrinks.map(function(energyDrink) {
    return energyDrink.caffeine;
}
//returns [95, 86, 110, 300]

//ES6
const caffeineContent = energyDrinks.map(energyDrink => energyDrink.caffeine);
//returns [95, 86, 110, 300]

Notice how both of these functions accomplish the same thing, but one is a lot more concise? That is why developers love arrow functions. Just remember not to go crazy, and only use them when you really need them.

Advice to My Past Self (First Year as a Software Engineer)

willparr — Tue, 14 Jul 2020 15:19:40 +0000

I just finished my first year as a software engineer. In this time I have worked with 9 different technologies and about 5 different products. I have enjoyed my first year, and I thought it would be good idea to do a retrospective on my experience so far. Read this for fun, or take it as advice if you are just getting into the field!

Ask questions ❓

I don't think there has been a time that I have gotten through a conversation with another coworker without asking a question. It's important to ask questions. Not only technical questions, but also ask questions about the business. Understand how the process works not only on paper, but in reality among team members. Also, ask questions about their day! It never hurts to be friendly to your team members and build relationships with them😉 Of course, ask questions in moderation and always try to find the answer on your own first.

People won't give you help unless you ask for it, and the best way to do that is by asking questions about items that you don't understand yet. How else do you expect to learn about the system?

Find a project to prove yourself (if you want) 🥇

If you want to move up the ranks and get promoted, then you will likely need to find a feature that will add a lot of value to the company, but is also in your skillset. This project is your springboard for getting more complex work and people trusting you with the work that you output. The tricky part is here is finding something that you can accomplish within reason, but also is large enough to help the company in a significant way.

Document Everything ✍🏻

When you are writing a new large feature, or maybe changing how an old one works, document this! Throw it in the ReadMe (if there is one) or create one. This helps others that had the same questions you did and now they have an amazing document to look at to help them. ReadMes were not heavily used at my company, but I started creating them anyways. Now, when people start on projects they know what resources they will need and can look over the document for some basic questions! It helps to get knowledge documented and not just living in people's heads.

Side Note: This is helpful for when someone has questions on a feature that you have worked on in the past. Now you have a reference for what you did 6 months ago!

Find hobbies ⚽ 📷

Find hobbies. More importantly, find hobbies that aren't programming. Everyone needs to have a life outside of work, it's important to your overall happiness. Try finding a creative and physical outlet like running and photography, painting and weight lifting, etc. Anything that helps get your mind off of work and software. Otherwise, you'll be burnt out in no time.

Ask for help and be open about your understanding 🙋🏼‍♂️

Earlier, we talked about asking for help. When you receive help or maybe someone is asking you a question, be open about your understanding. Unless there is an enormous gap of your understanding and what people expect you to know, people are usually willing to help. You don't need to know all of the system when someone from product asks a question, or understand a piece of code as soon as another engineer explains it to you. If you give the impression that you understand when you don't, it will become a problem later.

Make goals 📅 📈

Make goals. Make goals. Make goals. What do you want out of your career and in life? By writing these down, you know what you are actively working towards. On top of this, make specific goals. I am a big fan of the SMART (Specific, Measurable, Attainable, Relevant, Timely) goal setting strategy. Maybe start with the long term goals, and create your short term goals and stepping stones for those. Maybe you don't know what you want long term, so make short term goals for now! By measuring your goal progress, you have an accurate view of what you are accomplishing in your career.

If you don't create goals and actively improve, you will learn slower, advance slower, and miss out on your goals. Also, by creating these goals, it makes it easy to talk about what you have accomplished in your yearly review with your manager.

Always be eager to learn 🤔

You probably got into software because you wanted to learn something. Maybe it was a minecraft mod or creating an app. Either way you learned how to accomplish these things. As a software engineer, it is important to never stop learning. How you learn it is up to you: side projects, videos, reading but always keep learning! Being eager to learn will help you grow as a software engineer and as a person by continually exposing you to new philosophies and ideas.

Stick to these principles, and you'll keep growing as a software engineer and as a person.

Signed,

Your future self

Generalist vs Specialist

willparr — Mon, 06 Jul 2020 15:57:24 +0000

You've seen it on job postings whether they explicitly say it or not.

"We are looking for someone highly skilled in {insert fresh technology here} and has experience building..."

Or maybe something like this

"We searching for someone with experience in {this thing},{that thing}, {and a little of this}..."

Which one is more catered to you? Do you try to be an expert in a technology, or do you want to be more of a generalist in your career?

Bonus Question: Those who have switched from a generalist (full stack with different languages) to a more specialist (maybe fullstack javascript) role, what are the pros and cons for you?

Image Credit