You don’t have to see a person’s code to figure out whether they’re a good developer. Over the past ten or so years, I’ve interviewed a lot of engineers. In that time, I’ve developed a set of techniques that allow me to quickly and accurately evaluate a developer without seeing their code. I’m now convinced that it’s not only possible, but objectively better to do it that way.
On May 10 (2018), Josh Pigford kicked off some Twitter drama with a Tweet that he and a lot of people found pretty uncontroversial. Unfortunately for Josh, it was not uncontroversial. Allow me to dispel the myth of job hopping.
I recently had a great conversation about application testing strategy and remote API calls. The question we were trying to answer was this: In an application which makes external API call, when should you mock those calls in your test suite, and when should you make live calls in your tests? My take on this issue: always always always mock external1 API calls. Here’s why: This gets more tricky when you own both systems, but I still stand by this as a best practice for that situation as well, for slightly different reasons. ↩
Aspiring software engineers are often asked for code samples to demonstrate that they’ve got some clue what they’re doing. This is pretty terrifying and it’s incredibly difficult. When they’re not done well, they don’t provide much in the way of useful information. I’m a lead engineer at a pretty cool software company. I’ve been in a lot of interviews and I’ve read a lot of crappy code samples. I decided to write about what would get me excited about a candidate’s code sample (and, by extension, them). Other people might feel differently. That’s cool; this isn’t a math test. (But I would love to hear those counter-points in the comments below!)
Over the past week I’ve been diving into Elixir and Phoenix. As it is with most languages, there some good and some bad with Elixir. That said, anyone announcing the death of Rails at the hands of Phoenix is probably a bit early. While I didn’t do any benchmarks myself, that path is well worn. It seems fair to say that Elixir is probably faster than Ruby and Phoenix is probably significantly faster than Rails. It’s also likely that Phoenix will handle WebSockets far better than Rails will, even with ActionCable. On top of all of that, Elixir seems to also have a slight edge over Rails in terms of asynchronous jobs, since they can be done directly. For truly heavy jobs, Elixir …