DEV Community: Megan

My very first Hacktoberfest!

Megan — Fri, 16 Oct 2020 22:19:46 +0000

I've been so excited about my first Hacktoberfest! I haven't had the chance to contribute to open source just yet in my career but I've really wanted to. I thought this would be a great opportunity to begin my OSS journey!

I'll continue to update this article with my progress throughout the month 😊

Stay tuned!

180 Days into my Job Search - Reflection

Megan — Fri, 09 Oct 2020 02:15:23 +0000

Wow... I can't believe it's already been 6 months of being on the job search. Given the global pandemic and whatnot, it has definitely not been easy!

But I've been lucky enough to have an internship and a bunch of great interview experiences.

As the end of my 6 months is coming quickly, I just wanted to share my reflections on the last 180 days with anyone going through the same challenges and difficulties of finding a software engineering job during this time.

I've found my #1 most important part of all of this:

Mental health

Along the way I neglected this the most and found that now, 180 days later, it's really come to back to bite me. I pushed through all of the difficult days and kept my eyes on the prize for 6 whole months but now that I've gotten my fair share of rejections and have had time to reflect, I've realized I'm totally burnt out.

I've been working on a project for a potential employer and have had difficulty just staying focused. I had to email them and let them know I wouldn't be done on time, which is something I work my hardest to never let happen. But I had to take this time for myself.

So please don't be like me and make sure to prioritize your mental health first and foremost. It is the most important thing and believe me when I say opportunities will always be there but your sanity won't.

Reach out, reach out, reach out

People swear by referrals, but that didn't actually end up working out that well for me. Surprisingly just reaching out to people really helped me to connect more with the community and just gain great advice from more experienced, senior devs.

I found that hearing about other people's journeys really helped me to put my own into perspective and gave me confidence when approaching interviews and recruiters.

I did however, have a great response rate from direct emails. That is 100% the way to go and I would tell my younger (6 months ago) self that LinkedIn connection requests will not get you anywhere.

I was also prescribed LinkedIn premium and that too did not seem to be worth its weight in $$$ at all. This is just my perspective but in my opinion, for what I was offered (even with just the free trial) it does not nearly justify the price.

Practice makes perfect

Do:

do more projects and continue to work on your skills
learn new technologies and try to stay up to date on exciting new products that interest you

Don't:

forget to look back at old projects and polish up ones that you might want to show to prospective employers
get too discouraged from rejection emails, they're common so just keep your head up!

Stay active

Keep up your social profiles and blog posts just to show that you are a part of the community.

I had a response to one of my emails letting me know that the prospective employer had read one of my blog posts and was reminded of their earlier experiences. Honestly, up until that point I didn't think anyone really paid attention to my blog posts.

But it was a good reminder that it's important to stay active in the community, be it by writing blog posts or just tweeting about what you've been up to. It's good to have a social media presence even if it isn't a huge one.

Thank you

I wanted to say thank you if you've actually been following along with my blog posts in the slightest. I know lately I've written a bunch of reflective blog posts, but I have done so in the hopes that these posts could be helpful to others going through the same things as me!

Just know that if you're still on this journey, we'll get there eventually. And as my old teacher told me, it just takes one! Hopefully you'll get that one soon 😊

Wishing you all the best! ❤️

Getting started with React and styled-components

Megan — Sat, 03 Oct 2020 00:15:16 +0000

Hi everyone!

My friend showed me this awesome website called Frontend Mentor that you can work on CSS projects to boost your CSS skills using predesigned challenges that you try to replicate. I loved the idea given that I have this love/hate relationship with CSS.

I thought I'd give it a go but I also thought I'd try implementing styled-components with React to learn some new skills while boosting my CSS ones.

I used styled-components a bit at my internship, but I never started a React project implementing it. I personally like the thought process behind styled-components and think it is extremely useful in large projects where css components could possibly be reused often.

So if you're interested here is a little tutorial on how to get started using styled-components with React. And if you're even moreeee interested you can see the progress with my challenge so far here.

Step by Step

Create your React app

You can just use good 'ol create-react-app

npx create-react-app my-new-app

Or however you would like to create your React app. You can feel free to use tags or anything you enjoy, I happened to add typescript to mine as I'm trying to get better with that as well.

Install styled-components

I'm a big 'ol fan of yarn, but use whatever you enjoy!

yarn add styled-components

npm i styled-components

Create components

After all of that installation is done, we can jump into the fun part, making the components!

So the way that styled-components works is essentially you will create a named component that can be a variety of structures.

They will be housed within your typical functional or class component and will use their component name to be called on and displayed.

Here is a condensed example of one of my card classes:

import React from 'react';
import styled from 'styled-components';

const Background = styled.div`
  display: grid;
  grid-template-columns: 2fr 1fr 2fr;
  width: 100%;
  border: 1px solid grey;
  margin: auto;
  padding: 50px 20px;
  border-radius: 20px;
  border: 1px solid #f2f2f2;
  box-shadow: 1px 1px 1px 1px #f2f2f2;
`;

class CardOne extends React.Component {
    render() {
        return (
        <Background>
            <LeftImage>
            <RightText>
        </Background>
        )
    }
}

export default CardOne;

You can see from above that within the render and return of the class CardOne, we are displaying our Background component.

And above we have declared Background as a styled.div which is essentially a div that is accessing our styled components. We can use styled to create buttons (styled.button), paragraphs (styled.p), you name it.

And within that declared Background variable, we include all of our CSS inside of our component.

So it's a nice way to break down each portion of what is inside of your divs and you can style them all individually or through their parent.

Get fancy

You can even get super fancy with styled-components and write logic inside of the CSS. For example you could have something like this:

const StyledTextField = styled.input`
  color: ${(props) =>
    props.isEmpty ? "none" : props.active ? "purple" : "blue"};
`;

Thanks for following along and I hope that this tutorial could be helpful for anyone starting out with styled-components. Happy coding y'all!

Resources

styled-components documentation
Gotta have Smashing Magazine's post on using styled-components
Introduction to styled-components by Johnson Ogwuru

The Software Engineer Case Study Interview

Megan — Thu, 24 Sep 2020 18:57:10 +0000

To round out my unofficial series on interviews, I thought I'd finish up with an interesting one that I've encountered recently: the case study interview.

I did a ton of googling on this interview type and wasn't really able to find much that was applicable. I think it's because it's such a weird hybrid of interviews that no one person has really pinpointed it. Which is completely understandable, I didn't really think I would ever encounter this type of interview either!

But for anyone out there who has been told they could expect "to solve a problem in a group" or were explicitly told it was a case study interview, I hope this may be a bit helpful in your preparation.

Overview

From my understanding and small bit of experience, this interview type is very much a hybrid of the systems design interview, a consultant interview, and a technical interview.

I had one interview that was much more high level, a designer, developer, and product manager were all present to consult with and I was expected to design an implementation of an app.

But for the interview that was explicitly labeled as a case study, I was given a prompt and ample time to come up with a solution of how I would solve a specific problem.

These two are very different but boil down to about the same pain points to solve for and similar questions to ask.

Breakdown / Tips

This was the breakdown of my thought process on the question:

Ask clarifying questions
- Ahh, if you've read any of my other interview blog posts, I am 100% confident you would be like "Megan, again with the clarifying questions?!" But I cannot skip over this fundamental step!
- Questions are the foundation of your solution and will help to ensure that you fully understand the question. They will also confirm that you are solving the problem correctly so that your interviews can dispel any confusion you may have or wrong assumptions.
- In the case where I was asked how I would design an app, I asked questions to confirm my assumptions about the users and the scale of the application.
Explain a high level overview of your thoughts
- Now that you are confident you know what the question is asking, give a short overview of what you want the app to look like.
- You can name some of the technologies you would use and how you'd like your front end / back end to be developed.
- You don't have to go into a huge amount of detail, but just give enough so that you have receive a bit of feedback on what your initial thoughts look like. If your interview agrees with your design, then you can go ahead and dig deeper into each portion.
Dive deep!
- Alright, you're on track and pretty much halfway through this! Now is what I think can be the more fun part, really developing each portion of the app.
- You can get very detailed, but in the case of the interview where I was expected to collaborate with the designer as well as the product manager, I tried to keep it more on the surface level and include each person in the thought process. I was able to speak with the designer on generally what the app would look like and how it would be helpful to function for appropriate user interaction (i.e. how certain buttons could be helpful in specific cases, etc.)
- Don't be afraid to just go in on the details and let the interviews know what you're thinking. That is the main function of this interview, to understand your thought process. And I'm sure if they have questions they'll ask!
Big picture
- After building the flesh and bones of this app, I'm sure you've impressed the interviewers already! But it's a good idea to take a step back in the end and confirm that your app is accomplishing all of the tasks you had originally set out for it.
- In the case of the panel interview I had, usually the concerns were always brought back to the user stories. What will help to confirm that the user will receive the items they had originally intended? Did some of the details you went into get in the way of the main goal?
- There could even be an instance where you want to look at the app from the business perspective. How will this be efficient and useful for the business itself? Depending on the company this could be a huge concern.
Know that you did great!
- After all of these interviews it's easy to be overwhelmed, stressed, and to feel like you may not have done that well. But know that you gave it your best and should be proud you even got to this step!
- Also don't forget to thank your interviewer and send them a thank you note within 24 hours of the interview.

Best of luck with interviews and know that I'm rooting for you!

Women Coders Unite!

Megan — Sat, 19 Sep 2020 22:55:51 +0000

I came across this awesome article on LinkedIn about how to be an empowered woman in tech. I found it so inspiring and really wanted to share as well as say a few of my own thoughts on the subject.

Diversity is so important, more now than ever, and women and anyone who identifies as a woman in the engineering community have had a long and difficult journey. I've heard and read horror stories about the way that women have and continue to be treated in this male dominated field.

I just wanted to share some things I've learned and come across in my job search as well as while talking to other women in the industry. I hope my experiences and advice could be helpful to some so that we can empower each other and help to create more diversity in the engineering field!

Everyone goes through feelings of imposter syndrome
- This one was huge for me because honestly I have struggled with imposter syndrome since bootcamp
- But I learned from talking with a lot of other engineers, women & men, that these feelings are totally normal! In our industry it's impossible to know everything and everyone feels like they never know enough. Just as long as you're trying your best and working hard, don't have any doubts in yourself. You're doing great :)
Don't be afraid to reach out to other women in the industry
- When I began doing my initial reach outs for my job search I was able to have some nice coffee chats with many different women in the industry. It was such a breathe of fresh air! I felt like there was always an instant connection just brought about by our shared experiences.
- It's so great to learn and hear from people who were once in your position and an amazing way to just grow your network because in the end we're all just here to help each other.
Find a mentor
- This isn't a must have, but I was able to connect with another woman who agreed to be my mentor and it's just been an amazing experience. Being able to have someone in the industry to guide you in your path is priceless. I've gained so much amazing knowledge and received such helpful tips that I'd recommend this to anyone.
- You can even go on LinkedIn and find a mentor there as they have a matching program. I didn't have the best experience using this but it was a start. I actually met my mentor through the WomenWhoCode slack channel, so make sure to join a bunch of slack channels and discord servers that match your interests. It's a great way to meet people!
Be proud of your journey
- No matter where you are from or what you've experienced, being a minority is never easy and you should be proud of yourself for making it! I am excited for the future as so much progress is being made, but never forget how hard you've worked to come so far. You are amazing!

Thanks for reading this and I hope it could be helpful for anyone out there. If you have any tips for other women and anyone who identifies as a woman, please leave them below. We definitely always have to look out for each and keep our community strong!

My First Internship Experience

Megan — Fri, 11 Sep 2020 21:55:08 +0000

I have officially completed my internship! Wow, what a rollercoaster it has been!

I honestly had an amazing experience and was able to learn so much from working at a small startup in the Bay Area.

I'm so grateful for the experience, especially during a time like this. And I feel that it's given me an awesome start to my software engineering career.

I thought I'd share my experience with you but also some tips I would have given myself pre-internship if I had known.

Tips:

First off and most importantly, be kind to yourself! I found myself being very hard on myself sometimes for not knowing everything right off the bat and needing to ask for help pretty often.
- I ended up having to use a bunch of technologies that I had no previous experience with. And it was definitely a huge learning curve. So be gentle with yourself and try to take it one step at a time.
- After numerous talks with other software engineers at different points in their careers, there is one thing I am certain of, everyone struggles! Know that people are going through the same difficulties as you and we're always all learning together.
That being said, don't be afraid to ask for help!
- I found myself often not wanting to bother my manager, but I also found that struggling in my lonesome was not productive at all. Know that people are often sooooo willing to help and it's totally okay to ask for help!
Communication is key
- Working fully remote was completely new to me, and I think it brings with it it's own set of difficulties. But one thing I found especially important, as with any position, is communication!
- Especially being remote, it's not easy for people to gauge where your productivity or progress is at. I made an effort to check in with my manager at the end of the day just to say what I'd gotten done for the day. I think this is the minimum and I could have been more open in my communication, which is something I'll be more aware of for my next position.
- But I do think it's especially important to let people know if you are having trouble or can't meet a deadline. Always try your best to communicate with your team and manager to ensure everyone is on the same page.
Double check your code before submitting PRs
- In the beginning of my internship I had never made a pull request before and wasn't really sure of what I was doing. I ended up just pushing my code like I used to do on my own projects. Full of debugging console.logs and messy code.
- After a few code reviews I realized it wasn't very professional of me to submit my code looking the way that it did while in development. So by the end of my internship I would double check all of my code and ensure it as bug free and dry as possible.
Try to soak up all of the information you can
- Especially being my first internship, I thought it was so important to try to gain all of the information I could. I mean you will always be continuously learning in this profession, but I wanted to make sure that I'd be a stronger programmer than when I started. After all, the point is to learn more!
Have fun!
- Work isn't always going to be fun, but make the best of it and know that you're off to a great start to your new career! And of course be proud of yourself for working hard and getting as far as you have.

Thanks so much for reading! I'm really excited to have been able to share this with all of you and I hope it could be helpful for anyone starting their new internships.

Excited for the next chapter and I hope you all have an awesome weekend and stay safe!

The System Design Interview (for beginners)

Megan — Wed, 02 Sep 2020 22:16:07 +0000

Honestly, when I first heard that system design was a part of many technical interview processes, I thought "isn't leetcode enough!?" And so, naturally, I put off studying for it as long as I could. But when push came to shove and I had to do a deeper dive into what is really being asked in these interviews, I realized it makes sense why this concept is so important.

These kinds of system design or architecture questions in interviews are just there to see your thought process. And as important as it is to see how you tackle problems on an algorithmic scale, it's just as important to see how you handle situations at a higher level.

That's just my two cents on system design interviews, but I thought I'd share a bit of my research with all of you. I recently had an interview that I felt pretty good about and I wanted to share the process in hopes that it could be helpful.

Introduction

From a quick google of "systems design interview questions" or "system architecture interview questions" you can find that there isn't just one rule of thumb for what to study. It's not as simple as "hey, do 100 leetcode problems and you're golden!". The interview is much less structured and much more open ended, which can be some of the difficulty.

You can get a nice idea of what to expect from googling these questions or watching a few youtube videos (I've included a few helpful ones below) but I'll break down how my interview went and my thought process.

Another interesting part about this type of interview is that you most likely won't be coding that much. There could be a bit to explain high-level what you're thinking or what your functions would do, but it wouldn't be anything nearly as detailed as an algorithmic question.

Note: quick note that this is just from my beginner standpoint and definitely not for mid-senior level positions. My understanding is that system design interviews for these levels are much more involved and require a ton more detail.

The Interview Guide

Now that that's out of the way, let's dive into my guide for the system design interview:

Fully understand the problem and what you can do to solve it
- It's a good idea to take a minute in the beginning to ask your clarifying questions and just ensure that you fully understand the problem that needs to be solved. Some good questions to ask yourself or the interviewer would be:
  - Will this need to be a full web app or just an API?
  - How can this product help solve users problems / what are they getting out of it?
  - How many people would be using this app?
  - How will the app or API be used?
- Note: Don't get too detailed right in the beginning as that could make it difficult to see the bigger picture. Keep it very general at the start and you can build more detail as you go along.
Scope and scalability
- Now that you have a good idea of what problem you're trying to solve, you should make a note of the scope and scalability of the app or API.
- You may have touched on this in the clarifying questions, but here you could start to imagine if thousands of users would be accessing this app all at once that could be a huge strain on one server. Whereas this could be an internal company tool that is only touched by a few people a day.
- You don't have to make any definitive choices now like "we will absolutely need 15 servers!", but as long as you have in the back of your mind a general idea of how this could scale later on, that's great.
Create a template for your general structure
- With all of this information, you should be able to make a very, very broad sketch of what your app or API would look like.
- Say you're making a cookbook app where you'd want to be able to create recipe cards and see all of your respective recipes as well as other people's. You'd most likely need a full app with a front end where users can add and view their cards as well as a backend with a database to hold the information about the recipes.
- You can be very creative at this point with how you would like to create your app or API, but just make sure you have a good reason for why you'd choose what you do.
Dive a little deeper!
- Awesome, you have your general structure set up! Now you can get a bit deeper into those details we talked about earlier. You can choose what you'd prefer to talk more about, but make sure that you are able to add a bit of detail to each part of the app or API.
- Front end: Here you could discuss what your pages would look like and how a user would access it. It could be nice to talk a little about authentication too if you feel it is necessary. You can also mention how the front end would communicate with the backend (REST style, etc.).
- Back end: I actually didn't spend very much time on the backend but I did mention what frameworks I might use and briefly explained why.
- Database design: A large portion of my interview was used to discuss the database schema. I actually had to write out the basic design of my tables and a few SQL queries. So I would recommend brushing up on SQL just in case that comes up.
Revisit scaling
- Now that you've really added a lot of detail to your app or API, it's a good time to revisit the scaling ideas we put off earlier.
- If your app or API is going to have a lot of activity like reads or writes in the front end, you may want to add a load balancer to handle all of your server requests. Here is a quick, helpful diagram for what a load balancer can do:

If you know that one of your servers is going to have a ton of requests, maybe hundreds of times more than your other servers, you may want to think about caching and how that could help. Or even think about splitting up what that specific server is handling or scaling that server by adding more power to it.
- Caching is helpful in that it allows more frequently accessed information to be stored and referenced more quickly than spinning up the database every time a request is made.

Tips

Remember that it is an open discussion!
- Initially I was a little hesitant to ask questions, but my interviewer was very helpful and we would discuss the pros and cons of different ideas I would bring up. It's nice because there really aren't any wrong answers, a lot of it is a matter of preference.
There are so many parts to this type of interview, don't feel like you have to know everything and be honest about what you do/don't know
- I think especially from a beginner perspective, it's amazing to know about all of these tools, but it's also okay to say what you don't know. Sometimes the interviewer will be nice enough to explain to you what something can do or help you think of different tools to use for a particular problem.

Resources:

The System Design Cheat Sheet
SQL Interview Cheat Sheet
Beginner's guide to scaling systems
Not a huge fan of TechLead but I did think this video was helpful
How to Succeed in a System Design Interview

Best of luck with your interviews! Please let me know below about your interview experiences and any tips you'd add 😊

What is memoization?

Megan — Tue, 25 Aug 2020 22:05:09 +0000

Stumbling my way through leetcode, I came across a problem in which most solutions implemented memoization. I tried my usual iterative techniques to no avail, and was very curious about this "memo" I kept seeing.

So what is memoization?

Not to get it confused with memorization, a completely different topic that usually doesn't have any place in programming (although, the name is based on memorization!).

Memoization is the technique of storing computed values for quick access in order to speed up slower functions. It is essentially like caching so these stored values won't have to be calculated multiple times.

Here is the wikipedia definition for more clarity:

In computing, memoization is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.

Memoization is almost exclusively used with recursion or dynamic programming as a way to significantly decrease the run time of a recursive function. Although dynamic programming doesn't have to include memoization, fairly often they are used synonymously.

Code example

I saw this great example using the Fibonacci sequence so I thought I'd replicate it as I found it incredible for basic understanding.

If you're not familiar with the Fibonacci sequence, it is essentially the sum of the two integers before it in the sequence. It begins with 1 and 1 and continues on from there forever. The first 10 iterations would look like this:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55

So this first example is our regular recursive solution for the problem:

def fibonacci(n)
    if n == 1 || n == 2
        result = 1
    else
        result = fibonacci(n-1) + fibonacci(n-2)
    end
    return result
end

If we were to solve this problem with memoization all we'd need to do is create a memo array and store each of the solutions we get from all of our different iterations of n.

def fibonacci(n, memo)
    if memo[n] != nil
        return memo[n]
    end

    if n == 1 || n == 2
        result = 1
    else
        result = fibonacci(n-1, memo) + fibonacci(n-2, memo)
        memo[n] = result
    end
    return result
end

You can see that we added an if statement at the beginning to check if we already have our result for n. If it is saved in our memo array then it's as easy as accessing that index.

Similarly, if we haven't seen the value before we will compute it and then save it into our memo array in the end.

Time complexity

You can imagine that using memoization would have a huge effect on the efficiency of this function. That's really the main benefit anyway! By storing all of our calculated values and avoiding repeat computations, we can reduce the average time complexity from O(n²) to O(n).

Resources

I actually got the code example from this amazing youtube video so please check it out! YK does such an amazing job of explaining the concept I would definitely recommend watching it if dynamic programming is new to you.

I also found this article super helpful and thought it breaks down memoization into something more digestible.

That's all I've got for today but I hope this explanation could be helpful to you! As always, please leave comments with your thoughts 😊

If at first you don't succeed, try, trie again

Megan — Sat, 22 Aug 2020 18:50:01 +0000

My apologies in advance, that title came to me and I just had to make this post. Plus I feel like it's been pretty applicable to my life recently 😂

Anyhow! As my studies continue, I wanted to do a little introduction to tries!

What is a trie?

Apparently a trie is a relatively new computer programming concept, aimed to solve a problem with the time and space complexity of trees.

It is used mainly for alphabetical characters and stores them in a tree like structure for easy traversal to create word or patterns. The trie starts with an empty root node which is connected or linked to a node for every single letter in the alphabet.

note: that means depending on the alphabet you're using, it could be over 50 different nodes!

The node itself holds a value and one or more references to other nodes in sequence.

Big O

The time complexity of tries are O(n) on average, worst case being that the entire word is present in your trie and you cannot simply return false upon a few traversals. But in best case, that we are only searching for one letter perhaps, the time complexity would be O(1).

For the space complexity, tries really are just strings for the most part and would not take up more than O(n) space even to create new nodes for each letter. Again, in a similar case where our string is just one letter it would be best case O(1).

Code Example

So I think that rubyguides actually has an awesome example and I'll replicate it here for everyone. But I'll write out the functions in a way that is a bit more understandable for me.

First we will initialize our node class which will have a value, a next array to contain all of the references, and a word value to indicate if we have found/completed the word we are looking for.

class Node
  attr_reader   :value, :next
  attr_accessor :word
  def initialize(value)
    @value = value
    @word  = false
    @next  = []
  end

Next we have our trie class, which has a few different methods. One to add a character into the trie which will either try to find the character if it already exists or add it. Another method that only finds the character if it exists. And lastly a method to simply add a node to the trie.

class Trie
  def initialize
    @root = Node.new("*")
  end

  def add_character(character, trie)
    trie.each do |node|
      if node.value == character
        return node
      end
    end
    add_node(character, trie)
  end

  def find_character(character, trie)
    trie.each do |node|
      if node.value == character
        return node
      end
    end
  end

  def add_node(character, trie)
    new_node = Node.new(character)
    trie.push(new_node)
  end
end

Now that we've established our node and trie classes, we can get to making the methods that will actually make use of our trie!

def add_word(word)
  base = @root
  word.each_char do |letter|
    base = add_character(letter, base.next)
    base.word = true
  end
end

def find_word(word)
  base = @root
  word_found =
  word.each_char.all? { |letter| base = find_character(letter, base.next) 
  }
  yield word_found, base if block_given?
  base
end

The add_word method is very clear in that we are looping through the word and adding characters to create that word. The second method for find_word I didn't modify as much as I found that the all? method was difficult to simplify. It effectively finds out if the case is true for each of the letters then it will return true. If it finds any matches it will return those via yield.

Resources

Found some great resources to aid in your learning of tries:

Thanks for reading and have an awesome weekend everyone!

My First Technical Interview Experience + Tips!

Megan — Thu, 13 Aug 2020 18:04:28 +0000

Hi everyone! I was so excited to land my first technical interview with a large company that I thought it'd be super cool to share my experience with all of you!

Honestly, I've been dreading the technical interview for a while. I've been studying data structures and algorithms as much as I can (as you know, I feel like data structures are all I really post about! haha) but I still haven't felt truly prepared for a real interview.

I also do mock interviews with some of my old classmates from Flatiron School which is sooo helpful and I could not recommend that more. Being able to simulate an actual interview, even if we are more comfortable with each other than we would be with strangers, is still extremely useful and good preparation.

But on to the actual interview!

It ended up being very casual and was half work-style questions and half technical. The question was meant to just test my thinking and problem solving abilities and ended up being a leetcode easy question.

I ended up actually solving the wrong problem, which the interviewer told me after finishing my solution 😂 But it was a good lesson to learn and after clarifying I was able to come up with a correct solution to the actual problem.

The interviewer was very nice and told me I could ask for tips and he could give me hints, but I was a bit too nervous and just debugged most of the problems myself. I did not get the chance to run the code but he had specified that I wouldn't be able to.

I used the technique that has been outlined by many others online and I find to be an awesome way to approach problems:

Ask clarifying questions
- Honestly I feel like this step is half so that I can ensure I am fully understanding what the question is asking (because that's super important!) and half buying myself time to think of a solution.
Think of good edge cases and ask for multiple examples
- If you can, edge cases are a great to start before you begin coding and they're pretty important. It's okay if you don't come up with any right away, but it's good to keep in mind throughout the coding process.
- Also it's just my personal preference, but I like to ask for multiple examples because I feel like it helps further my understanding of what the question is asking. Totally optional though!
Take some time to fully think of solutions and get ready to discuss the best one you can come up with. I always felt awkward before being very quiet during this time, but if you just ask the interview for a minute to think, they usually don't mind.
Discuss your solution with the interviewer and write some pseudocode
- Now that you've thought of your solution (don't worry if it's not the most optimal), describe your thought process and step by step go through how you would solve the problem. You can ask the interviewer what they think of your solution and they will either have feedback or tell you to proceed.
- I find it is also helpful to write out (commented out of course) the process you have thought of. This step tends to be preference as well, but I've yet to think of a time when it wouldn't be beneficial to have your thought process actually written down. In the instance that you don't get to finish solving a problem, at least anyone who sees your solution will be able to read what you were thinking and hopefully understand how you would have finished the problem.
Get to coding!
- Alright, now that you fully understand the problem, thought of all the edge cases, came up with a good solution, and wrote down your pseudocode... you're ready to actually code! Do your best to stick to your solution and if any issues arise, go ahead and bring them up with your interviewer.
- Depending on the interviewer they may offer tips or help you understand where you're going wrong. Even if they stay silent and allow you to struggle on your own, don't worry, just stay calm and debug as much as you can.
- You got this!
Unstuck yourself if necessary
- Personally, my nerves tend to get the best of me. And in my interview I couldn't get my last loop to return the correct output. I knew what I needed but was getting lost in debugging one line.
- So I took a breath and started back at the top of where my problem began. For me, breaking down the problem into small pieces and putting print statements where I don't understand outputs is super helpful and weirdly calming.
- You know what works best for you, but if you do get stuck don't worry and just take it step by step until you can find where the bug is that's breaking your code.
Testing
- Sometimes your interviewer will allow you to run the code (which is awesome!), but if they don't, that's okay too. Just make sure with them first before you try running anything.
- In the case that you can't run it, go through the code step by step with one of the examples, ensuring that the outcome is what you expect. I honestly prefer this just because I find I catch the most bugs this way.
Space & time complexity
- My first interviewer didn't ask me for anything pertaining to big O, probably because it was just a skill check. But my second interviewer (more on that next time!) did, so of course be sure to know how to calculate that. I have a handy space complexity blog post if you need a little refresher.
You did it!
- You made it to the end of your technical interview! Congrats :) Whether you struggled the whole time or it was a walk in the park, I think either is a good learning experience and every interview will make you better.

Thanks for reading and if you have any technical interview advice to share, please do! It'd be awesome to hear your technical interview experiences and stories as well.

Regular Expressions Crash Course

Megan — Wed, 05 Aug 2020 18:25:48 +0000

Hi all! I came across a regular expression problem in a hackerrank and was completely stumped. I didn't think regular expressions were a common interview question, but I did realize how useful they could be. So I thought I'd post a little crash course on regular expression in hopes of helping others.

Okay okay, so first off... what are regular expressions?

"Regular expressions or RegEx is a sequence of characters that define a search pattern, mainly for use in pattern matching with strings, or string matching, i.e. “find and replace”-like operations."
GeeksForGeeks via Wikipedia

Basically, you can create a combination of characters (because regex uses a lot of symbols) to match exactly to a string you would be looking for.

A good example and what it is commonly used for is pattern matching in emails. That happened to be a part of the question I received as well.

It makes sense if you're going over hundreds or thousands or hundreds of thousands of emails that you wouldn't or couldn't feasibly look through each one one at a time. Enter... regular expressions!

Now given this is just a crash course, I will only go over a few basic examples so this definitely isn't all there is to know about regular expressions. But you will be able to use this information to build up your regex knowledge!

I think it is easiest to learn at first if you use a nice regular expression compiler like Regex 101 or Regexr. You can test your pattern very easily with these websites.

If you mosey on over to one of those sites you will notice that regular expressions have a fairly common setup across the board.

The strings will begin and end with a forward slash followed up a string, for example:

/ (put your regular expressions in here!) /g

The string at the end denotes the different flags for how your regex get interpreted:

Letter(s)	What it stands for	What it does
g	global	searches through the entire string, not just for the first match it finds
i	case insensitive	will search for the text whether it is capitalized or not
m	multiline	used with start and end denotations
s	single line / dotall	will match any character (used with .)

There are more flags than this available (and sometimes denoted by different letters), but for our purposes I didn't include them as they are more advanced than what we will go over. For now we will stick with g so we know that our entire input will be evaluated.

Alright, now that you have somewhere to put your regex and know how it's structured... let's get to creating!

Letters and Numbers

Longhand

If you want to denote a range of characters or numbers, you can do so uses these:

characters	what they do
[a-z]	lowercase range from a-z
[A-Z]	uppercase range from a-z
[0-9]	range of digits from 0-9

So for instance, if our input text to test over is:

"How now brown cow"

Our regular expression:

/[a-z]/g

would find all of the letters except for the capital H.

Shorthand

characters	equivalent	what they do
\w	[0-9a-zA-Z_]	includes all letters (case insensitive) and digits
\d	[0-9]	range of digits from 0-9
\s	-	white space (tabs, regular space, newline)

These are also very straightforward, but if we continue with our previous text example, our regular expression could be:

//w/g

and it would find all of the letters, including the capital H this time.

NOT Containing

These are similar to the above and you can see that if you capitalize the letter in these shorthand versions, it changes the meaning to NOT including certain characters in the string:

characters	equivalent	what they do
\W	![0-9a-zA-Z_]	does NOT includes all letters (case insensitive) and digits
\D	![0-9]	does NOT range of digits from 0-9
\S	-	does NOT include white space (tabs, regular space, newline)

Continuing with our example from above, using the regular expression:

/\W/g

it would not return any matches for letters or digits, but it would return matches for the spaces in between the letters.

Modifiers

Now that we've taken care of the characters, what if we wanted them in a specific order? Here is where modifiers come in to play:

characters	what they do
.	matches everything but new lines
\|	used to separate different strings
\.\	literal period if needed (escaping)
*	0 or more of that character
+	1 or more of that character
?	only 0 or 1 of that character (optional)
{m, n}	between m and n (m and n being integers) of that character

There are also two more important special characters to be aware of: the ^ denotes the beginning of a regular expression and the $ denotes the end of a regular expression. Keep these in mind for the examples below!

Examples

Of course we need some helpful examples!

IP address validator

/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/

This one is great, very straightforward and uses all of the shortcuts we just learned! As I'm sure you are familiar with IP addresses, this example just checks that each set of digits between the periods are actually digits.

Email address validator

/^\S+@\S+\.\S+$/

I wanted to be sure to include this one as regular expressions are often used for email address validation. This is a very simple example of an email address, but as you can tell it checks that there aren't any spaces and that the string includes only one @ and one period.

Resources

As usual, I'd like to include some extra resources I found very helpful:

Thanks so much for taking the time to read this! I hope that it could be helpful for you. And as always please feel free to leave comments or corrections. Have an awesome week!

Sass vs Less: Which do you prefer?

Megan — Thu, 30 Jul 2020 20:10:27 +0000

So I guess I'm sort of obsessed with these poll-like opinion based posts lately, but I love hearing what the Dev community's take is on so many subjects! This week I wanted to talk about CSS - a "language" that I love completely and have such deep hatred for all at the same time.

This isn't a new debate, that's for sure, but I've mostly used vanilla CSS my whole life and was very interested in this preprocessor debate.

If you're new to CSS or the idea of preprocessors here are the formal web definitions of each:

CSS

MDN:

Cascading Style Sheets (CSS) is a stylesheet language used to describe the presentation of a document written in HTML or XML (including XML dialects such as SVG, MathML or XHTML). CSS describes how elements should be rendered on screen, on paper, in speech, or on other media.

Sass

Wikipedia:

Sass (short for syntactically awesome style sheets) is a preprocessor scripting language that is interpreted or compiled into Cascading Style Sheets (CSS). SassScript is the scripting language itself.

Sass documentation:

Sass lets you use features that don't exist in CSS yet like variables, nesting, mixins, inheritance and other nifty goodies that make writing CSS fun again.

Less

Wikipedia:

Less (which stands for Leaner Style Sheets) is a backwards-compatible language extension for CSS. This is the official documentation for Less, the language and Less.js, the JavaScript tool that converts your Less styles to CSS styles.

Less documentation:

Less only makes a few convenient additions to the CSS language, which is one of the reasons it can be learned so quickly.

Now that you have some context, here is my usual data table with comparisons. I scoured the internet for other people's opinions and have compiled them below:

	Regular ol' CSS	Sass	Less
Setup	Ready out of the box styling	Setup required to ensure that code compiles before rendering	Setup required to ensure that code compiles before rendering
Use of Compiler	Not necessary	Needs compiler	Needs compiler
Use of Variables	Not capable	Can use variables	Can use variables
Documentation	Standard documentation with LOTS of information online	More frequently updated repo with less issues and PRs than Less	More issues and PRs than Sass repo
Integration	Great for smaller projects, becomes excessive in larger projects	Helpful for larger projects for cleaner, dryer code	Helpful for larger projects for cleaner, dryer code

It's also good to keep in mind that CSS is always updating as well, and there have been some great new features added recently. Some that can even rival some of the benefits that could only be gained before by using a preprocessor.

But what do you think? If you've used either of these in the past, which do you think is better? And if not are you interested in either of them or preprocessors at all? Or is CSS on it's on plenty enough to deal with as it is?

Excited to hear all of your opinions and hope you all have a great rest of your week! 😊