Cute interview illustration
Cute interview illustration

I’m an engineer who’s beginning to interview candidates for coding work. I’m loving meeting new people, and I’m also benefitting a lot from the incredibly interesting conversations that spark in the interview room. However, while it’s exciting for me to see the process from the other side, I know full well how daunting it is to be in the interview chair. I wrote this article hoping to assuage some fears by removing some of the mysteries around interviewing for software engineering positions.

Right now, my understanding of the gap between being an interviewee and an interviewer is developing. As I learn more about the process from the interviewer side, from colleagues who’ve been interviewing for far longer than I have, I can see clearly (with hindsight) some of the more egregious errors I made in the interviewee chair. …


Person standing on hill overlooking lake with arms outstretched.
Person standing on hill overlooking lake with arms outstretched.

As I get the hang of interviewing software engineers, I’m learning a lot from my colleagues who have been doing it much longer than me. One of the things that’s most surprising to me is that they don’t look for exact skill set matches for the interview. As we all know, software interview questions aren’t the best indicator for what day-to-day working with a person is like. To answer perfectly, the questions we ask demand a really broad set of technical expertise. Most candidates that we see (at least at more junior levels) simply won’t have that broad expertise yet. Here’s the cool thing though — we’re not looking for a perfect answer! Instead, we’re reviewing the candidate’s problem-solving approach, and checking the tools they have at their disposal to solve the problem. …


Five people in suits looking at a laptop all business-like.

During virus season I’ve gone through the same emotional journey as everyone else in the world — worry, anxiety, loneliness, grief — all too familiar to us all now. I’ve spent a really long time wondering how I can use my skills to help people through this time.

From speaking to friends, it seems a lot of us are trying to channel excess time and nervous energy into something productive. For some folks, this will include learning new skills. Many of us still aren’t able to physically return to a workplace, and are looking to level up during this time.

As someone who’s passionate about coding, and furthermore, as someone who has learned a lot through self-study, I wanted to share some of the things I’ve found most helpful in my own journey towards learning coding. If you’re researching which direction to focus on first, here’s my two cents on the five programming languages that are most useful to know. And below are some tips on learning to code that I’ve put together from my own experience. These may not be helpful to everyone, but I hope you get something from reading this. …


grid showing multiple programming language logos
grid showing multiple programming language logos

I sometimes get the question from people just learning to code “what programming language should I learn”? I answer with:

Android isn’t really a programming language, so sure the title is a little misleading. Read-on to understand why Android is important enough to make the list.

JavaScript

What

Most people think JavaScript is only useful when building user interfaces.

But wait…

Some people who built their UI in JavaScript have also leveraged that knowledge to build backend services in — guess what? Yep, JavaScript.

Where

Google, Facebook, Microsoft, Netflix, Paypal, Groupon, Airbnb, Uber, the list of big names goes on. Because JavaScript runs everywhere. I mean everywhere. …


Pick the programming language you know best. I’ll pick JavaScript. Now imagine every value you could create in that language. Yes, every value.

In JavaScript, you’d have numbers like 0, 1, -42, and 3.14. You’d have strings like the empty string "" or the classic "Hello, World!". You’d have objects like {id: 7, name: "Kate"} or {props: {...}, state: {...}} if you’re a React developer. You’d have functions like function add(a, b) { return a + b } or event => this.handleChange(event.target.value).

That’s a lot of values. An infinite amount of values.

Image for post
Image for post

This is the set of all values for your programming language. …


Over the last year, the Flow team has been slowly auditing and improving all the possible error messages generated by the type checker. In Flow 0.66 we’re excited to announce a new error message format designed to decrease the time it takes you to read and fix each bug Flow finds.

Image for post
Image for post
Source: Dmitry Boldyrev

The images in this blog post are of Flow’s new CLI renderer, designed by Lee Byron. Lee graciously offered to design an updated CLI renderer when I introduced him to the new error message format.

What makes an error?

Flow’s type system is structural and allows for thorough type inference. …


Image for post
Image for post

Learn what some of the unexpected costs of GraphQL non-null fields are.

In the GraphQL type system all types are nullable by default. This means that a type like Int can take any integer (1, 2, etc.) or null which represents the absence of any value. However, the GraphQL type system allows you to make any type non-null which means that the type will never produce a null value. When using a non-null type there will always be a value. A GraphQL non-null field is a GraphQL field where the type is non-null.

Non-null fields in GraphQL may seem great at first, after all they guarantee that you will always have a given field. However, using a non-null field may make it harder to evolve your GraphQL schema, and allow small errors to propagate in such a way that you lose important data which may have been returned if the field were nullable. This post explains the unexpected costs of non-null fields so that you can make informed choices when designing your schemas. Before we look at those costs, let’s take a closer look at some of the benefits of non-null fields from a UI developer’s perspective. …


Image for post
Image for post

The first version of Flow support for React was a magical implementation of React.createClass(). Since then, React has evolved significantly. It is time to rethink how Flow models React.

In Flow 0.53.0 we are changing how Flow models React and in doing this we can provide better types for higher-order components, strict typing for React children, and fixes for a host of bugs in Flow’s React support.

The biggest change we are making is to modify how you define React class components. From version 0.53.0 and on, the React.Component class will take two type arguments, Props and State (as opposed to the three type arguments including DefaultProps that React.Component took before). In the past Flow would infer Props and State from your property definitions, but now Flow expects you to pass in Props and State explicitly. A React component in 0.53.0 …


I currently have three conference talk proposals that contain ideas which I really want to explore. Even if I never end up giving a talk on these ideas I want to put these out into the world anyway and start talking about these ideas. I also think you will enjoy reading them 😉

The titles of my proposals are:

The first is based off of the controversial idea that JavaScript will die thanks to WebAssembly. …


Image for post
Image for post

Design principles for building effective GraphQL mutation systems that can evolve over time

Designing a good GraphQL API is tricky, because you always want to balance utility and convenience with a consideration around how the API may evolve in the future.

The main points to consider when designing your GraphQL mutations are:

About

Caleb Meredith

Product engineer at Airtable. Previously Facebook. @calebmer on Twitter

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store