I recently started a new position as a Sr. Frontend Engineer at Facebook. In this post, I cover the resources and techniques I used to prepare for the interview process, including for studying up on vanilla JavaScript and the DOM API, writing cheat sheets for technical interviews, and practicing for behavioral interviews.
I concluded my GraphQL series for the Omada Health Tech Blog by sharing some tips we found for implementing GraphQL APIs using the graphql-ruby gem. These include the code organization structure we chose and how we were able to add GraphQL-specific details to our existing request logging system.
This is my second post for the Omada Health Tech Blog on adopting GraphQL. In it, I outline the various benefits we found GraphQL brought compared to how we traditionally implemented APIs, including better documentation, mobile client support, and performance.
Written for the Omada Health Tech Blog, this post explores the process I helped lead at Omada of investigating and eventually adopting GraphQL for several important features. It covers our decision making process and our strategy for incremental adoption. It also touches on our approach to scaling GraphQL's learning curve and bring various engineers on the project up-to-speed.
There are a lot of challenges to overcome when optimizing the page load speed of your website or web app. One of these is getting your most important assets downloaded to the client as quickly as possible. These assets likely include one or more CSS files and one or more JavaScript files. CSS is crucial to get to the client right away since it's needed for initial render. JavaScript may be equally as crucial if you're doing your rendering client-side. So these are the assets you want the browser to start downloading as soon as possible. One thing that can get in the way is generating the HTML for your page server-side. If generating the HTML takes any significant amount of time, the browser can't start downloading assets until your server generates and sends down all the HTML with the assets referenced via link and script tags. For example, on this blog I server-side render the React components that make up my pages, which usually requires waiting for a database call to complete before I can finish rendering the contents of a page. It'd be great if the browser didn't have to wait for the server to finish this work before it can start downloading assets.
Thankfully, there are a few techniques you can utilize to get the browser downloading your critical assets even before your server has finished generating all of the page's HTML. One of them is called early flush, and it involves sending down the HTML for a page in separate chunks instead of all at once. In this post, we'll take a look at how early flush works, how you can use it to get the browser downloading assets early, and how big of a difference it can make when your server has a lot to do.
I've been working as a software engineer, primarily focused on front-end development, for a few years now. I recently started a new job as a senior front-end engineer at a company called Omada Health. During my job search, I spent a lot of time trying to figure out the most important questions to ask when applying for a software engineering job. I was looking for somewhere that would facilitate my growth, where I could make an impact, and where I would enjoy my work. So far, I believe I've found a company that meets these qualifications and then some. In this post, I want to present some of the questions I asked during the interview process that helped me make the decision to choose Omada. These questions are roughly divided into categories including company info, people and processes, product, and engineering. I think they represent a good baseline of the info a software engineer needs to decide on a new position. I'll go through each of these categories and explain their questions.
One of my favorite ways of improving my knowledge of "vanilla" JavaScript and the browser's DOM API is to create complex UI components without utilizing any libraries or frameworks. It's a great way to familiarize myself with the methods available for DOM manipulation, event handling, and information retrieval. Along the way, I always pick up a few tips and tricks to add to my front end toolbelt. The technique fits in nicely with my philosophy that one of the best ways to learn in programming is to "re-invent the wheel".
In this post, I'm going to walk through implementing an image zoomer component. It's basically what you use on a site like Amazon to get a closer look at an image by hovering your mouse over a thumbnail.
I coauthored this post for the LinkedIn Engineering Blog, providing details on how we defined reusable style patterns for our web implementation of LinkedIn's design language, Art Deco, and how we documented them in our pattern library documentation.
Following in the footsteps of some great JavaScript developers, I've built my own, over-engineered blog. In my case, I built it as a single-page application running on React and Redux client-side and Express server-side. While the endeavor hasn't been the most practical I've ever undertaken (a blog hardly needs to be a SPA), it's been extremely helpful to me in learning an awesome technology stack.
One challenge I wanted to tackle as part of this project was to get my blogging app to support both server-side and client-side rendering (make it a "universal" app). In my experience, server-side rendering is great for enabling a quick initial render and client-side rendering is great for quick subsequent page views. As part of achieving this goal, I discovered a few handy tips. I'm going to share these in the hopes they'll be of help to others.