DEV Community: Caleb Meredith

How to survive (and thrive!) in software engineering interviews

Caleb Meredith — Sat, 11 Jul 2020 22:20:04 +0000

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. I could tell stories about the things that I’ve done…

Ok, just a few. Purely for illustrative purposes. And maybe some amusement. Let’s call these—uhh—Story Charmander, Story Squirtle and Story Bulbasaur. Because why not?

Story Charmander

The worst interview I ever had ended early. Why? I was way too forthright with my opinions, and immovable on my stance. Things I’m still working on today. And while I am a huge proponent of confidence (see below), my nerves had pushed me right through confidence and into arrogance. Not a good interviewing look! More on this later.

Story Squirtle

My second story is about a time when I couldn’t come up with a simple answer, so instead grasped at the most esoteric, niche data structures I could muster (Bagwell’s ideal hash trees with a branching factor of 32, since you asked) to solve…wait for it…a problem asking me to do date math skipping weekends. The interviewer was, to their eternal credit, extremely patient, and once I’d stopped grasping at straws, gently queried whether that would really be the most efficient, cost effective solution for a client. That brought me back down to earth pretty quickly.

Story Bulbasaur

The third story is about the time I helped build an app and coded in right / left swiping with redux-saga that almost blew my own mind with its elegant beauty. Yes, it was that good. I wanted to explain all the awesome details of the code to my employer. And my employer ~~was so fascinated that he paid me double to write a book about it~~ didn’t care. Not one single bit.

I still think fondly about that code, from time to time.

So, you’re preparing for a software interview? Welcome!

Now that I’m in the other chair, I find that I have empathy with both sides. One of the really interesting things I didn’t appreciate before is that the interviewing process really is all about communication. By which I definitely mean two-sided communication. This train of thought got me mulling on all the things that I wish someone had told me before I started interviewing. So here, I’m going to explain some of the things that we look for in candidates. My intention is to make the process less intimidating, if possible.

There are a lot of myths around; stories that seem designed to worry candidates. I was certainly anxious, particularly given my oddly shaped background. And this needless worrying did me no favours at all. This article is intended to be more transparent, dispel some of those myths, and explain the process a little better.

I also want to spend a little time exploring how personal behaviors that we put on for one reason can very create different impressions on those around us (please refer back to Story Charmander). I hope that the following points will remove some of the mystery surrounding interview rooms, and maybe even allow you to enjoy the experience of meeting people who, most likely, share some of your passions with you.

Interview terrors: taming the beast

Lots of people get these. Arguably most people. We all feel worried, agitated, like our stomachs are full of ~~butterflies~~ raging, fanged netherbeings.

It doesn’t have to be this way! Having some nerves before important events is a good thing, causing adrenaline to flow, which in turn will help your natural charisma to shine in the room. However, unchanneled fear is more harmful than not, in several ways. Here, I’m going to share with you a few strategies I’ve learned to face some common pitfalls within engineering interviews.

Rejections! Fresh rejections! Get ‘em while they’re hot!

Some people hamstring themselves, being so worried about failing the interview that they fail to even apply for the job. This is a huge shame. Really. I almost want to shake some of my intelligent, awesome friends when I think about the jobs that they’ve settled for, instead of applying for the jobs they deserve, all because of a lack of confidence. Their inner voice made the decision that they weren’t going to get the job, and they then made sure of that by never applying.

Look, truthfully, for most people, the fact is that you will apply for more jobs than you land, i.e. you will face some rejections. This is ok! Please, don’t let fear of rejection put you off applying in the first place. If you don’t give yourself a chance, why would someone else?

I think we’re all familiar with rejection-to-success stories; everyone has at least one and you can fall down a plethora of internet wormholes reading them. So I won’t repeat those stories here. However, recently, I‘ve been finding it more helpful to train myself to look forward to the rejections — to consider each rejection as one stepping stone closer to a YES. I’m really enjoying Jia Jiang's rejection therapy talks as a way of understanding this process.

I like to imagine the process as collecting a bunch of rejections that I can then trade in for a YES at a swap meet. You may have a different visualization technique.

The interview itself: Shall I compare thee to a band-aid?

Ah, the best bit. Are you a ripper-offer, or a slow peeler?

In theory, a perfect interview would be you demonstrating your smart, cool, funny qualities so well that when you leave, the interviewer(s) can’t imagine being on a team without you. Perhaps you’d have a conversation ignited by glowing sparks about developments and solutions in a field you’re both interested in. (Hopefully. If the interests aren’t shared, there may be bigger problems to fix 😉).

However, in practice, know this: the interviewer is looking for indications of your skills and behaviors. Essentially, they want to know three things:

Can you do the job as advertised?
Can you learn fast?
Are you a person they want to work with for the next three—five years?

And don’t forget, crucially, the interviewer should also want to show you how cool the company is to work for.

Anything else is just icing on the cake. Flowing conversation would be amazing, but honestly, one interviewer may be trying to remember to assess you and not just have a fun conversation, another may be worried about ensuring you’re having a good time; meanwhile you are trying to remember how html works. No one single interviewer gets a final say in these things. What I'm trying to say is that it’s tough, and there are a multitude of moving parts to interviews.

And recently, I’ve actually been thinking, instead of sugar coating this process, maybe the truth is really the best that can be said about this. An interview isn’t intended to be a walk in the park. Hey, 👁👄👁. Just acknowledging that fact will allow you to get to grips with the nature of the beast.

So yes, you are being evaluated while you are in the room. But please don’t forget, you should be doing some evaluating of your own while you’re in the room! Do you want to work with your interviewers? Do you get a good vibe as you walk through the offices? Interviews are not one-sided lectures—you should actively participate in making your own judgments about the company. Understand that the interview is a necessary part of this process. It might not be pleasant, but facing it with strength allows you to have some power over the situation.

Also please note, if you’re more of a slow band-aid peeler, sorry—I don’t know of other, more useful advice for you.

The interview itself - some answers are more right than others

Let’s get into the details. The list of three things above is a summary, and there is a bunch of information out there on learn how to talk about yourself, your achievements and your abilities. I have faith in you—you’ve got this part.

But that stuff? That’s the basic stuff. Here’s where you’re really going to make an impression. Try to remember at all times that you are being considered not just for the job as described, but as an individual who’s going to be able to grow and develop alongside the rest of the people in the company. Your interviewers want to see that you have that potential. How do we look for it?

Well, there are a few indications, and one really interesting one I want to talk about relates to Story Bulbasaur (see above).

The moral of that cautionary tale is that yes, code can be beautiful, and complex, and imaginative. Is this always what a client is paying you to do? No. Is it ever? Unlikely. Your clients probably won’t care about the intricate, clever solution you came up with to fix their issue. They just want to know it’s fixed.

But wait! There's more ... On the other hand, your co-workers will care very much what solutions you are using, as they’ll be the ones helping to maintain and develop your code in the future. They will also be the audience you want to woo with well-designed code.

So long story short, in the interview room, when we are looking for potential, we are almost certainly looking for your ability to take a practical approach when it comes to work. The trick to this is to try to achieve a balance between demonstrating your knowledge, and being pragmatic.

The interviewers: just…some other people?

A point so important, so vital, so often-forgotten: we’re just people. Moreover, we are people who want to stop interviewing other people so we can get back to work, so that we can go home on time. This incentivizes us to be on your side — truly, we want you to be ✨The One✨ so that we can end the interview early!

Techniques for Improvement

So, now you have some of the common pitfalls and experiences that many of us go through on this journey. Here, if you’re interested, are some of my thoughts on how to change your approach to software interviews from now on.

Confidence is Key

Work on your confidence before getting into the room. Really work on it. Use affirmations or whatever is necessary. You need to be able to talk with assurance about what you’ve achieved, and use your skills to solve problems while in the room. If you don’t believe in yourself, it’s going to be harder for you to do these things. The interview is about proving to us in person that you have the skills your resume said you had.

Always try to aim for balance. At this point, please refer back to my personal ‘Story Charmander’. For some people (guilty), confidence under pressure has a habit of mutating into something that seems like arrogance. Work on your communication skills before the interview with friends and family members. Remember, we can’t read your mind, so something that may seem obvious to you will need to be explained to people who don’t live inside your head. Think of it like this: remember how for school math tests, you couldn’t get high marks unless you showed your work? Show us your work! We want to know how you’re arriving at your conclusions.

And finally, take the time to understand that in this area, just like everything else in life, there are very few cut-and-dry answers. Almost everything will have grey areas which can be debated and played with. Part of any interviewer’s job will be to test your boundaries and see how well you work in a team. As long as you can’t be malleable and accept other points of view, you’ll be telling your own ‘Story Charmander’ to people for a while.

Practice may not make perfect, but it sure builds muscle memory

I wholeheartedly recommend that you practice interviewing in preparation for an interview. Find a friend who is familiar with interviewing and set up some Zoom time with them. Or join an interview practice group - these do exist, and you just have to find them. You’re not practising to get perfect, because you won’t. What you will do is improve and build your personal tool-set. Work on spotting patterns rather than aiming to do every problem under the sun. We’re interested in the solutions you offer, sure, but also your routes to solutions, the way you think, and the tools you have at your disposal and choose to use.

Programming languages and problem solving

Try to be comfortable in at least one programming language, but don’t get hung up on your usage speed. Remember, we’re not looking at how fast you can type, or how many languages you can list. We are looking at how you use the tools at your disposal to effectively solve practical problems. Often, a candidate who is very familiar with only one language but has spent time practically using a language will outperform a candidate who is familiar with three—four languages but spent no time practically using those languages.

Will I have to use a whiteboard like on TV?

Most likely yes, this will probably come up. You may need to show your work on a whiteboard. Seems like it’s easy as pie to simultaneously think, talk, write on a board and explain your thinking when the people on TV do it, right?

Yeah, it’s not.

It requires some serious hand-eye co-ordination, the ability to organize your thoughts, and simultaneously present. It’s further complicated in current, social distancing times with the necessity to ensure that:

Whatever program you’re using for the interview will allow you to present; and
You have enabled the necessary permissions to be able to present.

My advice?

Practise presentation skills with a friend who enjoys being talked at. Use Google Docs and Miro. Check your settings several times before any interviews begin. Then practise presenting again.

Conclusion

The thing I most want you to take away from this is the fact that we are all just people. If you and we are in a room together, it means the recruiting team believes you can pass based on your resumé. Whether your resume is full or not, you’re in the room, so try to have fun talking about the thing you enjoy doing! And know this:

We, as interviewers, want you to succeed so that we can go write some more cool stuff. We want you to succeed so that we can have an extra person on the team to do even more cool stuff with. The interview is simply an opportunity for you to wow us in person.

Now, go forth and interview.

And let me know if you have any questions.

Because I’m interested.

Tired: Golf, Wired: Boardgames

Caleb Meredith — Mon, 15 Jul 2019 19:00:00 +0000

My mom is an accountant and a lot of people in her office enjoy playing golf. However, my mom doesn’t play golf so that means to join recreational business outings that involve golf she’s either aimlessly wandering the playing field or not participating at all.

This got me thinking, what is the future of business recreation? Will it continue to be dominated by golf, or is golf as business recreation a generational thing?

I predict that the future of business recreation in the next 20–50 years will be boardgames! Boardgames are great, they are:

Cheap: The most expensive games max out around $60. That’s quite reasonable when you have 5–8 players.
Inclusive: Anyone can play! Generally, everyone will be around the same experience level. These games are also designed to be fun for newcomers.
Collaborative: A good game will also serve as a team-bonding exercise. You can get to know your co-workers better by playing a co-operative game or by playing against each other in a hidden information game.
Short: You can pick a game that fits into the time you have. Games with quick 30 minute rounds allows parents to play while still getting home to their families.
Flexible: All you need is a table, people, and the game. You don’t need a full golf course or equipment.

I’m not talking about classic boardgames like Monopoly or Risk. I’m talking about the huge wave of indie boardgames.

If I’m right, and boardgames become a mainstream part of business recreation, then the ability to run a boardgame night and introduce new players to the activity will be pretty valuable.

In this post I’ll share some of my boardgame recommendations, specifically ones I think would work well in the workplace. I haven’t played all of these…yet. If you’re in the Bay Area and you’re interested in the future of “business recreation” we can give one of these a spin.

One Night Ultimate Werewolf

Time: 7 minutes, Difficulty: easy, but can become more challenging as you add roles

My first, and strongest, recommendation is One Night Ultimate Werewolf. The name is a bit of a mouthful, but all the words actually mean something. I’ll call it “Werewolf” from here on out.

In Werewolf you have three to eight players and you give everyone a role. Two or so players will get the “werewolf” role and everyone else will be human villagers. The humans have five minutes to correctly identify the werewolves. If the humans discover the werewolves, humans win. Otherwise the werewolves win. So the werewolves must lie and pretend they are villagers to not get caught. The game also gives some human roles “powers” like the power to see the role of one other person or the power to swap two roles. You can watch some game play here.

Werewolf is in the hidden information genre and is actually a very common format for tabletop games. Growing up, I knew this format as “Mafia” which is a game you play with a standard deck of 52 playing cards.

However, Werewolf makes a couple big changes which streamlines the format and makes it much more fun.

An entire game of Werewolf fits into a single round. Hence why “One Night” is in the title. Normally, in a Mafia-style game you have multiple rounds where players are progressively eliminated. In a one night format players don’t get eliminated so no one has to stop playing!
Furthermore, you don’t need a game master! Normally, Mafia requires one person to run the game to make sure no one is cheating. Werewolf instead comes with an app which will run the game for you. That way no one has to sit out during play.

These two changes mean everyone in a business recreation setting can play and can keep playing for multiple rounds. A Werewolf round is also really short which allows for quick games.

Werewolf is a very collaborative game that’s great for team bonding. You really need to know the people around you at the table. To know who your allies are and to know when someone is bluffing. I strongly recommend Werewolf for business recreation.

Sheriff of Nottingham

Time: 1 hour, Difficulty: medium

In Sheriff of Nottinghamevery player is a merchant trying to stock their shop with goods. One player is also the sheriff which rotates to someone else every round. In a round, players will put some goods into a pouch. For example, three apples. However, players may also smuggle contraband, like beer, into their pouch! Each player gives their pouch to the current sheriff and they declare what’s in the pouch. The sheriff may choose to either believe the player or inspect the player’s pouch. If there is no contraband in the pouch, the sheriff is fined. If there is contraband in the pouch, the player who tried to smuggle is fined. Of course, you can also bribe the sheriff to not inspect your pouch.

If you’ve every played the game Cheat (aka BS) with a standard deck of 52 playing cards, then you get the basic idea. You want to smuggle contraband past the sheriff since contraband is valuable, but you also don’t want to get caught.

It can take a second to understand all the rules. Make sure one person reads the rule book ahead of time if you’re in a group of new players. You can watch some game play here.

The physical elements of the game are very engaging. Whether you’re putting cards into a pouch and sliding it over to the sheriff, tossing coins over in a bribe, or popping open the button on a pouch looking for contraband gives an authentic smuggling experience.

Captain Sonar

Time: 1 hour, Difficulty: medium

Disclaimer: I haven’t played this game.

In Captain Sonar you have two teams made of two to four players with each team piloting a submarine. Players have roles like navigator, engineer, and sonar operator to position their submarine against the opponent. The navigator calls out the direction the submarine is moving on a grid. The enemy sonar operator is responsible for listening to the opposing captain to record enemy movements. Once one team believes they have the location of another team they may fire a torpedo.

So this game is a lot like Battleship except each team only has one submarine and that submarine is piloted by multiple players.

This game is all about teamwork and communication. With good communication you can strategically manuever your submarine, with bad communication your opponent will know exactly what you’re up to. The game can get hectic with a lot of people talking at once, but that’s also part of the thrill.

Dominion

Time: 30 minutes, Difficulty: hard

Dominion is a deck building game for two to four players. You start with a couple cards and you slowly buy more, building up your deck. Dominion is a lot like Magic the Gathering, in fact, it’s frequently marketed with: “Want to play Magic the Gathering but don’t have the time or money to invest in Magic? Play Dominion instead!” Which is perfect for me. I love deck building games, but the Magic investment always intimidated me.

Dominion comes with a bunch of different kinds of cards. You play each game with a different set of those cards. That means you can have multiple games of Dominion with wildly different feels depending on the cards you play with.

The game is pretty easy to learn, but there’s a lot of depth, complexity, and strategy to the game. Especially when you add in expansions. A player can easily pull ahead of their competitors by employing strategy. This game might be a bit less inclusive than the others because of that. At some point, you need to start thinking strategically or you’ll get left behind.

In a workplace, I’d recommend playing Dominion in a tournament format since the maximum number of players is four.

Tabletop RPGs

Tabletop RPGs are also a compelling category for business recreation. The most popular Tabletop RPG is Dungeons & Dragons, but that’s a massive game which can sprawl over multiple four hour long sessions for years. I think D&D can be great for building teams in a business setting, but you need commitment.

D&D is not the only Tabletop RPG, though! I recommend watching the Tablepop series to get an idea of what shorter form single session Tabletop RPGs look like.

Here are some of my recommendations beyond D&D. Unfortunately, I don’t have too many recommendations for Tabletop RPGs that play out over a single session. I’d like to hear yours!

Honey Heist: You’re a bear pulling off a heist to steal honey from Honeycon. This is a fast, fun, one-shot tabletop RPG.
Monster of the Week: You’re a monster hunter and every week there’s a new threat to fight. Thematically similar to Buffy the Vampire Slayer and other Monster of the Week TV shows. Plays out over multiple sessions.
Vampire: The Masquerade: Players are vampires struggling against their bestial natures. Plays out over multiple sessions.

I also think single session Tabletop RPGs could be a fun addition to a tech conference. You get some well known speakers on stage and run a session. If you’re a conference organizer interested in exploring this idea more, let me know.

Conclusion

If I’m right and boardgames become a mainstream business recreation activity, then being able to run a boardgame night and introduce new players could be a valuable skill in a work environment.

So I’m investing into building this skill. I’ll keep you updated on whether or not it works out for me.

My Adventures Writing a Cross-Platform Virtualized List

Caleb Meredith — Tue, 09 Jul 2019 19:00:00 +0000

I wrote a virtualized list! It was quite the adventure.

I was working on a cross-platform React Native app that also rus on the web with React Native Web. None of the existing virtualized lists were suitable for the product I wanted to build. Not FlatList, not react-window.

So, as one does, I wrote my own virtualized list. Forking React Native in the process. You can see the final code in a public gist.

I’m going to describe my entire adventure in this post. Through my experience I hope to inspire you to take control of your code. If writing a virtualized list, or anything else, would make your user’s life better, you should do it! You need not be bound to existing libraries. You have the power to fork and modify dependencies as you see fit. Fear not the unfamiliar, if someone out there wrote a virtualized list then there’s no reason you can’t!

This is a story divided into four parts.

Part 1: The Product
Part 2: When I realized existing virtualized lists wouldn’t work…
Part 3: How it works
Part 4: Forking React Native

Part 1: The Product

I was building a React Native Web/iOS/Android app which was, basically, a forum. A forum has posts and then people could leave comments on that post.

If you were reading the post for the first time, you’d want to read the first comments and scroll down. If you were catching up on the discussion after replying, you’d want to read the latest comments and scroll up.

So I needed a virtualized list that would support scrolling from either direction. I came up with, what I believe, is a new UI pattern: the Skim List! A sister of the Infinite List.

In a Skim List we pre-allocate space for all the items in the list. When the user scrolls to a position in the list, we load the items at that position. So if I scroll 50% through the list, I’ll load items halfway through the list. If I scroll to the end of the list, I’ll load items at the end of the list.

Here’s the Skim List in action on web. It works the same way on mobile.

These GIFs are slowed down and I added network throttling when recording so you can really see the progressive loading behavior. It’s really fast and slick when you get your hands on it.

As you might be able to imagine, this list also lets you scroll to a random place in the list and move around.

Part 2: When I realized existing virtualized lists wouldn’t work…

I first tried using React Native’s FlatList.

That was working fine, I was able to implement a list where you were able to scroll down and the comments below you loaded. That’s what FlatList is optimized for. However, I also needed the ability to jump to the end and load comments while scrolling up! FlatList just wasn’t built for this.

Next I explored react-window. At first glance, the library obviously wouldn’t work. You need to know the heights of all your items ahead of time for react-window. Since I was working with comments on a post, I had know way of knowing the item heights!

There’s a PR open to add a dynamically sized virtualized list for react-window, but it hadn’t been merged yet.

I needed to incrementally load items in the list when they scrolled into view and while the items were loading I needed shimmer placeholders. I couldn’t do this with FlatList but I could with the unmerged react-window PR! However, I needed a solution that would also work on React Native iOS and Android. react-window is web only.

Well, that meant I needed to write my own virtualized list.

Part 3: How it works

The way my virtualized list works is it takes the total number of items (in this case comments) on a post and it takes an array of all the comments. I represent the array as a sparse array. That means any positions in the array without a loaded comment will be undefined.

type Props = {
  commentCount: number;
  comments: ReadonlyArray<CommentID | undefined>;
};

For all the comments which are not loaded I render a placeholder component called <CommentShimmer>. A comment shimmer renders grey boxes which are meant to look like a conversation. Different comment shimmers have different heights. I measure the total height of the scroll view with code that roughly looks like commentShimmerHeight * commentCount.

I use a pretty standard virtualized list technique. The same one react-window uses: absolute positioning. I add a scroll event listener which calculates the onscreen comments. Then I use absolute positioning to make sure the comments are rendered at the right position in the virtualized list.

So whenever a user scrolls I:

Figure out which comments to render.
Render only those comments, unmounting any offscreen comments.
Position the rendered comments in the list with absolute positioning.

This only works if I know the size of all comments in the list. I know the height of unloaded comments since they are just <CommentShimmer>s. However, when a comment loads it might have a completely different height!

When a comment loads I need to measure it. Since I’m using React Native, I must measure asynchronously. So when the comment is loaded but not measured I render the <CommentShimmer> and the <Comment> next to each other. Hiding the<Comment> with opacity: 0. Once we’ve measured the <Comment> we can get rid of the <CommentShimmer> and update the height of the list.

So there are three states any comment could be in:

// State 1: Unloaded Comment
<>
  <CommentShimmer />
  {null}
</>

// State 2: Loaded but Unmeasured Comment
<>
  <CommentShimmer />
  <View style={styles.hidden} onLayout={handleCommentLayout}>
    <Comment />
  </View>
</>

// State 3: Loaded and Measured Comment
<>
  {null}
  <View style={null}>
    <Comment />
  </View>
</>

You can see this in the renderItem() function.

Part 4: Forking React Native

Ok, at this point the list was working and it was working pretty well. However, there were a couple bugs I just couldn’t fix. I didn’t just want a good experience, I wanted a flawless experience. This led me to fork React Native so I could add a feature to <ScrollView>.

First, let me describe the bug.

When the content of a scroll view resizes, the platform (Web or iOS in this case) needs to determine where the new scroll position should be. Usually, the scroll position is measured as the number of pixels that have been scrolled from the top of the scroll view. So when content resizes, that number is usually kept constant. See the below image for an example.

We change the size of the scroll content, but the scroll window (the red box) stays the same distance from the top of the scroll view.

This works well in most cases, but it doesn’t work well when the user is scrolling from bottom to top. That’s because when we load a chunk of comments, the virtualized list size changes. We add content “above” what the user was reading which either pushes or pulls the content the user was reading out of the viewport.

Instead what we want is to pin the scroll window to the bottom of the scroll view. So when we add new content the distance of the scroll window to the bottom of the scroll view stays constant. See the below image for an illustration of the difference.

So I forked React Native and added the pinWindowTo prop. When set to pinWindowTo="top" we use the default behavior. When set to pinWindowTo="bottom" it uses the behavior depicted in the previous image.

This is the important part of the commit in the Objective-C code for the ScrollView component on iOS.

       // offset falls outside of bounds, scroll back to end of list
       newOffset.y = MAX(0, newContentSize.height - viewportSize.height);
     }
   }

+  if (![self.pinWindowTo isEqualToString:@"bottom"]) {
+    CGFloat oldOffsetBottom = oldContentSize.height - (oldOffset.y + viewportSize.height);
+    newOffset.y = newContentSize.height - viewportSize.height - oldOffsetBottom;
+  }

   BOOL fitsinViewportX = oldContentSize.width <= viewportSize.width && newContentSize.width <= viewportSize.width;
   if (newContentSize.width < oldContentSize.width && !fitsinViewportX) {
     CGFloat offsetHeight = oldOffset.x + viewportSize.width;

I don’t currently have an Android implementation which is why I haven’t contributed this back to React Native. In the meantime, this works great for me!

I also implemented this feature on my React Native Web fork.

_pinWindowToBottom() {
  const element = this.getScrollableNode();

  const lastScrollTop = this._lastScrollTop;

  const lastScrollHeight = this._lastScrollHeight;
  this._lastScrollHeight = element.scrollHeight;

  const lastClientHeight = this._lastClientHeight;
  this._lastClientHeight = element.clientHeight;

  const lastScrollBottom = lastScrollHeight - (lastScrollTop + lastClientHeight);
  const nextScrollTop = element.scrollHeight - element.clientHeight - lastScrollBottom;

  element.scrollTop = nextScrollTop;
  this._lastScrollTop = nextScrollTop;
}

Other changes I’ve made in my React Native fork:

Fixed React bug until React and React Native publish a new version.
Send iOS adjustedContentInset in scroll events since it’s important for accurate measurements involving “unsafe areas” on iPhone X.

Other changes I‘ve made in my React Native Web fork:

Fire onLayout in a microtask instead of setTimeout() so it fires before the next browser paint. This is very important for my virtualized list double rendering strategy!
Remove unsafe life-cycle methods like componentWillReceiveProps so that I can enable React Concurrent mode in my app.

In defense of forking

Forking your dependencies is frequently maligned, and for good reason. Without adequate upkeep your forks will fall behind the latest version of your dependencies. You’ll miss out on critical bug fixes and security patches!

When I fork I’m very careful to make sure there’s a clear upgrade path in the future.

I only make small changes. The change should only touch a few files and should be very well documented.
I only make changes which I’d reasonably expect to get merged upstream some day. That way there’s a path to getting off the fork.
I’ll only make changes I wouldn’t expect to get merged on projects that aren’t actively maintained.

Once I’m comfortable that the change won’t make upgrading too hard in the future, I fork. Then I have criteria for proposing my forked changes upstream.

Is the change tested?
Is the change documented?
Can I show the change working in a production app?
Can I justify the change to contributors?

This is a lot of work and slows down shipping. To me, it‘s more valuable to live on a fork for a few months and fix bugs for users immediately than to make users wait a few months for a proper open source release with the change.

The best part of open source is that it’s, well, open. You have the power to modify your dependencies. It’s a dangerous power, but if you use it wisely you can ship brilliant user experiences no one else is capable of.

Conclusion

As developers, we have so many tools to ship brilliant user experiences. Don’t be afraid to think out of the box when you encounter a particularly sticky problem. For me, writing my own virtualized list was the best way to build the experience I wanted.

Also don’t be afraid of forking your dependencies. Yes it’s dangerous, yes it will make your life harder if you’re not careful, but it’s also an incredibly powerful tool. Recognize the risks and use it where appropriate.

I put the code for my virtualized list in a gist. I don’t currently plan to turn it into a reusable open source component. That wasn’t my goal. Shipping a unique experience for my users was my goal.

Writing Good Compiler Error Messages

Caleb Meredith — Mon, 01 Jul 2019 19:00:00 +0000

It’s never fun when you see an error message while trying to ship some code. It means you’re one step further from working software! It doesn’t help that a lot of error messages are completely inscrutable.

After spending a lot of time redesigning Flow’s error messages I’ve developed a personal style guide for writing helpful compiler error messages. Before jumping into the style guide, I’ll share my philosophy around error messages.

Philosophy

Roughly, you can sort a developer’s reaction to an error message into two
categories:

80% of the time, the developer will immediately know what the fix is. The error will be related to code they’re actively working on. The developer may even know how to fix it just by seeing where the red squiggly in their IDE is. No need to read the error message.
20% of the time, the developer won’t immediately know why the compiler says their code is incorrect. The compiler might have a complex rule that’s non-intuitive but important to the safety of the program. In this case, an error message should provide enough information to enable the developer to take a deep dive into their program.

In the 80% case a developer is either quickly iterating through their code and a long error message would be a disservice to their productivity. They only need a glance at the message to know what to fix.

In the 20% case it will be really difficult to pack enough context into a single error message to explain the problem. The error message’s fix might be somewhere far away from the reported location since the compiler can’t determine a human’s intent. The error might be caused by a really nuanced rule that can’t easily be explained in an error message format.

A great example of a rough error messages in the 20% case is anything reported by the Rust borrow checker or the Elm infinite type error message:

I am inferring a weird self-referential type for x:

11| f x = x x
      ^
Here is my best effort at writing down the type. You will see ∞ for parts of
the type that repeat something already printed out infinitely.

    ∞ -> a

Staring at this type is usually not so helpful, so I recommend reading the
hints at <https://elm-lang.org/0.19.0/infinite-type> to get unstuck!

Elm even acknowledges that “staring at this…is usually not helpful”.

Context

It’s also important to understand the context of where the developer will see an error message. For a programming language, ideally you have good editor integration so the user is going to see your error message in an editor like VSCode.

The IDE context favors short error messages that are one to two sentences long. When you hover over an error the popup doesn’t give you much space!

Many IDEs, like VSCode, also have some kind of panel where they show you all the error messages at once. The design of this space is also best suited to short one to two sentence long error messages.

Thinking about the context where an error message is displayed influences my style guide a lot. Usually, most compiler developers are designing their error messages in the command line (CLI). Which is why you get colored multiline messages that print out code.

I design error messages IDE first, not CLI first. Like the way you’d design a website to be mobile first. The IDE is much more constrained than the CLI. If you design a good IDE message you can easily adapt it to the CLI. It’s much harder to adapt a message designed for the CLI to an IDE since you didn’t think of an IDE’s constraints when designing your message.

Style Guide

Now that you know my philosophy and the context I design for, let’s get into my error message style guide!

Keep error messages short. Preferably a single, clear, sentence. This format works best in an IDE context.
The error location is so important since that’s where the red squiggly goes in an IDE. Pick the smallest possible location at the operation which triggered the error. If the user is writing a new operation the error will point to where they are working. If the user is refactoring the error will point to all the operations which need to change.
Don’t print out information a developer could easily find in their code. Instead print a reference to that information which is linked in an IDE. TypeScript likes to print out huge types in error messages, this makes it hard to read the message.
Use correct English grammar. This is probably obvious, but it can be hard to make a program which produces correct English grammar. It’s easy to stitch together arbitrary sentence fragments. Put some rules on the grammatical structure of your sentence fragments. It’s also worth going the extra mile to add grammatical decoration like articles: “a String is not an Int” vs “String is not Int”. Just be careful when using developer-defined names.
Write messages in first person plural. That is, use “we”. For example “we see an error”. This personifies the compiler as a team of people looking for bugs in the developer’s code. By personifying our type checker error messages feel like a dialogue. Elm’s error messages are famous for using first person: “I see an error”. First person feels a bit uncomfortable to me. A compiler is certainly not a single person, nor is it built by a single person. I prefer “we” as a compromise.
Use present tense instead of past tense. Instead of “we found” say “we see”. When an error is displayed to a user, the code is currently in a bad state. From the compiler author’s perspective, the compiler runs at discrete points in time and “finds” errors at those points. From the developer’s perspective an error in their IDE reflects the current state of the program, not a discrete compiler run. Prefer the developer’s IDE context, use present tense.
Reduce the grade reading level as much as possible. I use the Hemingway Editor for this. I’ll paste in an error message and the editor tells me the grade reading level (for example, 6th grade). I then try to reduce the grade level as much as possible without sacrificing clarity.
Use language the developer will understand, not compiler-speak. Words like “identifier”, “token”, and “expression” are compiler-speak. Prefer the names a developer would use in conversation with their peers. Also consider the context of your error message. If you expect a variable name, say that instead of saying “expected identifier”.
Use Markdown for formatting error messages. If you want to include a code snippet put it between backticks (`) which are used in Markdown to indicate inline code. The code editor should format your message appropriately.
If you use quotes, make sure they are the proper curly quote characters. For example: “phrase” instead of "phrase". See the difference? It’s subtle. I’ve gotten into the habit of typing these characters after taking a typography course. U+201C (“), U+201D (”), U+2018 (‘), and U+2019 (’).

Following this guide will produce error messages with a consistent tone, voice, and style.

Conclusion

Short, simple, and clear error messages are much better than long and detailed error messages. They fit the developer’s IDE context better and they don’t distract the developer when they are trying to debug a particularly unintuitive error.

Good error messages will make developers more efficient. They’ll spend less time staring at error message text and more time building products their users will love.

IDE Wishlist

There are two features I want from the IDEs rendering my error messages written with my style guide. Specifically, I want these features in the
Language Server Protocol (LSP) Specification which is supported by VSCode, Atom, and other code editors.

I want my error messages to be rendered with markdown. Currently, at least in VSCode, error messages are rendered with a monospace font. My messages are designed to be proper English sentences with inline code snippets, not code.
I want to link to code in error messages. Often, I’ll have an error that reads “Foo is not Bar”. I want “Foo” to be a hyperlink to where the compiler found the Foo type! Same for Bar. I can hack around this with the LSP’s relatedInformation field but it’s not the same as being able to write a hyperlink inline.

Taking Control of Compilation

Caleb Meredith — Tue, 18 Jun 2019 03:00:00 +0000

The more work we can do at compile time, the better! That’s less work our code has to do at runtime, but it’s not easy to move work to compile time. In this post I propose a new way of executing code, focused on JavaScript applications, that makes moving work to compile time as simple as moving a variable to global scope.

Let’s first think about our code’s compilation and execution in two phases, buildtime and runtime respectively.

Buildtime code executes on the developer’s machine before they deploy their application. Runtime code executes on a user’s machine when they run the application.

Buildtime tasks include Webpack bundling many JavaScript files into one big file or Babel compiling ES6 features down to ES5. Svelte does a lot of work at buildtime to create a fast application at runtime.

When we developers write JavaScript, or other product languages like Swift and Kotlin, we expect that all our code will be executed at runtime. If we want to execute something at buildtime we write a script or a compiler plugin.

There are a lot of tasks in product development which would make sense to run at buildtime, but we often run these tasks at runtime instead since it’s convenient. For example:

Parsing Apollo GraphQLqueries.
Parsing Styled Components CSS.
Choosing a translation based on the locale.

There are also a lot of tasks which we do run at buildtime but require lots of configuration outside of our source code.

Bundle splitting.
Optimizing image formats like SVG.
Extracting CSS to a static file.
Generating HTML files.

We have many opportunities to optimize our applications at buildtime. However, we miss a lot of those opportunities because configuring Webpack or Babel or_insert buildtime tool here_ is hard.

We also have very few ways to innovate when it to buildtime work. There’sSvelte which had to build its own compiler to innovate at buildtime. There’sbabel-plugin-macros which requires macro authors to write a Babel AST transform where it’s easy to miss corner cases.

Today, I will propose a vision for a new way to execute programs that makes writing buildtime code free. No Webpack plugins. No Babel transforms. No custom compilers.

By making buildtime code dead simple to write, we can empower every developer to make the next big compiler optimization for our products.

Vision: Modules execute at Buildtime, not Runtime

Today a JavaScript module that looks like this:

import fibonacci from './utils/fibonacci';

console.log(fibonacci(12)); // 144

Will print “144” to the console of every end user of the application. This module executes at runtime.

Instead, let’s execute it at buildtime and add a hook for executing code at runtime.

import fibonacci from './utils/fibonacci';

const x = fibonacci(12);

Build.createBundle('my-bundle.js', () => {
  console.log(x);
});

We now execute this module at buildtime. We compute fibonacci(12) once on the developer’s machine instead of thousands of times on the machines of their users.

Then, we call Build.createBundle() which creates a new JS bundle namedmy-bundle.js. Just like adding a new entry to your Webpack config. After running this code at buildtime you’ll get a bundle that looks like this.

var x = 144;
console.log(x);

We don’t have to include our fibonacci() function in the bundle and we can directly inline the constant result of calling fibonacci(12).

Let’s consider a more advanced example, translations.

import App from './App';
import TranslationContext from './TranslationContext';

const localeNames = Build.importDirectory('./translations/locales');

for (const localeName of localeNames) {
  const locale = JSON.parse(
    Build.importFile(`./translations/locales/${localeName}.json`)
  );

  Build.createBundle(`app.${localeName}.js`, () => {
    React.render(
      <TranslationContext.Provider value={locale}>
        <App />
      </TranslationContext.Provider>
    );
  });
}

Let’s say you have a directory ./translations/locales with three files that include translations for your app: en-US.json, es-MX.json, and zh-CN.json.

In this example, we declare that our app depends on all the files in our translations directory using Build.importDirectory() and Build.importFile(). A good buildtime framework can also then watch these JSON files and rebuild the bundles when they change.

We then create a new bundle for every locale where we render a React app! Since the arrow function captures the locale JSON data, that data will be included in the final bundle. Along with any other constant data we capture.

If you have a page that doesn’t require any data from the user, you may also compile it statically at buildtime. Like Gatsby!

It‘s not just our top level application files that run at buildtime. Every one of our files would run at buildtime.

export function TodoItem() {
  const data = useQuery(query);

  return <div className={styles.item}>{/* ... */}</div>;
}

const query = graphql`
  fragment todo on TodoItem {
    id
    name
    completed
    # ...
  }
`;

const styles = css`
  .item {
    border: solid 2px red;
  }
  /* ... */
`;

In this example, we have two variables in our module scope: query andstyles. Both of these variables would be computed at buildtime! We’d parse the corresponding GraphQL and CSS, run any transformations, and output JSON objects to the resulting bundle.

The only difference is we’d do it at buildtime instead of runtime.

To use a React component defined like this:

import TodoItem from './TodoItem';

// Nope! We don’t render in the module scope.
//
// ❌ React.render(todos.map(todo => <TodoItem todo={todo} />));

// Instead we render in a bundle we create at buildtime.
Build.createBundle('app.js', () => {
  React.render(todos.map(todo => <TodoItem todo={todo} />));
});

Interested?

Does this model of execution interest you? Let me know! Twitter:@calebmer.

There’s a lot to figure out to make this work in JavaScript. I imagine we could create an AST transform that adds an environment record of the variables captured a function. So the following code:

const x = fibonacci(10);
const y = fibonacci(11);

Build.createBundle('my-bundle.js', () => {
  console.log(x + y);
});

Would be transformed by wrapping all functions in some addCapturedVariables()function:

const x = fibonacci(10);
const y = fibonacci(11);

Build.createBundle(
  'my-bundle.js',
  addCapturedVariables({x: x, y: y}, () => {
    console.log(x + y);
  })
);

That way buildtime code could serialize captured variables out to a runtime bundle.

Making this process fast is another question entirely. There are likely ways to intelligently determine if buildtime or runtime code was changed. If only runtime code changed, then you don’t need to re-run your buildtime logic.

DEV Community: Caleb Meredith

How to survive (and thrive!) in software engineering interviews

So, you’re preparing for a software interview? Welcome!

Interview terrors: taming the beast

Rejections! Fresh rejections! Get ‘em while they’re hot!

The interview itself: Shall I compare thee to a band-aid?

The interview itself - some answers are more right than others

The interviewers: just…some other people?

Techniques for Improvement

Confidence is Key

Practice may not make perfect, but it sure builds muscle memory

Programming languages and problem solving

Will I have to use a whiteboard like on TV?

Conclusion

Tired: Golf, Wired: Boardgames

One Night Ultimate Werewolf

Sheriff of Nottingham

Captain Sonar

Dominion

Tabletop RPGs

Conclusion

My Adventures Writing a Cross-Platform Virtualized List

Part 1: The Product

Part 2: When I realized existing virtualized lists wouldn’t work…

Part 3: How it works

Part 4: Forking React Native

In defense of forking

Conclusion

Writing Good Compiler Error Messages

Philosophy

Context

Style Guide

Conclusion

IDE Wishlist

Further Reading

Taking Control of Compilation

Vision: Modules execute at Buildtime, not Runtime

Interested?

Further Reading