Cloudbacon A flowy thought place

Derailing Tech Interviews For The Better

One of the most feared activities on this planet is the tech interview. Not so much the first, get to know you interview but, the third interview. The one where the interviewer asks a question about recursion… or ML. No, I am not currently looking for a new job, I have just had the pleasure of derailing a technical interview recently. In addition, this topic always seams to be top of mind. Plus a constant topic talked about in any software engineering circle.

The hard part of it all is pinpointing what makes these interviews so terrifying. Perhaps it is the need to sit there and let the interviewer barate the interviewee with questions that they feel are relavant. We all know these, they may include Towers of Hanoi, cycle detection, something about man hole covers, and my all time favorite: some overweight campers need to get over a rope bridge in 17 minutes. The answer to the above is 12. The campers, in their packing extravaganze happen to have brought a rope. This allows them to pull the required flashlight back across the bridge without having to walk it back.

And… why do these suck? It’s simple: we don’t use Haskell or ML in the real world (not many of us). We also, as web programmers(apparently not even kernel programmers) rarely use recursion. And if we did, Babel or some other transpiler would deconstruct it for us(t’s faster that way). Yet, it is a constant that we will be inundated with these questions during the interview process.

Frankly the above blow but, here are a few that can turn the tide of any interview.

  1. Research the companies open source work. Look for good documentation, well written commit messages and inquire about documentation. Doubly so where it is lacking (no documentation is complete). In some ways, these developer soft skills are more inportant than recursion.
  2. Inquire about how they communicate. Do they use asynchronous tools that add to documentation or do they prefer to do things through video chat? If the latter is true then how or when do they document their face to face time? Have they upgraded their Slack account so history is completely searchable?
  3. Are they partially remote (“remote by design”) or remote first? If the position is remote or augmented the answers here are key. It shows how they value remote employees and if they know how to work remotely themselves.

These questions are aimed at getting the interviewer away from tooting about their ML knowledge. They require a good bit of company research by the interviewee but, this should be a given. Knowing the people who are grilling you on the other end of Skype is the first step in winning. And winning is the only outcome that makes sense when being subjugated by someone else’s ML knowledge.

Hubot Sightings With Monit

Slack and bots go together like peanut butter and chinese food. They are quite, literally over running the joint. So with an already loud and notification filled app like Slack, what’s one more? Hubot is a somewhat older, coffee script powered happiness engine from the folks at GitHub. Getting one of these guys up and running isn’t really the topic here but, this guide is super easy to follow.

Now that there is a bot up and running, we can’t just check out of the server and have it continue to run. That’s where Monit comes in. Monit is a dead-simple, text based uptime monitoring system. It can search out, at an interval and make sure a specific program is still running. If the PID, or whatever is missing, Monit will use the designated start process to start things back up.

Ok, so how can we stitch Monit and Hubot together? Matt Garrison, a couple years ago put together a gist for just this occasion. A couple of things to make this thing work:

  1. Make sure on the restart and start services to use a user and group that is available to your server.
  2. Name the bot properly
  3. Make sure to use the correct path to the bot
  4. And finally/lastly, call the hubot bin from node_modules, it’s cleaner.

Happy annoying your fellow Slack mates with kittens and Archer quotes. Also, if for some reason Matt removes the above link, here is my forked gist

Update for Oct 11, 2015

Since writing this, we have moved on from Monit to God. God, may require Ruby but, overall it has been a much more stable choice over Monit. Monit seemed to generate new instances of the Slackbot And never cleanup the old pids. This left the users confused when they interacted with the bot because any command would be multiplied by the amount of instances currently running. Not good when you are trying to not spam your team’s Slack channel.

God has been exceptionally reliable and always seems to reap the previous PID before creating another instance.

Webpack Hot Reload And Rails

Webpack seems to be getting plenty of lip service these days. Doubly so in the React community which means most of Facebook. Since Rails leans so heavily on the asset pipeline, how can we merge ES6, modules, and other bits of Webpack greatness with the age old, do one thing well: Sprockets

The following two scripts (one used for Development, the other Production), show that Webpack can easily integrate with Rail’s existing asset pipeline. While giving way to utilizing many of the best features hidden in Webpack.

A few caveats about running these scripts:

  1. The directory structure assumes a ./client folder, top level in your Rails app.
  2. The common/development script assumes that assets will be served from a server. This means you will need a few javascript_include_tags wrapped in Rails.env
  3. The two urls for this server are: http://localhost:8080/webpack-dev-server.js and http://localhost:8080/bundle.js.
  4. To run the Dev script: $(npm bin)/webpack-dev-server --config webpack.config.js --hot --progress --inline --display-chunks
  5. And the Prod script: $(npm bin)/webpack --config webpack.production.js
  6. Currently there is only one ‘entry point’ defined as ‘app’. This will need to be modified depending on the entry point or bootstrap script.
  7. The Production script builds one file into the app/assets/javascripts directory.

That’s it!

Infinity Keyboard

As an avid keyboardist, keyboarder… whatever. I jumped on the very first Inifinity Keyboard offered by Massdrop back in November of 2014. Having built it, played with it and attempted to program it with a missing web interface; there is definitely more than a few words on my mind. However, this post is more of an introduction to the knowledge gained throughout my time with it, instead of a true review/product breakdown. GitHub houses a random collection of markdown files. One specifically highlights ways to build/config/customize the Infinity’s layouts.

Hopefully this helps folks out who are struggling with the seeming lack of information surrounding this obscure but, somewhat interesting way to define keyboard layouts. If for any reason you happen to want to add or correct anything, feel free to open a GitHub issue.

One last thing: There seems to be a lot of talk surrounding the bounce/debounce rate of these boards. Some of them seem to exibit double key presses from one single keypress. While this is a configurable option in the KLL files, it should not be a need if the board was properly soldered. A very easy fix is to flux/solder the connections up with quality 60/40 rosin core solder.

Update 2015-04-12

I have finally compiled all of the build scripts into one KLL based directory that could be wrapped in Git. The Git repo is, as always on GitHub and everyone should fork it if they are looking for a quick way to bootstrap their Infinity based Keyboard.

In other news, the awesome folks at Massdrop have released an ErgoDox keyboard variant that will be powered by the same configurator/keyboard mapping language. The great thing about these keyboards using the same controller is only needing to have one workman-p mapping that can be flashed to different keyboards. Which means, although I own and adore my now gen1 ErgoDox, I will definetly be picking up the new version. Likely with stiffer, Cherry MX Tactile Greys.

Problem Solving In Golang

Nope, not actually problem solving because that is in fact boring, something that no one is really interested in and somewhat of a non starter. Doubley so when things haven’t been updated much around here. Go or GoLang is a fantastic language at hunting down problems, or what some would call “debugging”. I would call it debugging as well however, I am sure there are a myriad of words that all mean the same thing.

Whenever a Go program comes under the green light, the developer uses the handy run command. This kicks off the compile step inheret in Go programming; and, since this is in fact programming, there will be errors. These errors are accompanied by a somewhat small stacktrace (thank you Rob) along with the line number where the offense is occurring. The greatest thing is that these exceptions are small, readable (by humans) and consise. A programmer with little information on the language mechanics can read: “no method x exists for x” and realize they likely lower cased the first character of the method’s name. Or perhaps they should just look back through through the documentation one more time to see where they took the incorrect turn.

ALSO! Captial methods… Good one.

Overall, a Luddite as myself can figure out what is going on in a language that I am actively learning and feel satisfied. No stacktraces where you have to increase the lines recorded in Tmux. Just a few lines… For humans.