Jade's weblog Archive

But today I want to talk about interviewing. I used to think I was an effective interviewee. I had some experience interviewing before, which gave me perspective on the other side of the table. So I thought I knew what was involved, and generally thought I understood the terrain.

But then I failed an interview I really cared about. I completely bombed it, after multiple interviews with the company. It shook me up, and made me reconsider. Maybe I wasn't that good at interviewing.

I talked with my friend Dana, who is one of the most savvy people I know at this sort of thing. I was impressed with how strategic her approach to interviewing was. She gave me some ideas of how to approach interviewing, and suggested I read up on interviewing.

So I spent some time learning about how to approach interviews, and the more I read, the more I became convinced that I had a lot to learn about interviewing. In fact, I sucked at interviewing.

One of the most important things I learned was that you have to have a plan going into an interview.

Here's my formula:

A) Find out what they want from the position. The best way to find out the answer to this is to ask, but you can also infer. Try to have three things you know they're looking for. So, for example, maybe they are looking for someone:

1) with Rails experience
2) who can help with scaling their backend system
3) and who has experience with developing social networks

B) Your main point during the interview is to make sure you cover those three points. You should have stories prepared that tell the story to SHOW that you have those areas covered. And if you know that you're weak in that area, examples of ways that you have overcome similar weaknesses in the past.

You can be absolutely sure they will ask about your current job, and maybe the job before that. People remember and respond well to narratives. Tell a story they'll remember, about one of those three points.

That's what I learned. Of course, I still messed up some of these points in my interviews, but I know I got better at it. I got four job offers within a month of focusing on improving my interviewing skills.

Also, be careful with your end date selection. Some places will extend your benefits to the end of the month, or not, depending on when the end date is. My recommendation is to give notice, but before you select the official date, talk with your HR person very carefully. This can be tricky, because often your end date is dictated by the date you'll start at the new position.

The tools we use don't really make this easy to diagnose. The server logs only write out after the request completes, so you don't know the URL that is causing the problem. And we get enough traffic that it's difficult to know exactly where the issue is.

One possibility is to write out the current URL at the beginning of each request. We tried this, but again, we have enough traffic that it's still difficult to read.

One of my team members, Levy Bajamundi, came up with the clever idea of optionally instrumenting our procs so that they show a stack trace if they get beyond a certain depth in the stack. If you set the level high enough, this pretty much guarantees you can automatically detect infinite loops, and it will give you data on where the actual problem is.

After some discussion, we decided to make this an optional, configurable feature. The code uses info level to check the current level in every method call, when enabled. If the level is too high, it writes a very prominent message to the log file, with a stack trace. We hope to use it to troubleshoot the problem and get it fixed quickly. And then turn it back off.

Will it work? Stay tuned.

The best thing about this, as far as I can tell, is that your code base is always in sync with your "database". That's also the biggest disadvantage: how do you roll back a code change? Maybe they use git submodules?

I'm curious what the performance implications will be like. I.e., how often are your objects actually committed? And how does this affect your commit log? Is it done on every change, or is it a scheduled job?

As much as I love databases (and feel like I have a lot of expertise in them), MagLev and ideas like this seem like a promising direction for web development. Why do we go through such contortions to store our objects and retrieve them? Why do we need ORM?

I actually replied to one position saying that I was more of a sumo wrestler than a rockstar or ninja. They were pretty good humored about it.

But it led me to wonder where these memes had come from, and why this was considered desirable.

I came to the conclusion that what they were really looking for was a very competent developer. But there is something about both of these monikers that sounds like they want a super-human to come and rescue them. And it seems (to me at least) to indicate that they don't actually care about a stellar team, but the cult of the individual.

How about this: instead of using rockstar or ninja, write out exactly what you're looking for?

New Relic offers a website as service product to monitor and diagnose performance issues in production websites. Their product is like a debugger for performance issues, but it's really something you have to see and use to see just how useful it is.

They started out in the Ruby on Rails space, and seem to have dominated that niche quite well. They've now expanded into Java, PHP, and .NET as well.

I knew I wanted to work at New Relic when I found myself recommending their product during interviews at other companies. But it was much more for me than just their product (which I think is outstanding and innovative): the team seems like a very smart group of people, and I felt right at home there. And they seem to have a very sane, humane engineering culture. It says a lot about New Relic when I turned down a job offer that pays about 30% more to work at New Relic. And I care about money!

So, now that I have secured a job there, I want to share some things I learned about searching for a job. I got pretty good at some parts of the job search and discovered I was quite bad at other parts.

Here's what I was good at: at the end, I was getting about an 90% response rate on my resume.

Here's what I was bad at: I sucked at interviews. What's funny is that I didn't know that I was bad at interviewing until I started learning about how to interview. I was doing almost everything wrong, except that I always did ask lots of questions during interviews.

Anyway, I plan to write some insights I learned, and complaints I have, here. So stay turned.

submit_tag, :onclick => "this.disabled = true"

Will cause the form to not be able to be submitted, except for in Firefox.

Instead, use: submit_tag "Save", :disable_with => "Saved"


What happens behind the scenes? Well, if you look at the source, it uses unobtrusive Javascript to work its magic: the rendered HTML says data-disable-with="Saved"

For Prototype, this is the Javascript that is called:

function disableFormElements(form) {
form.select('input[type=submit][data-disable-with]').each(function(input) {
input.store('rails:original-value', input.getValue());
input.setValue(input.readAttribute('data-disable-with')).disable();
});
}

For Jquery (which I'm using), this is the Javascript that is called:

var disable_with_input_selector = 'input[data-disable-with]',
disable_with_form_remote_selector = 'form[data-remote]:has(' + disable_with_input_selector + ')',
disable_with_form_not_remote_selector = 'form:not([data-remote]):has(' + disable_with_input_selector + ')';

var disable_with_input_function = function () {
$(this).find(disable_with_input_selector).each(function () {
var input = $(this);
input.data('enable-with', input.val())
.attr('value', input.attr('data-disable-with'))
.attr('disabled', 'disabled');
});
};

My guess is that my original code was disabling the FORM instead of the submit button when being clicked?

I can't believe he doesn't know who Mork and Mindy are. His Jewish comment was offensive. But the topic is interesting.

They built a MySQL plugin which allows you to use the InnoDB backend and a new query API that uses indexes and avoids the time lost to locking tables and parsing SQL.

Really this just shows how inefficient MySQL is? But it's cool that the architecture allows you to work around these inefficient parts.

It's also pretty amazing that they were able to outperform memcached.

Squealer on Github

If you want to get insight into how well tested your Ruby code is, rcov gives you very nice looking results.

• Write code that can write to Cassandra in parallel to Mysql, but keep it disabled by the tool I mentioned above
• Slowly turn up the writes to Cassandra (we can do this by user groups “turn this feature on for employees only” or by percentages “turn this feature on for 1.2% of users”)
• Find a bug :)
• Turn the feature off
• Fix the bug and deploy
• GOTO #2

What I find interesting is the development in architectures that let you alter the availability to consistency trade-off based on your needs.

I've been looking at Cassandra recently, and it's very impressive.

#!/bin/sh
rake

Very simple, but it prevents commits that break the test suite. My next step is to extend my capistrano deploy scripts so that they do a bundle install (and gracefully roll back on failure). And then, it seems like I could just add a post-commit script that looks like this:

cap deploy

There are some disadvantages to having these hooks: they slow down the speed of a commit. But having a stable master will force some great habits: extensive testing for any new commit to make sure nothing breaks, etc...

On a mission critical system, I'd probably add a build server that takes each commit, runs an extensive test suite, emails on failure, and doesn't proceed unless the commit succeeds. And you'd probably start with continuous deployment on QA and/or staging first.

I like the organization of Rspec tests, and the DSL seems fairly intuitive so far. First impressions are good.

https://www.rubick.com/rails/

We've done this at work -- I just didn't know what it was called.

It looks like it's well on its way to getting a zillion comments.

To understand the idea behind Plantworking, try and imagine if everyone on Facebook or Twitter was only posting topics that were related to gardening. Imagine the usefulness of that!

I'm actively working on the site, and I'd appreciate any feedback you might have.

http://www.plantworking.com

fatal: Couldn't find remote ref HEAD

I found the bug report here and used the workaround suggested there:

cd vendor/plugins/
git clone -q http://github.com/rails/exception_notification.git

OR EVEN BETTER

git submodule add http://github.com/rails/exception_notification.git vendor/plugins/exception_notification

I dislike the MongoMapper API, and it seems like Mongoid has a few nice features that seem like they make a big difference, like naming your keys.