DEV Community: Tori Crawford

Productivity in Working Parents

Tori Crawford — Tue, 09 May 2023 19:36:11 +0000

It is 2023 but, unfortunately, we continue to live in a world where there are still stigmas surrounding working parents. An example of one of those stigmas is that once an employee becomes a parent they become less committed to their job and therefor less productive. This specific stigma is one that I am going to discuss today, because I do not believe that becoming a parent makes you less productive. Sure, you may need to work more flexible hours in order to work around school/daycare drop offs or extracurricular activities but working flexible hours does not have a direct correlation to a decrease in work productivity.

Spoiler alert: if you read the article cited above you will discover that flexible work hours actually increases productivity and it is not only working parents who want flexible hours.

According to one study, parents were more productive than their childless peers. The study states that "mothers of at least two children, are, on average, more productive than mothers of only one child, and mothers in general are more productive than childless women." The study saw similar results for fathers of at least two children, but there was a slight difference in productivity in relation to childless men and fathers with one child. The study concluded that childless men and fathers of one child saw similar levels of productivity, but "toward the end of their careers, however, childless men appear to be somewhat more productive than fathers of one child."

Why are parents more productive?

There are multiple studies that have attributed the following factors as reasons why parents are more productive. Parents

are great multi-taskers
are empathetic
develop better time management skills
are "more likely to be in touch with the world and willing to research things"

From my own personal experience since becoming a mother, I know every single one of those factors listed above applies to me. I have become a much better multi-tasker, despite having thought I was great at it before parenthood. I have always considered myself an empathetic individual, but since becoming a mother I have found that my increasing ability to have more patience (especially with a 2 year old) has coupled beautifully with my empathy. Lastly, my time management skills have also increased exponentially because my ability to prioritize and actually sticking to set time boxes has gotten stronger.

Moving Forward

It is important to note that these stigmas and biases are not always intentional. They may be unconscious biases that people are not even aware that they are holding onto. The first step is recognizing that you may have these opinions or beliefs about working parents and doing your own research to discover if you are correct or not. I have provided many different studies and articles at the bottom of this post that could be useful, but I highly encourage everyone to do a bit of research on their own.

While individuals can make a difference, employers and companies also have to acknowledge and actively fight these stigmas and biases by implementing trainings and creating work environments that are safe for every single one of their employees.

Layoffs: It’s Okay to Not Be Okay

Tori Crawford — Tue, 17 Jan 2023 22:28:14 +0000

Layoffs. It’s a word we are all becoming very acquainted with here in the tech world—more for some than for others. Whether you survive a round of layoffs or become another one of the thousands of people laid off, they affect everyone. In my short 3.5 years in the tech industry, I have gone through 4 rounds of layoffs. I survived the first 3 and was unfortunately laid off in the most recent round.

There are many feelings to be spoken about on both sides: surviving a layoff and being laid off. One can lose their sense of safety and, depending upon how the company handled the layoffs, there could be a lot of anger, resentment, mistrust, etc. When you survive a layoff there could also be a layer of survivor's guilt that can strike many people. It hit me very hard the 3rd round of layoffs I had experienced. I had only been at the company for a week and a half. I thought for sure I’d be an easy target to lay off, but no, two of my teammates who had been at the company for a while were laid off. The big thought in my mind for weeks following was “Why not me?”.

Fast forward about 8 months and my company announced another round of layoffs and unfortunately, I was one of those affected. The first thing that crossed my mind was needing to pass along all of my knowledge on the current projects to my teammates, which I did. Then I cried and I cried A TON.

I cried because I was losing the best team I had ever worked on. I cried because I was losing the best lead engineer I had ever worked with. I cried because I was losing some of the best senior and staff engineers I’d worked with because they taught me SO MUCH with tons of patience. I cried because I was losing my mentor. I cried because I was losing the first manager who ever showed interest in helping me progress my career to the next level. I lost more than just a job, a paycheck. I cried because I had lost all of those things I have just mentioned.

This post does not truly have a purpose other than for me to express my thoughts/grief and to let everyone else who has been laid off know that what they are feeling is completely okay and normal. Don’t beat yourself up. Don’t search for those “why’s” because you’ll likely never get closure. Try to accept your new reality and work through the grieving process. You got this.

Note: The cover image for this blog post is brought to you from a hike in Great Smoky Mountains National Park in July 2022.

How Do You Decide It Is Time to Move On?

Tori Crawford — Wed, 06 Jul 2022 19:39:54 +0000

It is not always easy to know when it is the right time to move on from your current role. For me it was honestly really hard.

The decision to start interviewing again happened kind of organically for me. I had a FAANG recruiter reach out to me out of the blue and I decided it wouldn't hurt to just interview in order to gain the experience. It wasn't until I was denied after the technical interview that I got bit by the curiosity bug. I started wondering what it may be like working for another company, on a different product, in a different industry. This is when I really started to contemplate whether it was time for me to move on.

I can honestly say that the decision to leave the company I worked for and dive into another job search was not an easy one for me for many reasons.

I genuinely liked my coworkers.
I had a rough initial job search when looking for my first role (feel free to checkout my many other posts about that job search).
Interviewing just makes me incredibly anxious and I honestly think it always will no matter the years of experience I have under my belt.

Despite all of these reasons, I decided it was time to start interviewing again because I sat down and asked myself the hard questions. Is there possibility for promotion at my current role? How likely, if so? Am I feeling fulfilled? Am I feeling challenged still? Do the company's values still align with my own? Is my manager helping me progress professionally? etc.

I ultimately listened to myself and my instincts and did what was best for me.

How do y'all decide it is time to move on from your current role and start interviewing again?

Despite Loss, Tori Coded

Tori Crawford — Tue, 09 Mar 2021 01:50:56 +0000

TW: miscarriage

It has been quite the year for me since International Women’s Day last year. I landed my first software engineering role at an amazing company. I got married. I got pregnant, twice. I experienced loss. I moved to a new state and, like everyone else, I have had to navigate living through a global pandemic. It has been a roller coaster of a year, to say the least.

Prior to losing my great grandfather to COVID and having a miscarriage, I was creating a lot of content here on DEV but have been unable to find the motivation to do so since my world kind of turned upside down. I honestly did not know if I would even muster up the energy to write this post, but this is something I have done every year since I started my journey into tech and I did not want to tarnish that, so...

Here I am to say that despite everything that has happened over the last year, I have continued coding. I continue to strive to gain as much knowledge and experience as I can in everything that I do. I choose to make the most of every situation. I continue to be vocal about my pain and loss in order to help comfort anyone who has to go through a similar experience. Last but not least, I continue to feel incredibly grateful to have ended up at a company where I feel valued and safe as a woman engineer.

Feel free to check out my FireHydrant spotlight for International Women's Day where I answer a few questions such as important lessons I have learned and advice that I have for women wanting to break into tech.

Note: This post's cover image comes to you from Static Peak hike in Grand Teton National Park, Wyoming.

444 Days Later, Tori Hit the Jackpot

Tori Crawford — Thu, 16 Jul 2020 02:12:50 +0000

If you've been following me for a while, you know that I had been searching for a job for quite some time, 444 days to be exact. Thankfully, I have some fantastic news to share with y'all. I started working for FireHydrant as a software engineer a couple of weeks ago. It has been such a great experience so far and I've grown to accept that the long, crazy roller coaster ride that was my job search has been worth every second of it.

Throughout this chaotic job search, I was open and vulnerable with every one of you. Y'all got to experience the many highs and the many lows with me and, because of that, you were some of my biggest supporters. There were many days that the positivity and kind words y'all shared with me are what kept me chugging along and I can't thank you enough for that.

Once again, I find myself here wanting to be open and vulnerable with you. Why? It's because I don't ever want anyone to feel alone. There were many times that I felt alone during my job search, because I rarely, if ever, found anyone who had been searching for their breakout role as long as I had been.

Due to this, I want to keep it real and provide you with the rough numbers of applications submitted, interviews completed, and rejections received during the entirety of my long 444 day job search. Ultimately, I want people, like my past self, to know that all of our careers and lives progress at different speeds and that that is okay.

The Numbers

Applications

Over the 444 days of my job search I submitted roughly 430 applications. Before anyone freaks out over that being an outrageous amount, let me break it down for you. I submitted just under 30 applications a month. My goal every week was to send out between 5 and 7 quality applications, which was totally manageable for me and gave me plenty of time left over to build projects, learn new skills, write blog posts, network, and contribute to open source. Oh, and to interview!

Interviews

Overall

In total, I prepared for and completed roughly 53 interviews.

First Round Interviews

Over the course of my job search, I had around 29 first round interviews.

Technical Interviews

I endured 20 technical interviews.

Quick Note: In this category, I included all code challenges, technical screens, and take-home assignments.

Final Rounds

I had the pleasure of making it to and completing 5 final round interviews.

Rejections

The total number of rejections that I received over the entirety of my job search was 143.

Side Note: Rejection was my least favorite aspect of the job search. It took a long time for me to accept that rejections are not personal and should not be taken to heart. Lots of tears were shed over this that I wish I could have back, but, like I said earlier, it was all worth it in the end.

No Responses

I had roughly 233 applications that went into the abyss to never be heard from again.

Offers

Of the 5 final round interviews that I had, I received 3 offers. The first offer was to be a software engineering coach at the bootcamp that I completed. The next one was rescinded due to COVID. The last offer that I received was to work at FireHydrant as a software engineer that I gladly and excitedly accepted on June 11, 2020.

Takeaways

Now that we've made our way through those numbers, I wanted to take a moment to discuss a few of the greatest takeaways from this job searching experience for me.

Do not take rejections too personally. This should help you maintain your morale and mental health.
Network. Network. Network.
Ask people who know you and your work to refer you. This will decrease the number of applications you have go into the abyss, I promise.
Take breaks. Interviewing is exhausting on your mental, physical, and emotional health. Give yourself days off every now and then. Allow yourself to disconnect and recharge.
Don't be afraid to ask for help. There are so many great communities out there in the tech world with engineers that are willing and excited to help. You're in one right now as you read this article (hint: DEV).
Be patient and understanding with yourself.
Continue learning and, if you can, learn in public. Write a blog post, tweet, record a video, live code online, etc..

Hopefully at least one of these takeaways is useful to you! If you are someone who has been searching for your first role for quite some time now, please know that you are not alone and that you will find that role.

Everything that led up to me working at FireHydrant has helped me become who I am today and I am incredibly proud of that person. It is my hope that you'll get to say that one day as well.

Note: The cover image for this blog post is brought to you from a hike at Caslte Rock State Park in California that I did this past weekend.

Data Structures From Scratch: Array

Tori Crawford — Thu, 11 Jun 2020 16:16:23 +0000

As many of you know, I have been searching for my first dev role for quite some time now. It took me completing quite a few technical interviews over the span of 6 or 7 months to narrow down what I thought was the main reason I wasn’t successfully making it past the technical interview round. I realized my weakness was my lack of knowledge in data structures outside of an array and a hash, as well as my unfamiliarity of some pretty important CS principles such as Big O Notation. Once realizing my weaknesses, I sought out to strengthen them so that I could

better increase my chances of landing my first role
become a better and more well rounded dev

In December of 2019, I enrolled in Andrei Neagoie's course Mastering the Coding Interview: Data Structures + Algorithms. I still haven’t managed to complete the entire course just yet, but I have had the opportunity to make my way through the Big O section as well as the entirety of the course’s data structures portion. While working through this course, I learned how to code data structures from scratch in JavaScript which inspired me to create this blog series.

With this blog series, I will be writing tutorials on how to create some of the more popular data structures from scratch in, my favorite programming language, Ruby. This is the first installment in this series and I figured we’d cover one of the more basic data structures (and one of the very first I ever learned), arrays. Let’s dive on in and get started!

Create the Class

The first step in the process of creating an array from scratch is to create the class, so let's get that done.

class MyArray
end

Awesome! Now let's move on to the next step.

Initialize the Class

The next step is to initialize our class. Before doing this, we need to think about what variables should be included in every instance of an array. One thing we know that is kept track of in regards to arrays is the amount of elements within the array, also known as the length of the array. We will implement an attr_reader for the length so that we can access the length of our array using .length outside of our class.

We also know that we must keep track of the elements that exist within the array. To do this, I’m going to have us save the elements within the array as a hash (the next data structure in this series!!). Why? Well, I don’t really see the purpose of using an array in my demonstration of creating an array from scratch, so we are going to make use of another great data structures!

Alright, let’s go ahead and build out the initialize method.

class MyArray
  attr_reader :length

  def initialize
    @length = 0
    @elements = {}
  end 
end

We initialize the class with a length of 0 because when the array is created, no elements are present. The same logic is used for the @elements variable that is set to an empty hash. With that done, let's move on to the next step.

`Array` Methods

The next step in the process of building out our array is to consider which methods we should build out. There are so many array methods and for the purpose of this blog post we are only going to cover a few. Please feel free to explore other array methods that you use frequently so that you can practice building out that functionality. The methods that I've chose to cover are

adding an element to the array - .push(element)
returning the element at a given index - .at(index)
removing the last element of the array - .pop()
removing an element at a given index - .delete_at(index)
removing a given element - .delete(element)
checking to see if an element exists in the array - .includes?(element)

For the sake of restricting all of our methods to one purpose as well as maintaining DRY code, we will also create an additional method called shift_elements(index), which will shift the elements within the array when an element is deleted using our .delete(element) or .delete_at(index) methods.

Let's dive on in to the first method we'll be creating: .push(element).

`.push(element)`

In order to add an element to our array, we are going to create the .push(element) method which adds the new element to the end of our array. In this method, we need to make sure to add the element to the array as well as increasing that @length count by 1.

def push(element)
  @elements[@length] = element
  @length += 1
end

If you are wondering why I set the element's index to the @length of the array, think about the differences between the way indices and length are counted. Indices start at 0, whereas length starts at 1. By setting the element to index of @length, I am setting it to the index of the last element in the array plus 1.

`.at(index)`

The next method we are going to build out is .at(index) which allows us to access and retrieve the element at a provided index. We can do this two different ways.

Example 1:

def at(index)
  if index < @length
    @elements[index]
  else 
    return nil
  end
end

Example 2:

def at(index)
  if index < @length
    @elements.each_value.with_index { |value, i| return value if i == index }
  else 
    return nil
  end
end

In both examples we check to make sure that the index we are attempting to access is not out of range for our array using a conditional. If the index does not exist, we want our method to return nil as that is the normal functionality of the .at(index) method.

Now, in the first example, we are using an array method referred to as an element referrence to access the element. In the second example, we use the hash method .each_value in combination with .with_index to traverse over each value in our array until the index of a value matches the provided index.

Note: I personally prefer to use the second example as it isn't making use of a built in array method, however, I will be using the first example in the remainder of our methods to save myself time.

Let's move on to methods that allow us to remove elements from our array.

`.pop()`

If there is ever a need to remove and return the last element in an array, .pop() is the way to go. There are three things that we need to accomplish when building out this method. We need to

remove the last element from the array
update the length of our array by subtracting 1
return that element

In order to return the last element in the array once the other two steps have been completed, we must save the element to a new variable before removing it from the array. Let's build it out!

def pop()
  # save the last element to a new variable
  last_element = @elements[@length - 1]
  # delete the last element
  @elements.delete(@length - 1)
  # subtract 1 from the length
  @length -= 1

  # return the last element
  return last_element
end

`.delete_at(index)`

The next method we are going to build that removes an element from our array is the lovely .delete_at(index) method. With this method, we can provide the index of the element we wish to remove from the array. This method returns the removed element just like .pop().

Now, this type of element removal is a bit more involved because we aren't just removing the last element in the array. We will need to shift the index of all remaining elements in the array up by 1. To do this, we are going to create the shift_elements(index) method that I mentioned earlier.

To build out this method, we are going to require a parameter: the index of the element being removed.

def shift_elements(index)
  counter = index
  while counter < @length - 1 do
    @elements[counter] = @elements[counter + 1]
    counter += 1
  end 

  @elements.delete(@length - 1)
  @length -= 1
end

At the end of our while loop, our array will look a little funky. The last element in the array will be repeated two times which means we need to remove one of them, hence our deletion of the last element in the array. If you'd like to take a closer look yourself, feel free to throw in a print statement.

Now that we have that method built, let's move on to the implementation of our .delete_at(index).

def delete_at(index)
  # make sure index given is within range
  if index < @length
    # save the to be deleted element for return
    element = @elements[index]

    # shift and remove desired element
    self.shift_elements(index)
    return element
  else 
    return nil
  end 
end

`.delete(element)`

The last removal method we'll be covering in this tutorial is .delete(element) which allows us to delete and return the provided element. This method is pretty similar to the one above except for one thing: we'll need to find the index of the given element in order to use our shift_elements(index) method. Let's build it out!

def delete(element)
  @elements.each_value.with_index do |value, index|
    if value == element
      self.shift_elements(index)
    # if given element does not exist in array
    elsif index == @length - 1
      return nil
    end 
  end 

  return element
end

`.includes?(element)`

Now for the final method we'll be building in this tutorial, and my personal favorite: .includes?(element). This method will traverse our array looking for the given element and return a boolean. If our array does not include the given element, the method will return false. If it does include the element, the method will return true. Let's go ahead and build out our final array method!

def includes?(element)
  result = false
  @elements.each_value { |value| result = true if value == element }

  return result
end

Final Product

Awesome! We've gone through and built out all of the methods for an array that we planned to build. Again, there are many other array methods, but for the purpose of this blog post we only did a select few.

Let's go ahead and take a look at the final product that we've built.

class MyArray
  attr_reader :length

  def initialize
    @length = 0
    @elements = {}
  end

  def push(element)
    @elements[@length] = element
    @length += 1
  end 

  def at(index)
    if index < @length
      @elements.each_value.with_index { |value, i| return value if i == index }
    else 
      return nil
    end
  end 

  def pop()
    last_element = @elements[@length - 1]
    @elements.delete(@length - 1)
    @length -= 1

    return last_element
  end 

  def shift_elements(index)
    counter = index
    while counter < @length - 1 do
      @elements[counter] = @elements[counter + 1]
      counter += 1
    end 

    @elements.delete(@length - 1)
    @length -= 1
  end

  def delete_at(index)
    if index < @length
      element = @elements[index]
      self.shift_elements(index)

      return element
    else 
      return nil
    end 
  end 

  def delete(element)
    @elements.each_value.with_index do |value, index|
      if value == element
        self.shift_elements(index)
      elsif index == @length - 1
        return nil
      end 
    end 

    return element
  end

  def includes?(element)
    result = false
    @elements.each_value { |value| result = true if value == element }

    return result
  end 
end

Final Thoughts

It's been a lot of fun creating this for y'all and I'm really excited to move on to the next installment in this series, hashes. I hope that this tutorial has been helpful. If there is anything that you'd like to add please feel free to do so in the discussion section below. Or if you want to build out your favorite array method and show it off, please feel free to share that in the discussion as well!

Thank you for reading and happy coding!

Note: The cover image of this blog post is brought to you from a recent hike that my fiancé and I did near Los Gatos, Ca.

I Love Technical Screens and Here's Why

Tori Crawford — Fri, 24 Apr 2020 20:10:52 +0000

More often than not, at this point in my job search, I have been doing well enough in the first round interview to get extended a second one. The second-round interview for most companies is often a technical one, whether that be a technical screen, a code challenge, or a take-home project.

The technical portion of the interviewing process, to me, is the most difficult aspect of the whole process because every company does it differently. To semi-quote Forest Gump, technical interviewing is “like a box of chocolates. You never know what you’re gonna get.”

Personally, (past me would be shocked that I’m about to say this, but…) I prefer having a technical screen or, as some companies call it, a pair programming session with one of the company’s engineers over any other type of technical interview.

Some of you who have experienced the technical interviewing process may be thinking “Why would you like technical screens over something you do on your own? There is so much added pressure when you are live coding with someone else.” Yes, those of you thinking that would be 100% correct, there is that extra pressure, but I get to experience working with an engineer at the company! Most companies will even have your interview with an engineer that you’d work with if hired. This means that I’d get a sneak peek at what it could be like working with that person for that company on a daily basis.

Completing a take-home project or code challenge on my own wouldn’t allow me to have that experience. I wouldn’t get the opportunity to walk through my thought process with the interviewer and bounce ideas off of them. They wouldn’t get to see me make mistakes, catch them, and then fix them. Most importantly, I wouldn’t be able to get a feel for what working with the company’s engineers is like.

Some of the things I ask myself during and after technical screens are

Did the interviewer challenge me by asking why I chose one solution and not another?
Did this person give me the answer when I asked a question or did they guide me in the right direction?
Was the atmosphere more like a collaboration or an interrogation?

These aspects of the interview are important to me because, as a junior, I want someone to question why I’m choosing to do something a certain way. What if my way is not efficient or completely wrong? I’d want to know that, but, hopefully, the interviewer doesn’t just tell me why it’s wrong, hopefully, they ask me questions that lead me to that realization. To me, I want it to feel like we are collaborating and bouncing ideas off of one another like we would if it were a normal day at work.

If the interview feels more like an interrogation or that I’m talking to a brick wall, I feel uncomfortable. When this happens, I immediately cross the company off of my list, because why would I want to work for a company that made me feel uncomfortable during the interviewing process? Should I want to work with someone I didn’t feel like I could collaborate with or with someone who may not feel comfortable answering questions? Or for a company that doesn't want the interviewers to answer questions?

Final Thoughts

I'm a junior developer trying to find my first role with a company that I believe could provide me with the best possible environment, one that will help me grow professionally and thrive. Technical screens help me determine whether a company will be a good fit for me, which is why I love them.

Interviewing with a company is as much about you being a great fit for them as it is the company being a great fit for you. If you have read any of my articles about interviewing prior to this one, you have heard me say that a ton already but I seriously cannot stress this enough!

Make sure you are doing what is best for you.

Note: The cover image is brought to you from a recent trip to the Antelope Valley California Poppy Reserve in Lancaster, Ca.

The Heartbreaks of Interviewing During COVID19

Tori Crawford — Mon, 13 Apr 2020 19:04:32 +0000

COVID19 has been disruptive to all of our lives. It has forced a lot of people to work from home and/or lose their childcare. Some of us are losing loved ones to this virus. Others are being laid off due to the financial difficulties a lot of companies are experiencing at this time. Some companies have had to put a freeze on hiring and others have had to fold. While these are a few examples of difficulties that people are facing during this pandemic, they don’t even begin to scrape the surface of problems people are experiencing at this time. With this article, I want to discuss the one that has been the most impactful on me personally, interviewing during COVID19.

The impact that COVID19 has had on my job search has been devastating. For some background on me (if you don’t already know), I have been actively interviewing for over a year in search of my first software engineering role. This means I have been on the emotional roller coaster ride of interviewing for a long time now. I have experienced some great highs as well as some pretty low lows.

Let me be honest before COVID19 hit I was already inching towards my breaking point.

Pre-COVID19

Noticing that I was getting close to my breaking point, I set out to improve on what I felt I was weakest at. My goal with doing this was to eliminate the stressors that I had control over in hopes to move further away from that breaking point. Before COVID19 hit, I felt that I was accomplishing this goal and my confidence in my interviewing skills was increasing tremendously.

Eventually, I had the opportunity to work with a startup for a week as a paid trial, an interview of sorts. This was an amazing opportunity for me as I viewed this trial as a win-win situation because it gave me a week of professional experience I didn’t have whether I was extended an offer or not. Luckily enough I was extended my first official software engineering offer after the trial was over. This was the proudest moment of my job search.

Then along came COVID19…

COVID19

Within a week of COVID19 becoming prevalent and amid contract negotiations, the company reached out to me and let me know they had to put a freeze on hiring. This news came after three hundred and fifty-six days of searching for a job and thirteen days after I received that offer. It was devastating, but I bounced back, as I always do in the face of adversity.

Backing up a tiny bit, before receiving that offer, I had already been interviewing with another company that had the intention of bringing on two new software engineers. When my first offer was rescinded, yes I was devastated (as I just mentioned), but I also felt a sense of relief because this other company felt promising so I shifted my focus to my upcoming technical screen with them.

After completing this amazing technical screen, I felt that I had found the company and the people that would help foster an amazing environment for my professional growth. When I received news that I was among the four final candidates moving on to the final round of interviews, I was ecstatic and also relieved that they weren’t putting a freeze on hiring.

For the final interview, I met with three other employees that I had not previously interviewed with as well as the hiring manager. After meeting and interviewing with each person, I got more and more excited at the prospect of working at this company. By the time I met with the hiring manager I was beaming with excitement, then came the bad news.

She started her portion of the interview by informing me that the company had cut her budget and she could only bring on one engineer. She then told me that two of the other candidates were mid-level engineers, which is always nerve-racking to hear as a junior as I don’t have the same experience they do. While this news sucked, I knew I still stood a pretty good chance considering I was one of four final candidates so I chose to stay positive.

The Heartbreak

After a few days of doing everything I could to distract myself while waiting to hear back, I got the news that they had chosen to go with a different candidate. With this news, I felt my heart crumble and all hope slide away with it. (To be completely honest here, this is incredibly hard to write about right now, as the feelings are all still very raw.) I had made it one year and eight days into my job search before the thought “I just want to quit” popped into my head. That’s a long time of riding that emotional job search roller coaster before finally feeling the need to get off of it.

To me, the fact that the thought even crossed my mind was more devastating than the rejection itself. I am not one to give up, ever, and I wasn’t going to let myself start now. To keep myself on the ride, I had to take a little bit of time to myself to recharge emotionally, so, after another interview only a few days later, I took two days to myself even though I had the intention of taking the rest of the week.

Moving Forward Despite COVID19

By the third day, I was completing a code challenge that was extended after the aforementioned interview. By the fourth day, I found myself browsing open positions, which struck a sense of panic in me due to the new influx of people searching for roles as well as the decrease of job openings all due to COVID19 layoffs and hiring freezes.

Part of me is happy that I am bouncing back and ready to ride the roller coaster again, but the other is hesitant knowing that there are most likely a few more heartbreaks in my future, whether they be due to COVID19 hiring freezes or other reasons. Either way, I’m going to rise up and keep moving forward knowing that the right fit for me is out there somewhere and I’ll find it eventually.

To anyone who is in the same boat as me right now, I feel for you. You are not alone. I know your struggles and I am here for you. Please feel free to DM me here or on Twitter if you feel you need to talk to someone.

Note: This post's cover image comes to you from an awesome hike I did in Waipiʻo Valley, Big Island, Hawaii.

What Non-Technical Interview Questions Have You Been Asked?

Tori Crawford — Mon, 30 Mar 2020 23:25:05 +0000

After my recent article, Looking for Your First Dev Role: Advice for Young Devs by a Young Dev Part 2, I have had a few new devs who are ramping up to apply for their first roles reach out to me and there was one common thread amongst them. They were asking about some of the most common soft skills or non-technical interview questions that I have been asked. Before this happening, I hadn’t really thought about writing a blog post about this topic, but here I am writing it!

With this brief article, I am going to list a few of the most common soft skills and non-technical interview questions that I have been asked over the last year. I would love for any of you reading this that have gone through the interview process in the past to contribute any of the common questions you were asked as well. Let us try to create a great resource for those new devs out there trying to land their first roles or any experienced dev entering the job search again wanting to brush up their interviewing skills!

The Questions

Can you tell me about a time when you overcame a challenge?
Can you give an example of a time you’ve had a conflict with a coworker? How was this conflict resolved?
Give an example of a time you’ve stood up for something you believed was right.
What made you switch careers? What ultimately led you to pursue software engineering?
What project are you most proud of and why?
How would you go about explaining a technical topic/issue with someone non-technical?
Tell me about a time that you built a good relationship with someone you didn’t particularly like.
What was the most difficult aspect of going through bootcamp? What was the most rewarding?

A Quick Note

These are all of the questions that I can think of right now. Check back at any point to see if I’ve added any new questions or to check the discussion section to see questions that the amazing DEV community has added.

I personally know how stressful the job search can be, so I hope that this article can help any of those new devs out there trying to prep for interviews.

Good luck to anyone out there interviewing!

This post's cover image is brought to you from my recent trip to Hawaiʻi Volcanoes National Park in Volcano, Hawaii.

Looking for Your First Dev Role: Advice for Young Devs by a Young Dev Part 2

Tori Crawford — Mon, 23 Mar 2020 23:50:38 +0000

It’s been a hot minute since I have written a blog on one of my favorite topics, the job search. On one hand, I know this is because I landed the software engineer coaching position at Flatiron School back in August (which I left at the end of November). On the other though, I didn’t stop interviewing even when I got that job, so what’s my excuse? I don’t have one.

When I wrote the first part of this series only 57 days into my job search, I never thought I would be where I am right now, still jobless. It’s been a tough ride over the last year and as I’m gearing up to hit the one year anniversary of declaring my job search, I have begun reflecting on the mistakes I have made along the way thus far. It is here, with this article, that I am truly self-reflecting and will be sharing the wisdom I’ve gained through this process.

Let’s get started!

Take Notes

After the first few months of interviewing and not having any luck, I wasn’t entirely sure what I was doing wrong and eventually decided to start taking notes at the end of every interview. As soon as the interview would end I would start jotting down notes about what I think I did well at and what I think I did poorly at. Then I’d sit and reflect on what steps I could take to improve. I would always ask myself: “How can I do better next time?” This is a very important question to ask oneself after every interview.

Rehearsed Answers

We all know that a lot of interviewers ask similar questions. This means that we often have thought-out answers for every one of those oh-so-familiar questions. I do, but I don’t always phrase it the same way every single time. Some days I phrase it in a way that I even surprise myself, and, on those days, I have started to write down the exact phrasing that I used. I then reflect on why the new phrasing stood out to me and which aspects I’d like to reuse.

To further this idea, I also take notes on the phrasing I didn’t like. There are times that I reflect and think that what I said could have come off wrong or wasn’t representing the message I wanted to relay. To avoid making the same mistake again, I write it down.

Ask Questions

One thing I’ve lived by during this whole journey is that the interview is just as much about me interviewing the company as it is the company interviewing me. The more interviews I have had, the more I have learned which questions bring out what I want to know about the company. There are a few key questions that I love asking and I’m going to share them with you here. Feel free to steal them for your personal use!

1. What is your favorite aspect of working at Company XYZ?

This question is one of my favorites. This gives the interviewer a moment to boast about their favorite aspects of the company. In my experience, the interviewer tends to have the longest answer for this question because as they talk about their favorite aspect they often think about other aspects and go on and on. It’s a fun moment for me to see the pride the interviewer has in the company they work for.

Immediately after asking this question, I follow it up with…

2. What is your least favorite aspect of working here?

This is also another favorite of mine that tells A LOT about the company. I often have the interviewer say something along the lines of “oh, that’s a tough one.” The answers I get always seem genuine. One time I got a very raw answer that once I ended the interview, I crossed this company off my list. To me, this is great because this is the point of interviewing! The company must be a good fit for me and the only way to find that out is to ask the tough questions. Which brings me to the next question…

3. What are the biggest challenges facing the company right now?

This question often gets answered with difficulties that face the company as a whole. If it is a startup, I often hear about the growing pains of a startup. If there is a new competitor in the field or something along those lines, they’ll mention that.

There are times that I omit this question if time is running out because I think the above question is more telling about a company.

4. What does Company XYZ do to promote an inclusive and diverse work environment?

The answers to this question, in my experience, have determined whether I want to continue interviewing with a company or not. With one company, I made it 3-rounds in and asked every person this question. None of them could give me a solid answer. To me, this comes off as if the company doesn’t do anything to promote an inclusive and diverse workplace.

Then there are times where I get an amazing answer that is detailed and says a lot about the company and how they care about their employees' mental health and well-being. This not only helps me get more excited about the company but also gives me faith in the future of tech. It’s often my final question to hopefully end things on a high note!

Note: Inclusivity and diversity are incredibly important to me, which is why I always ask this question. If these things aren’t important to you, then this question seems a little pointless and you don’t need to add it to your question list.

Technical Interviews

Now for the embarrassing story. After almost a full year of interviewing I have completed a ton of technical interviews. It is normally at this point in the interview process that I have received those daunting rejection no-reply emails. There have been many interviews when I thought I had crushed the technical interview, but it turns out, I hadn’t.

It wasn’t until around October/November of 2019 that I realized what was going wrong. To prepare for a final round in-person interview, a friend at the company offered to help me prepare. He brought up multiple data structures that I knew about but didn’t know why I should use one over the other or what their Big O implications were. This opened my eyes and by December I enrolled in the Udemy course Master the Coding Interview: Data Structures + Algorithms created by Andrei Neagoie.

Now we are creeping up on April and I have still yet to complete the course, but my confidence during technical interviews has improved tremendously and I have moved on in the interview process more often than I had before.

Here are a few things I have changed recently that I think have helped and hopefully one would find useful:

Speak most, if not all, of your thoughts aloud. This gives the interviewer the chance to get to know your thought process. If you choose to use data structure A over data structure B, let them know your reasoning.
Write comments and pseudo-code as much as possible before diving into writing code. This allows you to discover holes or possible problems in your approach before starting to write code that you’d have to change. It’ll save you time from going down the wrong path.
Ask clarifying questions when necessary.
Come to terms with the fact that you will not always finish the problem and that is OKAY!

Handling Rejection

Rejection: arguably one of the toughest aspects of the job search. When I first started the job search, I felt as if every rejection was personal. This is a really silly mindset to have when looking for jobs and I am very happy that I have come to realize this. It has made a world of difference in my ability to bounce back after receiving a rejection. I often like to think of the old saying that when one door closes, another will open in its place.

Now, if you get lucky and receive a rejection from an actual person and not a no-reply email, make sure to leave things on good terms. This happened to me recently and the company reached back out a week later offering to do a week-long paid trail interview. This was amazing for me because it gave me the ability to gain a week's worth of professional experience that I had never had before. I got to sit in on a design review, daily stand-ups, code reviews, etc.. It was an invaluable experience I would not have gotten otherwise.

An update on that story: I received an offer, but due to COVID19 the offer was rescinded. They have since offered to hire me as a contract engineer until I find a full-time role somewhere. I am incredibly blessed and grateful to have been exposed to this amazing company that cares.

Anyways, make sure to handle rejection with grace and try to bounce back as fast as you can. If you find yourself struggling with rejection don’t worry, you aren’t alone. I have had my fair share of rejection tears over the last year. Feel free to reach out to me if you can’t seem to move past one, I am a great positivity buddy.

Keep Improving

The most important piece of advice I can give you today is to continue improving yourself. Continue to write code. Continue to learn new things or deepen your understanding of topics that you already know. Continue to learn more about yourself and your weaknesses so that you can turn those weaknesses into your strengths.

Final Thoughts

While it is incredibly disappointing that I have yet to land a full-time role as a dev after nearly a year of searching, I am proud of myself for continuing to self-reflect and improve throughout the whole process. If, in a few months, you haven't secured a role yet, could you self-refect and say that you are proud of how far you have come? I think this is an important question to pose to yourself down the line or to use as daily motivation. Always strive to continue improving yourself!!

Another closing note I'd like to mention is that the choice to be positive is important in maintaining your mental health during the job search, so do your best to stay positive. I get it, sometimes you just can't stay positive. Take 30 minutes and just let all the negativity out. Let it be acknowledged, then move on.

Note: This posts cover image is brought to you from my recent trip to Hawaiʻi Volcanoes National Park in Volcano, Hawaii.

Nevertheless, Tori Kept Interviewing

Tori Crawford — Fri, 06 Mar 2020 20:50:08 +0000

For anyone who doesn't know much about me, I am a career changer who attended and later coached at, Flatiron School. I graduated from their online self-paced software engineering program in February of 2019 and declared my official job search start date as March 26th. Now, here I am, March 6th 2020, almost exactly a year later, still without a job, and believe me, it hasn't been from a lack of trying.

As someone who was a two-sport collegiate athlete and double major, I am no stranger to working my butt off to accomplish what I want. The grind I've been on to establish myself in the tech world has been no different.

Every single day I wake up and figure out what I plan on doing that day to make myself even just the tiniest bit better. Currently, I am working my way through a Udemy course on technical interviewing so that I can work on bettering myself in that respect.

Lately, a majority of my days are spent applying, prepping for interviews, and interviewing. It has been fun (and stressful) to be actively interviewing at 3 different companies at a time since January. At one point it was 5 companies at once which was very chaotic but I wouldn't change it for the world. Why? Well, because I love coding and I love the continuous flow of learning and improving myself.

Keeping with this determination and drive to break into tech will, one day soon, help me land a software engineering position at a company that I love. Giving up is not part of my character, it is not in my genes. So, with that said, nevertheless, I continue coding, interviewing, and learning.

Get to Know the Command Line: Basic Git Commands

Tori Crawford — Mon, 06 Jan 2020 19:58:14 +0000

A few weeks ago I started the “Get to know the Command Line” series with this Basic Commands article. This article that you are currently reading is the second installment which will cover basic Git commands that I believe new developers should get acquainted with. Actually, more than just acquainted. New developers need to get downright cozy with these commands as they are not likely to be going anywhere any time soon.

Before jumping in let's cover the following question: What is Git? It's a version control system that can be used for small and large projects alike. What is a version control system? At the surface level, a version control system helps keep track of changes made to a codebase while at the same time keeping a copy of the previous versions.

With that introduction behind us, let's go ahead and get started.

`git init`

git init is the command that allows us to add Git to our current working directory (project). To go into more detail, this command creates an empty Git repository or reinitializes one that already exists.

For the purpose of this blog post, I created a new project called git-command-practice and used the command cd git-command-practice to change into the project's directory. From here, I am going to initialize Git for this project.

`git remote add origin <GitHub URL>`

For those of us who use GitHub as our preferred repository hosting site, we need to create a new GitHub repository. The next step would be to use the command git remote add origin <GitHub URL> in order to connect our local project with the GitHub repository.

This allows us to see the changes and commits we've made to our code on GitHub. we'll be able to see file changes, new lines of code, deleted lines, as well as commit messages for each commit that has been made.

`git clone <GitHub URL>`

The git clone command is used to copy an existing repository to one's local machine. Let's say someone wanted to clone one of the existing projects I've worked on that exists on my GitHub profile, like my portfolio site. The way to do this is by using the command git clone https://github.com/torianne02/victoria-fluharty-portfolio.

Now that we have covered the commands that we need to get a repository up and running, let's discuss some of the commands that we will be using often while writing code.

`git` / `git --help`

I am about to throw a few commands at y'all and it might feel a little overwhelming. Don't worry though, these next few commands are really helpful for those of us who have a hard time memorizing things, like me.

If one feels lost or can't remember a command at any time while writing code, they could make use of either of the commands git or git --help, which return the same thing: a list of common git commands.

As with most Git commands, git --help has options that allow us to add to it to receive a different kind of output.

Note: Most Git commands have a multitude of options and I will not discuss them all here, but I will discuss a few notable ones I think may be helpful.

`git --help -a`

This command lists available subcommands.

`git --help -g`

This Git command outputs a list of Git guides available.

`git --help <command name>`

This is a helpful Git command that allows us to view details about a specific Git command, such as the description, options, examples, etc..

`git status`

git status, in my opinion, is arguably the most important Git command that is used regularly while writing code. This command allows us to see the status of the current working tree. It does this by outputting the paths that

have differences between the index file and the current HEAD commit.
have differences between the working tree and the index file.
are in the working tree that are not yet tracked by Git.

At this point, let's create a file in this project called practice-file.rb. Now let's use the command git status.

Notice that it says our new file is "untracked," this leads me to our next command:

`git add <file path>`

git add is the command used to add the contents/changes of a file to the index. In order to add our newly created file to Git so that it can be tracked, we would run the following command

`git add .`

If one wants to add all the files that they have recently changed, they could use the command git add ..

If there is one thing that I want my readers to take away from this article, it would be that one should never use this command without first running git status. Why? To make sure that one is aware of all the files that have been changed and are about to be added to the index. What if a dev accidentally hit a key and caused a typo on a file that was never meant to be edited?

Okay, okay. Maybe it isn't that dramatic, but please always be aware of what you are adding to the index!!

Now that we used git add let's use the command git status again to see what it looks like.

Notice the phrase "Changes to be committed" followed by the file path that we recently added to the index, practice-file.rb. This brings us to the next command: git commit.

`git commit`

The command git commit records the current contents of the index, which just happens to be all of the changes made to the code that we added to the index by using git add.

`git commit -m`

When committing code, one wants to add a detailed message about the changes being made to the code. In the case of this example, I created a practice file in order to take screenshots of the commands I am covering here so I should express that in the message. In order to accomplish this, I have to add -m 'message here in quotes' to the command git commit. Here is what it looks like:

You will notice in the screenshot that I had a few typos.

Guess what?! It's not a nightmare and we can fix this!

`git commit --amend -m`

Let's be honest, we all make mistakes from time-to-time. Thankfully, Git gives us the ability to fix our typo mistakes in our commit messages.

If we notice our mistake BEFORE using the next command (git push), we can use the command git commit --amend -m 'new message to replace old message'. Let's fix that typo!

Awesome! Now we are good to move on to the next command.

`git push`

The command git push comes into play once one is happy with the changes made to their code and with the commit messages that they have recorded. git push updates remote references and repositories, in our case the GitHub repo, of the current repo with local commits and changes.

`git checkout <branch name>`

git checkout is a command that allows one to switch between the different branches of a repository. What is a branch? A branch is essentially a copy of the master version of the repository with a unique name that a developer can use to make changes to the codebase without directly changing the master branch.

`git checkout -b <branch name>`

One common practice when using Git is to create a branch for each new feature or major change one wishes to add to the project. A branch allows the developer to work on a branch of the master codebase. In other words, the developer can make a ton of changes to this branch and it wouldn't affect the main version of the codebase. At least not until they choose to add the new changes to master.

Let's create a new branch called new-practice-branch and switch to it by using the command:

Now, let's use git checkout to switch back to the master branch.

Now that we've covered branches, let's cover what command to use when one wants to join two branches together.

`git merge <branch name>`

git merge is the command that one would use when they want to merge two branches together. Let's say we are currently in our master branch and we want to add the changes made to our new-practice-branch to master. In order to accomplish this, we need to use this command

Awesome! Now we've merged two branches together. Now let's say we were working with a partner and they made changes on their own local machine and pushed to our remote GitHub version of master. This means that my local version of master is not up-to-date. Don't worry! There is a command to fix this.

`git pull`

git pull gives us the ability to fetch changes from another repository or local branch and integrate them with our local repository. Pretty neat, but this doesn't quite fix our problem. The next command does though! Let's check it out.

`git pull origin master`

The command we need to use in order to update our local version of master with our GitHub's remote version of master is git pull origin master. All we are doing here is adding an origin pointer that tells Git where we want to pull from.

For this example, I was the only one working on the project so there is nothing to be pulled which is why I received the message "Already up to date." This would look different if this wasn't the case.

Final Thoughts

Phew! It probably feels like I just threw a lot of new commands at you. Don't worry though! Even senior developers have to Google things from time to time, so don't feel bad if it doesn't stick right away. The more you use the commands, the faster they'll become second nature for you.

Good luck with your journey and be on the lookout for future articles in this series!

Note: The cover photo for this post is brought to you by one of my favorite places on earth: Twin Lakes in Mammoth Lakes, Ca.

Resources

Git-- commands you need to git going!
6 Git commands every beginner should memorize
Essential git commands every developer should know
git-help
Basic Git Commands

DEV Community: Tori Crawford

Productivity in Working Parents

Spoiler alert: if you read the article cited above you will discover that flexible work hours actually increases productivity and it is not only working parents who want flexible hours.

Why are parents more productive?

Moving Forward

Related Articles and Studies:

Layoffs: It’s Okay to Not Be Okay

How Do You Decide It Is Time to Move On?

Despite Loss, Tori Coded

444 Days Later, Tori Hit the Jackpot

The Numbers

Applications

Interviews

Overall

First Round Interviews

Technical Interviews

Final Rounds

Rejections

No Responses

Offers

Takeaways

Data Structures From Scratch: Array

Create the Class

Initialize the Class

Array Methods

.push(element)

.at(index)

.pop()

.delete_at(index)

.delete(element)

.includes?(element)

Final Product

Final Thoughts

I Love Technical Screens and Here's Why

Final Thoughts

The Heartbreaks of Interviewing During COVID19

Pre-COVID19

COVID19

The Heartbreak

Moving Forward Despite COVID19

What Non-Technical Interview Questions Have You Been Asked?

The Questions

A Quick Note

Looking for Your First Dev Role: Advice for Young Devs by a Young Dev Part 2

Take Notes

Rehearsed Answers

Ask Questions

1. What is your favorite aspect of working at Company XYZ?

2. What is your least favorite aspect of working here?

3. What are the biggest challenges facing the company right now?

4. What does Company XYZ do to promote an inclusive and diverse work environment?

Technical Interviews

Handling Rejection

Keep Improving

Final Thoughts

Nevertheless, Tori Kept Interviewing

Get to Know the Command Line: Basic Git Commands

git init

git remote add origin <GitHub URL>

git clone <GitHub URL>

git / git --help

git --help -a

git --help -g

git --help <command name>

git status

git add <file path>

git add .

git commit

git commit -m

git commit --amend -m

git push

git checkout <branch name>

git checkout -b <branch name>

git merge <branch name>

git pull

git pull origin master

Final Thoughts

Resources

`Array` Methods

`.push(element)`

`.at(index)`

`.pop()`

`.delete_at(index)`

`.delete(element)`

`.includes?(element)`

`git init`

`git remote add origin <GitHub URL>`

`git clone <GitHub URL>`

`git` / `git --help`

`git --help -a`

`git --help -g`

`git --help <command name>`

`git status`

`git add <file path>`

`git add .`

`git commit`

`git commit -m`

`git commit --amend -m`

`git push`

`git checkout <branch name>`

`git checkout -b <branch name>`

`git merge <branch name>`

`git pull`

`git pull origin master`