Large, well-known tech companies have a different problem. They have a huge number of candidates applying for each position, and they really want to hire extremely smart people who will make tremendous contributions over time, allowing for top notch graduates who don’t necessarily have a lot of experience with particular technologies, while keeping out candidates who are not really good at programming. Large companies are also litigation targets, so firing someone is not as easy. As a result of that, hiring someone is not as easy to do.

This difference shows up in the way that large tech companies interview candidates. The classic puzzle questions (made famous by Microsoft, and imitated by many since then) are designed to measure intelligence via problem solving ability. Whether they ever accomplished that is debatable, but this sort of interviewing is now easy to prepare for because there are so many answer guides available online.

A more respected technique of interviewing programmers that has survived is the coding interview. In my career I have found that most of the companies that required me to code in an interview were better overall (nicer companies to work for, more successful, with smarter co-workers) so I am happy when a company I’m interviewing for asks me to write some code.

However, in my experience as an interviewer at several companies, programming job candidates are generally unprepared for this type of interview. I suspect that this is because they expect to just have to answer questions verbally and then get hired, proving their skills afterward. As I mentioned above, this may make sense for startup companies due to the lower volume of candidates, but for large tech companies, this is not feasible. (Similarly, for smaller companies growing quickly, such as a startup that just got a VC cash infusion that is ready to staff up, hiring a bunch of promising candidates and then having your existing programmers look over their shoulder for the first few weeks may not be feasible due to the sheer number of people they’d have to keep an eye on.)

When I was a college freshman studying electrical engineering, I was shocked at the workload in the engineering classes that every engineer had to take, as compared to some of the general prerequisite classes or more specific EE courses. I later learned the term “weed-out course”, which refers to a course designed to both teach the material and to “weed out” (eliminate) students who were not prepared to work hard and really pursue that major.

Larger companies need to use coding exercises in interviews as a “weed-out” technique, to eliminate the weak candidates as early as possible. So if you’re trying to get hired at a large tech company, you need to get over the idea that you can talk your way into a job, and prepare yourself for the somewhat unnatural challenge of coding during an interview.

Coding Interview Advice

Working on a small, unfamiliar problem with no language reference, no API reference, no autocomplete, and no error highlighting really flusters some people. This is a hurdle that you will have to overcome in order to demonstrate that you are in fact a good programmer.

Specifically, you should develop the ability to write a correct 10-20 line program body on a whiteboard, a piece of paper, napkin, etc. under time pressure in your preferred language. Practicing in ink on paper, maybe using a sharpie or dry-erase marker on a legal pad, and then typing it in and trying to compile and run it, is great practice.

Also, as a programmer your job is to talk to people and understand the problem that your code is supposed to solve. This is incredibly important in real programming work, and is a gigantic topic in itself (e.g. are the requirements you’re being given really the requirements or are they someone else’s partial solution to the real problem, which you can negotiate?). Not surprisingly, if you solve the wrong problem in your interview, you won’t give a good impression even if your code solves some other problem that the interviewer doesn’t care about.

So, make sure that you fully understand the problem; repeating it back to the interviewer and maybe rephrasing it is a great way to do this. Write down lots of notes and scribbles (tables, diagrams, maybe the exact text of the question as the interviewer said it) until you completely understand the algorithm and corner cases before jumping to code. The last thing you should do is to write out the code, and it should be obvious to you and the interviewer that you already have solved the problem before you do so. Remember how your math teachers insisted that you show your work instead of just writing down the answer? This is a good way to think about coding interviews: you need to show how you got from the question to a particular solution; this will help you avoid misunderstanding the question, gives the interviewer a chance to correct any confusion you have about what the problem is, and will force you to really think through your solution. You don’t want to be distracted by looking around the room for an eraser or trying to improve the penmanship of your curly braces while you scribble some half-baked code on the whiteboard and then constantly erase and rewrite it as you think. Finish thinking through your solution in detail, then write down the code.

Finally, practice with friends in mock coding interviews. If you’re lucky you will have other programmer friends who can benefit from switching places and letting you be the interviewer, and you may be able to learn how to be a better interviewee from watching them make mistakes. :)

Someone else solved this problem three years ago but nobody accepted their patch, and now /etc/bash_completion.d/screen has been overhauled and the patch no longer applies.

I updated the patch so it works and resubmitted it to Ubuntu.

If you don’t wanna wait, grab the code from this gist and do this:

sudo patch /etc/bash_completion.d/screen screen.patch

This will probably work on Debian too since that’s where the completion script came from.

Well, a few months ago Ilya Grigorik posted a Gist containing a really amusing microframework that is one of the most brilliantly expressive bits of code I’ve ever seen, without being particularly hard to read. 13 lines of Ruby code provides a web application that will allow any Ruby object you choose to have its entire public API exposed via URLs of the form /method/arg1/arg2, where the method return value becomes the response body.

For the benefit of non-Ruby developers, I’m going to walk through all 13 lines of code plus the 1-line example application to explain how it works. I really hope that by reading through this explanation you will come to appreciate the expressiveness of Ruby, and maybe what a clever bit of dynamic language programming this is.

Here is the code: Inspired by @JEG2’s talk at Rubyconf… Any ruby object, as a webapp! ‘Cause we can. :-)
In particular, note the 7th comment, with the embedded animated GIF. This should put you into the right frame of mind for understanding this code.

Line 1: Load RubyGems, which is a library that helps you manage other Ruby libraries that your code depends on.

Line 2: Load Rack, which is a standard API for connecting web servers to web application frameworks.

Line 4: We are modifying the Object class itself, so our changes will affect every object in the application.

Line 5: We are adding an instance method called “webapp” to every object.

Line 6: We are going to modify the class of just the instance whose “webapp” method was invoked. This may seem paradoxical: how can you modify its class without affecting all other instances of that class? The answer is that we are actually creating a unique, anonymous subclass, and the object whose “webapp” method was invoked now becomes an instance of it. So when a caller invokes “webapp” on an object, we will modify just that instance.

Line 7: We are defining a method in our anonymous subclass named “call”, which takes a single argument, “env”. This is what the Rack API will invoke to ask our web application to handle each web server request.

Line 8: We are splitting the URL path on occurrences of “/” and storing the result into an array, and then filtering out all elements of that array that return true when the “empty?” method is called on them. Then, using multiple assignment, we take the first element of the array and assign it to the local variable “func”, and a new array containing the remaining elements to the local variable “attrs”.

Line 9: The Rack API expects a return value of an array containing 3 elements: an HTTP status code, a hash of HTTP response header names and values, and the response body. So here we respond with that array. “send(func, *attrs)” is an expression that calls “send” on self, which lets you invoke a method without specifying the name of the method nor the arguments to be passed to it until runtime. The method invoked is the one named in func, and the argument list passed to that method are taken from the attrs array. This is how the URL of the web request is mapped onto the API of the object that you made into a webapp.

Line 12: The return value from invoking the “webapp” method will be the same object that “webapp” was invoked on, which now has our special “call” method added.

Okay, so that’s it: a tiny Ruby web app microframework. Now we’re going to use it to expose an object!

Line 16: Start up the Mongrel web server listening on port 9292, and load up an empty array as a Rack webapp.

Lines 17-19 are a joke: because our webapp is an array, we have just implemented a horizontally scalable in-memory sharded NoSQL database, which is really the only suitable option for our expected ROFLScale needs.

Line 23: [].push(1) returns [1]; rack calls .to_s (convert to string) which returns “1″ as the response body.
Lines 24 and 25: Since the array is the webapp, the changes are persistent.
Line 27: [1,2,3].to_a returns [1,2,3], and [1,2,3].to_s returns “123″.
Line 29: Remove the last value, returning 3 and leaving [1,2] in the array.
Line 30: Remove the first value, returning 1 and leaving [2] in the array.

/usr/local/bin/macirb:60:in `block': No such file or directory - open() failed (Errno::ENOENT)
	from /usr/local/bin/macirb:9:in `block'
	from /usr/local/bin/macirb:7:in `
'

If you’re seeing this, you need to do something like this:

# preserve history across irb executions:
require 'irb/completion'
unless 'macruby' == RUBY_ENGINE
  require 'irb/ext/save-history'
  ARGV.concat [ "--readline"]
end
IRB.conf[:SAVE_HISTORY] = 100
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-save-history"

What I changed was to add lines 2 and 5 from that excerpt, making lines 3 and 4 only run if I’m *not* using macirb. If you’re getting the same error from macirb, this (or something similar) should fix it.

The monit configuration stanza (in monitrc) looks like this:

check process mailtunnel with pidfile /var/run/autossh.pid
  start program = "/root/start_mailtunnel.sh"
  stop program = "/root/stop_mailtunnel.sh"
  if changed pid then alert
  if failed host localhost port 2525 protocol smtp with timeout 30 seconds then alert
  if 3 restarts within 5 cycles then timeout

start_mailtunnel.sh looks like this:

#!/bin/sh
export AUTOSSH_PIDFILE=/var/run/autossh.pid
/usr/bin/autossh -N mailtunnel &

And that -N is the key to making ssh happily connect and not run a remote shell, which would want a tty on stdin. That’s how you tell it to just be a port-forwarding connection.

The ssh mailtunnel config just has some port forwarding rules, and “ExitOnForwardFailure yes”.

Finally, stop_mailtunnel.sh looks like this:

#!/bin/sh
test -e /var/run/autossh.pid && kill `cat /var/run/autossh.pid`

So now instead of making a YAML file and referring to it, pass the options like this:

bundle config build.nokogiri \
--with-xml2-include=/usr/local/include/libxml2 \
--with-xml2-lib=/usr/local/lib

The problem would appear unpredictably, and defied my attempts to reproduce it, with one exception: Netflix Instant streaming would invariably result in a failure in less than 15 minutes of play. I tried updating the Silverlight plugin, and then simply not ever using Netflix streaming, but that didn’t help. Eventually I found that running anything that kept the CPU near 100% utilization for a minute or so would trigger the problem. Could it be a thermal issue?

I use iStat Menus so I was able to easily see that my CPU temperature was over 160°F whenever this happened, and my fan speed was about 6000 RPM. I tried placing something under my laptop to increase airflow underneath it (simulating my wife’s Griffin Elevator), but that didn’t help. I did some searching to see if that CPU temperature and fan speed were unusual, and found the Intel Mac Temperature Database. It seems like other folks have seen higher CPU temperatures than 160°F without problems, so that probably wasn’t it.

I decided to dig around a bit to see if 6000 RPM was a reasonable fan speed. Apparently not; several pages I found mentioned that MacBook Pros get uncomfortably hot because the standard temperature to fan speed profile that Apple used wasn’t enough to keep the laptop cool, and so some people use smcFanControl to increase the minimum fan speed to 4000 RPM. I installed smcFanControl and found that 6000 RPM is the maximum fan speed it allows.

I wondered if maybe my laptop was getting hot, and the fans were working as hard as they could and still couldn’t keep the temperature under control?

Following that hypothesis led me to this post in the "Macbook overheating?" thread on MacRumors. Since I’ve upgraded the hard drive in every MacBook I’ve owned, I have the tools to open one up already, and the excellent iFixIt Fan Replacement Instructions were almost the same as what I’d had to do for a hard disk replacement, so I decided to go ahead and open it up and take a look myself.

Here’s what I found:

The right fan filter is almost completely clogged. (click to enlarge)

The left fan filter is also almost completely clogged. (click to enlarge)

Jackpot. I vacuumed the dust out. Here’s what it’s supposed to look like:

That's much better.

The left fan filter is now clean-ish.

I put it back together, and the problem is gone! Cost: $0.

As a bonus, it runs cooler so it isn’t painful to use on my lap, and since the fans don’t have to work so hard, it’s quieter than before.

So if you have a flaky MacBook Pro of similar age that’s running strangely hot and your fans are running at full blast, maybe you should open it up and see what your dust situation is. Like I said, my guess is that every single MacBook Pro will experience this problem sooner or later.

User story: “As a princess I want to confirm my royalty so I get bruised after sleeping on 40 mattresses over a pea”. Just tell real stories”

That sounded so much like a Cucumber feature that I decided to write it as one:

Feature: Physical Sensitivity
  In order to confirm my royalty
  As a princess
  I want to be very delicate

  Scenario: 40 mattresses on a pea
  Given there is a pea on the bed
  And there is a stack of 20 mattresses on the pea
  And there is a stack of 20 featherbeds on the mattresses
  When I try to sleep on top of the stack of featherbeds
  Then I should not be able to sleep

But do you know about kill -STOP and kill -CONT?

I’m not sure of the exact mechanism (kernel vs. user process) but everything I’ve used it on on a Mac OS X machine has responded to it in the same way. So you may find a process that doesn’t do this, but I haven’t found one.

Basically kill -STOP 1234 will pause the process with pid 1234, and kill -CONT 1234 will resume it. It’s as if you can sleep individual applications instead of your entire computer.

It’s simple, but you can probably imagine why this would be useful. Want to keep Firefox with 45 tabs open, but you’re not using it for a while and you want to save battery life? Pause it. Pretty much anything like “I don’t want to quit and then re-launch this but I wish it wasn’t using a bunch of CPU time while it idles” is a good candidate.

Remember that this means your app my time out when it is resumed, as if you had slept your laptop. So network connections it had open when you paused it may be broken when you resume it. So pausing Terminal.app with a bunch of open ssh connections to remote servers isn’t going to work too well.

`method_missing': No sham defined for name

It’s discussed in the machinist Google Group as well.

It’s because of a wacky hack that’s part of Machinist that overrides Module.name so you can do Sham.name, but ZenTest expects Module.name to do what it does normally.

I have a fix for this.

I sent notahat a pull request via GitHub, so hopefully it’ll be merged by notahat into the official machinist gem, but until that happens you can try mine. I published the gem as JamieFlournoy-machinist to rubygems.org.

Try ‘gem install JamieFlournoy-machinist -v 1.0.6′ and see if it works for you. It does for me with ZenTest 4.2.1, autotest-rails 4.1.0, and a Rails 2.3.5 project.

(my machinist fork on github)