DEV Community: shawnhuangfernandes

Anti-Advice: Handling Rejection

shawnhuangfernandes — Thu, 07 May 2020 01:55:15 +0000

We All Struggle With Rejection

Asking someone on a date and being turned down. Being picked last for a pickup sports game. Getting bad news after an interview. Requesting to have your own electric guitar solo in a mariachi band. Clearly I am no stranger to rejection.

Many of us (myself included) who are seeking jobs as junior devs are getting heavy doses of rejection in large part due to the current state of economy.

I personally have had recent trouble trying to pick myself back up and continue the job hunt with the same vigor I had when I started.

It's been 3 months of rejection. That's a long time!

But... On the bright side, I've gotten really good at coping with rejection. I want to share with you my tips for dealing with those hard knocks. Let's get started!

Tip #1: Always Blame Others

You may not know this, but a job rejection is basically a personal attack to your ego. The ego is literally the most valuable asset any candidate brings to the table.

Instead of focusing on areas of growth (as the age-old saying goes: growth is for nincompoops), shield your precious ego by blaming anything but yourself. Everything is fair game when it comes to blame:

The company (they personally had it out for you most likely)
The circumstance (the questions were dumb, the code challenge was pointless)
Anyone who cares about you (distractions, the LOT of em')

Tip #2: HUSTLE HUSTLE HUSTLE.

What? Did you not get the memo from LinkedIn? All you had to do was:

Wake up every day at 4 am
Do 4 algorithms before 9am
Go for a 12 mile jog to clear your head
Send out 10 job applications by 12pm
Do a pull request on 3 people's code and fix their stuff
Network with 10 recruiters
Start a side business
Do yoga
and repeat this every day for 6 months

It's so easy. You really ought to shame yourself until you start doing this.

Remember: If you're not hustling, then you should feel bad, because feeling bad is the best and healthiest way of being productive.

Tip #3: Rewards are for Winners.

The LAST thing you want to do is reward yourself for trying. You should encourage WINNING, not TRYING. If you get rejected, don't take a break. Don't go for a walk. Don't eat tasty food. Don't take a day-trip. Rewards for people who aren't rejects.

Remember: Just because you put yourself out there in the job market and was validated through rejection, does NOT mean you deserve a reward. Don't promote this behavior! Makes me want to vomit just thinking about it.

Tip #4: Need More Emotional Distancing.

Just stop caring. The next rejection won't hurt if you stop caring. It doesn't matter. Nothing matters. I'm pretty sure I read somewhere in Forbes or National Geographic that not only does indifference turn you into a better hustler (which, come on, we all want that), but it makes you look cooler too.

Bonus points: If you can also not discuss your feelings with anyone. We all know that if you don't talk about your problems, you don't have any problems!

Tip #6: Don't think, just do it.

Have you seen your social media feed lately? It's full of people who are doing AMAZING things ALL THE TIME. Those people CLEARLY just do awesome things, and certainly haven't spent time reflecting on their failures.

Don't reflect on your rejection, as it might make you feel insecure, which could potentially hurt your ego (you didn't forget about your precious ego, did you?).

I mean really, what could you possibly learn from reflecting on your past experience while it's still fresh in your mind? Nothing, that's what!

JUST DO IT

In Conclusion

I hope this unsolicited advice finds you well. As some final remarks, please make sure you:

Hustle at the cost of your personal health
Do not help others who are also struggling, as they are the enemy
Protect your ego
DO NOT post any of your own anti-advice as comments to this post

Coldest Regards,
Shawn

Life As A Bootcamp Dev - Week 13: Finding Productive Hobbies

shawnhuangfernandes — Tue, 28 Apr 2020 17:05:57 +0000

Hi All!

As of recently, I found myself being pretty unproductive. A response to an interview I had intensely prepared for got pushed out and I had trouble staying motivated to keep sending job applications out.

So I took a break (asides from the two projects I was collaborating on!).

I did a number of things I normally don't do to take my mind off the interview in general, like watching TV and playing A LOT of video games.

I was convincing myself that I was just passing time until I would hear back from my interview.

If I got rejected, it was back to job applications, no problem!
If I got accepted, it was a whole new chapter of my life!

So I justified spending hours just killing time, for a couple days. And then the day came when I was supposed to hear back about my interview, and I was notified that the company was going to need another week.

Yeah, my "time killing" strategy wouldn't be reasonable for a WHOLE additional week. I wanted to find hobbies that I could improve at that I could potentially use in my coding projects that were also fun and relaxing. Here's three things I picked up:

1) I recently started learning piano. I loved putting sounds in my projects during my bootcamp, and I always wanted to learn to make my own music. My wife is an amazing piano player, so she had been teaching me the basics. It's been a blast!

2) I began practicing to make digital art using ProCreate. I always enjoyed throwing pictures/animations into my projects that came straight from my brain rather than the internet! I just practice by drawing whatever comes to my head. Here's a random drawing I made.

3) I started making small games using Unity. I've always been interested in world building and telling stories, I figured this would be something cool to explore that also lets me practice my coding AND design skills! Here's a snip from a simple number guessing game I made!

My Point: Do Something Small!

If you've also been hit by negative thoughts or just feeling crummy about your situation, it is totally okay to take a breather and take a break. In fact getting burnt out is way more unproductive than binging on something for a day or two.

Sometimes though, the best escape isn't actually doing nothing, but creating small things through activities you enjoy.

I usually feel guilty after watching 2 hours of TV, because I have "accomplished nothing".

But I usually feel happy after spending 2 hours drawing a silly picture, because I made a silly picture :).

I'll be getting back on this job application train now.

Good luck with your own endeavors!

Shawn

Life As A Bootcamp Dev - Week 12: Interview Highlights

shawnhuangfernandes — Mon, 20 Apr 2020 02:53:08 +0000

Here We Are Again!

For those of you wondering where the past couple weeks have gone in terms of this blog post, I ended up writing a series on System Design as preparation for an interview I had during this past week!

I'll do a short recap of my interview experience, as that's been what I was focused on during the past couple weeks! I've also been particularly exhausted from studying for 8-10 hours straight for two weeks, so I'm just taking it easy until I hear back!

Interview Application

This was a position that was targeting new programmers, but was about a totally new topic that I'd never heard about: Production Engineering. A couple things I did before I applied was:

I googled the position to understand exactly what Production Engineering was
I researched the company (although the company is well-known) and looked at their mission & values and tried to see if they aligned with my core values
I messaged a couple Production Engineers at the company to get some information on the role and figuring out their day-to-day

I liked the position, the team, and the work. It involved a lot of new concepts that I didn't learn in my bootcamp, but I decided it would not hurt to apply and see what happens! Application Sent!

The Coding Challenge

Now at this point I had been using Leetcode and Hackerrank to practice algorithms. I had been doing easy problems and was feeling pretty good. When I say I was feeling good, I mean I could:

Understand: Given the problem, I could re-state it clearly for myself to determine what it was asking me to do.
Diagram: I could draw or diagram the problem on a whiteboard or on my laptop
Pseudocode: I didn't get excited and try to jump into implementation, instead I could write an english-y version of my implementation that was easy to follow
Code: I could take my pseudocode and comfortably translate it into Javascript/Ruby.

Doing easy problems let me build the muscle memory of following this process.

Luckily, I had networked with some fellow engineers who advised me to start trying to tackle some medium level coding problems as preparation for any coding interview. Immediately I started hitting road blocks.

I was following my regular process, writing code that I knew was working, but leetcode and hackerrank were shutting down my solutions for some specific test cases. What was going on?

My solutions were timing out (aka taking too long to run).

I needed to learn to optimize my code. This is why everyone on the planet tells you to "learn your data structures". I was using nested for-loops to brute force my way through problems, with a rare application of a hash to speed up indexing. This simply wouldn't cut it for medium problems, and turns out, is partially-acceptable in an interview.

So my strategy changed:

1) Understand the problem
2) Diagram the problem
3) Pseudocode a BRUTE FORCE solution
4) Code your BRUTE FORCE solution
5) Evaluate your solution (what could be improved)
6) Optimize your solution
7) Repeat 5 & 6 until you're satisfied

From my studies, I realized there is so much more to algorithms that I haven't even touched on, but for the most part, I focused on going through this process as I did coding problems.

And Then The Challenge Came

I was sent an email for the coding challenge. I would be given an hour and a half to complete 2 coding problems. I had a lot of practice doing this, so going in I felt pretty confident.

The platform basically worked the same as LeetCode:

I had a problem laid out with a sample input and expected output
I had an area where I could submit test cases
I could run or submit my code

I flew through the first problem in less than 15 minutes, and I decided to annotate my code with comments just to be extra clear!

The Disastrous Second Problem of 2020

I was feeling really confident. I had an hour and fifteen minutes to do a single problem. I dived into the second problem and immediately knew I was in for some trouble. It involved traversing a matrix and determining the shortest route to a specific point considering the values of the matrix. I hit a mental block and minutes ticked away and I felt myself getting more and more nervous. I wanted to get some code on the page and after 10 minutes of thinking, I took the first solution and began implementing it. It didn't take long before I was getting frustrated because my solution couldn't handle edge cases, and I fixing the edge cases broke the other ones. Long story short, I couldn't finish the second problem.

But, in the last 5 minutes of the challenge, I wrote out my full understanding of the problem, acknowledged that I didn't have a working solution, and discussed possible implementations.

I don't know if that played any part in my evaluation, but I passed the coding challenge, barely!

The Interview

I was sent an email with a PDF packet of a laundry list of things I'd be tested on in two weeks. This wasn't to intimidate me, but a LOT of these things I honestly had no idea about. Some of them included:

Linux
How to troubleshoot a computer using bash
How operating systems work
System Design

and also some things that I was familiar with:

Coding
Behavior Qs!

At this point, I knew that if I wanted to really go for this position (which I knew I liked already), I'd need to commit myself to learning some new material for the next couple weeks.

I had a conversation with one of their recruiters which helped me understand what I should target. I found some awesome online resources to learn Linux, the Shell, and System Design and spent the next two weeks immersing myself. I actually learned a ton of interesting things about Linux (the vision behind it, how it works under the hood etc) and got absolutely fascinated with system design. Although learning in an almost academic way wasn't super exciting, I tried to make it fun and informative by doing things like writing blog posts or using useful bash commands to look at my own computer's processes.

I also created a STAR (or SAR) table in Google Sheets to help prepare myself for the Behavioral part of the interview. I also continued with my algorithms to prevent another debacle!

And so I trained for two weeks!

Taking The Interview

Because of COVID, everything as being done online. My interview had three parts, each one being conducted by a separate interviewer:

Part 1: Linux + Coding
Part 2: System Design
Part 3: Behavioral

Part 1: Linux and Coding

With my struggle with the coding challenge at the forefront of my mind, I came into this part of the interview with the intention of taking my time, talking things through, and asking questions before anything else.

We started with the Linux questions first. Some of the questions I immediately knew, others I asked for clarification, and prefaced that I was a beginner to Linux administration. My interviewer was happy to answer my questions and I think my bringing it up was a better alternative than trying to pretend I was an expert.

The coding part of the interview was short. The algorithm felt easy, but as I followed my process, I found myself catching some edge cases (which I made sure to verbalize). I provided a brute force solution, and then evaluated its performance, and provided a "divide and conquer" approach to reduce the runtime complexity. My interviewer seemed pleased with the result, and I left this part of the interview feeling good!

Part 2: System Design

This was a very conversational part. I greeted my new interviewer and we immediately jumped into some basic questions about whether or not I understood the basic parts of a System and then moved into designing and optimizing a system on a limited budget.

I felt like I did very well on this part of the interview for one reason: I did not just provide one answer for each system design question, but I provided multiple alternatives and explained my justifications. I felt like this was the strongest part of my entire interview, and I left feeling awesome!

Part 3: Behavioral

I have one main problem with answering questions: I talk way too much. During my behavioral interview, I was asked some pretty standard questions about my projects and how I handle teamwork. The interviewer did cut me off during one of my answers, which meant I was probably rambling at some point. Nevertheless, I did spend a good amount of time talking to the interviewer and felt like although I could have been more clear, it went well overall.

And Now We Wait

So now after this two week study-pocalypse, I'll be awaiting an answer to see if I made the cut or not! I'm both dreadful and excited, but I was told that in the next couple days I should have an answer. Here's to hoping! Regardless, you'll know the outcome in my next post!

Good luck with your own endeavors!
Shawn

System Design Intro For Bootcamp Grads: Part 3

shawnhuangfernandes — Mon, 13 Apr 2020 05:30:57 +0000

This is the third installment of my introduction to System Design, as I prepare for an interview that requires knowledge of System Design! I hope this serves you well as a starting point for your dive into System Design!

In the previous two blog installments, I covered:

Terminology/Jargon
System Design Principles
Monolith Architecture
Microservice Architecture
High Level System Components (Servers, Caches, Databases, Load Balancers)

Looking at a web service that may or may not exist, Hopefully you might be able to:

choose a high level backend architecture to use
keep the 5 system design principles in mind
break down the web service into general components

However, one key part I haven't really covered is optimizing a design. Such as how you can tailor your design for efficiency? For reliability? For scalability? In order to understand some of the options available for you to optimize your design, I'll briefly go over some of the high level strategies I've learned:

Horizontal Scaling vs. Vertical Scaling
CAP Theorem
Cacheing
Single Region vs. Multi Region
Horizontal Partitioning vs. Vertical Partitioning
Indexing
Redundancy & Replication

Horizontal Scaling vs Vertical Scaling

This is probably the most widely used term in System Design. They are relatively simple to understand.

Horizontal Scaling simply means that in order to increase your system capacity, you install more units (e.g if you had N servers, you now have N + 1 servers). You can horizontally scale any part of your system, but this works particularly well with distributed systems, and it is one of the primary reasons they are used. They can meet large scale demand at lower cost and higher reliability than monoliths.

Vertical Scaling means that in order to increase your system capacity, you upgrade your existing units (i.e replacing your computer with a faster, better one). This type of scaling is usually used in monoliths, but you can vertically scale parts of your system too.

CAP Theorem

More often than not you will be designing a distributed system (multiple services that are totally independent from each other). When designing a distributed system, you can't have it all, you need to decide on some tradeoffs.

The CAP Theorem states that any distributed systems can only provide 2 of the 3 characteristics: Consistency, Availability, and Partition Tolerance

Consistency means that ANY particular request being served from ANY server will not show dissimilar data.

Availability means that your servers can take requests 100% of the time.

Partition Tolerance basically means that your system will never have issues communicating with each other.

I was trying to explain this concept to my partner, and she gave me an example from her work that illustrates CAP Theorem.

Imagine you're working on the same excel spreadsheet (database) with multiple coworkers (servers):

If you all made sure that everything you updated was in sync with your coworkers, and that there were no inter-communication problems, you wouldn't be able to do your work 100% of the time, because you'd have to wait occasionally to resolve inter-communication problems. (Consistent, Fault Tolerant, but NOT Available)
If you made sure that all your coworkers could work on the spreadsheet 100% of the time and also ensured that they wouldn't have any inter-communication problems, you could potentially be dealing with inconsistent data. (Available, Fault Tolerant, but NOT Consistent)
If you made sure that your coworkers could work on the spreadsheet 100% of the time and also made sure they were checking in with each other before working on the spreadsheet, you'd be susceptible to inter-communication problems. (Available, Consistent, but NOT Fault Tolerant)

If designing a distributed system, keep the CAP Theorem in mind!

Cacheing

When do you decide whether or not you need a cache? If you have a high volume of requests for common data (like a request to see a celebrity post), it's a good idea to use a cache.

Additionally, when it comes to optimization of a cache, here are some considerations.

Where should I put my cache?
What should my cache eviction policy be?
How should I update my cache?

Where should I put my cache?

Cache is quick-access memory, so you can either move it closer to the server handling the request, or move it closer to the database.

Closer to the Server: If the Cache is stored in the server, this could potentially increase response times (since we wouldn't need to check for data all the way back in the database). However, you'd need to make sure (in a distributed system or a horizontally scaled service), that each cache has consistent data.
Closer to the Database: If a Cache is located near a database, this would reduce response times, but you'd get the data consistency you'd need because the cache could be a separated from your server(s). This cache could also be scaled independently.

What should my cache eviction policy be?

Since caches are typically small, they might get full quickly, and you might need to push out data according to specific criteria (pulled directly from Grokking the System Design Interview):

First In First Out (FIFO): The cache evicts the first block accessed first without any regard to how often or how many times it was accessed before.
Last In First Out (LIFO): The cache evicts the block accessed most recently first without any regard to how often or how many times it was accessed before.
Least Recently Used (LRU): Discards the least recently used items first.
Most Recently Used (MRU): Discards, in contrast to LRU, the most recently used items first.
Least Frequently Used (LFU): Counts how often an item is needed. Those that are used least often are discarded first.

How Should I Update my Cache?

As a re-iteration, caches allow you to store frequently accessed data from your database in a small localized storage for performance. That being said, Caches need to have some sort of mechanism to remain in sync with the database (or mark data that isn't consistent. This is called cache invalidation.

Write-Through Cache: new data is written into the cache and database at the same time. This allows for consistent data, quick reads, but slow writes.

Write-Around Cache: new data bypasses the cache and goes straight to the database. The cache will be populated by some other means. This allows for quicker writes, but also has the risk of creating a thing called a "cache miss", where lookup data is missing from the cache and has to go all the way to the network.

Write-Back Cache: new data goes into the cache and eventually will be put into the database. This increases speed but has the risk of potentially losing data if say... the power goes out.

Multi-Region or Single-Region

When deciding on a distributed system, you may want to distribute your system in one region or in many. This is mainly a question of reliability vs cost.

Why would I want to spread my system across the globe? Reliability. If one region system experiences something like a Hurricane, your system can "failover" to another region.

This was something that came up in a mock-interview of mine, so I thought I'd bring this up here!

Horizontal Partitioning vs. Vertical Partitioning

When you design your database, you may want to optimize it by partitioning, or breaking it up. This might be because you want to scale, balance database loads, or availability etc.

Horizontal Partitioning: If we decide to split our database up by the rows in the table (or by a particular attribute of the table), this is horizontal partitioning. The drawback to this is that if our criteria for how to partition the rows isn't good, you could have a "shard" or "partition" of the original database being loaded very hard and others being underutilized.

Vertical Partitioning: If we split our database by its particular models (let's say we have a users table, tweets table etc), this is vertical partitioning. The drawback to this is that you may need to further partition your shards if the demand for the database data goes up (because a single database may not be able to handle the cost).

Indexing

Imagine you have a giant database that you need to look through. Sometimes having a sort of table of contents would help us index directly to the right place in memory to grab data. An index serves as a separate table that stores references to the database to increase our read speeds!

Sounds great, why wouldn't we use indexing?

Well, in order to have a new record, you'd also need to generate a new/unique index. This would decrease the latency for our write operations.

Redundancy

Often when you're designing a system of any kind, there might be "weak links" that might take your whole system down if they were compromised. These are called single points of failure. Redundancy fixes single points of failure by having a backup of whatever that thing is, be it a database, a server, or even a load balancer.

The common scheme for implementing this is called the Master-Slave system. Basically the masters gets every update and eventually moves them over to the slave.

And That's It! Where To From Here?

System Design goes way beyond the basics that I went over during these blog posts. Honestly, I don't really know much more than you!

But if you are looking to really accelerate your System Design education from this point, here's what I'd recommend:

Watch some sample System Design interview questions like this one or this one or this one!
Go through the entire video and note down the terms you don't understand
Google the terms, and try to understand them with respect to what you already know
Start thinking about how you'd build some of these services! Draw it out!
Continue with the deep dive on System Design concepts and if possible, incorporate them in your own projects!

Good Luck with your learning! Stay healthy!

Reading Resources:

System Design Primer
System Design Interview
High Scalability (Website)
Grokking The System Design Interview

Video Resources:

Gaurav Sen System Design Series
File, Block, and Object Storage

System Design Intro For Bootcamp Grads: Part 2

shawnhuangfernandes — Mon, 06 Apr 2020 01:54:33 +0000

This is the second installment of my initial dive into System Design as prep for an interview for a Production Engineer. If you are new to System Design and didn't read the first blog post, I recommend it!

NOTE: Please use this as a starting point to learn about System Design, as I am super new to System Design and may be using some terminology loosely! I provide some resources at the bottom of this blog as references to dive deeper!

If you want to skip straight to the technical stuff, scroll down to the Expanding On The Fundamentals - High Level Design.

Why System Design Matters?

Whenever I'm learning something new, I always try to figure out its practical relevance to my life.

System Design has both practical and technical relevance:

Practical Relevance

In my day-to-day, I constantly use software-based services (Netflix, Shutter, even LinkedIn). I also have experienced the frustration of having those services "go down" or be unavailable for some periods of time. These services rely on good system design (the structure) as well great UI (the look) to keep customers like myself coming back and using them. Understanding System Design makes me really appreciate the deliberate decisions taken by system engineers to make sure I can enjoy the services I use and rely on day to day.

Technical Relevance

As a fullstack developer, learning basic System Design changed the way I approach project planning. Here was my current design flow:

1) "I'll plan a project" -> I create my user stories, mockups, models
2) "I will implement the project with tools that I'm familiar with" -> I usually end up picking React for the front end, and pick a REST or GraphQL style backend arbitrarily, etc.

That sounds fine, what's the problem? The problem is that I am trying to fit my project AROUND tools. The tools I'm using may not be the best fit based on my project.

This is the equivalent of saying:

1) "I need to hang up a picture frame"
2) "Well, in my toolbox I've got a sledgehammer and sandpaper... I'll make it work!"
3) You proceed to lose all house renovation credibility for the rest of your life.

Basic system design knowledge lets you break down a project/problem into its requirements and makes sure you can pick and implement the right pieces of technology for the job

Expanding On The Fundamentals - High Level Design

In the previous blog post we covered some very high level system design concepts:

Terminology/Jargon
System Design Principles
Monolith Architecture
Microservice Architecture

In this blog post, I'll try to introduce you to some of the components in a typical system. I'll also list out some resources from the last blog post (and some new ones) in case you are interested in learning more about System Design.

Bird's Eye View: A System

Looking at a system from a top level view. It'd look something like this.

Business Logic

Devices and software dedicated to serving user or internal system requests such as:

A user wants to create a new record (creating a new account) in a dating service
A user wants to see all their followers (viewing many accounts)
A user might want to update their account name (updating an existing record)
A user might want to delete their account

Business logic consists of components that let an application efficiently carry out these kinds of CRUD (Create, Read, Update, Delete) operations. Typically the servers that carry out the logic store data in some kind of data storage if future requests will need access to data.

Data Storage

These are devices & software dedicated for the long-term storage of data that the system will need to carry out its services (whether it's to let a user search a song, or follow someone's feed). This typically will hold SQL/noSQL databases or Object Storage. These respond to the business logic. Usually services interact with data storage, and therefore the storage is not exposed to client requests (they are typically the last steps in service routes).

High Level System Components

Both parts of a system may be comprised some basic components

Business Logic

Service(s)
Load Balancers

Data Storage

SQL & noSQL Databases
File/Block & Object Storage
Caches

Let's look at each of these and see what they are and how they fit in!

Business Logic

Service

A Service is function that is built of infrastructure (think servers, caches, load balancers etc.) that are designed to accomplish a specific task. They might interact with client requests or be totally internal. It lives in the business logic part of your system.

A Netflix streaming service has a single responsibility of getting a video to a user. Netflix has other independent services like a searching service, or recommendation service.
A URL shortening service... shortens a URL.
You might even have internal services (that users don't interact with), like a cleanup service that deletes old unused data, or a service dedicated to generating unique identifiers as an intermediate step in a record creation.

For example, You can imagine that a client sends a request (maybe via HTTP), which hits a proxy server that determines whether Service #1 or Service #2 handles the request. Either service handles the request and persists data to their respective database. Service #3 may get triggered every 3 months to clean up or do something with the data in both the databases. Totally random example, but hopefully it illustrates the point.

Services are the modular components that build the business logic of a system.

Load Balancers

Load Balancers are used in distributed systems when you are dealing with multiple servers that are for the same service. They balance the workload equally among all the servers, as well as re-route work in case a server goes offline (as well as other things). Here's a simple diagram of a system that would use a load balancer.

When you begin to scale your services up, perhaps you might want to install new machines dedicated to a service. You'd would then incorporate Load Balancers in your system design.

Data Storage

When talking about Data Storage for a system design, we often break them down into Databases and File/Block/Object Storage.

Databases

Databases are systematic collections of data. When you are deciding what kind of database you might need to use in your application, you'll be deciding between SQL and noSQL. Here's a breakdown of them both according to my studies.

SQL

SQL is a relational-database/table-based query language. If you've used PostgreSQL or SQLite for Rails projects, you've worked with this before. SQL is a good database structure to follow if you want a database that:

has a fixed schema (data structure never changes)
requires complex queries
has many relationships (data has references to each other)
will be interfacing with a monolith system
dealing with financial transactions

noSQL

noSQL is a non-relational/object-oriented query-language that has its own place in a system design. MongoDB is an example of a noSQL database. noSQL is a good database structure to follow if you want a database that:

has a flexible schema (data structure may change)
simple queries
does not have many relationships (not many internal references)
will be interfacing with a distributed system
easier to run metrics or calculations on the data

Block, File and Object Storage

File, Block, and Object Storage are types of data storage that is meant for storing chunks of data like images, videos, and other types of files. You'd opt for this if you have data that has no structure (maybe you'd be storing a .txt file one time and a .png another time).

Block Storage

Block storage is typically located near the server (in the same physical space). It separates its data in hard disks and DOES NOT use the internet to send data. It's all local, so it's really fast. Naturally, it's hard to scale this type of system up because of its reliance on physical space.

File Storage (Network Attached Storage)

Typically connected via a local-area-network (I think of a computer network in an office building). Data is organized into files and directories. It's not as performant as block storage, but can scale more easily.

Object Storage

A highly scalable type of storage because you can connect any device from anywhere. Whenever you hear the term "cloud", that cloud is typically backed by Object Storage. It is very good for storing large amounts of unstructured data. It is the least performant of the three types of data storage. Typically if you're working with storing media, you'll have to consider implementing some form of Object Storage in the data storage part of your system. AWS S3 is one example of Object Storage (in fact it's used very often in cloud storage).

Caches

Imagine you have a service that accesses a database to get data based on a user request. What happens if you have many requests for that same piece of data? Well, each request for that same piece of data would have to go all the way to the database, and having the server 'search' for the same record in the database would be inefficient (reference the graphic below).

If we decided to use some special "local" storage for specific kinds of data like this, we could potentially reap some benefits:

Prevent multiple calls across the network
Prevent/Avoid recalculating things (store calculations)
Avoid overtaxing a database

This is where a cache comes in handy. Caches in System Design are basically intermediate storage between a server and database dedicated to getting common/useful data quickly. A cache could be installed on the physical server (so we are not required to use a slow network call to get the data), or an intermediate source of storage between the server and the data storage. If we threw a cache into our system to reap some of the above benefits, it might look like this.

Conclusion

Hopefully at this point you are familiar with the simple building blocks of a larger system.

There's so much more left for me to learn! I feel like the more I dive into System Design, the more the topic opens up! It's exciting and overwhelming. I know a couple of my colleagues, like me, are also having interviews involving system design so I hope that this helps them and anyone else who is in the same boat!

Next Steps and Resources

Now that I have a grasp on the parts that build the business logic and data storage parts of a system, I'll try to hit on some design concepts and strategies as well as possibly answer a typical system design question in some future posts.

I hope this was helpful for you, and encourage you to learn more on your own! Here are a couple resources that were helpful for me:

Reading Resources:
System Design Primer
System Design Interview
High Scalability (Website)
Grokking The System Design Interview

Video Resources:
Gaurav Sen System Design Series
File, Block, and Object Storage

I hope this was helpful! Good luck with your own endeavors!
Shawn

System Design Intro For Bootcamp Grads

shawnhuangfernandes — Wed, 01 Apr 2020 02:10:20 +0000

Last week I heard back from a company hiring for a production engineer, and they told me that I passed a coding challenge I'd taken a month prior, and I'd be having an interview in a couple weeks. I was ecstatic!

They provided details on my interview, that would be split into three parts:

Coding (Yes!)
Systems Design (Wat?)
Behavioral (Yes!)

I had never ever heard about System Design, but I had two weeks until I was going to interview for this awesome position. So I decided to hit the books.

A System Design Primer

The definition of a System is a set of things working together as parts of a mechanism or an interconnecting network.

In this way, System Design for Software is similar to a Library System.

If you wanted a convenient way to share books between people, you might build a small library, maybe with a single person handling all the tasks of library-ing like:

Checking out books
Taking late payments
Cleaning and re-stocking the shelves
etc.

What if your library starts to gain popularity, and soon hundreds of people are coming in to use it? You may need to design the library infrastructure such that it reliably serves the increased library traffic. Maybe you'd add shelves to hold more books? Maybe you'd assign specific jobs to specific people (e.g librarian etc.). Perhaps each person might have a backup who's on call in case they are sick? This is one example of designing a reliable and efficient library system.

In this same way, if you write some code that does something useful, say... a library API. Maybe you built a single application that:

Manages check-outs
Handles transactions
Signs In/ Creates User accounts

And let's say that people love using your API, and a lot of people want to use it, we mean MILLIONS of people. You may add more servers and databases? Maybe you'd separate your central system into modular systems for each API service? Maybe you'd install backup servers or databases to make sure the API is always available. This is one example of software system design.

Is This Important To Know?

Here's what I think the perks of knowing the basics of System Design are:

If you want to build useful apps that help people on a larger scale, familiarity with the infrastructure that makes your frontend and backend go will really help you pick the right technology (i.e parts of the system) for the job.
Most larger companies build and maintain large systems, and thus System Design knowledge seems to be valued by these companies!
It is full of technical jargon, which means you'll look smart ;).

Overview of a Basic System

First, Some Terminology For Future Reference

Client: For all intents and purposes, consider it as an entity that makes requests of servers. This could be a React application making a fetch request, or a browser requesting access to a URL.
Server: It's a computer/program that takes requests from the client directly or from another component and interacts with other components like a database. This is like a controller/model pair in Rails that persists, retrieves, or updates things from a database.
Service: Pretty ambiguous term. It's a feature-specific thing the system does for you. This is like an URL shortening Service, or Netflix Streaming Service.
Database: Structured data held in a computer that persists. These are like your SQL databases hooked up in a rails backend
Request/Response: Communication typically sent between client/servers following an application protocol like HTTP. I can't really explain it better than this.
Latency: How long it takes to get a response.
Bandwidth: How much data can be passed through (aka throughput).

At a very high level, the two main pieces of a web application are:

The Frontend Client: Anything that is making the request to the backend server(s). In a Rails-React app this would mean the React project would be the Client.
The Backend System: The part that handles requests from the Client through HTTP or similar requests and persists data if necessary. This could be a cloud service, or an API that I built in backend hooked up to a PostgreSQL database.

The System simply takes requests, handles it, and gives a response back to the Client. System Design focuses on the Backend System.

Down One Level: System Architectures

So far, in the past two days, I've learned of two structures/architectures for the System: the Monolith and Microservice Architecture.

Monolith Architecture

Put simply, a Monolithic System Architecture means you have a backend system whose full functionality resides with a single unit (think of it as one giant program or machine). This architecture "style" applies to the servers as well as the database.

Server: Single program/machine that handles all fetches for all resources

Database: If you have a single database holding all the data.

If you ever built a Rails backend, that is a completely monolithic architecture. I'm pretty familiar with this so this was a bit of an 'Ah-Ha!' moment

Microservice Architecture

Microservice Architecture means that you split responsibility among different units, thus being modular. This also applies to both the server and the database.

Server: If you have separate programs/machines that focus on taking fetches for different resource (or service).

Database: If you have multiple databases, perhaps one database for each resource.

I have never built anything based on this architecture, but I have heard of some technologies that use this architecture such as MongoDB for databases and Microsoft Azure for servers. I would like to get some hands on experience at some point, hopefully before the interview.

System Design Principles

Just like there are principles when writing code (an example being the 4 Pillars of Object Oriented Programming), there are also System Design Principles. Here's what I found in my studies:

1) Scalability - What if your product/service gets popular? Are you going to buy more servers? Are you going to replace your current server with a bigger one? etc.
2) Reliability - What if part of your product/service unexpectedly turns off? Do you have backup servers? etc.
3) Availability - How often will your product/service be usable? 100% of the time (never needs maintenance)? 10% of the time?
4) Efficiency - How quick is the response to a fetch (aka latency) and how much data can pass through the system (aka bandwidth)
5) Serviceability - How easy is your product/service to operate and maintain?

As I'm learning more about the components in Monolithic and Microservice design, I'll keep these principles in mind, as they typically govern why one design decision is made over another.

Monolith vs Microservice

So, if I were trying to build my own software product, which one should I use?

As someone who has been learning about this for less than 2 days, I don't know the definitive answer. But from my research, there are advantages and disadvantages of both systems and typically it's wise to incorporate both architectures into your system to reap the benefits of both.

Monolith Pros and Cons

Pros:

Quick internal processing time: Because everything lives in a single system/machine, things DO NOT need to communicate over the network/internet. This speeds up how quickly this system can perform.
Consistent Data: Since everything is localized in one place, it's easier to make sure things are updated before returning data to the client.
Less Complex: You don't have additional parts to manage separate & distinct services. Designing it is less complex.

Cons:

Hardware limitation: Imagine having to turn off a huge system that serves thousands or millions of people every time you had to update it. Also, following a monolith architecture, upgrading your system means replacing it with something bigger and better, which works only until a point (space limitations etc.)
Single Point Of Failure: If one part of your monolith breaks, your entire monolith breaks. This is like having one giant script with a syntax error on line 43,287. Your entire script will come to a grinding halt.

Microservice Pros and Cons

Pros:

Scales Well: Because a Microservice isn't one giant thing, and is instead modular pieces that are connected via a network, when you want to add more capacity, you can add infrastructure anywhere in the world. Also, because your system is made up of independent parts, integrating a new service doesn't affect the availability of other services (nothing needs to be shut off... in a sense).
Resilient: If one of your servers suffers a catastrophic failure, like a rat chewing on wires, or the intern accidentally flips the power switch, your entire system won't crash. One of my peers gave me a perfect example of how Netflix's recommendation system might go down, but you can still watch your movies (you probably wouldn't even notice).

Cons:

Higher Latency: You have separate systems, which may need to communicate via the network/internet. This will bog down the system.
Inconsistent Data: Since your system is broken up or "distributed", getting the most up to date data is not a given. You'll need to account for this.
More Complex: There will be additional components because there's more to manage in a microservice architecture. You'll also need to connect them, which is another design hurdle.

Next Steps

What has been covered in this blog post is very High Level Design. Actually implementing these architectures (Low Level Design) is incredibly complicated and I am currently learning how to further break down systems into functional components before I apply my coding skills to implement them. There is so much left for me to learn, and I'll be trying to cover them in some subsequent blog posts. My hope is that it might help another developer with little to no knowledge of System Design feel less intimated by the subject and find some direction so they might also get prepped to take an interview that involves System Design.

If at this point, you're still interested in learning more, I'll leave a couple resources at the bottom of this post.

The next steps in preparing for my system design interview will be:

1) Learning the specific components of a distributed system (Caches, SQL, noSQL, Load Balancers, Proxy Servers) and understand their uses and how they work.
2) Learning about strategies for optimization such as Data Partitioning, Indexing, Consistent Hashing and other words that at this point sound like jargon to me.
3) Understanding the process of answering system design questions in an interview environment
4) Breaking down a couple large well known system services such as Facebook Messenger, Instagram Posts, Netflix Streaming and trying to explain it in a way that even I can understand it.

Resources For Learning System Design:
System Design Primer
System Design Interview
High Scalability (Website)

I'll see y'all in another blog post!
Good luck with your own endeavors!

Life As A Bootcamp Dev - Week 9: Big Interview and Focusing on Learning

shawnhuangfernandes — Mon, 30 Mar 2020 05:59:59 +0000

The Week In Review

I'm starting to feel like I can summarize the past couple weeks with a couple works.

COVID. UGGGGG! Learning. YAY! Job Hunting. PAAAAIIIINNNNN.

That being said, I'm going to stop "grading" myself as I have have done in previous weeks, and I'll highlight the things that were particularly interesting, insightful, or motivating that might be of value to others who are struggling with the current job market.

Although the job hunt has been slim pickings, many people (whom I didn't know) really showed up for me and took time to chat about how I could re-strategize to be successful in the long haul of what seems to be the beginnings of a rec___ion (we're not allowed to say the word, it might jinx everything).

Let's jump straight into things

A Big Upcoming Interview and Making A Commitment

Note: I have recently noticed that mentioning names of businesses and people has gotten me into trouble, so if it sounds like I'm being mysterious, it's not because I want to withhold information, it's because I learned through hard knocks.

That being said, I took a coding challenge for an entry-level apprenticeship position at a well known company two weeks ago which I had previously thought I bombed. They told me this week that they will be pushing me to the next step, which is the in-person (AKA virtual) interview which will happen in 2 weeks.

They provided me a PDF which basically said:

We will be testing you on 3 things: Coding, System Design, and your Behavior.

This is what went through my brain when I read this:

1) Coding: Cool Cool! I've been doing algorithms, and I can really be sure to learn the advanced data structures like Trees, Graphs, Linked Lists. I can prepare for this!

2) System Design: ... I'll probably start by Googling this?

3) Behavioral: I can make sure I know myself, am confident, and can relate my core values to the team and the company in a genuine and honest manner. I'm genuinely excited about the position, so this should be straightforward.

Hopefully I'm making it clear that I knew nothing about System Design.

Well, at least not explicitly (more on that later). So I decided to learn a little bit about what System Design is, and try to understand its importance for my growth as a developer who loves building things that have meaningful impact.

Long Story Short: System Design is really important, full of technical jargon, and my top priority for preparing for this upcoming interview. I am currently taking a course online, referencing some awesome resources, and leveraging connections in my network to help me prepare

Here are some resources that were provided to me, in case you find yourself wanting to learn about System Design (these were provided to me by other developers, pay their kindness forward by sharing this with people who might benefit from it):

System Design Primer
System Design Interview
High Scalability (Website)

I will be submitting a blog post in a couple days where I try to break down System Design into parts that even a goober like me can understand as part of my studying, so keep posted!

Focusing On Learning

Learning new stuff is incredibly fun, especially when you can put it into practice. I was recently on a call with someone from business who was reaching out to developers out of the goodness of her heart to help them position themselves to pull some success out of the hardships of COVID.

She gave me positive feedback on my profile, resume, and general presence, but she asked me a good question:

What are you learning?

I told her about the two projects I'm working on, the technologies I'm using, and the team I'm working with. She told me that building projects is awesome, but companies are also looking for people who are actively learning AS WELL AS building stuff.

Example: If you're working on the coolest algorithm that does something but nobody knows what, it's as if you're not doing it at all.

Lesson: Make sure companies can see what you're learning. Apply it in projects, write blogs about it, help others learn.

My plan is to target relevant skills that a development company I'd want to work for, cares about, and use them in my projects and show them on my profile. So far this week I've taken courses in the following:

Agile Development
Software Architecture Foundations

I have a list of other courses I plan on taking, but I would like to apply concepts I've learned in these courses to both of the projects that I am involved in.

The Next Couple Weeks

Since I've got this big interview coming up, I'll be dialing back my project work and diving into learning System Design and doing algorithms. I'm exciting to buckle down, learn some skills, and let you know how it goes next week!

Good luck with your own endeavors!
Shawn

Life As A Bootcamp Dev - Week 8: The Importance Of Resolve

shawnhuangfernandes — Mon, 23 Mar 2020 04:33:36 +0000

The Past Week

Last week has come and gone, and being in the midst of what looks like the beginning of a recession due to COVID, I've tried to keep my head down, stay positive, and keep myself busy. Networking is very hard, but being cooped up at home gave me an opportunity to really focus on building my tech skills. My week is reflective of that:

Summary

To be frank, it's been rough:

People are losing their jobs (which sucks), and means there's more people looking for work
People (recruiters especially) are really hard to get responses from
Hiring freezes are becoming a thing of the present, and it's becoming harder to find opportunities
Socializing with people in-person (something I love) is not an option, so much of my presence and interactions are through the internet
We've had some scares within my immediate community with COVID, which is unnerving

But there are some cup-half-fulls too:

It's very clear that I picked the right partner, we've spent literally 2 full weeks (24 hours) around each other (she's working from home) and it's been so much fun (asides from stress of the job hunt/COVID).
I get entire days to work on projects, research new technologies, or do my job prep with literally no chance of distractions
It's been a wake up call for our household on how we prepare for emergencies
I learned about GarageBand (I now realize why iPads are used for parenting)

The Game Plan From Last Week

Here were my todos from last week, with the more interesting talking points in bold.

Send out 10 applications for "Junior Software Developer" roles
Message/Follow Up with at least 15 recruiters or software devs
Continue working on Personae
Continue working on Play It Forward
Do 10 algorithms
Do 1 whiteboard practice problem
Cover a couple chapters from Cracking The Coding Interview
Draw something, or just do something NOT tech related

Continue Working On Personae

This week in Personae, my deliverable for the week was to implement backend authentication and do a slight refactor of the rails models to allow us to scale the application down the road.

After doing my model refactor, I tested the functionality out in my seeds file using

console rails c

. Yay! Using my prior Flatiron experience, the plethora of blogs, and documentation, I also got my user authentication working as well! Marked off our team Trello board and moved onto my other stuff for the week!

Continue Working on Play It Forward

This was a really fun and challenging week in Play It Forward. I was charging ahead and trying to really get our rough application views working so we could play with the GraphQL/Hasura backend that Jen had built. At this point, I'd been playing with Tailwind and React for long enough that I had developed a strategy to quickly whip out some views in a methodical way.

Create the page as a component in my pages folder
Divide the mockup for that view into reusable components, and create them

In the page container component, add divs to structure the page to the appropriate layout

import React from 'react';

import Navbar from '../components/Navbar'
import AuthWindow from '../components/AuthWindow'

// Layout
// Navbar, AuthWindow
const AuthPage = () => {
    return (
        <div className="auth-page w-screen h-screen">
            {/* Navbar */}
            <Navbar />

            <div className="auth-page-body flex h-full justify-center items-center">
                {/* AuthWindow */}
                <AuthWindow />
            </div>
        </div>
    );
};

export default AuthPage;

Add one component into the page at a time, and test it to make sure it works. In this case I was building the AuthWindow component rendered above.

import React, { useState } from "react";

import LoginDialogueBox from "./LoginDialogueBox"
import SignUpDialogueBox from "./SignUpDialogueBox"

// ClickableTabs (x2), LoginBody || SignUpBody
const AuthWindow = () => {
  const [loginTabbed, setLoginTabbed] = useState(true);
  const [isVolunteer, setIsVolunteer] = useState(true);

  const tabHeaderClass = "flex text-white justify-center items-center w-6/12 h-12 ";
  const selected = "bg-blue-500";
  const unSelected = "bg-blue-600";

  return (
    <div className="auth-page-window flex flex-col h-80 w-9/12 bg-red-400">
      {/* Clickable Tabs */}
      <div className="flex">
        <div className={tabHeaderClass + (loginTabbed ? selected : unSelected)} onClick={() => setLoginTabbed(true)}>
          Login
        </div>
        <div className={tabHeaderClass + (loginTabbed ? unSelected : selected)} onClick={() => setLoginTabbed(false)}>
          Signup
        </div>
      </div>

      {/* LoginBody || SignUpBody */}
      {loginTabbed ? <LoginDialogueBox isVolunteer={isVolunteer} setIsVolunteer={setIsVolunteer}/> : <SignUpDialogueBox isVolunteer={isVolunteer} setIsVolunteer={setIsVolunteer}/>}
    </div>
  );
};

export default AuthWindow;

Then you get Jen's opinion how how it looks, and see if it needs tweaks

Building UIs this week was really fun. I learned a LOT about CSS from using Tailwind's utility-driven library, and I also began converting components into Typescript with Jen's help! Most of all, I became a lot more confident with managing using state and props as well. Currently all the views are built for mobile, so next week I will be making the UI responsive for desktop as well!

Draw Something (or just DON'T code)

Because I've been drawing animations and images for Play It Forward. I decided I'd take a small break from coding during the week and practice my drawing. I particularly was interested in just getting my hands on a pencil (or apple pen?) and putting my brain on a page.

In the spirit of feeling grateful for the good things we do have, despite the challenges of the job hunt, My partner helped me come up with this.

This is actually a title page for a secret thing I'm doing, but I'll tell you more about that later down the road ;).

Good luck with your own endeavors!
Shawn

Life As A Bootcamp Dev - Week 7: Long Term

shawnhuangfernandes — Mon, 16 Mar 2020 05:40:39 +0000

This Week

The COVID crisis has affected King County (where I live) pretty significantly, and as a result, dampened my ability to network and interact with others. I consider myself lucky, because I personally haven't experienced any hardship further than not being able to go out to restaurants, which is very minimal.

Here's my illustration of this week:

Overall: It was more or less was productive. Being forced to be in my house for multiple days did make me feel little bit crazy. Here's a quick synopsis of what I did. Items I will be talking about in further detail are bolded.

Presence:

Sent out 10 job applications
Worked with my mentee at ADA on one of her new projects

Networking:

Sent messages to over 20 recruiters to get information on positions and/or companies, and surprisingly heard back from a couple!
Sent messages to around 10 software engineers working in positions I applied for, and some of them even got back to me!

Learning:

I started reading Cracking The Coding Interview once again to get a handle on data structures that weren't covered during my bootcamp
I completed 9 algorithms (I'm starting to go into LinkedLists, and some of the algorithms were taking me over an hour to figure out!)
I really dived into Github, React, and Rails as I collaborated on Personae and Play It Forward with my two teams.

Working On Personae - Setting Up A Rails Backend API

Before I dive into what I did, a quick snapshot of what Personae is.

Personae is a text annotation tool that allows organizations to collect feedback on projects and pull out meaningful data from them using machine learning.

I suggested our team use Trello to split up our deliverables. After our kickoff meeting on Monday, I ended up taking responsibility to build the server of our web application!

My plan was to build a Rails API that could serve data to be consumed by the frontend.

The general flow of how this happened was:

Used rails scaffolding command to generate a rails project setup with PostgreSQL database
Double checked gems/libraries needed (bcrypt, cors etc.)
Checked config files (ensuring CORS was enabled)
Generated resources for Models.
Setup relationships using Rails conventions in each model
Build some very simple serializers to clear up some of the JSON that'd normally come back from my API endpoints
Setup the routes for the API endpoints using the nested API::V1 convention
Migrated everything to create the schema so any created instances of the models would live in the database
Tested for expected behavior using the rails console
Populated seedfile with some data to show the team before our Friday check-in

I hadn't done much Rails in a while, and it was a good exercise to get back into the flow with the backend. I coordinated with Christian (the frontend person) to make sure the JSON I was planning on sending was structured properly for the client to receive!

When we connected at the end of the week, I presented the backend data as JSON, Christian presented the frontend view he had build, and the PM took notes and updated us on the work he was doing meeting with potential clients. Very cool stuff! We'll be connecting next week to set up the next sprint!

Working on Play It Forward

Play It Forward has been a blast to work on. Just as a recap on its purpose:

Play It Forward is a web application where nonprofits and volunteers can connect with one another through events, and volunteers are incentivized to engage through added elements of a game.

This week I was working on some rough front end views just to understand how we will be working with a new CSS library called Tailwind. I wanted to wrap up 2 basic views:

Nonprofits List Page
About Page

Jen (my collaborator on this project) spent the week trying to refactor one of my components into Typescript and also integrate the backend she built using GraphQL.

For some reason I can't seem to attach images, so I'll share those at a later time!

For next week, Jen and I will be swapping roles, and I will be learning GraphQL and Typescript, and she will be using my views as a reference to build our login/signup page using Tailwind. I'm excited to see how she does as well as learning a new web service methodology (as opposed to REST).

Preparing for The Long Haul

I'm beginning to think that this job hunt will be especially difficult considering some factors:

Recruiters being less responsive considering COVID
Reduced hiring capabilities due to the state of the economy
Less opportunities to meet with people to work on things

Considering that previous grads averaged a 3 month job acquisition in a normal economy, I'm mentally preparing myself to be ghosted more frequently for the next couple months!

My Simplified Game Plan For The Long Haul

Seeing as networking will be pretty much done remotely, and my online presence is pretty much based on my ability to network at this point, Here's my short laundry list of things to do for next week:

Send out 10 applications for "Junior Software Developer" roles
Message/Follow Up with at least 15 recruiters or software devs
Continue working on Personae
Continue working on Play It Forward
Do 10 algorithms
Do 1 whiteboard practice problem
Cover a couple chapters from Cracking The Coding Interview
Draw something, or just do something NOT tech related.

This will be tough for sure, but I was once told that people who work hard tend to be luckier than those who don't, so I guess I'll just do my best to be lucky :).

Good luck with your own endeavors,
Shawn

Life As A Bootcamp Dev - Week 6: Quarantines, Routines, and the Job Scene

shawnhuangfernandes — Mon, 09 Mar 2020 03:39:37 +0000

The Past Week

Since I'm very much still in the job hunt from last week (going on about one month and a half), I'm still trying to keep myself accountable on all fronts. Here's how I felt I did.

Summary

As some (or all) might be aware, the corona virus (or COVID-19) situation has had a noticeable effect in Washington State and as a result I took precautions and did a self-quarantine. As a result, I haven't had the chance to go out and meet with people and attend meetups. I added some little COVID monsters as an indicator that I wasn't being lazy. That being said, this was a relatively productive week, and here's a summary (talking points will bolded):

I officially passed on a job opportunity from last week, and connected one of my colleagues with the company.
I submitted 10 job applications.
I reached out to 15 recruiters/developers on LinkedIn.
I completed 15 algorithms and did 1 whiteboard practice problem).
I began officially mentoring for ADA.
I officially began work on Personae.
I built some views for Play It Forward with Jen.
I had my resume reviewed and polished it further.

Passing On An Offer

From last week, I interviewed with a really cool startup for a position as a developer advocate. Looking back, I was just so excited that ANY company wanted to hire me and I jumped into the interview with both feet and tried to bring my authentic overly-enthusiastic self to the table.

For my interview, they gave me about 2 hours to use their platform's API to build something. 2 hours is a long time, and I barely got myself set up with an access key within that time. I had barely anything to show when the time was up.

I still remember the moment when the CEO walked into the room and asked "So how did it go?", and I responded jokingly with something along the lines of "How did what go?". I was initially embarrassed but started feeling way more comfortable when we started talking because I could be totally honest about how I felt about the interview, the position, where I was as a developer, and my future.

Here are samples of things I remember saying during my interview (just add rambling and awkward pauses and it'll be like you were right there):

"I don't think I have the experience that you need to fill this position, this looks like you will need someone who understands the underlying workings of web technology as it applies to developers. I have a good practical understanding from my bootcamp, but it would take time for me to learn the underlying things"
"Have you thought about reaching out to developers through Hackathons? Having a hackathon sponsored by you folks where you encourage the use of your API in a project would be a cool avenue to promote your product"
"This is my first interview."
"This WeWork space is so fancy!"

So overall, being honest didn't help me say the right things, but it helped me hold a genuine conversation as if I was working with them, which I was told later, was something they appreciated.

An important takeaway for me was when my interviewer asked me this question:

"What ONE thing do you want to do?"

Which, of course, in my brain I heard myself say:

"Oh man, say whatever you think she wants to hear, SAY YOU WANT TO WORK WITH APIS FOREVER"

She could tell I was having an internal struggle trying to not BS but also not 'throw away' the interview. She put a nugget of knowledge in my head that really helped me understand how I could be better with my job hunting.

She told me that many members of her engineering team were not chosen originally because they were super-duper software engineers or data scientists (in fact they weren't even remotely involved with web technologies). She picked the people on her team because they were magical.

To her, magical people love doing one thing, dive deep into it, and get really, really, REALLY good at that one thing. The rationale is that if you have the discipline and interest to follow-through with one thing (whether its frontend, backend, devOps, drawing, mechanical engineering, writing) you have the ability to be magical about anything you care about.

Her advice to me? Pick ONE thing you really enjoy, practice it, don't give in, and integrate that thing into whatever you do, wherever you work

The conversation with her made me realize that my fear of not being able to apply to all the jobs because of weird qualifications was irrational, and made me lose touch with why I decided to struggle with a new career in the first place.

I loved making experiences and I wanted to integrate creativity and technical knowhow to grab everyone's attention and reshape the way they live their lives for the better. In order to do that, I'd need to build my skills (clearly I need more practice with APIs)!

I learned some awesome skills in web development, and instead of trying to justify that I knew all the buzzwords on all the entry-level job postings, I'd better start working really hard to learn and build stuff one stack that I enjoyed. React is easily my favorite, so from here on out I'll be focusing on React (with some dabbling in React Native for fun) with some Rails just to keep my backend skills up to par.

That being said, I realized that the position wasn't totally aligned with the skills I was trying to build, and I respectfully declined, but also connected them with another candidate who I know would be a rockstar for them!

Mentoring With ADA

I really wanted to give back to the dev community, especially to those who found it difficult like I did to pick up dev skills. I decided it'd be a good idea to be a mentor for others, and after finding the ADA school, I wanted to donate my time! I was set up with a mentee and had my first (and second) 1-on-1 online session with them. This was really awesome for multiple reasons:

The tech stacks students learn at ADA are identical to those I learned at Flatiron (Ruby, Rails, React, Javascript)
They are project based (very intense!), so I got to work with this person on projects, which is more challenging than helping with concepts in my opinion
My mentee is not from a programming background, is super motivated, and can definitely make a huge impact in her own community when she enters the tech space for real

They are currently working on a Ruby project to set up some has-many relationships. It is a good refresher for me to help someone else, and it is something I look forward to every week!

Working on Play It Forward

Working on a React project feels good. Jen and I did some extensive brainstorming and planning, so this past week I did some coding! I had access to the mockup, which let me break down each page into its components. When I was coding up each page, I had a couple of priorities:

Build the structure, do not flush out every detail. I want to get Jen's opinion during our check-in meetings and standups to keep her in the loop.
Add helpful comments that help break the page up for readability. I anticipate that other developers may jump on board this project, and keeping it easy to read is really important.
Add personal flair. Even though I'm building some structure, since I am responsible for the UI, I wanted to take some opportunities to inject my own personality into the project to keep it fun! Jen actually liked some of the rough gifs and images I made.
Build for mobile first, then come back and make it responsive for desktop.

Example: The Landing Page

I built two views this week, the landing page and an events list page. Let's walk through how I built the landing page using React and Tailwind.

Looking at the mockup I drew using Procreate, this is what I had to follow:

I recognized that in the Landing Page we had three main components:

Header (needs a header component)
Text (add h1 or other html text)
Event List (needs an event card component, and event container)

I ended up deciding to replace the text with a Logo gif (that I made in Procreate), so the structure looked like

Header
Gif Logo
Event List

When I wrote the code in react, I tried to make this apparent.

// React Imports
import React from "react";

// Custom Imports
import Navbar from "../components/Navbar";
import EventCardCollection from "../components/EventCardCollection";
import trophyGif from '../media/animations/trophy-rotate.gif'

// This functional component renders the landing page
// Layout (from top --> bottom):
// Navbar, Logo, Upcoming Events
const LandingPage = () => {
  return (
    <div className="flex flex-col w-screen">
      {/* Navbar */}
      <Navbar />

      {/* Logo */}
      <div className="flex items-center justify-center h-64">
        <img className="h-64" src={trophyGif} alt="" />
      </div>

      {/* Upcoming Events */}
      <div className="flex flex-col items-center justify-center w-screen flex-grow">
        <h1 className="font-bold text-xl pb-1">UPCOMING EVENTS</h1>
        <EventCardCollection />
      </div>
    </div>
  );
};

export default LandingPage;

The class names are coming from Tailwind. Styling with it was really fun, and it actually helped me understand what CSS actually does (and learned CSS in the process). I prefer this over prebuilt components that naturally hide CSS from you.

The page, after some basic polish, looked like this:

You might notice that the color scheme is not the same as the mockup, and that's because I'm building it for a mobile view, but the mockups are for desktop. This will be apparent for every page, but Tailwind provides some nice utilities to dynamically change layouts based on screen size, which I will be visiting later down the road.

Note: Jen is working on the backend data, so I created some mock data in the same format as Jen will be providing from the backend which I used to populate the event cards.

I followed the same design process for the event list page:

I'll be checking in with Jen on Monday to walk her through what I've done, and see where she's at. Very exciting React stuff!

Working on Personae

Kicking off our React Project Personae has been awesome. They're both very dilligent, involved, and just pleasant people. This past week we were getting the project setup, and also committing to 2 meetings a week. Mondays we will have standups (for deliverable setting), and Fridays we will have recap meetings (for reviews).

In the beginning of the week we did our standup zoom meeting and we assigned some basic deliverables to each of us.
My deliverables for the week were:

Create a simple react project with tailwind setup on it
Create a rails backend api hooked up with postgresql
Draw up a simple model visualization for the backend

The first two bullets were really easy. I had a project (Play It Forward) that was already set up with react and tailwind. I pretty much used that project as a boilerplate and set it up on Github. The rails backend was also just a simple command line action and it was also created.

For the model visualization, I had the page mockups that the PM provided in an awesome slide deck. Looking through those, I categorized what kind of data we'd need for a backend and drew it up in Procreate (drawing software).

Our team met at the end of the week to have our recap meeting:

The PM shared with us clients he met to discuss use cases.
Christian provided a frontend view component list so we can jump straight into the UI and get coding.
I provided my deliverables

Right now everything is going smoothly, we will be meeting again on Monday to set new deliverables for the upcoming week!

Next Week

This week felt productive but I think I spent a lot of time working on projects and doing coding-related activities, but I will need to keep on networking and sending applications out. It does feel nice to have some project work going on, because I can definitely talk about it in the upcoming interviews-to-be-had. Very excited for what the next week will bring!

Thanks for reading! Good luck with your own endeavors!
Shawn

Life as A Bootcamp Dev - Week 5: Interviews, Offers, and the Power Of Networking

shawnhuangfernandes — Mon, 02 Mar 2020 08:26:21 +0000

This Week In Review

This week was pretty exciting overall! I had an interview for a cool startup which was a humbling and eye-opening experience. I completed nearly all of the items on my todo-list from last week, and even learned some information that might really help me strategize about how I might job-search in the future. Here's my rating for this week:

Stuff I Said I'd Get Done

From the previous week I had a list of things that I needed to get done before I 'had any fun'.

NOTE: I will be marking in bold the items I will be elaborating on. If you are curious about any of the items I'm don't talk about during the blog, feel free to reach out to me on LinkedIn or here.

Presence - how people see me

Send 15 applications out
Get feedback from my portfolio website
Update my portfolio website

Learning - developing base competencies in programming and development

Update Flexable Native initial views (incomplete)
Solve 15 algorithms on Leetcode
Try to whiteboard 3 problems
Work on Play It Forward
Work on Personae
Read Chapters 7-11 on Cracking The Coding Interview

Networking - forming awesome relationships with awesome people

Email follow-ups
Software Engineering Interview Meetup
Other Meetups (incomplete)
'Coffee' Meetings

Additional Things That Happened

I became a mentor for the ADA bootcamp**
I had an interview with a company and am being considered for a position

Incomplete: Updating Flexable Native

I mostly wanted to talk about this because you too, may need to make an executive decision to drop some of your expectations for how much you can get done! I made the decision to postpone Flexable Native and here's why:

During weekdays, I was:

Going to meetups
Meeting with people in-person
Reaching out to people via LinkedIn
Sending Cold Applications
Committed working on 2 projects with actual people
Committed to being a volunteer mentor at ADA
Doing algorithms
Trying to practice whiteboarding
Trying to dive deeper into tech stacks that I know

During the weekends, I was:

Trying to spend quality time with my partner
Serving as a life coach at a non-profit
Apparently fixing my parents' fence (as a TOTAL side note, if you have to choose between a privacy fence and not, don't pick a privacy fence)

Asides from making myself pretty busy, the biggest factor that made me drop Flexable Native was that I was working on two other projects that I absolutely love and furthermore, that I was a member of a team.

To me, collaborative projects are not only great opportunities for developing your tech skills (in the same way personal projects do), but they build incredible relationships and demonstrate a highly-valued skill companies look for: Working well in teams.

Try To Whiteboard 3 Problems

A lot of my weekdays have been spent at Flatiron, and I do the job hunting shenanigans in the company of at least 4 other graduates. We decided to each do a whiteboarding problem where one of us becomes the interviewee, and the rest of us become the interviewer. Having this dynamic makes it more interactive for both parties (as opposed to awkwardly watching someone mumble and struggle on their own). I've learned a lot about whiteboarding process (it almost feels like a game). Here's the breakdown:

First Understand the problem. Ask clarifying questions and eventually re-state the problem back to the interviewer so you are BOTH on the same page
Then, Diagram the problem. Drawing some sort of pictorial view of how you plan to handle the data/structures is a really strong way of demonstrating that you put a lot of thought into solutions rather than immediately trying to code a naive solution
Then Pseudocode your solution. Writing your solution in plain english will once again demonstrate that you know (from a top level) how to solve the problem, and will also help your interviewer help you solve the problem (since they know ever step you will be coding out before you write any code down).
Then Code your solution. Obviously practice really helps here, but there are also small things that can help you not get overwhelmed like partitioning the whiteboard space into 3 columns to save space, or making a truth table to hold values so you can 'debug' your own code, talking about what data structures you'd like to use up front, how you'd optimize your code, or what the Big O Notation of your code is.

Work On Play It Forward

Jennifer Williams (one of my peers from Flatiron) and I had sat down and began flushing out some actual deliverables on our old Hackathon Project reboot.

This was a learning opportunity to learn some new web technologies together, so part of our planning involved choosing what technologies we'd use. Here's the list we made:

We wanted to try to keep our work process accountable, so we jumped on Github Projects and started a kanban board for our backend and frontend. Here's a snip of our frontend git repo.

We normally start our web applications with some mockups, so I decided to use Procreate on my iPad to draw our mockups. Here's a couple photos of some of the mockups.

That being said, I am working on the Frontend portion of this project, and Jen is working on the backend part. I'm excited to keep practicing my React skills and dive a little more into styling using a new framework called Tailwind CSS. Jen helped me figure out how to configure it with Create React App and now all that's left for me to do is build each view with its respective components. This upcoming week, I'll be diving into React and building actual (hopefully) reusable components to build the UI.

Work On Personae

Had an initial meeting with the team for Personae and we all agreed on a schedule:

Monday we will have a standup where Christian and I will talk about what features we want to implement that week, and our general plan for doing so
Friday we will touch base with the PM to discuss what worked, lessons learned, and get his insight as he is the visionary for this project

We are meeting on Tuesday to also get the project off the ground. Christian and I won't necessarily be working on separate pieces, we both may end up working on backend and frontend portions as needed.

Very excited to see where this goes!

Sending Email Follow Ups

I learned something very cool this week. People really like it when you care about them.

In all seriousness, I wanted to see how a lot of post-grads were doing, so I just sent them an email/message asking how they were doing. So many of them were so receptive and even offered to meet up and chat about how my job hunt was doing. From that, I not only got some more people to potentially come to a board game night I'm planning on hosting but they also were nice enough to offer to refer me to people they knew (or even recruiters).

Be nice to people, and be genuine! Kindness is a powerful networking tool.

Software Engineering Meetup

I attended a meetup this week that definitely changed how I looked at my position as a job seeker. It was hosted by a company called Outco and they had an initial portion dedicated to advanced algorithm techniques such as Tabulation and Memoization, but the later half of the meetup was very relevant to me because it was about how to do reverse-recruiting.

If I had to summarize what reverse recruiting is, it is your ability to humanize the people you network with, identify the problem they're trying to solve, and engage with them in a way that helps them recognize that you are solving their problem.

When I first started reaching out to recruiters, I basically said this:

'Hey, I hear your company is hiring for some job. I want that job. Here's 6 reasons you should give me that job. I am... I have done... I'd love to talk more about why that job should be mine.'

However, this comes off as selfish, and it totally ignores the recruiter and their problem. You can notice that I mention I... I... I'm...I over and over again. Here's the steps (from what I gathered) to reverse recruit when reaching out to engineers, recruiters, and possibly CEOs.

1) Recognize THEIR problem (Recruiters are PAID to find you, Engineers are paid bonuses for referrals etc)
2) Share your solution to their problem using WHY, HOW, WHAT

Why you're interested in helping them solve their problem (make it mutual)
How you found them
What experience and skills you bring to them table 3) What potential do you have (Why should someone invest $100,000 in you)

Although I haven't heard any responses from recruiters, I will definitely share responses from recruiters after using this strategy in future blogs.

Had an Interview For A Company, And Got An 'Offer'

I was reached out to by a startup that said they liked my resume and my portfolio website and wanted to have a phone screen a couple days ago. I'll break down the order of events:

Got an invitation by the startup to have a phone screen for a position
Accepted the invitation, and began reading up on the company and the position (I read blogs, CTO/CEO bios)
Wrote up reasons why I liked the company, and how they were aligned with my development goals, and also wrote up a list of risks (for both the company and myself)
Did the phone screen, which was pleasant. They asked me about my strategy with learning new technologies, why I got into tech, and my experience working with others. I saw opportunities to be honest about my excite for the opportunity, while also being transparent about the fact that this was a high-performing startup which I might lack the experience to contribute to. I emphasized my willingness to learn, which resonated with the person.
They decided to move me into an on-site interview. I met their Head of Product via zoom in the morning, went into their WeWork space and was given a task of using their API to build something simple. I failed, I very much struggled with the API documentation and had to call in the CTO multiple times to help me just get a basic setup started.
I met the CEO after and spoke about the experience. She was really honest about the nature of the companies work, which I read as "I don't think you'll be a good fit at the moment". I practically told her "I don't think I'm the person you're looking for". We still had a good conversation and she left to discuss with her team. The CTO came in and asked me if I'd like to work with one of their product engineers for two weeks to see if I'd be a good fit. I told them I'd think about it.

I honestly don't know if I handled this situation in the best way possible. I was absolutely nervous, I felt really dumb, I babbled and spoke in circles. I caught myself thinking too much about what my interviewers must be thinking about me.

This startup seems like an awesome opportunity to dive deep into technologies and also use my creativity to build wacky apps using their API. They are also in a market that's growing super rapidly, so being a part of that wave seems great too. On the flip side, I just don't know if I have to developer chops to perform at the level they need, and I have a HUGE fear of disappointing others.

Well, I'll hear more about this next week, so in the mean time I'll just be chugging along with more job hunting stuff!

Good Luck With Your Own Endeavors,
Shawn

Life As A Bootcamp Dev - Week 4: Another Week, Another Job Hunt

shawnhuangfernandes — Mon, 24 Feb 2020 08:54:00 +0000

This Week In Review

This week went a lot smoother than last week, considering that I came in with a plan of attack for tackling the junior dev job hunt! Here's how I thought it went overall:

Presence - 8/10

AKA how I worked on how I appear to job recruiters, companies etc

What I Did

Sent out 10 job applications (previous week deliverable)
Finalized my Gatsby portfolio website (previous week deliverable)
Reach out to 5 recruiters and 5 developers (previous week deliverable)

How It Went

Sending out 10 job applications (cold applications)

It took some time to compare my desired job criteria against the actual job postings on LinkedIn, GlassDoor, Dice and other job boards. This included:

Reading the desired qualifications, and re-arranging my resume as necessary
Writing a unique, genuine cover letter as a supplement to the application
Contacting any bootcamp grads or engineers who may already work for that company for insight

I have been told that cold applications are typically the most unlikely way to get an interview as a bootcamp junior dev. That being said, some people get discouraged or don't understand the point of cold applications. I personally feel like cold applying is a great way of understanding more about the type of position you want to work in. I don't have expectations to hear back from employers, but I will put my best effort when sending my application materials over!

Things I Could Do Better: Send more applications out, and also do more sleuthing on finding actual people to talk to rather relying on an ATS algorithm to have mercy on me.

Finalizing my Gatsby Portfolio Website

It is finally up! You can find it here! It feels good to be able to actually have a website that is a central place to look at my projects and also see information about me. I haven't quite figured out in what circumstances I should share my portfolio project, but I am excited to fill in the fields for job applications that ask for it.

Things I Could Do Better: Having the Gatsby portfolio site is nice, but I definitely need to revisit it to make it more responsive. I'll get feedback on it and go from there.

Reaching Out To 5 Recruiters and 5 Developers

I wanted to reach out to recruiters to just let them know that I was interested in both the company as well as particular positions their companies were hiring for. I used LinkedIn to find all the recruiters by:

Seeing the recruiter on the job posting and contacting them that way
Searching the company on LinkedIn and finding the people/recruiters who worked for that company and messaging them

Of the 5 recruiters I messaged, 0 have responded. This is alright because I came in with the understanding that this is normal. Recruiters' accounts get blown up on LinkedIn, but I wanted to do my due diligence.

Reaching out to developers was particularly successful. I looked for bootcamp developers who went to Flatiron, particularly other earlier graduates who snagged jobs. This was much easier than writing a message to a recruiter:

I was very much excited to see how their new jobs/lives were
They would give me really honest feedback on their work
Most of them were situated in Seattle, and I could set up coffee meetings
Some of them very much understood the struggle, and offered to help me polish up things like my resume, or get me in contact with another professional

Things I Could Do Better: I spoke to a lot of people, and sometimes I'd want to reconnect with them at a later time (like a recruiter or someone who offered to help me out). I will be creating a separate category in Trello to track my conversations or follow-ups!

Next Week

Send 15 applications out, and try to contact developers/recruiters to learn more about each position if possible
Get feedback on my portfolio website from other developers
Fix up platform/size issues on portfolio website

Learning - 6/10

AKA how I learn to speak code, solve algorithms, and build projects

What I Did

Completed 15 Algos (on LeetCode)
Play around with React Native to build 4 simple views for one of my old projects, Flexable

Things I Didn't Do:

Read Chapters 7-11 on Cracking The Coding Interview (I didn't realize the amount of time meetups and new projects would take, and cut this out of this week's activities)

How It Went

Completed 15 Algos (on LeetCode)

These were all focused on Array operations. I think as an exercise it was really nice to keep my Javascript skills sharp. Furthermore, it was a good exercise in thinking about what a solid algorithm answer looks and sounds like. Whenever I tried solving an algorithm, I would think about some things I learned from Cracking the Coding Interview:

What is the O(n) in terms of speed and memory usage?
What type of data structure might be ideal for the algorithm?
What might be potential pitfalls/refactors to optimize the solution?

This helped me learn not only just how to solve the problem, but also how to talk about the problem, which is a really important part of white-boarding interviews.

Things I Could Do Better: Find some people to do actual white boarding with, and try to do some mock white board interviews with some colleagues! Also, maybe share some of my solutions with others to get feedback on the readability of my code!

Play Around With React Native

As an exercise in a mobile development, I wanted to make small steps towards learning how to use React Native by building some simple views for one of my old projects. In my quest for mobile competence, I started learning React Native Navigation so I could go between my views. There were some additional projects and meetups that I became involved with that took some time away from this, so I mainly just got around to learning and implementing some basic routing. Here's a sample:

// React Native imports
import React from "react";
import "react-native-gesture-handler";
import { NavigationContainer } from "@react-navigation/native";
import { createStackNavigator } from "@react-navigation/stack";

// Custom imports
import LandingScreen from "./screens/LandingScreen";
import AuthenticateScreen from "./screens/AuthenticateScreen";
import MenuSelectionScreen from "./screens/MenuSelectionScreen";

import { YellowBox } from "react-native";
YellowBox.ignoreWarnings(["Remote debugger"]);

const Stack = createStackNavigator();

export default function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator
        screenOptions={{
          headerShown: false
        }}
        initialRouteName="LandingScreen"
      >
        <Stack.Screen name="LandingScreen" component={LandingScreen} />
        <Stack.Screen name="AuthenticateScreen" component={AuthenticateScreen} />
        <Stack.Screen name="MenuSelectionScreen" component={MenuSelectionScreen} />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

I spent a lot of time reading React Native docs and understanding how stacks, screens, and components all fit into the larger mobile 'navigation' picture. I added a simple button with an event listener to make sure stuff worked! Here's a sample of my landing screen with the equivalent of a Link To in regular React:

// React Native imports
import React from "react";
import { View, Button, Text, StyleSheet } from "react-native";

// Custom imports
import colors from "../constants/colors";

const LandingScreen = ({ navigation }) => {
  return (
    <View style={styles.screen}>
      <Text>This is the landing screen</Text>
      <Button
        title="Go to Authenticate"
        onPress={() => navigation.navigate("AuthenticateScreen")}
      />
    </View>
  );
};

const styles = StyleSheet.create({
  screen: {
    height: "100%",
    width: "100%",
    paddingTop: 40,
    paddingHorizontal: 15,
    backgroundColor: colors.primary
  }
});

export default LandingScreen;

I'm excited to continue further into React Native land next week!

Things I Could Do Better: I need to partition my time accordingly, because there's quite a few new activities that will be on my plate for the next week!

Next Week

Add UI components on each of the 4 views, and have functional navigation between
Solve 15 more algos on LeetCode
Try to do 3 Whiteboarding Sessions either by myself or with other people
Work on Play It Forward (see below)
Work on Personae (see below)
Read Chapters 7-11 on Cracking the Coding Interview

Networking - 8/10

AKA building meaningful relationships with other professionals

What I Did

New Project: Play It Forward
New Project: Personae!
Went to a SeattleJS conference
Went to a Career Path In Tech Meetup (Last Week's Deliverable)
Going to a Junior Dev Struggle Bus Meetup (Last Week's Deliverable)
Going to a Community Hack Night Meetup (Last Week's Deliverable)
Got a Referral for an actual job and took an interview and bombed it
Contacted by a consultant and sat down to talk about contract jobs
Reached out to various people and set up some meetings and explore some cool opportunities!

Things I Didn't Do:

Try to balance Networking with Learning and Presence (I definitely neglected learning React Native because I was running everywhere).

How It Went

New Project: Play It Forward

Play It Forward was one of the projects I worked on during one of Democracy Lab's hackathons. It was the brainchild of Jennifer Williams, one of my classmates at Flatiron and myself. We both loved the idea 6 weeks into our bootcamp and promised each other we'd keep working on it after we graduate. Sure enough, Jen and I reconnected and decided we'd get cracking. We met at a coffee shop and started making a plan of attack!

We're hoping to use this as a opportunity to practice our React chops and do some deep dives into new technologies such as GraphQL, Tailwind CSS, Apollo, Typescript.

New Project: Personae

During last week's Diversity and Women in Tech meetup, I met some really awesome people, including a PM working on a cool project. After some casual conversation he mentioned he was looking for support for a project that he was trying to get off the ground that might help local government and beyond. Coming from a government job, this really resonated with me, and it looked like he wanted some help mocking up a proof of concept web application. I volunteered to help him out and we set up a meeting this week! I brought this up to my Flatiron cohort and one of my peers, Christian Kastner, expressed interest, so we joined forces to help the PM work on this project. More details on this in upcoming posts!

Went to the SeattleJS Conference

My first conference! It was a very technical jargon heavy conference (talking mainly about cool new tools), and it was hard to follow the content. I decided to leave early and go home and work on my projects, algorithms, and job applications.

Things I Could Do Better: Try to endure a jargon heavy experience (by Googling and make connections with people!

Went To Career Path In Tech Meetup

One of my old coaches at Flatiron who is now employed, Lucy Suddenly, was a panelist during this meetup, and I wanted to support her. Additionally, I love compassionate tech spaces that are actively trying to support those who are statistically at a disadvantage in the tech field. This meetup mainly hit on the non-conventional ways the panelists found their way into a tech job.

Things I Could Do Better: I actually spent a lot of time socializing, but I forgot to actually connect with people on LinkedIn or leave thank you messages for the hard work of those who planned the event. Gratitude goes a long way!

Going to THE JDSB (Junior Dev Struggle Bus) Meetup

Great Meetup with a mixed crowd of developers sharing their experiences with job hunting, networking, and learning. It was held in a loud bar, and I found myself almost losing my voice just trying to talk to people! It was really encouraging to chat with other devs going through the same experience as myself. I connected with some other bootcamp devs, but I also decided to leave early to get home on time!

Community Hack Night Meetup

Simply some time for developers to work on personal projects in a group setting. I went with my fellow graduates Jen and Fonzie and we used the time to study. We arrived slightly late and didn't talk too much to anyone. I definitely want to go again and work on my React Native Project, Personae, and Play It Forward with other community devs.

Got A Referral, Bombed an Interview

I applied to an awesome company and was introduced to one of their recruiters who gave me an opportunity to actually take a pre-screening frontend technical interview on Code Signal. If I passed the test, I would move on to the next stage.
I was given 1.5 hours to tackle three coding questions:

A simple algorithm involving arrays (or string, or numbers, based on how you approached it)
A basic DOM manipulation problem in JS
A string-related algorithm I was incredibly nervous, and had never taken an interview before. I accepted this as a learning experience and jumped in expecting to struggle, and struggle I did*.

My strategy was this:

Solve the problem using a naive solution if an elegant solution wasn't clearly obvious to me
Write comments explaining each step
Below the code write how I would optimize for performance, what I thought the big O was, and possible caveats/refactors

I spent 20 minutes on the first problem, 60 minutes on the second problem (which didn't pass the tests), and ran out of time on the third problem. I understood DOM manipulation pretty well during my bootcamp, but after 6 weeks of React and no vanilla javascript, I was very rusty.

What I Could Do Better: Practice writing Javascript, try to do as many technical interviews as I can.

Spoke with a Consultant about Contract Jobs

A Consultant reached out to me this week and wanted to know if I was interested in doing contract work in the future. I set up a meeting to learn more about it and met them on-site. After a short discussion I gleaned the following knowledge:

This wasn't a job offer, this was just trying to gauge whether or not I would be interested in being considered for contracts. I would still be interviewing for these positions.
The consultant did not just reach out to every bootcamp grad (to my surprise), and mentioned that it was clear I put a lot of thought into my resume, which was the reason they reached out to me. Arguably, I don't really know what their bar is.
The consultant did not find me on LinkedIn, but apparently found me on Dice. I happened to be on Dice because I had applied to a job that required a Dice account.

The person I met was actually really nice, and very honest about the pay and how their business operated. It seemed like a good opportunity for junior devs to get a food in the door with a company if hired on contract, because companies often hire contract engineers to full time positions later down the road.

When I got home, I sent a thank-you email to the person I met, and also wrote a reminder to check back in with them at the end of next week.

Reached Out To A Bunch Of People

I've been really active with reaching out to a lot of people. I think the biggest lesson I learned this week is that helping people and being nice is the best networking strategy. Many people who have offered to help me out have either worked with me on a team or are people who I made laugh. I have a couple exciting activities lined up with some people this next week, and we'll see what happens! I'll be sure to talk about it in more detail later!

Next Week

Email Follow Ups
Software Engineering Interview Meetup
Other meetups
Coffee Meetings

In Closing

This week as been really busy, but there's definitely room for improvement. I now totally understand why job hunting as a junior dev takes a lot out of you. However, I have enjoyed branching out, meeting people, working on meaningful projects, and exploring the options for my future. Whether it takes 3 days or 3 months, you'll find me here, working and blogging!

Good luck with your own endeavors!
Shawn