In today’s digital world, every business and organization collects and uses data to build better products, target the right customers, improve efficiency, and even forecast future demand.

They say that data is the new oil – and now is the perfect time to enter the data analytics job market.

According to PayScale, the average salary for entry-level roles in analytics is around $55,492 per year. The average salary for a skilled analyst is about $88,928 per year. Even if you are a beginner to programming in Python, you can learn the essential skills for data analysis quickly if you are consistent.

In this article, I’ll go over what Data Analytics skills you'll need to know, and how to prepare for and ace interviews to land a Data Analyst position with Python.

What Does a Data Analyst Do?

As a data analyst, your primary responsibility is transforming raw data into meaningful insights.

Usually, the job description involves cleaning and organizing data to make sure that the quality of data is good. You'll also perform statistical analysis, interpret trends in complex datasets, build models, and create visualizations to communicate findings effectively. This information will help teams make business decisions and get valuable insights for the company's managers and key stakeholders.

Market research analysts collect and evaluate consumer and competitor data. A business analyst for Walmart could analyze purchase trends and identify seasonal patterns during events like Black Friday, Christmas, and New Year. This data could help the company expect higher demand and re-stock.

A data analyst at IKEA might analyze customer preferences in different rural and urban regions to better strategize which products to sell.

Data plays a role in every stage of a company, from market sizing and customer acquisition to advertising, customer journey, final conversion rate, and data-driven decisions.

Since I started working in data science, I have always felt like a little detective uncovering patterns and hidden knowledge. Are you now excited to learn how to become a data analyst? Let’s start with actionable insights.

Essential Technical Skills to Develop

The first step while preparing for any role is identifying and learning the right skills. Here are the essential and in-demand skills you should learn to become a data analyst:

Python Programming

One of the most crucial skills for a data analyst is proficiency in the Python programming language. Python is widely used in organizations to perform various tasks such as handling datasets, cleaning and manipulating them, and carrying out statistical analysis.

The popularity of Python stems from its ability to support a plethora of open-source packages and libraries and its flexibility and user-friendliness. I am confident that Python will continue to be an indispensable tool for data analysts in 2024.

If you’re new to Python, you can check out the Introduction to Python course on Hyperskill with hands-on projects, where I contribute as an expert. You don't need any degree to start learning.

But Python is vast – where should you start?

Start by learning basic syntax and data structures like lists, dictionaries, classes, and so on.

Once you are comfortable with the basics, get familiar with the essential libraries like Pandas (to read and manipulate data frames), Numpy (for statistical analysis), Matplotlib, and Seaborn for data visualization (creating plots).

• Here's a helpful course that teaches you Pandas and Python for Data Analysis.
• This course teaches you how to use Matplotlib for data visualization.
• Here's an in-depth guide to using NumPy for scientific computing in Python.

Python logo

SQL

SQL (Structured Query Language) helps you interact with large relational databases. You should learn how to create and update SQL tables, perform filtering and aggregation, and extract insights. MySQL is a commonly used syntax.

You can check out the SQL course for beginners on Hyperskill. And if you want a text-based overview, here's a full handbook that teaches you all the SQL basics you'll need to know.

Data Visualization Tools and Software

Analysing the data is the process, but presenting your insights is the final destination. You must master visualization analytics tools like Tableau software or Power BI to create dashboards and reports.

As a data analyst, you may have to present your findings to non-technical teams interpretably. There are also many advanced methods, like interactive dashboards and geographic mapping, for visualizing spatial data to help make informed decisions.

Statistics

Probability and Statistics cover a wide range of essential concepts for anyone working with data. You should know the basic types of distributions, such as Normal, poisson, and skewed, and how to handle each.

Many metrics, like mean, median, and standard deviation, can help analyze numerical variables and identify anomalies or outliers. P-value and Hypothesis testing are also critical.

Here's a tutorial on the top Stats concepts to know before getting into Data Science if you want to check your skills.

Excel

Even though most of us are familiar with Excel basics, you should learn functions like VLOOKUP, HLOOKUP, INDEX, MATCH, and IF statements for data manipulation.

Understanding how to use PivotTables for summarizing and analyzing large datasets and enabling dynamic data exploration is crucial.

If you want to learn more about how you can use Excel for data analysis, here's a course on that.

Develop Your Portfolio

The data analytics industry is highly profitable but also fiercely competitive. More than simply working through courses and acquiring skills is required to stand out.

To become a successful data analyst, you must build a portfolio of projects demonstrating your abilities.

Once you're familiar with the relevant technology, identify a problem that requires analysis and locate a publicly available dataset. Analyze the dataset using various methods and extract any meaningful insights. If you don't have a degree, focus on making your portfolio the best you can.

Kaggle is a best friend to any data analyst beginner. Numerous datasets are available in all fields, from movie reviews and tweets to medical X-rays. Open notebooks allow you to see what expert data scientists have worked on with the same dataset. This is a great way to get guidance on approach and inspiration for ideas to try out.

For example, take the popular Kaggle dataset of IMDB Movie reviews. What can you do with it? I’ll share a few ideas to help you get started.

You can begin at a basic level by calculating statistics to summarize critical metrics such as average rating, distribution of ratings, and the most reviewed genres.

Then you could use natural language processing (NLP) techniques to perform sentiment analysis on the movie reviews.

Next, create visualizations to present findings effectively. For instance, plot sentiment scores over time, visualize the distribution of reviews across genres, or create a word cloud highlighting frequently used words in positive and negative reviews.

Tailoring your projects to align with your interests and the specific requirements of potential employers will make your portfolio stand out in a sea of applicants.

For example, if you want to work in healthcare, do a project that adds value to the field. Remember, it's not just about the code; it's about telling a compelling story with the data.

Finally, you'll want to scrape and analyze real-time data. Build a tool that tracks social media sentiment about a brand or analyzes website traffic patterns.

How to Build a Good CV

The first stage of any job application is shortlisting based on your CV (or résumé). Creating a concise and technically sound CV/résumé to increase your odds is crucial.

Your CV must be based on your educational background, coursework information, achievements, prior internships or work experience, and extracurriculars.

Let me share a few tips on creating a compelling CV or résumé:

• Custom CVs: When creating your résumé, customize it to the job you are applying for. Emphasize the skills and projects that are most relevant to the specific role. If appropriate, you can also include any extracurricular activities demonstrating your ability to manage a team. But you must provide only accurate information – this should go without saying, but embellishing your résumé beyond your actual experience is unacceptable.
• Quantify your achievements: Instead of mentioning that you conducted data analysis, mention specific projects, tools used, and your impact. For example, you could say that you increased website conversion rate by 15% through A/B testing. Remember to add any Python libraries, frameworks, and tools you used.
• Keep it concise and visually appealing: Recruiters review hundreds of résumés and may need help reading each line in the first round. So make a résumé that simultaneously conveys your skills and experience highlights. Use bullet points, clear headings, and formatting when needed to highlight certain aspects.

Tips to Ace the Technical Interview

The final stage is the technical interview. Below, I have gathered some tips that will help you understand what your preparation might involve, along with examples of questions you might encounter. Remember that each case is unique and you should use these as general guidelines.

First, make sure you practice coding a lot. You can use platforms like HackerRank or LeetCode. Remember that transparent and efficient code is vital for passing an interview. For example, you might be asked to describe the correct syntax for the reshape() function in NumPy.

Next, make sure you are comfortable working with SQL. You'll need to know how to handle complex queries, joins, subqueries, and data manipulation in SQL. A question like "How do you subset or filter data in SQL?" or "What is a Subquery in SQL?" could come up.

You should also be prepared to discuss and demonstrate your skills in data visualization. You should be able to explain your choices in visualization for different types of data. For instance, "How is joining different from blending in Tableau?" or "What is the difference between Treemaps and Heatmaps in Tableau?"

You'll also want to have a good understanding of statistics. Be prepared to discuss statistical concepts like mean, median, mode, standard deviation, correlation, and regression analysis.

You might be asked to interpret data or explain the significance of statistical findings in a business context, such as "Explain the term Normal Distribution” or “How do you treat outliers in a dataset?”

Next, make sure you have a solid foundation in data cleaning and preprocessing. Be ready to talk about experiences with cleaning and preparing data, involving dealing with missing values, outlier detection, and normalization.

Knowing tools like Pandas in Python can be particularly beneficial. An example question could be, "How can you add a column to a Pandas Data Frame?"

Be comfortable with data-driven decision making. You might be asked to explain how you have used data to inform decision-making in past experiences in order to demonstrate your ability to draw conclusions from collected data and use it for the company's business decisions.

You should also be able to showcase your past work. If possible, bring examples of your past work or projects, such as a portfolio or detailed case studies.

Be ready to discuss the challenges faced, how you approached them, and the outcomes. Questions like "Have you ever run an analysis on the wrong set of data? How did you figure out your error?" can be expected.

Also, don't neglect behavioral skills. Be prepared for behavioral questions that explore your problem-solving skills, teamwork, and ability to handle deadlines and pressure. Reflect on your past experiences and be ready to share stories that highlight these skills.

And finally, brush up on your industry knowledge. If the company operates in a specific industry (like finance, healthcare, retail, and so on), having some background knowledge or experience in that industry can be advantageous. Tailor your preparation to understand the unique data challenges and opportunities in that sector.

Remember, each company may have a different focus in their technical interviews, so try to get as much information as possible about the interview format beforehand. This way, you can tailor your preparation to meet their specific expectations.

Conclusion

Becoming a data analyst is a marathon, not a sprint.

If you are interested in a career as a data analyst, Python is an excellent language to learn. It is a versatile tool that allows you to manipulate, analyze, and visualize data effectively. By mastering in-demand skills such as Python, SQL, Data Visualization tools, Statistics, and Excel, you can set yourself up for success in the data analytics job market.

Also, building a portfolio of projects showcasing your abilities is crucial to stand out as an entry-level data analyst. The data analytics industry is rapidly growing, and there is a high demand for qualified professionals.

So, start learning and experimenting with data today to land your dream job as a data analyst in Python.

Embrace the learning, celebrate the small wins, and don't be afraid to ask for help. Good luck with your goals and data analyst career path!

Thank you for reading! I'm Jess, and I'm an expert at Hyperskill. You can check out an Introduction to Python course on the platform.

I have selected all of the major questions you should know as a React developer in 2022, whether you are interviewing for a hired position or not.

These questions cover everything from the core concepts of React to a practical understanding of when you should use certain features.

To get the best results out of this guide, make sure to try to answer each question yourself before looking at the answers.

Let's get started!

1. What is React? Why Use It?

React is a JavaScript library, not a framework.

We use React because it gives us all the power of JavaScript, but with built-in features that improve the way we build and think about building applications.

• It gives us a way to easily create user interfaces with tools like JSX
• It gives us components to easily share parts of our user interface (UI), which static HTML itself cannot do
• It allows us to create reusable behavior across any of our components with React hooks
• React takes care of updating our UI when our data changes, without the need to update the DOM manually ourselves

Extra Credit: There are frameworks in React that give you everything you need to build an app (with little to no third-party libraries), like Next.js and Gatsby.

React was created for building single-page apps in particular, but you can make everything from static sites to mobile apps with the same React concepts.

2. What is JSX?

JSX is a way of building React user interfaces that uses the simple syntax of HTML, but adds the functionality and dynamic nature of JavaScript.

In short, it is HTML + JavaScript for structuring our React apps.

Though JSX looks like HTML, under the hood it is actually JavaScript function calls.

If you write a div in JSX, it's actually the equivalent of calling React.createElement().

We can build our user interfaces by manually calling React.createElement, but as we add more elements, it becomes harder and harder to read the structure we have built.

The browser cannot understand JSX itself, so we often use a JavaScript compiler called Babel to convert what looks like HTML into JavaScript function calls that the browser can understand.

3. How do you pass data to React components?

There are 2 main ways of passing data to React components:

1. Props
2. Context API

Props are data passed from a component's immediate parent. Props are declared on the child component, can be named anything, and can accept any valid value.

function Blog() {
  const post = { title: "My Blog Post!" };

  return <BlogPost post={post} />;
}

Props are consumed within the child component. Props are always available within the child as properties on an object.

function BlogPost(props) {
  return <h1>{props.post.title}</h1>
}

Since props are plain object properties, they can be destructured for more immediate access.

function BlogPost({ post }) {
  return <h1>{post.title}</h1>
}

Context is data passed from a context provider to any component that consumes the context.

Context allows us to access data anywhere in our app (if the provider is passed around the entire component tree), without using props.

Context data is passed down on the value prop using the Context.Provider component. It can be consumed using the Context.Consumer component or the useContext hook.

import { createContext, useContext } from 'react';

const PostContext = createContext()

function App() {
  const post = { title: "My Blog Post!" };

  return (
    <PostContext.Provider value={post}>
      <Blog />
    </PostContext.Provider>
  );
}

function Blog() {
  return <BlogPost />
}

function BlogPost() {
  const post = useContext(PostContext)

  return <h1>{post.title}</h1>
}

4. What is the difference between state and props?

States are values we can read and update in our React components.

Props are values that are passed to React components and are read only (they should not be updated).

You can think of props as being similar to arguments for a function that exist outside of our components, while state are values that change over time, but exist and are declared inside our components.

State and props are similar in that changes to them cause the components in which they exist to re-render.

5. What are React Fragments used for?

React fragments are a special feature in React that let you write group children elements or components without creating an actual node in the DOM.

The fragment syntax looks like an empty set of tags <></> or are tags labeled React.Fragment.

In simpler terms, sometimes we need to put multiple React elements under a single parent, but we don't want to use a generic HTML element like a div.

If you are writing a table, for example, this would be invalid HTML:

function Table() {
  return (
    <table>
      <tr>
        <Columns />
      </tr>
    </table>
  );
}

function Columns() {
  return (
    <div>
      <td>Column 1</td>
      <td>Column 2</td>
    </div>
  );
}

We could avoid this problem by using a fragment instead of a div element in our Columns component.

function Columns() {
  return (
    <>
      <td>Column 1</td>
      <td>Column 2</td>
    </>
  );
}

Another reason for choosing a fragment is that sometimes adding an additional HTML element may change the way our CSS styles are applied.

6. Why do we need keys for React lists?

Keys are a unique value that we must pass to the key prop when we are using the .map() function to loop over an element or a component.

If we are mapping over an element, it would look like this:

posts.map(post => <li key={post.id}>{post.title}</li>)

Or like this if we are mapping over a component:

posts.map(post => <li key={post.id}>{post.title}</li>)

And in both case, we need to add a key that is a unique value, otherwise React will warn us.

Why? Because keys tell React which element or component is which in a list.

Otherwise, if we were to try to change items in this list by inserting more or editing them in some way, React wouldn’t know the order to put them in.

This is because React takes care of all of the business of updating the DOM for us (using a virtual DOM), but keys are necessary for React to update it properly.

7. What is a ref? How do you use it?

A ref is a reference to a DOM element in React.

Refs are created with the help of the useRef hook and can be immediately placed in a variable.

This variable is then passed to a given React element (not a component) to get a reference to the underlying DOM element (that is, div, span, and so on).

The element itself and its properties are now available on the .current property of the ref.

import { useRef } from 'react'

function MyComponent() {
  const ref = useRef();

  useEffect(() => {
    console.log(ref.current) // reference to div element
  }, [])

  return <div ref={ref} />
}

Refs are often referred to as an "escape hatch" to be able to work with a DOM element directly. They allow us to do certain operations that can't be done through React otherwise, such as clearing or focusing an input.

8. What is the useEffect hook used for?

The useEffect hook is used for performing side effects in our React components.

Side effects are operations that are performed with the "outside world" or something that exists outside the context of our React app.

Some examples of side effects include making a GET or POST request to an external API endpoint or working with a browser API like window.navigator or document.getElementById().

We cannot perform operations like these directly within the body of our React component. useEffect gives us a function within which to perform side effects and a dependencies array which lists any external values that the function relies upon.

If any value within the dependencies array changes, the effect function runs again.

9. When do you use React Context vs Redux?

Redux is probably the most commonly used third-party global state library for React, but you can replace the word "Redux" with any global state library for React.

React context is a way to provide and consume data throughout our application without using props.

React context helps us prevent the problem of "props drilling", which is when you are passing data with props through components that don't need it.

Instead, with context we can consume the data exactly in the component that needs it.

While we only use Context to get or "read" values globally in our application, Redux and other third-party state libraries allow us to both read and update state.

Context is not a replacement for a third-party state library like Redux because it is not built for state updates. This is because any time the value provided on Context changes, all of its children will re-render, which can hurt performance.

10. What are the useCallback & useMemo hooks used for?

The useCallback and useMemo hooks exist to improve our components' performance.

useCallback is to prevent functions that are declared within the body of function components from being recreated on every render.

This can lead to unnecessary performance issues, especially for callback functions that are passed down to child components.

useMemo, on the other hand, memoizes an expensive operation that we give it.

Memoization is a technical term for functions that are able to "remember" past values they have computed if their arguments have not changed. If so, the function returns the "remembered" value.

In other words, we may have a calculation that takes a significant amount of computing resources and we want it to be performed as sparingly as possible.

If that case, we use the useMemo hook, which differs from the useCallback hook in that it returns a value, not a function.

Become a Professional React Developer

React is hard. You shouldn't have to figure it out yourself.

I've put everything I know about React into a single course, to help you reach your goals in record time:

Introducing: The React Bootcamp

It’s the one course I wish I had when I started learning React.

Click below to try the React Bootcamp for yourself:

Click to get started

It's not a big secret that building a developer portfolio can greatly increase your chances of getting hired.

Everyone tells you that. But, they don't always tell you what makes a good one.

You see, many portfolios are generic and rather uninspiring. If your portfolio looks just like everyone else's, then how can you expect it to stand out?

Well, it won't stand out.

But don't worry – I've been there. My first portfolio was bland, uninspiring, and had many of the not-to-do's I talk about in this post.

However, I'm an ex-marketer, turned developer, I know how to make something stand out. I've made ad campaigns that have skyrocketed sales and had people talking. I realized I needed to think like a marketer to make my portfolio stand out.

The good news is that the same principles can be applied to your portfolio to level it up. If you read this guide and implement the tips, you'll raise your portfolio above the sea of other junior developers trying to stand out.

Before we launch into the five tips to level up your portfolio, let's just make sure we are on the same page.

What is a portfolio?

A portfolio is a way for you to showcase who you are, what skills you have, and most importantly the work you've done.

As a developer, your portfolio is going to be in the form of a website. The main goal of this website is to showcase yourself and your work in the best way possible.

It needs to make you stand out and it needs to make employers think "Whoa! I'd like to work with this person". Ultimately it will need to show them that you could be awesome to work with so they are compelled find out more about you.

A portfolio should therefore include some standard elements. Below are the bare minimum elements your portfolio must include.

The bare minimum of a portfolio

These are the non-negotiables of any developer portfolio:

1. Responsive design (learn about how to do that here)
2. Projects showcasing your work
3. An "about me" section or somewhere people reading your site can learn about you
4. Your portfolio needs to be accessible
5. Your portfolio should have a custom domain. Buy a domain name – you can get them for less than $10. Don't send people to 39238834.netfily.com
6. A way for people to contact you, preferably your email

If you have these six non-negotiables on your portfolio, you are off to a good start.

Now let's look at five ways you can level up your portfolio, starting with a non-obvious one.

Five things you can do to level up your developer portfolio

1. Know your target audience

One area that can help level up your portfolio is knowing exactly what the purpose of your portfolio is. That is, who is this portfolio for?

If I asked you what the purpose of your portfolio was, does the output match that? Let's say, for example, the purpose of your portfolio is to land your first junior developer role. Then your portfolio is going to look very different from someone who is looking to be a freelance web developer.

Therefore the first thing you need to do is ask what is the purpose of your portfolio. Start broad and then try to refine it. Keeping with the junior developer role example, you could refine it down to a junior frontend developer specializing in React.

If you are a junior frontend developer, then your portfolio won't need things like the generic skill cards below.

These cards are better suited for someone who is looking for freelance work.

When you know the purpose of your portfolio, you can better tailor the information to communicate why someone should help you achieve your purpose.

2. Level up your project details

This is the most important section of your portfolio, and it is the one section I often see that is not well-executed.

If you browse something like r/webdev and search "portfolio" let me tell you what you're going to see if you click 90% of those portfolios and look at projects. You're going to see a calculator app, a weather app, tic tac toe, a movie finder app, "insert big website" clone, and so on.

Now, don't get me wrong – these are useful projects for learning the skills they require. And people have spent time making them. The problem is that everyone builds the same stuff. You can often just follow along with a tutorial and create them without much thought.

There are two problems here.

The first is that you are not differentiating yourself. If I'm HR or the hiring manager why should I pick your calculator app over the other 30 in the inbox? Also, how can I trust that you built this thing yourself and that you didn't just copy/paste code from a tutorial?

The second is that most people just put the project in, link to the GitHub repo, and maybe a live demo. This doesn't tell the person who is potentially going to hire you a lot, and it doesn't give them much reason to employ you over everyone else who has done the same.

So then, how do you make your projects section stand out? Let's look at a few ways you could level up the projects section of your portfolio.

Add original projects

You don't have to reinvent the wheel or make the next great social media application. But it would be great if you tried to use a different API instead of the standard weather API.

You could for instance create a surf report app that is the same as a weather app but instead you are calling different endpoints. This shows me that you know how to call an API outside of a tutorial.

If you're not sure how to make your own original project then check out this guide on how to plan and build a programming project for beginners.

Give some details about the project

The first problem is that many projects are unoriginal. The second is that most people don't give more than the basic details about the project.

What will make you stand out is giving some details about your project. When I say details, what I mean is give me a story about the project. The best portfolios I see tell me about the project don't just show it to me.

Try answering some of these questions.

• Why did you choose to build this project?
• What challenged you when making this project?
• What did you learn from making this project?
• What learnings have you taken with you into other projects?
• What would you do differently next time?
• Did you get stuck at any point? How did you get unstuck?
• What was your process for completing this project? Did you do wireframes, make a Trello board, or did you just get stuck into it?

If you answer these questions and craft them into a few succinct paragraphs, I will now know a lot more about your abilities as a developer. I can see what interests you, how you overcome challenges, how you learn from those challenges, and what skill level you are.

You're already well on your way to standing out if you follow this tip.

3. Remove Unnecessary Fluff from Your Portfolio

Sometimes the best thing you can do to improve your portfolio is to remove things.

You should remove things that add no value to your target audience and things that reduce your credibility.

Here is a list of things you to remove and why.

1. Step-by-step tutorial projects. These projects hurt your credibility. They are unoriginal, they don't show me what you can do. Rather, they show me that you can copy what someone else does.
2. Projects not related to development or the job you are trying to land. These just aren't relevant to your target audience.
3. If one of your Projects is the portfolio itself. Why get rid of this? The reason is that they are on your portfolio now. They are interacting with the project. So save space for another project.
4. Skill progress bars. While they look cool, they are bad. If you're a junior you probably know 10% JavaScript, would you want to represent that? What the heck does 80% CSS mean? If you remove one thing, please make it these.
5. If your portfolio is a carbon copy of someone else's portfolio – start over. It's not cool for starters. Plus, I want to see what you're capable of doing, not what you're capable of copying. It can come back to hurt you in the long run.

4. Give your about me some personality

There is this song by Paul Kelly called "Every F$*#%) City" and the general idea of the song is that every city is the same. Well, I've seen a lot of portfolio's and a lot of them look the same.

The section that often comes off as the same is the about me section. Let's look at an example below.

"Hi, my name's Jonny Lucky, a Full-Stack Web Developer from Example Town. I love building websites that solve life's unique problems.

I work primarily with MongoDB, Express, React, Node, and GraphQL and have set up countless WordPress and Shopify websites. My previous career was as an IT Consultant, E-commerce Business Owner, and Digital Marketer. I also really enjoy tinkering with CSS.

In my spare time, I play video games and also work out."

Hello Jonny Lucky, or was it Lucy Lovely? I forgot because I'm the HR person and I've read 50 of these portfolios and they are all very similar.

If I were to change your name, town, and tech stack, many of these candidates would just become one.

To be fair, there are some personal touches like the that they "play video games and also workout". But, guess what? A lot of other applicants also enjoy these things.

Can you see the problem, if you have an about me section like the above? You won't stand out and you'll come across as a little stiff.

Your about me needs to be a little bit spicy, it needs to show your personality and experience. Because your personality is different from other people, so your about me section should be too.

Let's have a look at mine to give you an idea of what you should be shooting for. I've gotten a few compliments on it.

"I'm an ex-marketer who loves building things with code.

I first became enthralled with programming in 2015. I was in San Francisco with my brother in law and he was telling me about this thing called Python and how it could automate things. As a person who looks for efficiencies, I was hooked.

I jumped right into Python on my flight back to Australia. Soon, I was automating my own things. I made a bot to book classes at the gym, one to send weekly reports to my boss and I even made one to like my girlfriend's content on Instagram. Unfortunately, that is as far as it went. Shortly after, I got promoted. So, I had less time to learn and I let programming fall by the wayside.

But, then Covid hit and suddenly I had more time without my commute. So, I started learning again. Specifically, I learned web development, as I had things I wanted to build for myself.

After a few months of self-teaching, I knew this was what I wanted to do for my career. So, I signed up for the coder academy Bootcamp and put my heart and soul into it. I was coding every day, late into the night, and on weekends. Until I was ready to be unleashed on production code.

Since the boot camp, I have grown as a developer, working alongside senior developers who have helped me raise my standards for what's expected of any web application.

I'm now seeking a full-time role where I can contribute my skills both in coding and business to help a company achieve their goals."

As you can see my about me section is unique to me. I'd say there isn't another soul on the planet who could write the same about me section without telling some lies.

Now, your about me section doesn't have to be zany, it can be professional. But, and this is a key point...

You need to make it interesting so the person reading it wants to continue reading it.

To make your about me section interesting, you can try things like stories and anecdotes. Try and weave them in with the key points you want to get across.

Another way to think of it is, if you are invited in for an interview would your about me be interesting enough that the person interviewing you would say "hey, I loved that story about X on your portfolio"? If it can do that you're winning because you've opened up more dialogue.

In the end, you're trying to spark interest in the person looking at your portfolio.

Think about it like this. If HR has 50 applications to get through, they are only going to interview 5 of those people.

If your about me section is a bland generic version like the first one, they are likely to just skim through it and onto your next section. If nothing else on your portfolio stands out, then they'll move on to the next application until something does jump out at them. You want to grab their attention and make them shift you to the interview pile.

Since most portfolios are generic, it doesn't take much to stand out. If you have less experience than someone else but their portfolio is generic and yours isn't, I'd argue you are more likely to get picked for an interview.

Why? Because we like to work with people we like, and if you show that you're an interesting unique person, I'd probably like to at least find out more about you.

5. Throw some Sprinkles on it

One of the most important lessons I was taught early on in my coding Bootcamp was that you need the doughnut before the sprinkles.

Looking at this analogy in regards to your portfolio, the doughnut is all the other things I have listed above. You need the baseline requirements of a portfolio like solid projects, an interesting about me section, and responsive design.

The sprinkles should come after you have all the basics. So, if you followed the tips above you have the doughnut. Now, you can start to make your portfolio shine.

Add things that make a prospective employer go wow! You can add amazing animations like Christopher Cherupil, cool transition effects like Philippe Neveu, or dark mode like Jhey Tompkins.

I added a Zelda-themed modal to make sure a prospective employer grabbed my résumé before they left my old portfolio site. I just made sure I had the basics first.

You can also go wild with your ideas, just make sure you execute them. You don't want unpolished sprinkles that could take away from your doughnut's main elements.

Summary

If you read this post and thought, oh man my portfolio is quite generic – don't fret. You now have 5 things you can do to level up your portfolio so that it moves from the "forgotten" pile to the "give this person an interview" pile.

I can frequently be found in portfolio advice threads on Reddit and Twitter trying to offer advice to people trying to break into the industry.

When you're done leveling up your portfolio, and you're looking for some feedback on it, make sure to Tweet it to me with a link to your site.

If you have a portfolio you're proud of or you're looking for feedback on it, follow me on twitter and tweet the link to me so I can look over it and give you some feedback.

If you have an awesome one I might even add it to my portfolios that pop list.

Hey everyone! 🌈 The seasons are changing, and September is the perfect month to focus on new goals and start new adventures. Maybe you've been on vacation, enjoyed the sun 🌞 or the mountains, and you're ready to dive back into work.

New adventures are sometimes unexpected. But I hope that when you saw the title of this blog post, you decided to embark with me on this extraordinary adventure of becoming a software engineer.

How Can You Learn to Code in 6 Months?

Learning to code is a marathon, not a 100m sprint. You need to become a lifelong learner, and the more you know, the longer will be the list of things that you feel the need to discover.

But (there's a but), if we're talking about changing careers, I think it's totally possible to become a Software Engineer (entry-level or junior) in 6 months or less. You just need to quickly acquire a good set of entry-level skills.

How do I know that it's possible?

Simple. I did it in 2017. And I'm not the only one. If you search for it, you'll find lots of people who've accomplished the same feat.

How to Learn to Web Development Basics Quickly

Now, to get this done in 6 months or less you need to be 100% dedicated to it.

So, this time frame will likely make sense for those who are jobless and have the resources to remain so while studying, or those who have quite a bit of free time. It's also helpful if you're looking for new opportunities and are passionate about tech, computers, and creating new things.

Spoiler alert: expect to invest somewhere around 8 to 12 hours per day learning and studying.

For those who have a job currently, but want to become a software engineer, just keep reading! You can apply this process over a longer time frame and gradually transition in over the course of 9, 12, 18 or even 24 months. No pressure at all.

How do I start learning to code?

This is a simple question. Despite the fact that there are lots of bootcamps out there – some paid, some free – freeCodeCamp is one of the best (if not the best) places to start.

The freeCodeCamp curriculum has a well defined roadmap (you can just follow the path, not worrying about what to learn and in which order) and a great, diverse, and inclusive community spread across Discord, the Forum, Twitter and YouTube.

So, start by signing-up for freeCodeCamp and get yourself comfortable.

Before that, make sure you grab a cup of your favourite tea or coffee! ☕

Start the freeCodeCamp Curriculum

Well, during the first four months, you need to focus on grokking the fundamentals. What you need to do is to invest heavily in the 3 first certifications:

1. Responsive Web Design Certification (300 hours)
2. JavaScript Algorithms and Data Structures Certification (300 hours)
3. Front End Development Libraries Certification (300 hours).

We're talking about 900 hours, which, divided by 10 hours/day, gives us 90 days of intensive study. Yes, intensive.

Of course it might take a bit more of time if you decide to invest 8 hours a day. 900 / 8 is more or less 113 days. So it still fits in 4 months.

My suggestion here is that you divide your time between tackling the challenges, reading, watching talks, and listening to podcasts or ebooks. This way you avoid getting frustrated or bored while always doing the same thing.

Follow freeCodeCamp's advice: "Read, Search, Ask".

This is the formula to success. You'll improve the way you search on Google, you'll discover interesting articles, talks, and books, and you'll eventually reach out for help somewhere online. Focus on this process. 🙏

Soon you'll be able to get yourself unstuck and this is one of the best skills a programmer can have.

Start Networking and Find Tech Communities to Join

The 5th month represents an inflection point in your journey. You'll need to raise your head up from the keyboard and look around.

Invest some time in networking. Create a LinkedIn and a Twitter account. Start building your social image and personal brand. State that you're learning to code and that soon you'll be looking for an entry-level/junior role in a tech company.

Interact with people, meet people, and ask questions (no matter how dumb they are. The truth is that there aren't any dumb questions, and once you know the answer, you might be able to help someone later with the same doubts).

If there's any tech-focused community group around you, mingle with the people and get to know them. If there isn't anything local, well, you can always create one.

That's what I did and it went great (maybe I'll write another article about it 💡).

At this point your basic tech stack is: HTML, CSS, JavaScript, and React. It will be pretty easy to fit in a lot of companies/teams as a front end developer.

The tech industry usually hires for the short-term, and nowadays frameworks are the dish of the day, so React skills can definitely help pay your first salary. 💰

You'll also need to invest in some other skills in the meanwhile:

1. Learn Git. Invest at least one week in trying to understand how Git and version control in general works and how valuable it is to work in a team, remotely or not.
2. Invest a bit of time in mastering your OS so that you feel comfortable while working. This involves VSCode config, terminal config, account config, and so on. Try to do online meetings with friends and share your screen or use a whiteboard. Google Meet is great to train you in this skill.
3. Learn a bit about note-taking and pick an app to help you manage your notes. Notion, Obsidian, or even VSCode are great tools for that. It doesn't need to be perfect, just start by organizing your notes somehow and later you'll find out what fits you the best.
4. If English is not your main language, sharpen your English skills. Read books and listen to talks and podcasts, so that you can get used to people's accents.

In the meantime, don't stop coding. This is the perfect time to polish up your certification projects.

At this point you should have the following projects done:

1. Responsive Web Design Projects

2. Tribute Page

3. Survey From
4. Product Landing Page
5. Technical Documentation Page

6. Personal Portfolio Webpage

7. JavaScript Algorithms and Data Structures Projects

8. Palindrome Checker

9. Roman Numeral Converter
10. Caesars Cipher
11. Telephone Number Validator

12. Cash Register

13. Front End Development Libraries Projects

14. Random Quote Machine

15. Markdown Previewer
16. Drum Machine
17. JavaScript Calculator
18. 25 + 5 Clock

Wow...you've already done so much! Take a few days to breathe and to treat yourself well. Recognize the achievements and how proud you are of yourself!

Show family and friends what you've been working on, and share it on your social networks. Everyone should be proud of you at this point.

Build Your Developer Portfolio

Okay folks. Now we're in the game.

Now you're going to build your portfolio. This is extremely important because the people and companies who might be interested in hiring you will want to check it out.

They're not necessarily looking for expertise, or for a very knowledgeable or experienced person. They're looking for passion, effort, knowing how far can you go alone, learning to code with some community support, on your own.

These are definitely the 3 things you must show:

1. Passion
2. Energy
3. Capacity (to evolve and learn "alone")

Move all your projects to GitHub, and make sure you add some good README.md files, with good descriptions about what you've done in each project. If you wish you can add a small list of things you want to improve in the near future.

But don't stop there – keep improving and polishing your projects. Put yourself in the shoes of the people who are hiring, and give some love to details that make the difference (this is how you can show the 3 things above: passion, energy, capacity).

Show that you know how to create good layouts, well-spaced content, the right colors, readable fonts, and so on. Make things look as great as you're able to.

Take a look at other projects and see how are people solving the same problems. Getting inspiration from their ideas (just please don't blindly copy code without understanding what it means) is not cheating and you can learn a lot by doing that.

Evolve your Personal Portfolio Project and make it your homepage (landing page). Make sure to share your contacts and to state that you're available for work. Share all your other projects in your homepage.

Keep polishing your work, keep coding and learning everyday, improve the relationships with all the new friends you've made, and try to find opportunities through social networks.

Apply for Jobs and Prepare for Interviews

You'll need to invest a lot of time in applying for jobs and getting interviews. You need to practice interviewing and I bet that soon, much sooner than you expect, magic will happen! 🪄

Applying for Jobs

Don't worry about failing. It's absolutely normal that you might fail your first interviews. And that's okay – you're learning some good tricks for the next ones.

Now, it depends a bit on what your goals are for this job and for your career. If you want to apply to a FAANG company, the bar is high (very, very, high). You'll need to pass hard technical interviews.

But no worries, freeCodeCamp has your back. You'll find a lot of resources so that you can sharpen your skills in the Coding Interview Prep Section.

If you're applying to any other company, you might not need to know quite as much about Algorithms and Data Structures. Rely on your portfolio and show the interviewer you're a confident person who is able to communicate, to show passion, and to put effort into whatever you do.

The Interview Experience

People have different opinions about what makes a good, effective interview. Personally I don't like timed or live coding challenges. My anxiety grows and my ability to focus and to solve problems drops to less than zero.

Plus, the best companies shouldn't be worried about how fast you're doing something. They usually prefer that you take twice as long, but do it that much better, making sure you think about each detail that a certain feature needs.

I usually prefer take home challenges. I can make myself comfortable, with a nice cup of tea or coffee, and I can investigate properly and do my best.

My recommendation here is that you go the extra mile. Care a lot about what you do and why you do it.

Write some documentation about why you've picked A or B, what's missing, or what you'd do in the future to improve your code.

Usually interviews have 3-4 parts:

• Screening: people want to get to know you. To hear you speaking and discover what's your superpower (motivation, resilience, perseverance)
• Test assignment: it can be a timed challenge, a pair-programming challenge where you're the driver (real time), or a take home assignment.
• Discussion of the assignment and a few technical questions. Possibly know how much you expect to earn.
• Offer / Rejection (this is usually a video call, in case they have an offer, or a simple "thank you" e-mail, in case you're rejected).

Sometimes there are interviews with more than one part of the team. Some teams like to pick people that fit well and they want to see if you're able to cope with them for a while.

Expect some off-the-wall questions, such as Star Wars trivia, or if you prefer tabs or spaces. There are usually no wrong answers, but people look for a sense of belonging while discussing these things with you.

The funniest thing that happened to me was a set of questions that I needed to answer quickly, without thinking. So the guys started:"React or Vue?", "Emacs or VS Code?", "Tabs or spaces? ", "Semi-colons or no semi-colons?", "Beer or wine?!?" Yeah, all these are important issues! 🤣

Final Words

If you get a job, don't forget to reach out to tell me how it went. I love to read these stories and I feel proud of every single person who did it.

Maybe 6 months wasn't enough time to get through this big list of things (even though, at first glance, they may seem pretty easy to accomplish – they aren't ❤️).

Just remember to treat yourself well and don't push yourself too hard.

Also, if it takes you longer than 6 months, don't worry: You can do it. You just might need more time for whatever reason.

When people start to learn how to code, they start in very different situations. Some have a PhD in Math or Engineering, some are coming from History or Philosophy, or from McDonalds (which also provides you with great soft skills: talking to people, being polite and kind, having compassion, being organized, doing things on time, tracking and controlling processes, and much more).

So whatever your background, just remember – it doesn't matter where you started. What matters is where you're going!

I'm sure that at this point, if you forget the 6 month time barrier, you will get there. And as I said in the beginning, learning to code isn't a 100m sprint, it's a marathon. So keep focused and keep doing your work.

Don't forget about your body! Drink water, don't spend too much time sitting in your chair. Try to have a good posture, exercise, and get out of your home. People need a bit of sun and fresh air. The way you treat your brain is very important. Never forget about this.

Last but not least, be kind to yourself and to every human being. You're great! ❤️

I'm Edo and you can follow me on Twitter. I usually tweet about code and career change.

I just joined Cisco Systems, India as a Senior Software Engineer (SDE III) on July 28, 2021. I am working with the Cisco Customer Experience team as a UI developer.

The entire journey from applying for the job to accepting the offer was two months long. I wish to share my interview experience which will help you prepare for a senior-level UI engineer role.

What you will get out of this article?

In this article, I will talk about my journey, from getting the job referral to accepting the offer.

I will talk about the different rounds of the interview process that I went through and the questions I was asked in them. The questions I share here will help you get ready for Angular development roles.

I will also share some of the questions you can ask the interviewer and the HR rep which will help you to know more about the company and the project.

So, lets’ get started!

How I Discovered the Job Posting

The first part of a job search is to get your résumé selected for the role you are looking for. I found out about this opportunity from a tweet shared by Alex Okrushko.

I have been following Alex for the last two years. He used to work with the Firebase team at Google and he is also a part of the NgRx team. I admire him for his immense contribution to the Angular community.

Alex is currently working as the Principal UI Architect at Cisco.

When he shared that they were looking for a UI developer, I realized that it would be the best opportunity to work directly with him. I sent a message over Twitter and he asked me to share my résumé. He was primarily looking for developers with strong Angular skills.

The First Round of Interviews

One week after sharing my résumé with Alex, I received an email for the first round of interviews.

The first step in the interview process was a take-home assignment via Devskiller. The invitation from Devskiller mentioned that I had seven days to complete the assignment. The total time allotted for this round was 2.5 hours. Once the test starts, you cannot stop it, so it has to be a single sitting of 2.5 hours.

I was given an Angular project with some bugs in it. There was a total of 11 unit test cases in the project. I was expected to fix all the bugs and make all the test cases green.

I started the test around 10:30pm (after my dinner) and finished it around 12:45am. I am most productive at night, so I chose that time. I was able to fix all the bugs and all the 11 test cases were green too. I slept happily that night 😊

Angular Concepts Covered in this Round

The first round of interviews was majorly based around the following Angular concepts:

• Data binding
• Event handling
• State ownership and flows
• Forms and form validations
• Observables
• Unit tests using Jasmine
• Attribute directives
• Structural directives - NgIf & NgFor

Alex verified my solution based on bug fixes, unit test status, and coding style. He was impressed with my performance in the first round and so I moved on to round two of the interview.

The Second Round of the Interview

I got the email asking for my availability for the second round of the interview. I was facing some health issues at that time, so I asked to schedule a week later and the interviewer was happy to do so.

The second round was also a project-based interview via Devskiller. I was given an Angular project and there are four questions based on that. All the questions are based on debugging and bug fixes. The total time allotted for this round was 1 hour.

The difference compared to the first round was that this time I was supposed to do a live coding session by sharing my screen with Alex. I was expected to explain the What, Why, and How of the code I was writing and talk through the solution. The thought process to approach the problem was given importance over the implementation.

This round was more of a pair-programming session with me in the driver's seat. Out of the four questions, I was able to solve the first three in 30 mins. The last one was based on the concept of Content child/view child. I struggled a bit with this question but a small hint from Alex helped me solve it.

I started the test at 10:30pm and finished it around 11:20pm.

I was allowed to use online resources during the interview. But the condition was that I had to explain what I was looking for and why.

At the end of the test, I was able to solve all four questions successfully. The feedback from Alex mentioned that I was struggling with a few of the concepts of RxJS and I need to work on that. But he was happy with my overall performance and I was promoted to the third round of the interview.

Angular Concepts Covered in this Round

The second round of the interview was primarily based around the following Angular concepts:

• ViewChild and ViewChildren
• ContentChild and ContentChildren
• Content projection
• Usage of Async pipe
• Multicast observables
• Parent-child relation of the components
• Services

The Third Round of the Interview

I got a call from my manager, Vaibhav, and he informed me that they were happy with my performance in first two rounds and wanted to schedule another round of technical discussion.

He asked me for my availability and I replied to him to schedule the call for the next day at 10 am IST. This round of interviews is conducted by the team in India so it has to be during IST working hours.

Two interviewers joined the call, and after the introduction, I was informed that this round would be divided into two sections, one for Angular and another one for JavaScript.

They started with the questions about Angular. This round had a mix of theoretical as well as scenario-based questions. The Angular interview continued for around 45 mins and I aced it. I answered all but one question.

After 45 mins they switched to the JS side. They started with the core concepts of JS and I answered those questions easily. Then they moved deeper into JS and I was asked few output-based questions. I struggled a bit here.

Then came more output-based questions and I was unable to answer a few of them. The JS interview also continued for 45 mins. I was not happy with my performance in the JS part of the interview. It was pretty average.

The interview was originally scheduled for 1 hr, but it got stretched to 1.5 hrs.

Angular Concepts Covered in this Round

The third round of the interview was based around the following Angular concepts:

• RxJS concepts such as mergeMap & switchMap
• Directives
• How does the ngIf directive work internally? How does it add DOM elements dynamically on the page?
• How can we create a custom directive (with practical example)
• What is Input and Output in a component?
• Few theoretical questions around services, lazy loading of modules, and component communication

JavaScript Concepts Covered in this Round

The third round of the interview was based around the following JS concepts:

• What are the different ways to create and call methods in JS?
• Closures
• Currying
• Event bubbling
• Output-based questions on closure and various setTimeout scenarios

The Fourth Round of the Interview

Two days after the third round of interviews, I got a call from Vaibhav. He informed me that the interviewers were impressed with my Angular skills but they were not happy with my JS skills. But the overall performance was good, so I was able to move on to the fourth and the final round of interviews. He also suggested that I work on improving my JS skills.

The final round of interviews was scheduled on the Tuesday of the following week from 12:30pm to 1:30pm.

This was a managerial round and Vaibhav was the interviewer along with another senior developer from my team. This round was more focused on my non-technical skills.

He asked me about the project I was working on with my current company. I was also asked questions about Agile methodology since I had mentioned that in my résumé. I told him about my open-source work and he asked few questions about that.

At the end of the interview, Vaibhav shared that he was happy with my performance and wanted to go ahead with the offer. The next step was to update HR so that they could continue with the salary and the offer formalities.

Question Asked in the Managerial Round of the Interview

The fourth round of the interview was entirely non-technical. I have mentioned a few of the questions asked in this round, and here are some more:

• Tell me about the current project and tech stack you're using.
• What is your current role and responsibilities?
• What are the Agile practices you are following currently?
• How does your sprint planning look like?
• How does a story refinement happen in your current project?
• How can you resolve a conflict of ideas within your team?
• Why are you looking for a change?
• Why Cisco?

Salary Negotiations and Getting the Job Offer

I was waiting patiently for the call from HR after the fourth round of interviews. I got the call after one week.

The HR rep congratulated me on clearing all the rounds of the interview and asked me about my current salary and notice period. She also asked me to share my payslip and compensation details from my current employer.

After two days, I got another call from HR and she informed me about the salary I was being offered. I asked if there was any possibility of negotiating a better offer. She told me that this was the best possible salary as per my employment grade and it was not possible to increase it any further. I asked her for some time to make the final decision.

I did not want to lose the job offer but at the same time, I also wanted to have a better salary structure than the one offered.

I discussed the situation with my family as well as a few of my friends. I also had a call with Vaibhav, and a few calls with HR as well.

I was very much confused at this point, so I decided to write down the pros and cons of this role. Here is what I came up with:

Pros:

• The project is customer-facing, so I'd get more exposure and increased responsibilities
• Working at the scale of Cisco would be a plus
• It would be a great learning and growth opportunity
• The brand value of Cisco is high

Cons:

• The salary offered was not up to my expectations

Finally, the pros outweighed the cons and I decided to accept the offer. So, I informed HR of my decision. But there was a surprise waiting for me.

HR informed me that since I had taken a long time (around 10 days) to decide on the offer, they have put my offer on hold. I needed to wait further for the final confirmation from Cisco’s end.

I panicked and thought that I had lost the opportunity. But I had no option other than to wait. TBH, I had lost any hope of getting the offer at this point.

After two weeks, I got a call from Vaibhav and he asked me if I was still interested to proceed with the job offer. After my confirmation, he informed me that HR was happy to release the offer letter. The next day, HR called me to confirm the same. By the end of the day, I had the offer letter in my inbox.

I gladly accepted the offer letter. I was relieved and ecstatic. All's well that ends well.

Job offer accepted

How to Ask Good Questions in Your Job Interview

Whenever you are being interviewed for a job, the interviewer always asks this question at the end – Do you have any questions?

A lot of people are confused about what to ask and what not to ask. Some people do not ask any questions at all.

Well, this is a good opportunity to learn more about the project, the team, and the company. So, you should ask your interviewer as many questions as you can.

Here are a few suggestions from my end.

What to Ask the Interviewer in a Technical Interview

• Ask about the details of the project you are being interviewed for
• Are you using any third-party tools/libraries in your application? If the answer is yes, ask about them.
• How does the code review cycle work?
• What are some of the current challenges in the codebase?
• What is the ratio of new features vs the bug fixes assigned to a dev?
• What testing framework do they use in the application for unit testing as well as E2E testing?
• What is the test coverage for the application?

What to Ask the Interviewer in a Managerial Interview

• Ask about the details of the project you are being interviewed for
• What kind of application it is? Customer-facing or internal?
• What will be my roles and responsibilities?
• How is the work-life balance in the project?
• What are my learning and growth opportunities in the next 1/2/3 years?
• What are the current challenges with the project?
• Are there any plans to add new features to the application?
• Ask about the current team structure and where you will fit in it
• How does the team culture look like in the current pandemic situation when we are 100% remote?
• What is the working shift for this project? Is it flexible or fixed? Are there any shift allowances provided? This is a very important question and is often neglected by the interviewees.
• An extension to the previous question – Does my job require any type of weekend support? If the answer is yes, ask about the timing, frequency per month, and the reimbursement policy around that.

What to Ask HR Before Accepting the Offer or Joining the Company

• Leave policies
• Health insurance policies
• WFH policies
• What is the timeline of the annual appraisal cycle?
• Will I be eligible for the appraisal in the next appraisal cycle?
• Do I need to sign any kind of employment bond?
• Does this job require me to move to another city/state?
• Do I have to serve a probation period upon joining the company? If the answer is yes, ask about the duration and its effect on your employment. Every company has different rules related to probation so ask as many questions as you can around this topic
• What are the covid-related benefits company is providing, for example vaccination, medical support, and so on?

Do you Want to Join the World’s Best Workplace?

Cisco Systems has been ranked number one in Fortune’s list of 100 Best Companies to Work For the year 2021 and 100 Best Large Workplaces for Millennials. Do I need to say anything more about the company’s culture?

Cisco provides you with ample learning and growth opportunities. You will get a chance to work on applications used on a worldwide scale. You will be always motivated to grow and explore yourself on a personal and professional level.

So, what are you waiting for? Go to the Cisco Careers portal and apply for the role you want.

I hope my interview experience will be helpful for you. Best of luck with your job interview.

If you like the article, share it with your friends. You can also connect with me on Twitter and LinkedIn. My DMs are always open.

As a React developer, I have gone through my fair share of front-end coding interviews. Recently, I had the opportunity to experience the process from the other side – as an interviewer. Here is what I've learned.

Coding interview usually involve a multi-step process where interviewers assess everything from basic technical knowledge to culture fit. Every step of that process is important and should not be underestimated. Prepare for all of it and prepare well.

But there is one thing that is at the core of (almost) every React interview.

Inevitably, at some point, you have to build a React app.

The App Assignment

Here is a short list of real app assignments I had to complete for my own React interviews over the years:

• Support Desk app – an app to display a list of support desk employees and their contact information.
• Video app – an app where, given a YouTube video URL, it displays it on the page. Users can comment on it.
• Projects app – an app to display a list of on-going projects that users can subscribe to and follow.
• Articles app – an app to display a list of articles where users can leave nested comments for each one.

These assignments are, in many ways, very similar to each other. The reason is that they are assessing the same set of basic React skills. Which skills are those? Let's break them down.

Interview Skill #1 – How to Build UIs with React

A primary job of a React developer is to build and structure React components in a meaningful way.

The assignments above are meant to test your ability to write code in a modular and reusable way while creating abstractions at the right level.

The main goal is for your app to work well. But, as a front-end developer, you are also expected to build UIs that look good, too.

Most of the time, the assignment will come with a concrete design you'll need to follow. If that is the case, it's important to stick closely to it.

But if you believe that there is a good reason to deviate, don't hesitate to do so. Just be prepared to explain why your solution is better.

If there is no design available, the interviewer is probably interested in understanding if you can create sensible UIs on your own. Although this could be more challenging, it also gives you the opportunity to show you are able to make conscious choices when it comes to the front-end.

Tip: It is easy to assume that the expectation is that you have to build all components from scratch. Using a third party component library might feel like cheating in an interview context. But it is not!

Make sure to ask in advance what is expected. Taking advantage of component libraries like MaterialUI or ChakraUI is a huge time saver during interview assignments and will allow you to focus on more interesting parts of the app.

Interview Skill #2 – State Management in React

Another important challenge when it comes to building React apps is state management. There is a myriad of ways to go about this depending on your concrete use case and goals. Check out my article on the topic if you are curious to learn more.

Whatever approach you choose, what is important during as interview assignment is to show the interviewer that you understand and are able to reason about state management.

Your solution needs to make sense without being overly complex or convoluted. Be prepared to explain and defend your choices.

Tip: It is a good idea to match your state management solution to the one used by the company your are interviewing for.

Do they use Redux? Then don't hesitate to include Redux in your project. Are they into state machines? Then xState is your friend, and so on. Make sure to ask the interviewer in advance what they would like to see implemented in your project.

Interview Skill #3 – Data-fetching in React

As a front-end developer, normally you won't be expected to build your own back-end. But the assignment you are given will probably involve some form of data-fetching – likely either through a mock API of some kind or just a JSON file with the necessary data.

This part of the assignment is meant to test if you, as a front-end developer, know how to talk to the back-end. Can you get, display and update the data you receive from the back-end correctly? Do you understand how API requests work?

In a more advanced setting, there might be a conversation about data-fetching architecture, data state management, and front-end caching.

Tip: Make an effort to implement a semi-realistic data-fetching mechanism in your app. In you are given a JSON file, don't just directly import the data in your components. Instead, use fetch or another more advanced (preferably async) approach to get it so that you are able to demonstrate your deeper understanding.

Interview Skill #4 – Routing in React

A lot of the time, creating a React project is synonymous with a single page application. So it is possible that the assignment involves implementing a routing solution.

Here the goal is to demonstrate that you understand the basics of client-side routing and are able to structure your app around it.

Tip: Avoid creating your own client-side routing implementation, unless explicitly required. Opting for React Router or Reach Router is a perfectly acceptable choice.

How to Stand Out in a React Interview

Getting a solid grasp on the basics discussed above is a must and it's a good start to earn points during an interview assignment. But to truly stand out, you have to go a step further.

Here is how.

Understand Your Setup

Most of the time you can get away with using toolchains like Create React App (or similar) when building a React project for an interview. This will help you get started and save time.

In fact, it is important to use those tools in order to spend your time on meaningful development rather than setup.

But it's also important to understand and be able to explain the basic tooling you are using. During a React interview, expect to be asked questions about Webpack and Babel, for example.

But what can really give you an edge is if you not only understand but are able to enhance your existing setup. One idea would be to add a linter (eslint) and a formatter (prettier) to your app. This shows that you really care about code quality and consistency.

Another would be to go even further and setup pre-commit hooks (husky) that lint and format your code with each commit. Crazy, I know!

These tools take minutes to setup but can seem like an impressive extra step in the eyes on an interviewer.

Test Your Code

Very few assignments will explicitly state that tests are required. For this reason, many developers assume tests are not part of the task and completely ignore them. This is wrong!

Most of the time, an interviewer will be impressed to see that you understand the importance of testing your code. It is a very easy but powerful way to set yourself apart.

It is not necessary to have a test for every single line of code in your project. Several strategically selected tests covering the more complicated logic should do the trick just fine.

Don't Ignore Responsiveness

Here is another aspect of your React assignment that is not explicitly mentioned most of the time – responsiveness.

Even if you are given a design at the beginning of the task, almost always it will not be a responsive one. It is up to you care enough about responsiveness to figure it out on your own.

Same as testing, most developers will just ignore responsiveness. Which is good news for you – it gives you the opportunity to shine!

There is no need for the implementation to be perfect and work flawlessly on every screen and device. The mere fact that this is something you though about in your development process should be enough to score you some major points.

Improve Accessibility

Accessibility is a huge concern for most modern web products. Taking even minor steps to improve the accessibility of your project, like adding alt text to your images, for example, can leave a really good impression.

Accessibility is also another reason why you might want to choose a third-party component library when building your assignment. Most components in these libraries are accessible out of the box.

Making your project as accessible as possible can truly make you stand out in an interview. But what is more, accessibility should be (and is becoming) the norm in web development. Make sure your future employer knows you understand that.

Details Matter

Everything in your code should tell the interviewer you are a competent developer – from basics like the way you name and structure your code to minor details like commit messages.

Given that these assignments are usually done under time constraints, it is tempting to just ignore these seemingly unimportant aspects. But getting them right can meaningfully set you apart.

Hopefully this article is useful for your next React interview. Let me know how it goes!

Follow me on Twitter for more tech content.

In it, we will learn about an all-purpose coding template for solving backtracking problems and apply it to two LeetCode hard problems. Ready to crunch your next coding interview? Let's go!

If you just want to dive right in, you can find the course here (and linked at the bottom of this article). If you want a little more info, read on. :)

Who is the Course for and What is the Backtracking Algorithm?

This course is suitable for anyone who is preparing for coding interviews, especially those who are looking to hone their skills in solving backtracking problems.

Backtracking is a common category for questions in coding interviews. The algorithm for solving those problems usually involves recursion and building incrementally on previous states to arrive at the ultimate valid solution.

Backtracking is a favorite topic among top tech companies like Google, Microsoft, and Facebook, precisely because it requires robust reasoning and coding competence to nail those questions.

However, because of its recursive nature and complex problem definition, backtracking problems are usually a major source of confusion among devs who are preparing for coding interviews.

To address this confusion, this crash course aims to arm with you a concise, 20-line template that you can apply to the majority of backtracking problems.

Course Outline

This course runs for a total of 40 minutes and the structure is as follows:

• An 8-minute introduction to the template

• A 15-minute hands-on code-along session for LeetCode Question 51. N-Queens

• A 15-minute hands-on code-along session for LeetCode Question 37. Sudoku Solver

The All-Purpose Template

For your convenience, I've copied the template over. This is exactly the same template that I use for my coding interviews, or when I'm developing algorithms for my indie games. I even used it once in my research on a non-convex optimization problem.

def is_valid_state(state):
    # check if it is a valid solution
    return True

def get_candidates(state):
    return []

def search(state, solutions):
    if is_valid_state(state):
        solutions.append(state.copy())
        # return

    for candidate in get_candidates(state):
        state.add(candidate)
        search(state, solutions)
        state.remove(candidate)

def solve():
    solutions = []
    state = set()
    search(state, solutions)
    return solutions

The first three are all helper functions, and the last and most important one, solve, is essentially the one that a LeetCode problem is asking you to write.

Solving LeetCode Problems Hands-On

We will next apply this template to solving two LeetCode hard problems: LeetCode Question 51. N-Queens and LeetCode Question 37. Sudoku Solver.

To illustrate the flexibility of the template, see below for how we solve the N-Queens problem by doing nothing fancy other than adapting the four functions (renaming solve to solveNQueens). The complete code for either problem is available in my GitHub gist.

Watch the video course to follow along my analysis and adaptation of the template.

class Solution:
    # solveNQueens is essentially the solve function
    def solveNQueens(self, n: int) -> List[List[str]]:
        solutions = []
        state = []
        self.search(state, solutions, n)
        return solutions

    def is_valid_state(self, state, n):
        # check if it is a valid solution
        return len(state) == n

    def get_candidates(self, state, n):
        if not state:
            return range(n)

        # find the next position in the state to populate
        position = len(state)
        candidates = set(range(n))
        # prune down candidates that place the queen into attacks
        for row, col in enumerate(state):
            # discard the column index if it's occupied by a queen
            candidates.discard(col)
            dist = position - row
            # discard diagonals
            candidates.discard(col + dist)
            candidates.discard(col - dist)
        return candidates

    def search(self, state, solutions, n):
        if self.is_valid_state(state, n):
            state_string = self.state_to_string(state, n)
            solutions.append(state_string)
            return

        for candidate in self.get_candidates(state, n):
            # recurse
            state.append(candidate)
            self.search(state, solutions, n)
            state.pop()

Check out the video course here:

You can access the template as well as the solutions to the two LeetCode problems (N-Queens and Sudoku Solver) in my GitHub gist:

Final Thoughts

Remember that practice makes perfect, so do try applying this template to more backtracking problems on LeetCode. Best of luck crunching your next coding interview!

For more content like this, check out my YouTube channel:

System Design is an important topic to understand if you want to advance further in your career as a software engineer. Even if you are just beginning your coding journey, it's a good idea to get a head start on learning about system design.

Early in your career you will mostly just be tested on your coding ability. In higher level interviews, however, there will often be a greater focus on testing your ability and experience at designing applications.

The biggest struggle engineers have with system design interviews is that they are more open-ended and there isn't any single correct answer. This lack of structure can be intimidating, so my goal with this article is to give you a roadmap for navigating these types of interviews with confidence.

What this article will cover:

• What is a system design interview and why they are used
• The main stages of a system design interview
• Example interview problem – Design YouTube

Video Tutorial

You can also watch this tutorial on YouTube if you like:

And I've created a playlist of videos on specific topics related to system design and web architecture:

System Design Interview Overview

At first glance it seems silly to ask somebody to design a huge app like Twitter or YouTube in 45-60 minutes. These apps were designed over a period of years by hundreds of engineers working together, so it's clearly an impossible task to do in a short interview.

There are two main reasons why companies use these types of interviews. The first is, of course, to test your knowledge about the technologies being discussed. They want you to go deep enough to make sure you aren't just throwing buzzwords around without understanding how things actually work.

The second reason might be more important, though. The system design interview is a way to simulate a realistic scenario where you are working together with the interviewer to determine the best design decision.

Getting the perfect answer isn't necessarily the most important thing here – it's some of the other things you can show, like:

• How do you handle being challenged? Do you get defensive or take feedback with a positive attitude? Are you stubborn or narrow-minded?
• Do you show knowledge of the various tradeoffs certain design decisions involve? There's a big difference between blindly making a decision and not realizing the consequences, and knowing the pros/cons and accepting the tradeoffs.
• Are you able to effectively communicate and if necessary explain complex technical concepts in an easy to understand way?
• Are you candidate somebody the interviewer would want to work with long term? Even if somebody is a genius, if they are miserable to work with they might not be a good hire.

Stages of a System Design Interview

In this section you'll learn a general framework for structuring how to handle a problem during a system design interview.

Clarify the problem and establish design scope

The first thing you'll want to do after your interviewer gives you the problem is to take a few minutes to ask some clarifying questions and figure out what exactly they are looking for.

The worst thing you could do here is just start off in the completely wrong direction because you didn't take the time to ask a few questions. You have a limited amount of time during the interview, so you want to make sure you focus on what's important.

Here are some examples of questions you might ask:

What are the use cases / features of the app?

In this article we will be using YouTube as an example. There are hundreds of different features you could design like ad delivery, authentication, recommendation algorithms, comments, video upload, video processing, and many others.

During an interview you only have time to cover a few of those, so make sure to ask the interviewer questions to figure out what they want you to focus on designing.

How many users are expected / what is the likely traffic volume?

The complexity of the system will depend on the amount of traffic it needs to handle, so make sure to gather this information.

You don't want to over-engineer things if the traffic is relatively low and you also don't want to get stuck with an app that can't scale because you didn't design it properly.

Ask questions like how many users the app will have, the average amount of data per request, how long data needs to be stored, and how reliable and available does the system need to be?

This step is going to help you beyond just getting more information to work with. You're also showing the interviewer that you understand how to gather information about a vague problem.

Determine Rough Capacity Estimates

Using the information you gathered during the first step, you can begin to make some rough estimates and generalizations for things like storage and bandwidth requirements.

This process will involve some basic math like multiplying the number of users by the average request size and the amount of requests each user is expected to make daily.

Create a High Level Design

Here you want to create a rough architecture for the system. Draw out things like load balancers, web servers, app servers, task queues, database, caching, file storage, and so on. You should include all the core components you need to create the system.

Make sure to communicate with the interviewer during this stage and check to ensure that you aren't missing anything. While they probably won't tell you directly, they will give you a nudge in the right direction if you forgot about some crucial feature.

API Design

This part is almost cheating because you are using the structure of the interview to your advantage to confirm that you are on the right path.

The interviewer is never going to deliberately lead you down the wrong path, so once you've created your high level design you can start sketching out some rough API endpoints for each component.

For the YouTube example they might look something like this, depending on which features you are building:

• uploadVideo (userID, video, description, title)
• comment (userID, videoID, comment)
• viewVideo (videoID)
• videoSearch (query)

In some cases you might not need to drill down to this level. If the interview question is very high level like "design Youtube", you can probably skip this part. On the other hand if you get a more focused question like "design YouTube's comment system", it would make sense to go more in depth.

Create a Data Schema

At this point you should have a good idea of all the requirements and data needed for the application to work, so now you can plan out how your data is structured.

Depending on what you are building and the requirements, you'll need to weigh the costs and benefits of things like using a relational vs non-relational database. When modeling your data you'll also want to account for things like potential data partitioning and replication.

Take a Detailed Look at the Components

What happens during this section will mainly depend on the feedback of the interviewer. They will probably pick out a few specific components to focus on and ask why you made certain decisions.

The most important part here isn't necessarily being 100% right. Instead, it's to show that you didn't just blindly make decisions and understand exactly what tradeoffs you were making.

You should be able to propose alternate design decisions that could have been used and explain why you didn't use them.

How to Design YouTube

Now that you have a general idea of how a system design interview works and a framework for handling a system design problem, I'm going to show you how to put it all into practice using YouTube as an example.

Step 1 – Define Problem Scope and Requirements

This will be a high level problem where we implement a few of YouTube's major features without diving too in-depth on any of them. The features to focus on will be:

• Users can upload videos
• Users can view videos
• Users can comment on videos

Step 2 – Determine Capacity estimates

The two biggest capacity factors in an app handling large amounts of video like YouTube will be storing all that content and bandwidth requirements to deliver the content to users. In this section you'll learn how to make rough estimates for capacity requirements.

The main focus here is not on being highly accurate, but showing a logical thought process for calculating these numbers based on the information available to you.

In an interview you would be given the data, but in this case I'm using two key pieces of data that YouTube has made public:

• YouTube creators upload 500 hours of video every minute
• YouTube users watch 1 billion hours of video per day

You can use these numbers to calculate storage and bandwidth requirements with a few assumptions.

Bandwidth Calculation

Daily bandwidth calculation

To calculate an estimate for bandwidth, we start with the amount of video watched daily. The key assumption here is how much bandwidth is used per hour watched, as this would depend on the quality of video most users choose to watch.

The 3 Gigabyte estimate is based on a rough percentage of users watching in standard definition and others choosing HD or 4K, which consume much more bandwidth per hour watched.

The math here is fairly simple: multiply 1 billion hours by the average bandwidth of an hour of video, then divide that by 1000 to convert to terabytes, then divide by 1000 again to get to Petabytes. The final bandwidth estimate is 3,000 PB used daily.

Storage Calculation

Step by step calculations for storage

Based on a few assumptions we can calculate that YouTube will need to store around 2.16 Petabytes of new video every day. Here's how we get that number:

• Convert 500 hours to 30,000 minutes of video uploaded per minute
• Each minute of HD video is roughly 50 Megabytes due to having copies of each video in multiple formats. We multiply that by 30,000 minutes and then divide by 1000 to convert to Gigabytes.
• We then take the 1,500GB uploaded per minute and multiply by 60 then 24 to calculate the daily amount of video uploaded. We divide by 1000 again to convert Gigabytes to Terabytes
• Our final total is 2,160 Terabytes uploaded daily or 2.16 Petabytes

Step 3 – Database Design

For our database we will use a standard relational database like MySQL. The schema will look something like this:

This design is very simple but has the essentials that you'd need for a basic implementation. It would be a good idea to do some research into the differences between relational and non-relational databases so you understand what kind of situations each excel at and when to use them.

For certain apps with different requirements a NoSQL database might make sense. Often large systems will have many different services that use different types of databases depending on their needs.

Step 4 – High Level Design

That's a pretty complex diagram, so let me break down what's happening:

• Client – This could be a user on a mobile app or their computer trying to upload a video, make a comment, or watch a video
• CDN – A content distribution network is used to reduce latency and improve reliability when it comes to delivering static content like videos or images. A CDN works by storing content in data centers all around the world so that the content is closer to users. This results in reduced latency because requests travel a shorter distance. There's also an added benefit of content being stored in multiple locations so even if one location can't serve traffic for some reason, another location can.
• Load Balancers – A load balancer accepts requests and routes them to servers depending on a number of factors. At YouTube's scale, a single server can't handle all the traffic and you want replication to prevent a single point of failure. The load balancer can check the status of servers and verify they can handle traffic or choose another server that can handle the request.
• Services – You can think of this as the app layer of the system. Instead of using a single monolith to handle traffic, we'll use several microservices to handle specific tasks. The second box for each of these services in the diagram represents multiple servers running for each of them to increase reliability. If one replica of the service goes down, there's always another to step in and handle traffic.
• Data Stores – When using microservices it is generally best practice for each microservice to own its own data. If one service needs data from another they can access it through an API.
• Video Upload Process – Handling the video uploads will involve multiple steps, as trying to handle it synchronously with the app server would be fragile and reduce performance. I'll cover this more in depth in the next section

I don't want to go too in-depth on these individual components because I could write entire articles on any of them if I wanted to explain them fully.

If you are interested in a more detailed explanation you can check out the system design playlist I linked to above which has videos covering most of these concepts.

Step 5 – Go Over Specific Components and Details

At this stage you have a working design. Now let's look at some of the specific components in detail.

Video Upload

Video content is the lifeblood of YouTube, and it doesn't exist without it. This means that making it quick and easy for users to upload videos is probably the most important feature.

Imagine uploading a multi-gigabyte video to YouTube and then seeing the upload fail after 30 minutes when it's 95% done. To prevent this you'll want to support the ability for resuming uploads if the client's connection is lost temporarily. The uploaded video can then be stored with a distributed file system like HDFS.

Once the upload is complete there's still a lot more to do before the video is ready for users to access. The video needs to be encoded into multiple different quality formats, you need to generate thumbnails, and push copies of the video to the global CDN.

Again, at any stage one of these processes could fail. To prevent this you'll have a task queue to manage this process and retry the processing attempt if it fails at any stage.

Database Scaling

The database is often the bottleneck of an application. You will probably be tested on whether you understand some of the fundamental concepts around database scaling. This could include caching to handle read requests, sharding, and replication.

Conclusion

Hopefully this article has given you a better understanding of what to expect during a system design interview.

This article mainly focused on the structure of the interview itself rather than the concepts you need to understand to answer the questions given during the interview.

Two great resources for beginning to learn about that are:

A great article posted here on Free Code Camp News: https://www.freecodecamp.org/news/systems-design-for-interviews/

The system design primer repo on GitHub: https://github.com/donnemartin/system-design-primer

Both cover just about every major concept you need to know for your system design interview and should put you in a great position for success.

Cybersecurity is one of the fastest growing fields in technology. There are 3.5 million unfilled jobs predicted by the end of 2021, there's been a 0% unemployment rate since 2011, and spending reached $123 billion in 2020.

Whether you are a fresh graduate or are looking to make a shift in careers and nab one of those jobs, knowing how to best position yourself in an interview can give you the edge.

I've been working in cybersecurity for over 10 years, and majored in Business Information Systems and Classical Languages & Literatures (I hated math so Computer Science as a major was out). You don't need an academic background in computer science to get your start in cybersecurity, you just need to be curious and learn.

Below are 10 tips I've put together to help guide you in preparing for your first or next cybersecurity role.

0. Apply for the Job

Forget the qualifications listed on the job posting (well, maybe not completely). Does the job seem interesting? Would you like to work at the company? Do you have some of the criteria? Then apply!

Too often, I've seen very qualified individuals not apply for jobs because they felt that they wouldn't meet every single criteria listed. But if you think you can meet some of the requirements, then apply and at least have a dialogue.

Often hiring managers end up throwing every requirement they can think of on the job description, rather than the minimum needed for the role. And forget the degree requirements completely - some of the largest companies in the world don't require degrees anymore.

1. Get Involved in the Cybersecurity Community

Join local meetup groups, or participate in Capture the Flag competitions, such as those hosted by the National Cyber League. These events are open to beginners and experienced people alike, and help demonstrate your passion and commitment to cybersecurity growth.

I often instruct our recruiters to highlight any résumés they come across where they see the candidate participated in cybersecurity events.

In every interview I conduct, I always ask how the candidate keeps up to date with cybersecurity - this is a great time to talk about your reading list, projects, and the events and groups you are part of.

2. Do Your Research

One area where I see candidates stand out from the pack is when they demonstrate they have researched my company, and the industry my company is in.

Every candidate should be prepared to answer "What threats do you see against my firm, and what advice would you give leadership to mitigate these threats?". Even better, if you know the name of your interviewer prior to the interview, spend some time researching them on LinkedIn to get a sense of their background.

One of the best interviews I conducted was with a candidate who actually performed some reconnaissance on my company prior to the interview. They looked up my company's information on Shodan, Google, and other avenues to get a sense of potential exposure and an understanding of our public presence.

Note: Please do not try to actively scan the company's infrastructure and report vulnerabilities during your interview. This type of activity is in the grey area of legality at best, and likely won't endear you to the interviewer.

3. Keep Up with Current Events

Any candidate I interview should be able to tell me basic information about the latest trends in cybersecurity. This includes being able to discuss what "WannaCry" is, thoughts on recent breaches (such as the recent SolarWinds attack), and suggestions on how to prevent, contain, respond to, and recover from ransomware.

Depending on the seniority, I may not expect detailed technical information, but a cursory understanding is required.

4. Presentation is Important

While it can be tedious, you should make sure to tailor your résumé and cover letter to call out areas of interest that are in line with the job posting.

Tailor your résumé to the job you are applying for - don't add in a laundry list of unnecessary information.

Introduction

The first part of the résumé, aside from your name and contact information, should be a brief introductory paragraph that really sells you to me. Explain what you bring to the table - this section helps separate you from the other résumés that just list work experience without giving context.

Work experience

List the most current position you have, and work your way back. Be prepared to discuss any major noticeable gaps in employment.

If you've been in the professional arena for quite some time, you don't need to list every single career - 10-15 years is a good range to display. No one wants to read a ten page résumé - so make sure that every bullet point is relevant.

Avoid acronyms where possible, and try to provide at least three bullet points for every job listed on the résumé. Make sure these bullets list out your accomplishments, and where possible provide hard numbers rather than vague text. For example, "Achieved 60% cost savings" sounds better than "Saved money".

A note on grammar: Use present tense for the job you are working in, and past tense for all prior roles. Also, please use grammar and spell-check in your word processing program. A poorly written résumé often gets rejected before it is even sent to the hiring manager.

Professional memberships, publications, speaking engagements, and certifications

If applicable, use this section to list out any boards, communities, or professional organizations you belong to, as well as your membership (for example, member, director, founder, and so on.).

This helps show the hiring manager your involvement in the community outside of your day to day employment and in general makes you a more attractive candidate.

Feel free to add in relevant or interesting memberships outside of cybersecurity groups - such as a troop leader for the Girl Scouts or board member of a non-profit. If your publication or speaking engagement is available online, include links to the content.

Last, list out your certifications, including the issuing body and when you achieved the certification.

Technical skills

Be careful with this section. It's tempting to list every single technical term under the sun here, but you should focus on the skills that you feel will make you an asset for the role you are applying to.

My biggest pet peeve in this section is when candidates put down "generic fluff" such as "OSI model", "TCP", "IP", "SSH", "Windows operating system", "Mac operating system", or even just a list of security tools.

When a hiring manager sees a technical skills section that only lists security tools, their first though is usually "Can this candidate perform if they did not have access to these tools?"

Caution: If you list a skill on your résumé, be prepared to discuss it. I learned this myself in one interview where I was asked a series of very technical questions about the Python language simply because I put it on my résumé.

5. Develop Your Hard Skills

Coding/Scripting skills

While not required for many roles, I do pay attention to résumés that indicate that the candidate has some form of development or coding experience.

If you don't have formal development experience, but you can do some basic coding (all of my coding pretty much involves having StackOverflow open in a browser window), you should absolutely put that on your résumé.

If you have contributed to any open source projects, or worked on code yourself, make sure that is highlighted on your resume as well - this is something I try to look for on résumés. Sites like freeCodeCamp, CodeBashing, and LeetCode can help provide a solid scripting and coding foundation.

Technology fundamentals

Understanding how a system works is fundamental to being able to efficiently protect it. Based on the role you are applying for, ensure you can speak at about relevant technologies, with insight into the attacks and defenses relevant to the technology.

For example, if I am hiring a network security engineer, I would expect the candidate to explain what DNS is, how it works at a high level, and what protocol it uses (UDP. Only say TCP if you can qualify when specifically it will be used).

6. Develop Your Soft Skills

Communication skills

Communicating well is one of the most important skills any cybersecurity professional can have. Most organizations have a limited team size for cybersecurity, and as such you may be expected to speak to senior leadership that may not have your technical background.

One element I look for in any résumé is whether the candidate has listed public speaking engagements, such as presenting a topic at a conference. I expect any team member to be able to speak with employees and break down complex cybersecurity topics into easily digested, actionable information.

Leadership skills

These skills are really hard to put down on paper. However, I expect any candidate to be (eventually) able to lead cybersecurity initiatives and projects.

Come to the interview prepared to discuss any project - whether from your career or a side project or activity (for example, coaching, tutoring, and so on) - where you had to take initiative, and what you learned from the experience.

Organization skills

Being organized is a key skill for a successful candidate to possess. No matter how good your technical skills, if you struggle meeting deadlines, or being able to multi-task (cybersecurity runs at a rapid pace - it is very difficult to have uninterrupted time focusing on one task), it will be difficult to land that job, especially on a small team.

7. Demonstrate Practical Experience

You don't need to have formal professional experience to apply for a cybersecurity job. However, you can give yourself a leg up over the competition by demonstrating projects and skills you have learned that are relevant to cybersecurity.

If you have a GitHub link to a project you worked on, or you decided to test out building a Kubernetes cluster on several Raspberry Pis, add that to your résumé!

8. Keep your Résumé Relevant

All too often I receive résumés that take up space listing out completed college courses related to cybersecurity when the candidate has been in the field for 5+ years.

Make sure that your résumé only lists relevant information - while it may not need to be relevant to cybersecurity (diversity of experience is always nice to see), college classes and a GPA really aren't relevant unless you are applying for your first job out of college.

While I am not of the opinion that a résumé must, no matter what, be only one page, the content should not feel fluffy. I rarely see a need for a résumé to be more than one page unless you have spent years in the field in various roles.

9. Be Professional

Cybersecurity in general tends to be a relatively informal industry (even more so in the age of digital interviews). However, first impressions are extremely important, so make sure to dress and act professionally during your interview (and ideally if you get hired too!).

I have seen candidates interview in stained undershirts, inappropriate graphic tees, and other unprofessional attire. This is your chance to make an impression, and while I wouldn't say you need to dress in a suit and tie, at a minimum you should dress in business casual clothing, similar to what you would wear if you had to come in to an office.

In addition to what you wear, how you speak is extremely important. We have all had bad managers in the past, or worked for terrible companies. However, don't spend your interview badmouthing previous employers or companies.

If you're asked about why you are leaving, or what issues you had with a job, it is better to just say the job "wasn't a good fit" and leave it at that. You don't want the interviewer assuming this is how you would talk about them.

How a candidate conducts themselves, and how diplomatic they are, is extremely important. Given how small many cybersecurity teams are, you can find yourself speaking with senior leadership, and the interviewer will be on the lookout for how you they believe you would conduct yourself in those situations.

Last, and this should go without saying, is always be polite. Whether to the HR recruiter, external recruiter, interviewer, or receptionist - always be polite. People do not want to hire and work with someone they feel is rude or disrespectful.

10. The STAR Method

Cybersecurity is a high stakes, fast paced field where critical and analytical thinking, ego (yours and others) management, conflict resolution, and leadership play a key role in the team's success.

Interviewers typically look for someone who has a hacker mindset - someone who is innovative, and can think critically to solve problems.

Come prepared to discuss situations where you have had to deal with conflicting priorities, solve complex problems, explain technical information to a non-technical audience, and even discuss areas where you see opportunity for growth in your performance.

While I won't go into various scenarios in this post, one key outcome I look for is whether the candidate understands how to frame cybersecurity risk.

There are times risks need to be taken, and it is our job to provide the right information so that the decisions made are informed. How well a candidate can analyze a problem is worth more than the experience written down on the résumé.

Especially when responding to behavioral interview questions, the STAR method provides a good framework of how to provide answers:

• Describe the situation you were in.
• What task were you performing, and what was the desired goal?
• Describe the action(s) you took to address the situation. Be specific and focus on your contributions.
• What was the result of your actions?

The jobs available in cybersecurity are many, covering numerous specializations that range from technical, hands on keyboard roles to governance and design roles. Use these tips to land your perfect job, and welcome to cybersecurity!

Further reading

There are two big things I that I usually find missing in interviewing guides:

1. Your chief aim as a candidate should be to make a connection and have a real conversation.
2. You may not be given a good opportunity to make a connection.

There is no one formula for success in interviews because interviews are run like the Wild West. But you can maximize your chances.

How to Connect with Your Interviewer through Stories

Tech interview guides focus a lot on challenges, puzzles and tests. We should put more emphasis on the discussions to establish if you’re a fit for the role.

As a candidate it’s extremely valuable to be well prepared for the fit interview. It’s a chance to make a great impression at a personal level and not just as a test score.

A big part of this preparation is having stories that present the skills you want to present. Let’s consider examples of what this can look like.

Example Interview Question and Answer

Interviewer: Could you give me an example of something you worked on at company X?

Candidate: One of my favourite projects was a performance improvement project. I introduced a new library for mapping code entities to the database. I also introduced a benchmarking tool to measure the improvement. It showed a speed-up of 40% for some queries.

Interviewer: That's interesting, what did you enjoy particularly?

Candidate: I enjoyed seeing the difference it made to the user experience. I also liked that it was a well-defined task and it was rewarding to get it done. I can talk more about the challenges if you like?

Interviewer: Sure, what would you say was the biggest challenge on that piece of work?

Candidate: Well I knew which library I wanted to migrate to. But it wasn’t compatible with another library we were using. I saw that it would become compatible if we upgraded that other library. So I had to explain that and get agreement to do the upgrade. There were some code changes involved and one of the others was initially reluctant. I convinced them by doing a small PoC to show that the changes weren’t that big.

Preparing stories that answer the first question in this exchange is good preparation. But the big value is in the follow-on conversation. That’s where the interviewer really gets to see your problem-solving skills. And in this case, also your teamwork skills.

You don’t want to just aim to be telling stories. You want to be bringing the interviewer with you through your accomplishments. Those accomplishments don’t make sense unless you reveal what was difficult about them.

Sharing your experience effectively is even more important for more senior roles.

Interviewer: What was the best thing you did at company X?

Candidate: I led the implementation of a new feature to generate business insight reports. It was very well received and helped lead to doubling of sales.

Interviewer: How did you ensure the reports offered the insights the business was looking for?

Candidate: It took a couple of iterations to get them right. We agreed on initial specs but they were a bit rough and the business wasn't very clear from the beginning. In the second iteration they got more excited and could guide us more clearly.

Interviewer: Why do you think the business wasn't excited until the second iteration?

Candidate: I think the mockups we'd done for the first didn't feel real to them. We'd mocked the data and they needed to see it with some of the real records to see the value they could get from it.

Here the initial story doesn’t demonstrate much. It asserts an achievement but it doesn’t demonstrate. The answers to the follow-ups show an appreciation of stakeholder management and requirements solicitation. Getting a flow of conversation going like this also helps the interviewer to relate.

Both of these example exchanges do well at making a connection. The answers get to the point and are explained so that the interviewer can understand them. They tell stories of overcoming challenges. They show appreciation of tricky problems as well as good collaboration skills.

Have stories prepared that show off your experience. Be prepared to answer questions like “tell me about a time when…” If you’re well prepared you’ll look forward to these questions. They can lead to good discussions.

Get to Know the Company

Your conversations will be more productive if you tailor them to the company and the role. Look at what the company does and what tech they use.

When you know a little about the company, think about which stories you’d like to emphasise. Which of your experiences would be most relevant to this role?

The job ad likely says which skills are must-haves and how much experience they’re looking for. It’s ok to not match it perfectly. Think about where you are a strong fit and emphasise that. Acknowledge your limitations and stress that you’d be keen to learn to fill the gaps.

You’re more likely to get favourable questions if you tailor your CV to the job ad. This need not be a lot of work. It could just be re-ordering so that the most relevant skills and experiences feature more prominently.

How to Connect with Your Interviewer through Thinking

Of course it’s not all about stories. The tech skills are crucial. But the technical evaluations are not just a chance to demonstrate tech skills. They’re also a chance to relate personally.

Don’t treat the tech parts as simply a test of knowledge. They should be tests of reasoning.

Take every opportunity to reveal your thinking. Say why you chose one approach rather than another. Say what you like about a technology and what you’ve found awkward.

It is usually ok to not know an answer. Share your thoughts and be interested in how to get to the right answer, if there is one.

Expect to be challenged on exactly how far your knowledge and experience goes. Maybe you don’t have experience using technology X for millions of transactions. Acknowledge that. Talk about what scale you have dealt with and how you would scale higher.

Sometimes you’ll get ‘gotcha’ questions. Questions where the interviewer really wants some obscure piece of knowledge you don’t have. Try to turn them into conversations.

You want to show that you are flexible and that you’re someone the interviewer could work with. That involves being humble about what you don’t know. Try to show that you could go on learning journeys together.

You should be prepared to be challenged with coding exercises. Look up what you can about how the company hires. It’s ok to ask them what to expect in the process.

How to Achieve your Goals

“We do not learn from experience… we learn from reflecting on experience.” - John Dewey, Philosopher

Interview prep takes time. Getting your stories prepared has to compete for time with technical preparation. You’ll want to tailor this to the company.

The key point is not about what prep to do. It’s about how to approach the interview.

Making a connection maximises our chances. Even if we make mistakes in the process, the interviewer is more likely to be generous to us if they relate to our experience and thinking.

The process of thinking about what we want to emphasise is also a good growth exercise. It forces us to consider which of our skills are most marketable. And also what we most enjoy.

We’ve a better chance of landing a role if we can explain how it would fit into our personal growth story. We want to be clear what attracts us to the role and how we’d grow with it.

The interviewer will likely ask us why we’re interested in the role. We should have a compelling answer, both for the interviewer and for ourselves.

Interviews are the Wild West

Candidates tend to assume interviewers have everything together. We assume that it’s a great company with a great interview process. So obviously if the interview goes badly it must be our fault?

Even in great companies you get messy hiring situations.

There may be multiple people in the hiring process and they may disagree on what they want. You may get one interviewer open to more junior candidates with an aptitude to learn. And another interviewer who wants all the relevant skills right away.

The interviewer should be trying to have a conversation with you. They should be trying to see how you approach problems and whether you’re somebody they could work with.

Unfortunately the interviewer might not be looking for conversation. They may be rushed or having a bad day. They may have limited thinking space.

Rarely is anyone trained in interviewing. Some people seem strangely ok with making interviews an exercise in ticking boxes. Or a kind of chess game to find faults.

The most common weakness in interviewers is being under-prepared and rushed. This leads to a passive approach to interviewing where the interviewer basically sits back and waits for you to impress them.

Tell stories about good work that you’re proud of. Stories about overcoming obstacles and making trade-offs. Try to relate the stories to what you know about the role. Where you’re not sure how your experience relates to the role, drop in the odd question to show how interested you are.

How to Succeed in the Wild West of Software Interviews

Think about what the interviewer is looking for. Which skills are must-haves and how much experience they want. Even ask them.

Have stories prepared and think about how to relate them to the role. Use your CV so that it prompts the questions you want. Stories aren’t the whole interview process but they are typically the centrepiece.

Have questions prepared to show how interested you are. Really try to imagine what you’d be doing day to day.

Think about how relatable each of your stories are. Make sure you tell them in a way that doesn’t require too much insider language or context.

The way to succeed in the Wild West of interviews is not to be an awesome gunslinger. It’s by being awesome at making new friends.

In my last article, I shared my thoughts on how to get an interview as a software developer. This week, I will share my thoughts on how you should prepare for that interview once you get it.

Tech interviews are notoriously nerve-racking and unpredictable. But there are steps you can take to mitigate a lot of these feelings.

Phases of the interview process

Most software development interviews have a similar structure - it's kind of like the modern foundation for these interviews.

You'll typically find the following phases in your interview process:

• Phone screen
• Technical phone interview
• On-site

Let's look at each of these in a bit more depth.

What questions should I expect?

Interviews in the tech industry are far from uniform, but I like to think of that as a positive thing. This keeps things interesting and can allow you to show off your skills in a new way each time.

This includes the questions that you will most likely be asked in your interview, but don't worry. There are lots of common questions that will help you be prepared for your big day.

From my perspective, these questions can be broken down into two categories, company-specific and situational (hypothetical).

Company-specific questions

Depending on the size and type of company you are interviewing at, the way they interview might differ. I suggest you use websites such as Blind or Glassdoor to gain insight into company-specific interview topics and questions.

As an example, The Interview Guys put together a great article that discusses Amazon's top interview questions.

If you spend a little bit of time searching around on the web, you should be able to find some questions that a certain company traditionally asks. This will give you a leg up on your preparation.

Situational (hypothetical) questions

You can expect these questions to touch on your work style, recent achievements, and your technical competency. A few topics that you can expect to be asked about are:

• Tell me about a time that you had to deal with a tricky bug. How did you fix it? What was the outcome?
• Do you prefer to work by collaborating (pairing) with others or on your own?
• What do you like about the programming language you use?
• Which new features of the language do you use most and why?
• Describe your team’s typical workflow for a project. What do you like about it? What don’t you like about it?

Remember, stay positive as much as you can. Although the interviewer is genuinely interested in your responses, they are also looking for any signs of negativity or difficulty you might bring into their current team dynamic.

Try to avoid talking down about a particular piece of technology you have used in the past. Instead, spin your response in a positive way.

For example, instead of saying “I don’t like using the spread operator in JavaScript, it’s too confusing”, you can say, “I know the spread operator is a newer feature of JavaScript, I look forward to learning more about it and how to use it efficiently in my code.”

Now that you have a good idea of what some common questions are and some elements to include in your responses, let's dive into each step in the interview process. The first step is the phone screen.

First things first, "tell me about yourself"

After you apply and a company has an interest in you, the first step is usually to schedule a phone interview. This is typically a pretty relaxed conversation with a member of HR.

You can expect them to ask primarily about your job history, what you are looking for next, and most importantly, why you are applying for a position at their company.

Just because this is typically easier than the other phases of the interview process does not mean you should not prepare for it. A few questions to prepare for are:

Tell me a little bit about yourself

This is a good time to give your “elevator pitch”. This will likely be one of the first questions you are asked and usually can be a great tone-setter for the remainder of the interview.

If you tend to talk fast, take a deep breath before you answer and try to speak slowly and clearly. A few items you want to mention in your response are:

• Ethos or interests you share with the company
• What excites you about software development
• Future goals that (hopefully) this company can help fulfill (that is, technical and professional growth)

What is a recent project you worked on that you are proud of?

Like most of these questions, the interviewer is not solely curious about your technical achievements. They are also looking for cues that convey you can communicate well, are reliable, and are someone who would get along with the other members of the team.

Try to be enthusiastic and answer questions fully, without rambling too much. An effective framework for answering these types of questions is:

• Give a quick overview of what the project is and the problem it solves
• Mention the technologies you used in this project
• Communicate any metrics that demonstrate any positive impact (like time-saving metrics, open-source contributors, number of active users)

Why are you looking to leave your current company?

This might be one of the trickier questions to answer. Make sure you have a solid answer for this one prepared prior to the interview, as it can tell a lot about a candidate pretty quickly.

Here are a few things you should avoid when answering this question:

• Being negative. Turn any potentially negative factor into a positive one. For example, “I am bored and unsatisfied with the work I do here” can be said instead like, “I am looking for a new challenge that cultivates my growth as a developer and an individual”.
• Talking about current coworkers or managers – keep them out of the conversation
• Discussing compensation and benefits

I think one of the best answers you can give to this question is an honest one – you are looking for something new. That is a perfectly reasonable answer!

The only pieces I might add to this response are your interest in new challenges, enthusiasm for the company, or a piece of technology that you know this company uses.

How to prepare for the technical phone interview

Ok, you were enthusiastic, personable, and well prepared for your phone interview. The next step in this process is generally a technical phone interview.

Before your technical phone interview, it's important to make sure you know which programming language you will use.

Which programming language should I use?

Before you start preparing for the other steps of the interview process, it would be prudent to have a good idea of which programming language you will use during the interview.

When it comes to this question, I have some pretty simple advice: embrace what you are comfortable with, and stick to what you know.

It is fairly common to want to use (or learn) multiple languages in our field. But, when preparing for an interview, it is best to stick with just one.

This will help shift your focus from worrying about which language you will use, to thinking of problems you have solved with the language you are most comfortable with.

Once you know which programming language you will use, you are ready to take on the challenge of the technical phone interview.

Discussing technical achievements and high-level programming topics

In a typical technical phone interview, you'll have a conversation with a senior member of the team you would join or with the manager of that team. You can expect a lot of this conversation to be focused on two things:

• Recent problems you have experienced in your current position and the solutions you implemented for them, and
• General language familiarity (such as when would you want to use an array instead of a hash table (object)?)

To help prepare for this interview, I suggest you start to write down answers to these questions.

Personally, I have used an Excel or Google sheet document that consists of 3 columns: questions, answers, and notes. You will find that taking the action of writing your answers down will help you come up with a concise and impactful answer.

There are a lot of resources online that list common interview questions, for frontend, backend, or full-stack roles.

This might seem like a lot of work upfront, but trust me – spending the time to prepare and convert your thoughts to pen and paper will really help you mentally flesh out your answers.

Okay, you've spent ample time preparing and you impressed your interviewer! The next step you can expect is the "on-site" interview.

What is the on-site interview all about?

The final stage of the interview process is usually referred to as the on-site. This is often the most in-depth and the most important to perform well at.

One of the main questions the company would like to have a good answer for is, how does this person work? The answer to this question is usually echoed through multiple levels as well, personal, technical, and professional.

Companies seek this answer by giving the candidate various exercises, technical and interpersonal, to gauge your skills and how well you will fit in at their company.

Depending on the company this interview can include various elements, but a few that are most common are:

• Pair programming
• Take-home assignments
• Whiteboarding

Excel during your pair programming session

One of the most common methods of gauging your skills is to pair program with a member of the team you might work with.

This session is usually 20 to 30 minutes and the problem you are given is generally something you will see on the job at this company.

There are a few things to keep in mind if you have a session like this:

• Try to stay calm and remember that you are interviewing here for a reason, they like you and see promise in you.
• Communicate out loud as much as possible, even if you think you are talking too much. It’s better to over-communicate in these exercises than to sit in silence typing away at the keyboard.
• Don’t be afraid to ask questions, they’re on your side! The interviewer has probably left out critical details on purpose to test your communication skills while working with other developers.

Ultimately, try and be conscious of the fact that this company sees promise in you on a personal and technical level. Be yourself and be confident!

If the company does not have a pair programming exercise included in their process, another common exercise is to give you a project or a collection of problems to solve on your own.

Crush your take-home assignment

If the company wants to gauge your work through the lens of how you work as an individual, they might ask you to complete a take-home assignment.

These can range from completing timed exercises on HackerRank to completing a small project with written instructions from the interviewer themselves.

Regardless of the style of take-home assignment, there are a few things I think you should keep in mind to increase your chances of success:

• Ensure you are in a distraction-free area for the entire allotted time
• Put any distraction-prone devices away
• Read all instructions to the problem(s), and then read them again

If your assignment is timed and you do not think you will have enough time to finish, write comments throughout the assignment with what your next steps would be if you had more time.

To be honest, a lot of these assignments are supposed to take longer than the scheduled time to complete.

The interviewer is always primarily focused on how you communicate, not that you can write code the fastest, or solve every algorithm you see.

Conquer the whiteboard exercise

Sometimes a company would prefer to take a look at your technical skills and ability to break down complex problems in more of an abstract way. The most common way of testing a candidate this way is by having them complete a whiteboard exercise.

This method of interviewing might be the most talked about, and the most feared. If you are asked to use a whiteboard to solve a question remember this: they are (usually) far more interested in how you communicate your problem-solving process, not that you can solve the problem.

If the problem they give you seems really hard, that is not because they are trying to stump you. They want to get a feel for how you tackle a hard problem. If you don’t end up solving the problem, that does not mean you blew your chance.

If you keep these things in mind during this exercise, it will increase your chances of impressing your interviewer:

• Repeat the question back to the interviewer
• Ask clarifying question about edge cases
• Confirm optimal results of the problem
• Write your code legibly
• Communicate each step you take

If you answered the question successfully by the time the session ends, ask your interviewer if that was the solution they commonly got. If not, ask what other candidates have done or what you could have done differently. This shows that you are engaged and curious.

If you did not answer the question successfully, write comments throughout the code about where you might continue to find the solution if you had more time. Again, a lot of these sessions are not focused solely on getting the “right” answer, but to get a good idea of how you approach new problems.

Practice interviewing, without the pressure

As I mentioned earlier, interviews are tough and can be hard to prepare for. However, I am a firm believer that the best way to ensure a higher chance of success is to practice, practice, practice.

Have you ever practiced a big presentation for school in front of friends or family? You might have still been nervous but, it sure does help you feel more comfortable speaking about your topic.

Interviewing is also a presentation, and the concept of practice runs are just as important. In the 2020 world, most interviews are completed remotely, which makes performing mock interviews feel more real.

If you know someone who is currently in the software industry, I would ask them if they would be willing to set aside an hour or so a week to perform these mock interviews with you. If they currently work in a similar role that you are interviewing for, even better!

A few other options are Pramp and CodeInterview. These sites allow you to schedule an interview, and pick a primary focus (topic), language, and area of expertise (frontend, backend, and so on).

These platforms also give you more flexibility so you do not have to worry about scheduling time with someone you personally know.

Interviews are nerve-racking, but I am confident as you complete more of them your confidence and comfort level will increase.

Should I cram the day before?

As the days go by, you are feeling more confident. You are tired from preparation, but excited to show this company what you are made of. It's finally the day before the interview – what is the best use of your time?

It might be tempting for candidates to cram as many Leetcode problems or whiteboard questions as possible the day before. But I believe the best thing you can do for your mind is to rest.

Celebrate your achievement, getting interviews is not an easy task. Be nice to yourself. Relax and spend the day doing any activity that brings you joy and (ideally) relaxes you.

This might sound counterintuitive, but I think it is the best thing for you to do. You will need your brain to work well at your interview. Therefore, giving it rest the day before is exactly what it needs.

In Summary

If you are reading this because you are going to start to prepare for an interview, congrats! I hope my insights can help in your preparation and your headspace as you approach your big day.

Ultimately, remember to take a deep breath, relax, and be confident in yourself. Whoever you interview with sees promise in your skills. You got this!

Job hunting is hard. It's not something you ever get comfortable with, because you typically don't do it often enough to get good at it. There's also A LOT of bad advice on the internet about how to job hunt.

Because it can be difficult to figure out which resources online are helpful, and which are useless, I've created a list of my top tips and favorite resources for job hunting, resumes, and interview prepping.

Here's my top tips to help you identify the things you're doing wrong when job hunting.

You have a poor resume.

Resumes which are poorly formatted, hard to read, full of grammatical errors, or don't accurately capture your experience can really hurt your changes of getting interviews.

Most people are bad at writing them, which makes sense – after all, you probably only write them every few years. And it involves selling yourself, and your skills, something which most people struggle with.

On top of this, it's difficult to figure out how to sort through all the advice on the internet in order to figure out which is good advice (please avoid the professional resume services).

Plus people rarely think that their resume is the problem, even if they've been struggling to get interviews. They'll often say something like 'but I've had tons of people review it and they all say it's okay!'.

There are a couple of problems with this: first, you want your resume to be better than okay. In order to stand out in an extremely competitive job market, it needs to be stellar.

Second, most people don't know how to write a resume, and therefore they can't help identify the problems with yours. Also, it's often hard for reviewers to provide constructive criticism for fear of hurting someone's feelings.

Finally, you really need someone who has a lot of experience hiring or recruiting in your specific field in order to receive accurate advice.

Need more detailed resume writing tips? Read this article.

You write a generic, boring cover letter.

You should write a personalized, custom cover letter for jobs you care about. Cover letters are a way that you can stand out from your competition and show the organization why you're interested in working for them, as opposed to any other organization.

This is more important to some organizations than others (FAANG typically don't care), but a great cover letter will never hurt your chances of being hired, only help them.

It can also be a helpful exercise for you, because it gives you the chance to think about and articulate why you're interested in working for this company.

This way, when you're asked in an interview 'why this organization?' you have an answer readily available.

In addition, your cover letter should be in the body of your application email - don't send an empty email with two attachments to the hiring manager.

You fail to proofread everything.

If you struggle with grammar and spelling, or English isn't your first language, check out Grammarly. It is free and will help you identify changes you should make to your writing.

Also, if you can, ask a friend who got great grades in English to help you out. If your resume/cover letter/application is difficult to read due to spelling and grammatical mistakes, the focus won't be on your achievements.

Plus, communication is a big part of any job (no matter how technical) and your application is a place to showcase your communication skills.

Since you've had essentially unlimited time to write and review your resume/cover letter/application, it's expected that they will be free from grammatical mistakes or spelling errors.

You forget about the behavioral interview questions.

Preparing for an interview is extremely important. For the technical questions, Cracking the Coding Interview, Interview Cake, Leet Code, and HackerRank are excellent resources (as is freeCodeCamp!)

However, a common mistake is to ignore the behavioral questions entirely. These questions can set you apart from your peers, and an inability to answer them well can ruin your chances of being hired, even if your technical responses are excellent.

The best place to start is often to look at Glassdoor interview reviews for the company you're interviewing with. This will help you get an idea of what type of behavioral questions they favor, as well as the STAR technique, outlined here.

In addition, Leet Code and HackerRank also have great discussion forums to talk about behavioral questions for specific companies and how to best prepare.

You don't dress up for your interview (even if it's over video) or you show up late.

It will likely make you feel more confident to dress well for your interview. And similarly to proofreading, will ensure that the focus is on what you're saying, not what you're wearing.

What is considered appropriate workplace attire varies based on the geographic location, industry, organization, culture, and so on. So it's important to do some research in advance to figure out what you should wear.

In addition, if you're interviewing via phone or video call, ensure that you've minimized background noise (or distracting items in the background), that your camera and microphone work well, and that you have a quality internet/phone connection from your location.

Again, the focus should be on helping the interviewer focus on what you're saying, not a poor internet connection, background noise, or an odd background. You should definitely be prepared to turn on your video camera during a virtual interview.

You apply for jobs which don't relate to your job history with no explanation.

If you've previously only had jobs doing x and are now applying for jobs doing y, you need a clear and convincing explanation as to why you would be good at this new job.

Employers often receive hundreds, if not thousands of resumes for a single position. They need a fast, easy way to sort through the resumes in order to decide whom they want to give interviews.

Thus, if there's anything wrong with the resume (typos, strange formatting, experience which doesn't match the position), they're likely to simply toss it in the 'no' pile.

It's your job to convince the employer that you would be great at the job (and why!) with your application materials. This is particularly relevant if you're attempting to change careers or are coming from a self-taught or bootcamp background.

That doesn't mean you can't apply for those jobs (plenty of self-taught developers have successfully changed careers!), but it does make it a little harder.

You need to clearly show to employers why you're qualified with an excellent cover letter and a resume which highlights projects you've done and transferrable skills from previous jobs.

You don't follow instructions.

It sounds simple, but many people don't follow instructions.

If the job posting asks you to submit a resume/cover letter to a specific email address, do that. Don't print it out and mail it to the hiring manager or mail the hiring manager something other than your resume or submit a video resume when they've asked for a pdf.

They've asked for specific application materials in a specific format because it is easy for them. If you go around that process, your materials may never make it to the appropriate person, or it may annoy them that you've created more work for them (like scanning a resume into an online portal where they asked you to submit it).

Your goal should be to make it easy for hiring managers and HR to look at and review your application.

You follow up right after submitting an application.

If they're interested, they'll reach out to you. If they don't reach out, it could have been for a million reasons.

Perhaps they already had an internal candidate in mind, they've already filled the position and forgot to take the job posting down, or your application didn't stand out to them.

Don't overthink why you haven't heard back, and don't bother them. Move on to the next application.

Keep in mind that this is only the case if you haven't been contacted about an interview. If you've already had an interview, there are different rules for following up.

You think that you're the exception to the rule.

Everyone seems to have a story about a friend of a friend who got a job from doing something highly unusual like mailing the hiring manager a gift, showing up to the office, or another gimmick.

They're almost universally bad ideas. Don't mail a hiring manager chocolate or add fake facts to your resume, or drop by the office unexpectedly.

There are times when a candidate is so strong that they're hired regardless, or times when the hiring manager may appreciate an unorthodox approach (often when they are a small organization and/or don't hire frequently). But the vast majority of people will find it annoying.

Plus, you probably don't want to work for an organization where that type of tactic would work. You want to work for a place where what matters is your ability to do the job.

You don't use a professional email address.

Something like firstname.lastname@emailprovider.com is fine. University addresses are also fine, but after you have been out of university for a few years, it's probably a good idea to update it.

Something like 'fantasydudette@yahoo.com' is not.

Good luck!

If you've managed to nail all of these, congratulations and best of luck to you on your job search journey!

Many people dream about working abroad in their industry. But they're often not sure how to do it easily, or how to attract the interest of companies who are hiring.

I was looking for a position as a Software Engineer, and I had about three calls a day from potential companies during my hiring process. Fortunately, I ended up with a lot of options to choose from.

So let me tell you a story so you can learn from the success I've had and the mistakes I've made.

In this article, I'm going to share tips regarding why and how you can take next steps in your career, especially if you are not tied to a specific location.

Strong companies with great products or services have a lot of strong candidates to choose from. But I'll show you how to establish yourself as a strong candidate as well.

Why do you want to go abroad?

If you are not sure how to answer to this question, or if your WHY is not strong enough, you will probably quit a few weeks or months after being hired.

Take your time to consider this deeply. There are multiple reasons why you might want to move and work abroad.

• You might find more work opportunities
• You might want to work in a country with less strife
• You might be able to get a higher salary in a different location
• You might feel like you'd fit in better there
• Or you might like to travel in and around that country

The reasons are many – just make sure you know yours.

It is also very helpful to know why you want to work for a specific company. Does their why match your why? Do your research to find out for sure (more about that below).

The easy way or the right way

The easy way

First, let's have a look at how to make this process easier for you. If you studied abroad, worked in a “work and travel” program, or something else similar, it should be way easier to get used to a job abroad.

You will have had deeper experience speaking other languages, traveling, meeting people of various cultures, establishing a social life from zero, and learning about different laws.

It should be even easier if you're applying for a job in the same country where you studied – or anywhere with a similar culture. It was also very helpful for me to complete the whole process with someone who similarly applied for an IT job abroad.

The right way

But in the end, it really depends on what you are looking for and why you want to go abroad.

Maybe you are looking for a big challenge instead of a safe journey. So think more about what fits your requirements and then figure out how to make it easier without sacrificing your needs. I think this is the right way to handle it.

As for me, I wanted to work directly with highly skilled and fast-learning people of different nationalities and ways of thinking. For that reason, I was focused on the diversity aspect more than on any similarities.

Evaluate Yourself

First things first: you need to analyze the skills required for your desired position, whether you want to work abroad or not.

Are you looking for a position that has requirements a bit out of your reach? Work on those skills for a year or two and give it a try again when you are more prepared.

Is it a position requiring high-level expertise in a certain area, a job that's not so often on the market? Make sure your skills match those requirements closely.

During the first few months you will have multiple opportunities to prove your qualifications for that position and agree on a way forward with the company.

Set ambitious goals for yourself

This is just a matter of where you are now and where you would like to get. If you want to be a part of a stronger team with higher standards than you have at the moment, then it’s good to increase your knowledge and skills before you start interviewing.

Keep in mind that some hiring processes can take 5–8 rounds and they test you from many different perspectives. So don’t forget to analyze the hiring process of each specific company.

This part can take months. During that time you can take some online courses from places like Udemy, Harvard University or Coursera.

Then you can continue with learning challenges on sites like Topcoder and HackerRank.

Finally, you can start preparing yourself with common interview questions on sites such as The Balance Careers, FlexJobs and HubSpot.

Establish your rate or ideal salary

One of the easiest ways to get a more objective review of yourself is to ask a senior ex-colleague to evaluate your performance.

It is also a good idea to test yourself using websites such as Devskiller and Codility. In that case, you might find out that you perform better than you expected and are able to score a better contract and salary during interviews.

Speaking of interviews, you will be probably asked about your salary expectations. This can be a tricky one to answer.

Many potential employees search the internet for the average salary using keywords such as “average salary of a developer in Prague”. Then they check Glassdoor, PayScale, Jobindex or Reddit, and, based on their years of experience, they try to find their value on an imaginary scale, where the lowest represents junior and the highest represents a principal developer.

It is better than nothing, but it doesn’t necessarily match your real value. Most times, you have to come up with that on your own.

Do Your Research

Quality of Life

Consider your priorities according to how long you expect to stay. I would set them differently in the case of a half-year contract versus long-term employment.

I was looking for opportunities in countries based on the following factors and values:

1. Intuition
2. Profit
3. Quality of life
4. Work culture
5. Economic growth (GDP)
6. Technological level
7. Traveling and nature

It takes time to analyze countries in relation to your career. However, if you are considering working abroad for a couple of years, then a few days or weeks of research can give you an incomparably higher value for long-term happiness.

To help myself figure out where would be best for me, I gathered data and put it in a spreadsheet.

The best-rated locations (Tab. 1) are based on my subjective preferences, so I would recommend making your own spreadsheet since your needs and preferences will likely be quite different.

Tab. 1 Results of analysis for developers

You can find some indexes such as quality of life or costs at Numbeo, Expatistan, WorldData, and more. The indexes must be on the same scale, for example, 1–100. Then you can multiply each index based on your priority, for example, 1–3.

You should have your salary expectations prepared for all countries you plan to apply to, in local currency (both monthly and yearly), for recruiters and companies.

Both gross and net salary need to be then converted in domestic currency to calculate the profit indexes for your spreadsheet about countries comparison (Tab. 1).

Profit can be calculated by the expected net salary per month of your desired position divided by total costs per month in a specific country. Indexes of profit can be created by a comparative method.

Barriers to Entry

It is also very important to check what barriers to entry might exist. You should also know the local laws. I would like to highlight some of these areas that might be surprising.

1. Visa requirements
2. Sponsorship requirements
3. Language barrier
4. Invalid driver's license
5. Pension missed due to short stay
6. Unpaid vacation days for the first year
7. Problems with opening a bank account
8. Higher costs of healthcare for new citizens
9. Amount of taxes and the difficulty of submitting a tax return

As for these highlights, I would like to mention some specific use cases.

For example, imagine you are hired by a German company. You might have to rely on English (based on requirements), but all of your co-workers speak German, even if it is against the company’s policy. This is related to the national diversity of the company.

When I lived in America, Finland, or Norway, it always took a couple of months to get a Social Security number. Having this document can often make your life easier. For example, Nabobil in Norway is an application that lets you rent cars more comfortably and cheaply.

Also, even if you are using Revolut or a similar application for money exchange, it can still cost a lot over a short period.

And perhaps tax returns seem unimportant compared to other issues. But if you've ever spent an entire week in the Netherlands working on taxes, then you know how expensive that can be in terms of a half-year contract.

Company Research

Compare your priorities to those of the company. Is it a fast-growing team? What's the average salary? Do you think you'd fit into the company culture?

All of the above and more are worth considering, but you should decide which ones are important to you and your goals.

For example, I asked myself the following questions:

• How I can help at this company? What are their expectations?
• How fast I can learn there? What is the seniority level of people whom
  I will be working directly with?
• What projects I will be working on? What technologies are they using for what issues?
• What is their average estimation of project development in terms of time? How accurate are these project estimations? How many users use the application?

You can also use multiple strategies to apply for jobs. For example, you can submit applications to a large number of companies to increase your options. In such a case it is a good idea to track your applications (Tab. 2).

Tab. 2 Companies in an interview process

I used to note basic information since I was dealing with a lot of different companies.

But perhaps you are quite picky and you don’t want to apply to a long list of companies.

In that case, first try to gain enough experience in your current position and show evidence of your results. If you don't stand out, large and desirable companies most likely won’t notice your application.

The Interview Process

Many people compare going on job interviews to dating. If you go on a first date after a couple of years away from the dating scene, you probably won’t be very confident. You'll be tense, and the whole date will be unpleasant.

It's the same with job interviews. Schedule your first interviews with companies where you would like to work – and then schedule those where you would love to work.

Also, your interview experience partly depends on the position for which you apply. For salespeople, it might be as big of a deal, since they've developed soft skills over time. It's just about presenting themselves like they've done multiple times before.

But what about developers who feel confident presenting their coding skills, but not at presenting themselves during the personal interview?

It would be unfortunate to realize that you spent half a year improving your technical knowledge, but forgot to practice answering questions such as: “Tell me about yourself.”

In the case of huge companies, it's a great sign if you get to the end of the hiring process – those last rounds of interviews which are mostly conducted in person at the office.

Even if you do not pass the interview, you might manage to set up multiple interviews during a single business trip. At the interviews for other companies, you would usually have to proceed with other steps before the physical interview, but now you can make a good first impression and raise your chances against the other candidates by visiting them.

Dealing with Recruiters

Some recruiters try to force developers to be hired for positions unrelated to their field and needs. They might just spam you just based on your social media profile headings, unfortunately.

But there are also those who actually read your expectations in your cover letter and offer something relevant.

Even if you don't get a job or choose a particular company, it is useful to keep contact with your recruiter. Especially if you decide to change jobs in the future or look for something abroad, you can contact multiple HR specialists and get additional help.

Most likely it won’t cost you anything, and as such you have nothing to lose. Just keep this in mind before deciding not to respond to relevant professional offers.

Getting a Competitive offer

Even if you get a final offer from one company, you still have the prospect of getting more offers from other companies. Have you heard the term competitive offer? In terms of the hiring process, it works as follows:

You complete your interview for a position with another company, where you get a higher salary offer. But it is not your favorite company. So you send the original email with the offer to the company of your choice to see if you can leverage a better salary (or whatever it is you want).

Sometimes this can result in better benefits or more money, and you usually have nothing to lose by sharing this request.

Conclusion

You don't need to commit to working abroad for the rest of your life. Just try it out, and if it doesn't work you can always take a step back. That's why the trial period at work exists.

I've heard many stories, such as "I was scared when I was younger and now I have too many commitments" – so don't miss out.

Now let's summarize the process one more time to see that it's not rocket science.

1. Decide why you want to work abroad
2. Consider the requirements in relation to countries based on length of stay and prioritize them.
3. Find the places where you want to go by comparing the requirements and do deeper research with a focus on laws and restrictions.
4. Prepare for interviews by boosting your soft skills and hard skills.
5. Research companies and apply.
6. Send competitive offers and get what you deserve!

Just keep in mind that this process can take months. During that time you can take some online courses from places like Udemy, Harvard University or Coursera to add to your skillset.

If you need some advice on boosting your learning skills, you can check out my other article about How to Succeed in Your Studies.

If you liked this article, you can check out my other stories here.

Cover photo by Nomadic Julien on Unsplash.

Technical interviews can be extremely daunting. From the beginning of each question to the end, it's important to know what to expect, and to be aware of the areas you might be asked about.

Fortunately, there's a way to prepare for any question that may come your way. It involves four parts:

1. Understand the question
2. Discuss tradeoffs of solutions
3. Write the code
4. Test the code

Let's try this technique with sample problem involving LinkedLists.

The Problem

Question: Given two singly LinkedListNodes, determine if the two lists intersect. Return the intersecting node. Note that the intersection is defined based on reference, not value. If the kth node of the first linked list is the exact same node (by reference) as the jth node of the second linked list, they are intersecting.

Step 1: Understand the question.

It's really important to know exactly what this question is asking. Some questions we could ask the interviewer are:

1. What exactly do we want to return? (A: The intersecting node).
2. Does that mean we can assume the linked lists always intersect? (A: Yes)

It's always important to gain a sense of the question before thinking about the approach to solving.

Step 2: Discuss the tradeoffs of different solutions.

One immediate solution is to traverse both linked lists at the same time until you reach an intersection. For this example, we would make a pointer at nodes 2 and 7, and traverse each of them one-by-one until we reach a common node.

However, as you may have noticed, this will not work as the lengths of the two LinkedLists may differ. What we want to do essentially is “chop off” the beginning part of the longer LinkedListNode, and then iterate repeatedly.

This would be the kind of conversation to have with your interviewer.

Step 3: Write the code.

Below is the method to achieve this.

We make use of helper methods here. We use getKthNode() to get the kth node of the given linked list. This is helpful when traversing the longer linked list to “chop off” extra nodes.

We also use getTailAndSize() which captures both the length and the last node of the given list. This is helpful because we definitely need the size to compare lengths of the lists. We also need the tails because if the tails of the two lists are unequal, then they don’t intersect at all.

Note that when we say “unequal”, we mean that the two nodes do not reference the same object. Even though they may have the same value and look identical, they must reference the same LinkedListNode to count as equal. (You can find more information on this here.)

Going back to the question, if we come across the case where the tails are unequal, we return a failed value (null).

Step 4: Test the code.

Below are some good test cases we can add. A helpful rule of thumb for test cases is the following:

• Empty/null case
• Considering options in the middle/beginning/end
• Sizes equal or different

This strategy doesn't only apply to LinkedList questions – this would work for arrays, Strings, and essentially any other data structure.

For this question, our LinkedList tests would be the following:

• Two linked lists which intersect at the beginning/middle/end
• Both/one linked list is null (should return null)
• Linked lists are the same/different size

We’re done!

More Questions:

• Circular Linked List
• Reversing a Linked List
• Palindrome Linked List

Interested in breaking into Computer Science? Eager to expand your knowledge base and learn new things? Enjoy problem solving?

If so, SWEPrep may be the newsletter for you. Subscribe to get fully explained interview prompts commonly given in engineering interviews, from Arrays to Dynamic Programming. Questions come out weekly and are also categorized by subject and difficulty. The above post is a Guest Post from the author, Sameer Khoja.

Subscribe to get full access to the newsletter. Never miss an update.

I don’t have a Computer Science degree so I had to create my own.

When I graduated from a coding bootcamp five years ago, I was completely unprepared for technical interviews. My coding bootcamp not only spent a brief (less than a few days!) time on algorithms and the coding interview, but I was out sick during that time.

Other candidates applying for the same jobs as I was had four years in school working on their computer science degree. I had three months at a bootcamp where I learned some basic concepts, Rails, and taught myself Angular.js.

Over the past few years, I’ve had to fill the gaps in my knowledge with resources that I could find online and for free. I’ve worked as a Senior Engineer for companies such as Eventbrite and I’ve even written an O’Reilly book. I’m proof that you don’t need a CS degree to succeed as an engineer.

Here’s how I did it.

Introduction To Computer Science

Before you try to dive in with complicated CS classes, I recommend that you start with a course on the basics. This will help give you a solid overview and will also help you to feel a little less intimidated. If you spend some time getting a solid overview, the rest of your free CS degree classes will be so much easier.

My favorite course was CS50: Introduction to Computer Science by Harvard.

This is probably one of my favorite classes of all time. I’ve always loved the idea of Harvard so it was sort of a no brainer for me to take a free computer science class there. I even briefly considered completing one of the Harvard certifications for programming but it was pricey so I stuck with the free CS50 course.

I didn’t end up getting the certificate with Harvard CS50. I thought it would be just as powerful to list the course on my resume. My general rule when it comes to paying for an online certificate is that unless it’s an AWS certificate from Amazon, it’s probably not worth it.

If you feel intimidated starting with a Harvard course (which I did as well!), you can find an easier course online to make you feel more comfortable before you jump into complicated topics.

Computer Science 101 is an introduction to computer science from the very beginning. You’ll learn how the internet works, a little about computer security, what a gigabyte is, some coding knowledge and more.

Algorithms

Get started with Algorithms next. The University of San Diego offers a free course, Data Structures and Algorithms Specialization, that has a tremendous amount of content available.

It’s overwhelming if you look at this entire course and think you need to finish it right away and understand everything. Try focusing on one section at a time and reviewing the concepts regularly.

And if taking a university course on data structures and algorithms makes you a little queasy, you can start small.

Udacity has a free course, Intro to Data Structures and Algorithms. I love taking free courses on Udacity and this one has a ton of great information. You’ll cover arrays, linked lists, stacks, binary search, maps, heaps, and more. This course can give you a great overview which will help you succeed in the more complicated course from the University of San Diego.

If you’re feeling brave after you finish an introductory course, MIT offers a course on Advanced Data Structures.

Operating Systems

Udacity has some pretty cool free content. They offer a class called Introduction to Operating Systems that is from Georgia Tech. This course will walk you through threads, concurrency, distributed systems and more.

I also found out that the book, Operating Systems: Three Easy Pieces, is available online and free. Books like this really helped me feel more confident in talking about concurrency and persistence.

Databases

Databases completely baffled me when I first started out. I tried to avoid working with them as much as possible early on. I asked a senior engineer for help all the time and thought because I didn’t have a CS degree, I shouldn’t be working with a database.

Wow, I was so wrong.

I finally got the courage to work with some backend code, and I loved finding how I could write efficient requests to get data from the backend and writing queries.

Stanford offers a free online course on Databases. And if that’s too intimidating to start with, Udacity offers a free course on databases that will be a lot easier to handle.

Mathematics

When I was contemplating a CS degree in college, everyone told me that I needed to be really good at math. I never got the CS degree, and five years later I haven’t needed to use much math yet.

But mathematics can teach you logic which, in turn, can help you become a better programmer.

Thankfully, MIT offers a Mathematics for Computer Science course for free. Taking a course like Mathematics for Computer Science can also help open you up to more possibilities in tech, like creating your own degree in Machine Learning.

I found out about MIT’s Mathematics for Computer Science course from TeachYourselfCS, which is an awesome website with a ton of resources for learning about computer science.

TeachYourselfCS also suggested a course on Linear Algebra which is available on YouTube. I love free content so I was super happy to find this book on Linear Algebra available online free as well.

So as you can see, you don’t need a CS degree to be an engineer. Some of the smartest engineers I've ever worked with didn't have a CS degree. Sometimes they didn't have any degree at all.

Don't worry if you don't have a degree. You just need to be able to do the job.

I'm writing a book on how you can become a Standout Developer, ace the interview and get a job. Find out more here.