Forem: Emma Bostian ✨

Lights, Camera, Action! My Tech Setup For Recording Courses && Podcasts

Emma Bostian ✨ — Sat, 03 Oct 2020 10:58:36 +0000

Earlier this week I posted a couple of tweets regarding my new camera and lighting setup! Many people were interested in what technologies I use to record online courses and podcasts so I’m here today to share all of the details!

// Detect dark theme var iframe = document.getElementById('tweet-1311629958960353281-925'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1311629958960353281&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1311940745344024577-483'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1311940745344024577&theme=dark" }

As a quick note, I am NOT a tech equipment expert. In fact I was advised to buy this specific equipment by trained professionals who have created online content for years.

I also want to explicitly note that this equipment is EXPENSIVE. I understand that many of you are not able to afford most of this equipment and for that I apologize. Where possible I will recommend more affordable equipment but the reality of it is that if you want the best quality content you have to spend some money.

Some of this equipment was provided by work, but the camera, lights, adapters, tripod, camlink, and keyboard I purchased myself. It was painful for me to spend the money but I keep reminding myself that this is a business expense and it will pay off in the long-run.

Also remember that this is my setup and yours could look completely different! I haven’t tried a ton of equipment variants so I am a bit biased in my reviews. I advise you to do your own homework and research the best solutions that fit your budget. You don’t have to purchase all of the equipment at once; you can accumulate it over time!

Please don’t judge me for the cat hair and fingerprints on my equipment. I ain’t got time to clean that shit everyday. With that, let’s jump right in!

Keyboard

Okay I’ll admit, I have a keyboard problem. I’ve tried a bunch of different keyboards in all different price ranges and every time I see a fun new keyboard I have an overwhelming desire to purchase it.

I recently backed the Keychron K3 Ultra Slim Compact Wireless Mechanical Keyboard and am very much looking forward to receiving that in the mail someday.

The keyboard I’ve been using for a long time is the Mini Ducky Frozen Llama keyboard.

This keyboard uses the Cherry MX mechanical switches, which means it’s not as deafeningly loud as other mechanical keyboard switches (so your coworkers won’t hate you as much).

While I love this mechanical keyboard and find it both aesthetically pleasing and easy to type on, I have some issues with it.

First, this is a Windows OS layout and while many of the keys map to Mac OS, I still find it a bit hard to use as the command and option keys are swapped from the Mac layout.

You’ll also notice that I don’t have an up-arrow key. This is because the Frozen Llama keyboard is a 60% layout, meaning it doesn’t have all the keys.

When I received the keyboard it didn’t have any arrow keys, but I re-mapped the keyboard and replaced the keycaps on the right-hand side to use the shift key as the up arrow. This poses issues when I try to use the right-side shift key and instead get an up-arrow.

This keyboard isn’t wireless which means it adds to the spaghetti nightmare of cables on my desk. Not a huge fan, but not a dealbreaker.

Lastly there is no back tick (`) / tilde (~) key which makes coding a freaking nightmare. There are keys on the Ducky keyboard which map to these characters but in all honesty I have no idea what they are and end up using my Mac keyboard when I need to insert those characters.

I paid about $99 for this keyboard off of mechanicalkeyboards.com and it took a few weeks to arrive. I probably wouldn’t re-purchase this. While it’s great it’s a bit impractical and I’d opt for something with a wider layout.

Laptop Stand

I use the Twelve South Curve laptop stand and I absolutely love it. I received this stand through work but it retails for about $50 give or take. I would 110% recommend this stand and purchase it for myself if something bad happened to it (but let’s hope it doesn’t).

Mac Adapter

If you have a MacBook then you understand the f*cking struggle of not having enough holes to plug your shit into (sorry for the profanity, I feel very strongly about this). And when you’re expanding your tech equipment you’re gonna have a lot of shit to plug in.

I’ve used this Mac adapter for years and really love it. I don’t know the exact brand but I did buy it off of Amazon. Here’s a comparable model that runs about $24.99.

If you’re going to be using a 4k monitor, be sure to have a 4k HDMI port (the one I linked above does). For all of the equipment I use, I need three USB ports and a 4K HDMI port but if you have a wireless keyboard you won’t need the third USB port (so the link above should work, and no it’s not an affiliate link although maybe it should be).

Monitor

I use the Dell Ultrasharp 27” monitor. I’ll just come out and say it: this shit is expensive retailing at over $400. I absolutely love this monitor but if it wasn’t provided through work I wouldn’t have purchased it (I am cheap ironically). The thought of spending more than $200 on a monitor seems absurd to me but then again I do appreciate the high-quality so really what do I know.

But to be fair it does move up and down, tilt forwards and backwards, rotate for landscape or portrait mode. It’s wide AF so you can troll Twitter while on a Zoom call without anyone knowing you’re not paying attention. And it’s a matte display so you won’t see all the nasty fingerprints left when eating Doritos while coding.

I’ll also admit that I know nothing about computer monitors, but the kind people of Twitter do know something about monitors so feel free to check out this thread on the best monitors for your workspace.

Microphone

When I began podcasting I started with the Shure SM58 LC microphone (I think). This microphone was provided through a podcast I frequent, JSParty and I used this with a pop filter (a noise protection filter for microphones that eliminate popping sounds). for quite a while. The quality was really good so I’d recommend this mic to someone starting out in the podcast industry. It retails for about $99 and you’ll need a mic stand to hold it up (unless you want to pretend you’re at a karaoke bar).

You’ll also need an adapter for this microphone (it’s not a USB) and an audio box (which we’ll discover in a subsequent section of this blog post). The adapter is an XLR male to XLR female and retails for about $8. All I could find is the German website so I apologize but you can likely find the same product in the U.S. if that’s where you’re shopping from.

Next I migrated over to the Blue Yeti USB microphone which retails for about $115. This mic is great for anyone looking to create online content or sound way cooler than their coworkers on meetings. It’s also free standing which is nice and allows you to plug your headphones directly into the microphone to hear yourself.

Now, if you’re looking for the ultimate podcaster/content creator/influencer setup, I got you covered. Enter the Shure SM7B microphone. This is the ultimate badass podcaster microphone.

This microphone doesn’t mess around, it’s super legitimate and as far as I know one of the best microphones on the market. It does cost about $400 but the quality is unparalleled. I recommend using the round pop filter the microphone comes with as I’ve been told it’s the most effective and I blindly listen to other people’s advice without fact checking.

Similarly to the first Shure microphone, you’ll need a male-to-female adapter as well as an in-line microphone preamplifier. I use the TritonAudio FetHead Germanium which is also expensive at a retail price of 929 SEK (Swedish kronor) or about $104.

Again you will need an AudioBox (which I’ll cover in the next section) and a microphone arm (which I’ll also cover) so in total this microphone setup retails for about $520 depending upon where you purchase each product. I’d recommend using a legitimate audio equipment website versus Amazon not only to support more local businesses but to ensure the quality of your products.

Audio Box

If you’re going to use a microphone that requires an adapter (like the two Shure microphones mentioned above), you’ll need to buy an audio box. I use the PreSonus AudioBox iTwo.

This audio box allows for two device hookups (i.e. two microphones) and retails for about $150. If you don’t need two inputs you can opt for a one-input audio box like the Scarlet Solo which retails for about $100.

I haven’t used this audio box but I was sent it by LinkedIn Learning to record a course so I’m sure their audio engineers have vetted the plethora of audio boxes available on the market. I’m also pretty sure Ali and Kelly use the Scarlet Solo to record our Ladybug Podcast episode.

Remember you’ll need a preamp to connect your microphone adapter to your audio box (I’ve listed mine above). Then you can connect your audio box to your computer via USB port. Here is what my setup looks like. (microphone => mic adapter => preamp => audio box => USB into computer).

When using an audio box you’ll want to learn about mic gain and how to set up your audio box. Here’s a video that explains the whole process. Admittedly I have no idea how to use my audio box; I generally plug it in and hope it works so I should probably watch the video I just recommended lol.

Microphone Arm

To hold up my Shure SM7B microphone I use the MIKA YellowTec mic arm. This mic arm is extremely expensive at about $400 depending upon where you purchase it. It comes preloaded with a mic adapter although if you move your mic arm in a specific way, the wires inside can snap and you’re screwed. I did this. Don’t be like me. Treat it gently.

You’ll also need to buy a mic arm clamp. I use the YellowTec MIKA YT3210 Table Clamp which costs about $50. It’s one of the best clamps I’ve ever used and is easily adjusted. Your mic arm just sits inside of it!

Here is my desk with the mic arm, clamp, microphone, and adapter all hooked up! Please disregard the cat hair…

Lighting

I don’t understand much about lighting but I did purchase a light for my setup (as recommended). I haven’t used it yet because it’s still light out in Sweden but come the Swedish winter it will become my best friend!

I use the Elgato Key Light LED Panel With 2800 Lumens. Again, this shit is expensive, but it seems to be the best on the market. It retails for about $199 per light and since I’m cheap I only bought one but I might invest in a second come winter-time. It comes with the desk clamp and is extremely easy to assemble!

Camera

Okay now on to the equipment everyone wants to know about: the camera. I bought the Sony a5100 for about $500 (yeah, it freaking hurt). I didn’t purchase any additional lenses.

To be honest, I have no idea how to use this camera. I don’t know what the specs mean or how to adjust aperture or whatever else anyone who’s decently versed in cameras talks about. I just plugged it in and went on my merry way. Again, I was advised to purchase this. So far so good but yeah… not cheap. Although, there are more expensive cameras out there so… yeah I have no idea what I’m talking about.

I also purchased the Joby JB01507 GorillaPod tripod for about $50. It’s honestly super cool but it’s a table-top / “I can cling to things” tripod, not a standing tripod, so there are limitations.

Along with the camera I purchased some accessories. The first is an adapter. This functions as a “battery” and allows you to keep your camera charging while using it. I use the Sony AC Adapter. I want to say it was around $100 and if you plan to use your camera as your web meeting camera, I highly encourage you to purchase it.

I bought a remote control for camera recording. I haven’t used it yet but it will definitely come in handy when recording online courses. I bought the Sony Cybershot remote control. This cost about $70 and sadly I can’t tell you my opinion as I haven’t used it.

Lastly I purchased the Elgato CamLink 4k. This allows me to use my camera as a web camera in meetings. It costs about $150 (so not cheap) but the quality is unparalleled.

Lastly I bought a micro-HDMI cable to connect my camera to the CamLink and a USB card (obviously). Both of these things can be purchased for relatively cheap at most home/electronics stores. My setup is: camera => mini HDMI cable => USB cable => CamLink => Mac adapter.

And that’s my entire setup! I spent way too long on this blog post so I hope it’s useful for you! I know this is all completely overwhelming and very expensive but if you’re looking to create a business out of digital content creation, unfortunately at some point you’ll need to spend a decent amount of money to achieve the quality you’re looking for.

If you have any questions, feel free to leave a comment but I probably won’t know the answers to most of them lol.

Have a lovely day!

5 Things You Need To Become A Senior Developer

Emma Bostian ✨ — Tue, 29 Sep 2020 08:09:01 +0000

In this week's Ladybug Podcast episode we chatted about the skills it takes to level up from a junior to a senior developer.

Junior to Senior Developer: Career Progression for Programmers

Ladybug Podcast

Your browser does not support the audio element.

1x initializing... ×

Before jumping into this topic I want to preface this with the fact that every single employer has different qualifications for what constitutes a senior developer, and just because you're a senior developer at one company doesn't necessarily mean you'll be a senior developer at another company.

Nothing frustrates me more than seeing "I became a senior developer in six months after joining the tech industry" blog posts. Not only do they instill a sense of inferiority in developers who take longer than six months, but there are many factors that go into a promotion.

Having a computer science degree, having a social media following, having a backlog of content to showcase your skills, and having excess time outside of your 9–5 job are all examples of privilege that facilitate your ability to become a senior developer.

As an industry, we must stop perpetuating this idea that if you hustle hard enough, it only takes "X" months to become a senior developer. It may take you sixth months, or it may take you six years. Don't let anyone influence your idea of how long it should take you to achieve a promotion.

Talk with your manager. Find out which boxes you need to check off before becoming a senior developer, and block out the noise that is present on social media.

But despite each company having their own definition of what it takes to become a senior developer, there are a few characteristics which all senior developer exhibit. Today we'll take a look at five of these characteristics which will jumpstart your progress towards becoming a senior developer.

Autonomy

Independence or freedom.

One of the primary qualities of a senior developer is having autonomy, or being independent. As a senior developer, you're expected to deliver work without needing much assistance. This doesn't mean you can't ask questions(in fact, you should ask questions), but it means that if you're given a task you're able to construct a solution and you know what questions to ask if you get stuck.

Autonomy is one of the characteristics I have struggled with for several years. Early on in my programming career, I felt lost. It's absurdly nerve-wracking to pair with senior team members and watch them seamlessly navigate their way through the code. How do they know where to start? How did they know this bug was originating in this file? How did they know to ask this specific person for help?

I'll let you in on a secret: all of these questions can be answered with "it just takes time and experience." It's safe to bet that your team members also felt this impending sense of impostor syndrome when they joined the company. And no matter how much programming experience you have, joining a new company with a new tech stack and new colleagues will always require time to acclimate.

When I joined Spotify this July, my manager and colleagues told me it would take at least six months to feel self-sufficient and productive. It's important to set appropriate and realistic expectations for yourself when joining a new company (especially as an entry-level developer).

But if your goal is to be promoted to a senior developer role, you must start exhibiting autonomy with your work tasks.

Initiative

The power or opportunity to act or take charge before others do.

Before promoting you to a senior developer, your manager wants to see that you take the initiative to find challenging tasks and help team members in need.

If you finish your task early, actively seek out other tasks or bugs that you can work on. If you see a team member struggling with their task, offer your assistance. If you see additional areas outside of your team to get involved, like helping to plan an internal conference or mentor a new team member, go for it!

You should also keep a list of your accomplishments. This will make it easier to reach the next level as you won't be scrambling to remember what you accomplished the past year.

Don't wait around for someone to give you work: actively seek out new and challenging work and write down your accomplishments.

Communication

The imparting or exchanging of information by speaking, writing or using some other medium.

Ahh "soft skills", every programmer's favorite area to excel in. I personally don't understand why "soft skills" are taught as a lesser skill for programmers. The higher up the ladder you climb, the more important your communication skills become.

The ability to write and speak effectively has many benefits. Whether it's impressing your colleagues during a technical presentation or writing up an internal blog post, communication is key.

To become a senior developer you must be good at explaining not just what you're doing, but why. This is especially important when mentoring more junior team members.

Understanding and conveying the why behind tasks will solidify the skills you're learning as well as the skills you're teaching.

Problem Solving

The process of finding solutions to difficult or complex issues.

Problem solving is an undervalued skill for all developers because it's not necessarily a skill developers are taught in bootcamp or degree programs. The ability to solve complex problems will arise throughout your career and will scale in complexity the longer you spend in the industry.

Learning how to problem solve early-on in your career will put you at an advantage when looking to achieve a promotion. I won't delve into the specifics of problem solving in this post but let's take a look at the general process.

First, you must identify and clarify the problem. Problems are often more nuanced than we initially perceive. What are you trying to solve? Are there dependent sub-problems that must be solved along the way?

Once you understand the problem you should list the possible solutions. What are the different ways you can solve the problem?

Now you're ready to evaluate your options. What benefits and drawbacks does each solution present? Are there performance implications for a solution? What about accessibility concerns?

You're now ready to select an option and build it. If you realize along the way that your solution isn't technically feasible or you encounter an unforeseen issue, you can always go back to step three and reevaluate your options.

Lastly, you can document your solution so that your team members can understand why you selected the solution you did.

Problem solving is an invaluable skill and it's undeniably one you'll need to become a senior developer.

Mentorship

A period of time during which a person receives guidance from a mentor.

One of the biggest factors in becoming a senior developer is the ability to mentor another team member. Mentorship is often though of as a formal relationship wherein the mentor has all the answers to the mentee's questions. This is an archaic definition of mentorship.

Mentorship is a symbiotic relationship where both parties are gaining knowledge. While most of the information will flow from the mentor to the mentee, the mentor should also be open to learning from their counterparts.

Mentors also shouldn't give out answers to the mentees' questions. Asking a question and receiving an answer has short-term benefits. Instead, a mentor's job is to guide the mentee towards the solution. By providing boundaries for your mentee to ideate and learn, their problem solving skills and confidence will grow more quickly.

As a senior developer you're expected to mentor more junior team members. It doesn't need to be formal (although a formal mentorship will serve your promotion more easily than an informal mentorship) but the act of supporting another team member will make strides towards your desired promotion.

The biggest piece of advice I can give to those looking to level up from a junior developer to a senior developer is to exhibit the characteristics of a senior developer before you have the title. If your company provides a chart with senior developer qualifications, make sure you're achieving the senior developer requirements before applying for a promotion.

And lastly, be patient. Being promoted to a senior developer can take months or years so don't compare yourself to other developers outside of your company.

Creating A Custom Scroll Bar In 24 Lines Of CSS

Emma Bostian ✨ — Thu, 27 Aug 2020 13:36:16 +0000

Have you ever encountered a website with a beautiful scrollbar and thought to yourself “wow, I wish I could create something like that.” Me too! And after a little investigation, I figured out that creating a custom scroll bar for your blog or personal portfolio doesn’t take a ton of CSS.

Today we’ll build a gradient progress bar that fades in from zero opacity to full opacity as you scroll. This tutorial only requires foundational HTML, CSS, and JavaScript knowledge and won’t make use of any JavaScript frameworks or libraries. You can find the full code on CodePen!

HTML.

First let’s create our document structure. Inside of the HTML CodePen editor let’s add two elements: our progress bar and our progress container.

The progress bar will indicate how far down the page the user has scrolled. The progress bar container will span the entire height of the page and contain the progress bar.

Let’s also add a page header with the text “Welcome” and some lorem ipsem paragraphs. I added seven of these paragraphs but for the brevity of this post will only include one.

<h1>Welcome.</h1>
<p>
  Lorem ipsum dolor, sit amet consectetur adipisicing elit. Aspernatur
  provident eveniet veritatis ipsa id consectetur ab tenetur dolores eaque.
  Temporibus laboriosam cum corporis amet doloremque animi aut ipsa ea a?
</p>

Here’s what our web page currently looks like.

CSS.

Now we’re ready to add our styles. First let’s add some basic page styling to make our site look a little nicer.

body {
  background: #171414;
  font-family: "Courier New", Courier, monospace;
  color: #ffffff;
  padding: 15% 15% 5%;
}

p {
  font-size: 1.8rem;
}

p:first-of-type {
  margin-top: 100px;
}

h1 {
  font-size: 200px;
  position: absolute;
  top: -5%;
  left: 15%;
  opacity: 25%;
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen,
    Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;
}

Next let’s hide the default browser scroll bar. We can use the webkit vendor prefix to hide the scroll bar in Chrome and Safari.

::-webkit-scrollbar {
  width: 0;
  background: transparent;
}

We’ll need to make special considerations for Firefox as it’s not a webkit browser and won’t respond to the webkit vendor prefix (like Chrome and Safari).

html {
  scrollbar-width: none;
}

Now we’re ready to style our custom scroll bar. First let’s set up our scroll bar container. We want our scroll bar container to be fixed to the right side of the viewport so we’ll use position fixed with top and right values set to 0. We’ll give the scroll container a width of ten pixels and a very light grey background.

#progressBarContainer {
  position: fixed;
  top: 0;
  right: 0;
  width: 10px;
  height: 100%;
  background: rgba(255, 255, 255, 0.05);
}

You should now see the scroll container appearing on the right side of the viewport.

Our progress bar will also be fixed to the right side of the viewport and have a width of ten pixels, however, we’ll give it a linear gradient from red to violet in order to make it stand out.

#progressBar {
  position: fixed;
  top: 0;
  right: 0;
  width: 10px;
  background: linear-gradient(to top, violet, red);
  height: 100%;
  opacity: 100%;
}

We want to dynamically update the height and opacity of our progress bar on scroll so let’s set height and opacity to zero.

#progressBar {
  position: fixed;
  top: 0;
  right: 0;
  width: 10px;
  background: linear-gradient(to top, violet, red);
  height: 0;
  opacity: 0;
}

JavaScript.

To update the height and opacity of our progress bar we’ll need to write a few lines of JavaScript. Let’s first grab our progress bar DOM node.

const progressBar = document.querySelector("#progressBar");

We’ll also need to calculate the total height of our web page. We can calculate the total height by subtracting the window inner height from the entire document body scroll height.

let totalPageHeight = document.body.scrollHeight - window.innerHeight;

Next, let’s add an event listener to the window. When we scroll we want to calculate the new progress height. We can calculate this by first dividing the window’s page Y offset by the total page height to get a decimal fraction. To use this value in our CSS code we must multiply this fraction by 100 (to get a percentage).

Lastly, we can set the progress bar’s height and opacity to the new progress height.

Unfamiliar with the ${} syntax? It’s called a template string or template literal and it allows you to combine evaluated expressions (the values between the ${}) with plain strings.

window.onscroll = () => {
  let newProgressHeight = (window.pageYOffset / totalPageHeight) * 100;
  progressBar.style.height = `${newProgressHeight}%`;
  progressBar.style.opacity = `${newProgressHeight}%`;
};

Conclusion.

And that’s it! You now have a beautiful custom scroll bar in just a few lines of CSS.

5 Tips On Landing Your First Developer Job

Emma Bostian ✨ — Fri, 31 Jul 2020 14:30:34 +0000

This week, Honeypot.io published a short video where I gave “5 Tips For Junior Developers | How To Break Into The Industry.”

One of the first comments that appeared said “‘How to break into the industry’ should be about how to get that job at IBM, and not what you did after you got it. Or am I missing something?”

After a bit of reflection, I realized that Stefan was completely right! I had skipped over a vital time in the developer’s journey: how to land your first developer job.

Today I want to address this gap and give you five tips on landing your first developer job.

I want to preface this post with the caveat that I was very privileged in my job search. I completed an internship at IBM and from there was offered a role internally at IBM. I did not have to apply for a multitude of jobs to land my first developer job.

Prior to landing a job with LogMeIn (my second role) and subsequently at Spotify, I applied for as many jobs as I possibly could. I did not hear back from nine-out-of-ten companies that I applied for and I struggled to determine why. I had landed my first job without much effort, why was I having so much trouble landing a second job?

The following tips have come out of my struggle to land a role and I hope they help any developer out there struggling to find their first or second role.

Have A Unique & Complete Resume

Let’s be honest: landing a job interview is difficult in-and-of-itself. We always discuss how anxiety-inducing the technical interview process is but we don’t often discuss how difficult it is to even get an interview in the first place.

When applying for your first role it can be intimidating to know which roles to apply for. Do you apply for a junior developer role? Do you apply for an entry-level developer role? Often the job requirements don’t perfectly align with what you deem your skillset to be, so you have two options: apply only to roles which you feel tightly align with your skillset or apply to all roles you think you generally fit into.

Regardless of which option you choose one thing is certain: you must have a stand-out resume to get noticed. Recruiters see hundreds of resumes and only spend about 7.4 seconds on average reviewing resumes.

A few tips for having a notable resume include:

Use a fun resume design to stand out from the other candidates
Prioritize the most important information at the top
List your contact information at the top
Don’t include a photo
List what direct impact you had on the success of a project in your work experience bullet points
Include quantitative data points to back up your work experience “so what” statements
I won’t be diving into the nuances for creating a technical resume, but I did create a full course with LinkedIn Learning that you can check out for more details!

Here’s what my resume looks like! Remember, we’re in a creative industry so you have a bit of freedom when designing your resume!

Demonstrate Your Willingness To Learn New Skills

When companies are looking to hire an entry-level developer they want someone who is motivated to learn. As a developer, we’re expected to stay up-to-date and learn continuously, thus it’s imperative to highlight your willingness to learn during the interview process.

If you have the time and ability to take a few online courses I highly recommend it. FreeCodeCamp, LinkedIn Learning, and Coursera are a few online learning platforms that offer certificates upon completing a course. You can add these to your resume and your LinkedIn profile.

Additionally, if you’re asked in an interview if you have experience with X technology, you can state “I haven’t worked with X before but I would be eager to learn it!” This shows that you’re excited to grow as a developer and from the company’s perspective this translates into a candidate who will be a great investment.

Avoid The Ego Trap

Straight out of college I had the biggest ego you can probably imagine (especially with an IBM internship behind me). “I deserve a great job and I won’t have any trouble getting an offer.”

There is a massive difference between having confidence and having an ego. I had a massive ego and it hindered my growth as a developer (and a human) for several years. I’ve seen many new developers also fall into the ego trap. The longer you work in the tech industry the more you realize how much there is to learn.

When hiring managers are making their decision they want to bring on a team member with humility. They want someone who is a team player and is not afraid to admit when they don’t know the answer to something.

Some of you reading this may not have fallen into the ego trap but I certainly did. Take some time to reflect on how you present yourself to interviewers but also how you view your own skillset. If you’re riding the border between confidence and ego it might be time to do some self-reflection. It will positively impact your success at landing your first developer job.

Demonstrate Your Skills With Projects

If you completed a college degree in software engineering or computer science you have an advantage over other applicants who did not complete a technical degree. If you completed a boot camp you likely have one or two projects that showcase your skills. But if you’re self-taught or are switching industries you likely don't have a large backlog of projects.

While it’s becoming more commonplace to hire candidates without formal education, I would be remiss if I didn’t acknowledge the privilege that comes with a relevant college degree. If you don’t have relevant formal education, I highly encourage you to have two or three coding projects on GitHub that showcase your work. It will be time-consuming but having these projects will increase your chances of landing your first job.

Learn How To Solve Complex Problems

Technical interviews are hard, it’s why I’m currently in the process of creating a full course on how to be successful in your technical interviews. A good technical interviewer will want to see how you approach complex problems, they won’t necessarily expect you to find the correct solution.

I never learned how to effectively solve problems and it put me at a massive deficit during technical interviews. A few tips for demonstrating good problem-solving skills during technical interviews include:

Clarify the question (they’re left with a few missing pieces to see if you can deduce them)
Write down the functional requirements (what are the things your solution absolutely must include)
List possible solutions as well as benefits & drawbacks
Speak your thoughts out loud
Admit when you don’t know something
Optimize your solution
Test your solution
Explain areas for improvement

I’m not an expert on how to solve problems so I encourage you to take time to learn how to solve complex problems. But by following the guidelines above you’ll improve your technical interviewing skills.

Landing your first developer role is exhausting and frightening. Keep in mind that everyone in the industry has gone through the same process. The reality of it is that it may take time to land a job interview and it will likely take you several tries to land a job offer.

I won’t tell you not to get discouraged: you will. Let yourself experience your emotions. Take a break from applying and interviewing and focus on your mental health, and come back to the process once you’re ready. You can do this.

The Beginner's Guide To Creating & Growing Your Blog!

Emma Bostian ✨ — Fri, 17 Jul 2020 09:43:14 +0000

Over the past month I've been working hard to write and publish The Beginner's Guide To Creating & Growing Your Blog and the wait is finally over!

In June I ran pre-sales of this e-book as a fundraiser for Black Lives Matter. I donated several thousand (cumulative) Resilient Coders, Black Women Speak, and Until We Are All Free. A huge thank you to everyone who pre-ordered the book and supported the fundraiser.

I am happy to say that the book is available again for purchase! There are two versions of the book: basic and complete.

The basic version is priced at $19 and includes:

12 activities
276 pages
Lifetime updates to the book
EPUB, MOBI, and PDF formats

The complete version is priced at $30 and includes:

12 activities
306 pages
30 pages of financial breakdown & analysis
Lifetime updates to the book
EPUB, MOBI, and PDF formats

Read it? Let me know what you think!

Why We're Not Publishing A New Episode This Week

Emma Bostian ✨ — Mon, 01 Jun 2020 06:24:12 +0000

Dear Ladybug Podcast friends,

We’re writing today to inform you that we won’t be publishing an episode this week. We strongly believe that the death of George Floyd and the protests happening across the country are of utmost importance. We are taking this week to remember not only Mr. Floyd but all Black people who have been unjustly killed.

We have donated our sponsorship profits from the next episode in support of Campaign Zero. Donating is just one way we can help the Black community and we encourage all of our listeners, if you’re financially able, to do the same.

We’re taking this week to educate ourselves about anti-racism and hope you will too.

Being Antiracist
Justice for George Floyd: What to Read and What You Can Do
Anti-Racism Resources For White People
Ain’t I a Woman: Black Women and Feminism by bell hooks
I Know Why the Caged Bird Sings by Maya Angelou
So You Want To Talk About Race by Ijeomo Oluo
How To Be An Antiracist by Ibram X. Kendi

Racism is not a “United States” issue: it’s a world issue. We all have a responsibility to stand against racism and support the Black community. Our Black friends and colleagues are hurting. Are you listening?

// Detect dark theme var iframe = document.getElementById('tweet-1266558160338325504-670'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266558160338325504&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266246773812588545-778'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266246773812588545&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266893273039159296-728'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266893273039159296&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266808675169009665-640'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266808675169009665&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266421245140221952-855'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266421245140221952&theme=dark" }

What's the kindest thing someone's ever done for you during your career?

Emma Bostian ✨ — Tue, 21 Apr 2020 16:16:03 +0000

We need some love during these difficult times, so let's start a wholesome thread.

What is the kindest thing someone's ever done for you during your career?

I Passed The Google Technical Interviews; You Can Too.

Emma Bostian ✨ — Thu, 16 Apr 2020 10:26:14 +0000

All of my illustrations come from UnDraw. Thank you for your work!

I pulled myself out of the Google hiring process after passing the technical interview process. I know what you're thinking: "Are you crazy?! Who pulls out of the Google interview process?"

This blog post will discuss my history with interviewing at Google as well as tips for passing your technical interview process (at any company).
Google is notorious for having difficult technical interviews, and is a highly coveted company to work for, which is why I chose to highlight it in this blog post.

That being said, there are many amazing companies to work for (some which aren't as well-known as this tech giant) and THAT IS OKAY. You don't need to work for a well-known company to be a successful developer.

Additionally working for a big company has drawbacks as well as benefits (which I'll cover in this post). Determine what you want out of a job and look for companies that emulate those core values and working environment.

I can only speak to the JavaScript/front-end interview process at Google (or any other company) and my interviewing experience might not mirror your interviewing experiences so please take my advice and experience with a grain of salt.

I won't divulge the interview questions asked during my Google interviews (or any other technical interviews) as I believe it's unfair to company. As a candidate you want to be hired for your problem solving skills and that's why I chose to highlight the skills you should study versus the interview questions I was asked.

Don't memorize solutions, learn the problem solving skills needed to build a performant solution! You can refer to the interviewing tips section for more insight on having a successful technical interview.

Lastly I just want to say thank you to the entire Google team as well as any current or former employees I talked with. My recruiters were phenomenal and every interviewer I met was wonderful to talk to. They never made me feel unintelligent and made me feel comfortable. The questions I were asked were fair and assessed skills I would encounter in my day job. And for that I say thank you.

History

This was my third time interviewing with Google (each time I got a bit farther). Here's the overview.

Round 1: 2016

The first time I interviewed was back in 2016 when I was still living in Austin, Texas. I was DULY unprepared for the technical interviews but managed to make it through the recruiter phone screen and had two technical phone challenges before I was rejected.

Round 2: 2019

The second time I interviewed with Google was at the tail end of 2019. I thought I was interviewing for a UX Engineering role on the Material Design team, however I ended up going through the full Software Engineering interview process and was a bit unprepared.

I passed the phone coding challenge and moved on to the on-site interview on the Munich campus. I had two front-end technical interviews, two data structures and algorithms interviews, and one interview centered around development process, communication and cultural fit.

One of my front-end interviews was conducted on a Chromebook over Google Hangouts and unfortunately we had technical issues (i.e. the Chromebook wouldn't start up, Hangouts wasn't screen sharing) and spent half of the interview troubleshooting. I was also told that my JavaScript skills could use some improvement.

As a result the interview was thrown out and the team wanted me to re-interview in a month or two back in Munich. At that time life was a bit chaotic and I declined to re-interview.

Round 3: 2020

Early in 2020 I re-interviewed with Google for a UX Engineering role and because I had just interviewed with them a few months prior the interview process was expedited for me (I did not have to re-do my phone coding challenge or on-site data structures and algorithms or process/cultural fit interviews).

I did a take home UX/engineering project where I designed user flows and information architecture, created high-fidelity mock-ups using Sketch, and built an app. I then documented my process and tooling selections in a succinct document.

Once past the take-home challenge I had three "on-site" interviews which were conducted over Google Hangouts (due to COVID-19). I had two front-end technical (coding) interviews and one UX interview discussing my take home project and enhancements that could have been made from a UX perspective.
After the "on-site" interviews I was informed by my recruiter (two days later) that I had passed the interviews and would move on to the hiring committee and team matching phase.

I met with a potential hiring manager to discuss the role at hand. Ironically I had met the manager during the second round of interviewing in Munich so it was nice to meet him again.

After meeting with the manager I waited for several weeks, and in the mean time continued interviewing with other companies. Unfortunately due to COVID-19 the internal hiring process was a bit chaotic and I ultimately ended up accepting an offer at another company.

I'll never know if I would have received an offer from Google, however I'm pretty damn proud of myself for passing the technical interviews. As someone who was told I wasn't good enough and felt I wasn't good enough to make it in this industry, I was proud I had even made it to the on-site interview round.

What It Takes To Get Hired

To be hired at Google you have to exhibit the following characteristics.

Be a kind person
Have a willingness to learn
Have good communication skills
Be a good problem solver
Exhibit great teamwork
Have empathy

Based on my experience they're not looking for geniuses, but rather kind-hearted, hard-working people with great communication and teamwork skills, and this holds true for many companies.

General Interview Process

The general Google interview process has five to six phases:

The general Google interview process has 5–6 phases:

Recruiter phone interview
Technical phone interview / coding challenge
Take home assessment*
On-site interview
Team matching phase
Hiring committee

* This step was only necessary for the UX Engineering role and not the Software Engineering role.

Let's dig a little deeper into each phase.

Recruiter Phone Interview

During the recruiter phone interview the recruiter will tell you a bit more about the role and the interview process. Don't take this interview lightly, however, as each step in the interview process is important and counts towards your overall performance.

Some tips for the recruiter phone interview include:

Read up on the role and the company ahead of time
Be on time
Have two or three questions prepared to ask the recruiter
Thank them for their time

Your recruiter will fight hard to get you an offer, so treat them kindly!

Technical Phone Interview

If your recruiter phone interview goes well you'll move on to the technical phone interview. During this call you'll pair up with a Googler who will give you a coding challenge question.

I had one question to answer and it primarily tested the following skills:

DOM manipulation (accessing DOM nodes, performing some task, dynamically generating new DOM nodes)
CSS

I coded my solution in a Google document. Here is the approach I took to problem solve.

Ask clarifying questions: The questions are left with a few missing pieces because the recruiter wants to see how you think.
Write pseudo-code: Writing pseudo-code allows you to get your thoughts in order before you jump into the code.
Code a brute force solution: You don't have to code the most efficient solution first. Starting with a brute force solution then optimizing shows your attention to performance.
Optimize your solution: Once you have a brute force solution, where can you optimize it? Can you refactor a nested for-loop into two top-level loops?
Test for edge cases: Once your solution is working and optimized, create some test cases. These will allow you to see if you missed any corner cases.

Coding Project

If your technical phone interview goes well you may be asked to complete a take home coding project. I was not asked for a project during the Software Engineering interviews, however I was asked to complete one for my UX Engineering interview.

I thoroughly enjoyed completing the coding project for a few reasons:

I was able to pick from two projects which showcased different skills
I had a week or so to complete the project (although I was informed it should only take a few hours) which reduced the "on-the-spot" pressure of a coding interview
I was able to showcase some of my strongest skills like thorough documentation, user flows, and information architecture
I was able to pick my tech stack

You should clarify project requirements with your recruiter before diving in. For example if you want to use a JavaScript framework you should ask if this is allowed.
Some tips for your coding projects include:

Try not to rely too heavily on third-party libraries. I chose to use Material UI, Google's design system, for the UI work because it showcased my knowledge of design systems and kept the UI consistent, however using a UI framework can have performance implications.
Be honest about the areas you would like to improve upon. One part I always include when submitting a take-home assessment is "areas for improvement." If you had an extra few hours or weeks, what would you have done differently?
Run you application through an accessibility tester. I ran my app through Google Lighthouse to test for accessibility.
Don't pour your heart and soul into the project. If the recruiter says to spend 2–3 hours on the project, don't spend a week working on it. You'll burn out and feel taken advantage of if they reject you after this step (I know from personal experience.)
Clean up your code. Be sure to remove comments and format your code appropriately.
Think about project architecture. Your file structure should be clear and organized.
Include setup instructions. If the person reviewing your code doesn't know how to run your application you probably won't move on to the next round.

On-Site Interviews

If you've made it to the on-site interviews, CONGRATULATIONS! This is a huge step and you should be proud of yourself!

During my second interview with Google I was able to visit the Munich campus and get a tour of the office (it was beautiful!), however during my latest interview process all of the on-site interviews were conducted over Google Hangouts due to COVID-19.

The on-site interviews consist of five rounds:

Two front-end interviews (coding)
Two data structures and algorithms interviews (coding)
One process/teamwork/culture fit interview

The front-end interviews will focus on front-end technologies like HTML, CSS, and JavaScript but may touch other areas like performance and asynchronous JavaScript.

Front-End Interviews

Here are the skills I recommend studying for the front-end interviews:

For an accessible gist please follow this link.

Data Structures & Algorithms Interviews

Here are the skills I recommend studying for the data structures and algorithms interviews:

For an accessible version please follow this link

Teamwork, Process & Culture Fit Interview

The teamwork/process/culture fit interview will be an amalgamation of topics ranging from Agile methodology or workflow, teamwork and collaboration, and conflict resolution.

To ensure success in this interview here are a few tips:

Have two or three projects you can discuss.
Have 1–2 team conflicts you were able to resolve.

Team Matching Phase

If you complete your on-site interviews, you've passed the hard part! Some candidates move directly to the hiring committee but some candidates go through the team matching phase.

In this phase you'll meet with prospective managers and discuss the team you'd be joining and the type of work you would do.

If a team wants you, they'll tell your recruiter and it will be added to your portfolio which will then be submitted to the hiring committee.

The Hiring Committee

The hiring committee is the last phase of the interview process. From my understanding the committee is comprised of several Googlers who review a candidate's performance throughout the entirety of the interview process.

In the day or two leading up to the hiring committee meeting, the reviewers read the candidate's packet and makes a recommendation on whether or not to hire the candidate.
At the meeting the reviewers discuss their feedback and if all members agree an offer will be extended.

I never received feedback about the hiring committee feedback, as I pulled out of the process before receiving it, so unfortunately I can't speak to the statistics of receiving an offer after going through the hiring committee.

Learning Tips

When interviewing here are a few general tips to ensure you perform to the best of your abilities.

Do a little each day

Although it might not feel like you're making huge strides, small bits of information compound to achieve amazing results. I love the book Atomic Habits by James Clear which dives into this idea more in-depth.

When you do a more focused amount of learning each day, you have a lower risk of burning out, and gives your brain more time to process the information you've learned.

Mix learning with doing

You can learn all the skills in the world but if you don't apply them to various projects you'll have a harder time using them in an interview. I recommend learning a skill or two and then finding an example application to utilize them in.

Learn to read other peoples' solutions

Your solution might work and might be optimized, but it's always a great idea to read other peoples' solutions and understand how they think. You might find a more performant way to complete a task, but in general learning to read code is a wonderful skill, and a necessary one, to have.

Interview Tips

When the on-site interview finally arrives, here a a few tips to keep you grounded.

Drink water

Having something to drink will provide you with a moment to catch your breath and relax. Your interviewer should ask if you'd like one but if they don't you're welcome to ask.

Ask clarifying questions

White-boarding questions are purposefully left with a few holes because the interviewer wants to see your ability to problem solve. If something seems unclear, it probably is! Write down the things you know and deduce what you don't.

Brute-force then optimize if stuck

If you have absolutely no idea where to begin, start with a less-performant solution; you can optimize later.

For example if you're asked to search for a number in a sorted array and return true if it exists, you can always start with a for-loop that iterates through each index and returns true if the number is found. In the worst-case scenario this leaves you with O(n), where n is the length of the array, because we're checking every single element in the array.

Further along in the interview you might realize "oh the array is sorted! I can use binary search to find the element!" Binary search is a wonderful divide and conquer algorithm that repeatedly searches for the target element by reducing the size of the array each time. This might end up being a more performant solution.

Speak your thought process

The point of the interview is to see how you think, so you must speak your thoughts out loud! Your interviewer can't read your mind.

If you're stuck between two solutions, tell your interviewer and explain your reservations about both. They might be able to put you on the right track.

Test your solution

Once you have a solution and you've optimized it, it's time to test. Many candidates forget about testing but this is a vital part of a coding challenge. Your solution might work for 75% of test cases but forget to account for the other 25% of edge cases.

Testing your solution is a must in an interview.

Don't rely on tooling

Google typically uses word documents or a plain text editor for their coding challenges so don't rely on linters or Prettier to format your code. Learn to write code in an environment without tooling.

Final Thoughts

Google isn't the "be-all-end-all" company to work for. You might not even enjoy working at a large company!

The most important thing to remember when interviewing is that this is a two-way interview. You're interviewing the company as much as they're interviewing you.

The skills you have are valuable and even if you get rejected it doesn't mean you're not good enough.

We all get more rejections than offers so hang in there.

Five Tips For Coding Interviews

Emma Bostian ✨ — Thu, 27 Feb 2020 07:47:08 +0000

Technical interviews are scary; the thought of having to write code on a whiteboard is anxiety-inducing.

Throughout our research and years in the industry we've put together some tips for helping you during your coding challenges.

Whether you're frontend or backend, knowing these tips, and practicing them before your interview, will ensure you put your best foot forward and hopefully land a job offer!

Do you have any additional tips? Leave them in the comments below!

Communication is key in any interview but in technical interviews it's imperative you explain your thought process.

Your interviewer wants you to succeed, but in order to help you, and potentially give you hints, they need to know your thought process.

If you need a minute to think, tell your interviewer! There's no shame in saying "I just need a second to think."

But if you're internally reasoning between two solutions, talk it out.

For example, if you're trying to decide the best method of sorting an array of integers from lowest to highest.

"I have two ideas in my mind. The first requires brute forcing the solution where we would compare every element in the index to its neighbor and if the integer on the right is lower in value than the integer on the left, swap them.

But this isn't optimal as it would require O(n^2) checks to ensure everything is sorted. I know merge sort is a more optimized sorting algorithm with a worst-case runtime of O(n log n), however I'm a bit unsure how to code that."

Stating your thoughts out loud will allow the interviewer to guide you and is often a chance to showcase your knowledge about data structures and algorithms.

In almost every case the question you receive for a coding challenge will have a few holes in it. The interviewer won't give you all of the information up front because they want to see you deductive reasoning and problem solving skills.

Thus it's important to think through all of the key information you'll need to solve the problem, and ask if something is unclear.

If you receive a question and you have no idea where to start, don't panic; we've all had this moment!

First, think about the information you have. What pieces of information do you need to solve this problem?

Second, what are you missing? In the previous tip we mentioned asking clarifying questions. This is great practice if you're stuck or need a moment.

Next, at the core of the problem, how would you brute-force this answer? In tip one we had the example problem of sorting an array of integers from lowest to highest.

The brute force method would be bubble sort where we're comparing every integer against every other integer and swapping if needed. And even though this isn't an optimized solution, getting the brute-force solution up on a whiteboard will allow you to refactor to something more optimal.

Is it possible to remove one of the nested for-loops in our sorting algorithm? Perhaps we can refactor to use a divide and conquer algorithm like merge sort!

A brute-force solution is better than no solution.

There will inevitably come a time when you simply don't know the answer to a question.

For example if you're asked "what's the difference between == and ===?" and you simply have no idea, just tell the interviewer!

You might say: "I'm not positive but if I had to make an educated guess I would say..."

This indicates that you're self-aware and honest but you're still willing to take a guess.

If you simply BS the answer and pretend you know what you're talking about, this indicates that you're not a truthful person and you likely won't receive a job offer.

Additionally if you ever receive a coding challenge question that you've seen the solution for or have already gotten in a past interview, be honest about it.

Your interviewer will be able to tell if you're regurgitating a memorized answer so it's best to be transparent. Plus your interviewer should appreciate your honesty.

Once you have a solution down, take ten minutes to test it. What are the obvious use cases? What are the corner cases? You'll likely find holes in your solution and can go back and refine them.

If you spit out an answer without testing it, you probably won't receive a job offer.

For example if you're asked to write an algorithm which determines whether there is a loop (or a broken edge) in a binary tree, think about the possible use cases.

Does your algorithm work if there are no nodes in the tree?
How about if there is only a root node
What if there is no broken edge/loop?
What if the broken edge is on the last node in the tree (bottom right)?
What if it's in the first level?

These questions will allow you to refine your solution. It might help you determine whether you want to use depth-first search over breadth-first search.

Testing is important! So don't forget it!

Keeping these five tips in mind will help calm your anxiety about coding interviews. Focus on solving the problem at hand while communicating clearly. You'll receive a job offer in no time!

You can check out our full episode for more tips!

DISCUSS: Technical Interview Horror Stories

Emma Bostian ✨ — Mon, 24 Feb 2020 13:43:45 +0000

In this week's Ladybug Podcast episode we discussed the frontend technical interview process.

Technical interviews are terrifying, and I'm sure we've all had bad experiences. Hopefully talking about why our experiences were not so great can help educate the tech ecosystem about how to give a great technical interview!

I'll go first.

Years ago, probably in 2016, I was interviewing with an overseas company. It was a startup and it was a product I genuinely liked. I had a great talk with the recruiter but decided to pull out of the interview process as I was unprepared to move abroad at the time.

I truly had a great experience with the recruiter though so I wanted to stay in touch.

Fast forward two years later, I re-connected with the same interviewer except this time was... not so great.

He called me at 6 am my time (due to time zone differences), and proceeded to badger me with technical interview questions like "whats the difference between const and let?", which I explained correctly but he made me feel like I gave the wrong answer.

I was duly unprepared for the technical interview questions, and explicitly stated as much, yet he kept throwing them at me.

Not only that, but the recruiter seemed like a different person.

The first time we interviewed he was SUPER down-to-earth and made me feel special. This time around he started the conversation with "have we met before" which threw me because A) we spent a lot of time communicating and you made me feel like you remembered me through email communication and B) you clearly didn't take two minutes to check if we had previously interviewed.

He even was answering Slack messages during our interview because "my teammate is having Zoom issues and I'm the only one who knows how to fix them."

Horribly unprofessional.

I left the interview and told him "thanks but no thanks."

He just reached back out to me (a year later) and needless to say I won't be following up with him.

What's your technical interview horror story? Leave it below!

Six Data Structures To Help You Ace Your Technical Interview

Emma Bostian ✨ — Fri, 07 Feb 2020 19:17:10 +0000

It's a new year which means many of us are searching for our next role. It's no secret technical interviews are hard, so we've compiled (hehe) a list of six data structures you should be comfortable with in 2020.

If you're going through a technical interview, these are must-knows.

We chatted about data structures & algorithms on this week's Ladybug Podcast so I recommend checking that out if you haven't already! We'll cover a lot more than the six data structures here!

Since these data structures have been written about until the cows come home, here are some of our favorite resources for learning them!

Good luck, devs!

🐞 Arrays

Arrays are the bread and butter of data structures. They are list-like data structures which allow you to keep track of elements. These elements can be reference types, like objects or other arrays, or primitives, like numbers or strings.

The length of an array in JavaScript is not fixed, meaning you can add values to the array easily.

🐞 Linked Lists

Linked lists are a data structure which isn't built-in to JavaScript, but can be created out of other JavaScript data structures.

A linked list represents a series of nodes where each node points to the next node in the list.

There are also doubly-linked lists where each node also points to the previous node in the list.

This structure uses the LIFO, or last-in-first-out, method where nodes are added to and deleted from the same end.

🐞 Stacks

A stack is not a built-in JavaScript data structure but can be built using arrays.

A stack is based on the LIFO, or last-in-first-out, concept. A stack is like a pile (or stack) of books where you have to take the top book off before you can get to the bottom book (unless you're a savage).

Stacks allow for constant time adding and removing of an item but unfortunately they don't provide constant-time access to the nth item in the stack.

🐞 Queues

A queue is similar to a stack, but uses the FIFO, or first-in-first-out, method. You can think of a queue like a line of people waiting to buy a movie ticket. The person who has been in line the longest (first) is the first to be serviced.

Emma's 'Stacks vs. Queues in JavaScript' blog post

🐞 Binary Trees

Binary trees are a data structure consisting of a series of nodes where each node can have a maximum of two child nodes as well as a value. The root is the top node in the tree structure and doesn't have a parent node.

A binary search tree is another type of binary tree where all node values are distinct, every parent node has a left child whose value is less than it and a right child whose value is greater than it.

🐞 Graphs

Graphs are a data structure comprised of nodes with edges. If a graph is directed, that means each edge has a direction associated with it (like a one-way street). In contrast, undirected doesn't have associated edge directions.

You might have a graph of people (purple) and movies (green) where each person can have several favorite movies but movies don't have a favorite person.

What are some other resources you like for learning data structures and algorithms?!

Leave yours below! 👇

I Built A Successful Blog In One Year, And You Can Too; 7 Tips For Enhancing Readership

Emma Bostian ✨ — Mon, 09 Dec 2019 07:39:40 +0000

At the time of writing this post, I've been blogging on the Dev Community for almost a year and have 12,509 followers.

I always loved writing. From a young age I would write "books" which were really just ~4 page fiction stories that gathered dust in the corner. I believe my enjoyment for writing stemmed from my voracious love of reading.

And while I always loved writing, I never intended to make a part-time career of it, yet I'm humbled to say that my blog has taken off in the past year and I want to share some of my tips for growing a successful blog.

I want to preface this post with the admission that, over the past year, my social media following has exponentially blown up which had an invaluable impact on the visibility of my blog. If you want to read more details about the crazy Twitter journey, you can check out my post.

1. Write consistently

The best advice I received from my mentor, Kahlil Lechelt, was to blog consistently.

"If you post it, they will come."

Blogging consistently allowed me to develop a backlog of content. And while blogging consistently was difficult, I quickly learned that I had to blog for myself and let go of the angst about the possibility that nobody else would read it, or even like it.

When I say "blog consistently" I don't necessarily mean publish a blog every single Monday, but publishing a new blog every week or so will allow you to build up a wonderful backlog of posts for others to read.

The goal should be to hook readers with one post, and then capture their attention with a nice backlog of other posts.

2. Include high-quality images and graphics

One of the things I did, which I believe had a positive impact on the success of my blog posts, was to include high-quality header photos and supplement the technical content with custom-designed graphics.

You can find free images for your blog post headers on Unsplash for free, however the images are often quite popular so be conscientious of the fact that others will use the popular images, and select less frequently used images when possible.

I also designed custom graphics and charts to demonstrate more technical concepts. I built my graphics using Sketch, and while this does require a bit of design knowledge, you can create custom graphics too!

Sketch is a paid tool and only works on Mac, however Figma is a free web-based tool that provides the same capabilities.

Additionally if you're not a graphic designer and you're looking for amazing illustrations, I cannot recommend Undraw enough. All of the illustrations are free SVGs and as such are fully customizable.

3. Link to relevant resources

If you discuss or note a technology, tool, or person in your blog post, link to it. I cannot tell you how many times I've had to open a new tab and Google something in a blog post because they didn't link it.

Take the burden off of your readers and link to valuable related resources.

4. Explain acronyms and related topics

If you're writing a technical blog post, please define your acronyms. I like to make the assumption that someone reading my blog post has very little prior knowledge of the topic I'm writing about.

So if I'm writing a blog post about JAMstack, I should define what JAMstack means (JavaScript, APIs, and Markup) so the reader doesn't have to.

5. Ensure images, graphics, and code snippets are accessible

If you're writing a post, everyone regardless of circumstance should be able to read it.

In the past I've made the mistake of including code snippets as images simply because they looked nicer. Accessibility trumps aesthetics. Use gist for code snippets. They're accessible and easily embedded.

6. Use quantifiable numbers where applicable

One thing I've noticed is that readers love a finite number of tips.
Some of my most successful blog posts are of the format: "X Tips For ... " People love actionable blog posts, hence the numbered tips in this post.

I recommend keeping the number of tips at 10 or below to maximize readership.

7. Write about your passions

I cannot say this loudly enough:

CREATE CONTENT YOU LOVE, NOT CONTENT YOU THINK OTHERS WANT TO ABSORB.

If you're not passionate about what you're teaching, nobody will read it.

First and foremost I write for myself. I write blog I can reference for years to come. And chance are if you love what you write, and you find value in it, others will too.

If your blog isn't catching on quickly, be patient. I recognize the fact that my growth was an anomaly. It can take years to develop a "successful" blog, but success is subjective. What I deem successful is different than what you deem successful.

For me, success is not a number, it's the impact I have on the community. If I can help one person, I've written a successful blog.

Go forth and kick ass, my friends.

Header image by LUM3N on Unsplash