Three months — Post coding bootcamp: The algorithms and the take home struggle
By: Kathleen B
Tags: Career Change, Coding Interviews, Software Engineering

Three Months — What’s new?

This week marks 3 months since I graduated General Assembly’s Software Engineering Immersive. Last month, I was in the midst of what most people would probably consider a “hell week”, on top of that I was preparing for a powerlifting meet (which I took first place btw, I’ll have a blog post about that in a while, it’s in my drafts) . I had 2 interviews one which is pretty difficult and another I had to do a take home assignment for it, all while it being in the middle of Thanksgiving, instead of me relaxing and spending time with family, I spent it stressing out and studying and doing a take-home. I’ll be getting into those details in a bit because I definitely learned a lot of things from that experience.

The interview process — Algos vs Takehome assignments

If you remember in my last entry, I mentioned that I was preparing for a big interview at the beginning of December. On top of that too, towards the end of November, I began the process with another company and instead their big thing was a take-home assignment.

As someone going into tech or as a career changer, more often than not we hear of the horror stories of technical interviews, specifically at the FAANG caliber companies where you’re thrown into the deep end to white board, and it would take months of practice to actually do well enough in the interview to pass. On the other hand, there are take home assignments which are controversial in its own way, due to the amount of time it would sometimes take to do.

Unfortunately for me, both of these opportunities fell through. But let’s talk about the processes I sat through.

The big interview I was preparing for is a big tech company that is considered “FAANG” in their industry. As such, their first round interview was a phone screen via a hackerrank, where I would collaborate with a software engineer. The first question, they asked about my background and technical projects that I’ve done in the past, and asking what I would do when it comes to something I don’t know (Google and documentation for the win!) Then came the technical question.

I was often told by friends in the industry that a certain data structure is very important and often gets asked in coding interviews. What data structure am I talking about? I’m talking about Binary Search Trees.

If you’re unfamiliar with Binary Search Trees, the oversimplified version of this, a tree has a root node at the top aka the parent node. The root node will contain a maximum of two children nodes, but the left side node should be less than its parent node and the right node is greater. So an example:

8

/. \

3. 10

/ \. \

1. 6. 14

So above is what is considered a valid BST. The left nodes are all less than the root node, and the right nodes are all greater than the root node.

So what question was I asked?

Exactly what I just clarified above. Write out code to check if a BST is a valid BST. Without me getting too much into detail, the way to solve this would be using recursion to use BFS to traverse the tree.

I personally thought it was pretty collaborative with my interviewer pointing me in the right direction at times. I got the code correct, but in the end they told me I need to work on my Data structures a little bit more and invited me to apply again in the future. No lie, I was really upset about that. Still, compared to how I was months ago in my first technical interview back in March and even last year. I saw how much I grew as a developer and found that I was better at talking things out and explaining what was going on in my head.

The Take Home Assignment

Oh yeah, and did I mention while I was prepping for the interview I just talked about above I was also starting the process at another company?

As I mentioned in the beginning of this entry, November was a crazy month. For this particular position, I applied for it at the start of November, got the email right away to schedule a phone screen, and the dates that were given to me was either Nov 13 (which I couldn’t do) or at some point in the end of the month. I chose the mid point.

The first phone screen was pretty straightforward, I moved on to the next round, then had another phone screen with the team lead, it was a little bit more difficult, but then I was moved onto the next round which was the technical take home. Without getting too much into detail, the take home assignment took up a LOT of time. The timing of it couldn’t be any worse either since it was during Thanksgiving too.

The take home assignment told us that we had to implement their product in any way we wanted to so we can get creative with it, as well as answering other questions.

Now, I was balancing out this take home assignment while also studying for another interview as I mentioned above. Due to the nature of this assignment, I ended up spending a lot of time working on it. It got so bad that one of my best friends started singing “Take a break” from Hamilton. It was definitely a test of patience, documentation, and investigation skills, things an aspiring developer should have, I guess.

After doing this assignment, I definitely have a deeper appreciation for those who do DevOps, I learned the importance of documentation and making sure it was well organized so if you need to backtrack, you can backtrack and find out what was wrong.

I could definitely see the appeal and the usage of the platform that I was working with when I did this, and thought of a wide variety of uses at the gym and even in the gaming industry.

As with the one above, unfortunately this did not pan out the way I wanted it to go as well. Despite failing the process after the take-home, I learned a lot from it.

What did I learn in both of these experiences?

So I experienced the best and the worst of I guess the technical interview spectrum. What did I learn?

Talk out your damn thoughts during the coding question.

I already knew this coming into this but, I’m not very good at expressing my thoughts. In a technical interview, it definitely helps if you talk out loud while you are coding so that way your interviewer knows what’s going on in your head and your thought processes, so that way they can point you in the right direction. If I stayed silent and just kept mumbling under my breath, I definitely wouldn’t have gotten as far with my solution.

2. Taking a break is important/Take your damn time

When you have a big interview coming up and you also have to do a take home assignment, you wanna spend all your time trying to knock out the take home right away. This was one of the biggest mistakes I made, I practically had two weeks to do the assignment due to the Thanksgiving holiday. Could I have actually sat down and relaxed? Most definitely, instead I powered through it and in the end, that’s probably what cost me from moving onto the next round.

3. In the end its you vs you.

Okay, so this definitely did not work out the way I hoped it would. I was honestly hoping that as a Christmas gift I would end up finally getting my wish of getting a job in the tech industry and starting off 2021 on a good note, being able to continue taking up my hobbies, and all that fun stuff.

Instead I’m walking into 2021 still funemployed and constantly searching for that one opportunity. It’s depressing. But now when I look back at both of these interviews, I came out as a better developer than I was at the start of November. I’m a lot more confident in talking things out and my thought processes after going through that and am a little bit more confident in my ability with data structures and algorithms ( I still need practice though) I can explain everything, but translating things to code is pretty hard.

So yeah, that’s what I learned sitting through these, there was definitely a lot more but I couldn’t remember it from the top of my head.