Jade's weblog Archive

How to Interview Effectively

I like to think that I do a good job with my resume. When I first started applying for jobs about a year ago, I wasn't that seriously looking, but I still was getting about a 25% response rate. Towards the end, I was getting a response from most every place I applied. I'll write later about why I think my resume gets a response when others don't.

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.

10:35 AM, 21 Nov 2010 by Jade Rubick Permalink | Comments (0)

Tips for when you leave a job

When you leave a job, solicit LinkedIn recommendations from your co-workers. It will be much harder to get them later.

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.

10:30 AM, 21 Nov 2010 by Jade Rubick Permalink | Comments (0)

Automated infinite loop detection in Tcl

At work, we are trying to diagnose why a recent push seems to be causing server instability. We eliminated a number of possibilities, and fingers are pointing towards an infinite loop somewhere in the codebase.

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.

02:09 PM, 18 Nov 2010 by Jade Rubick Permalink | Comments (1)

This is where the ActiveModel refactoring is starting to bear fruit. This is a very cool idea: using git to persist objects in Rails.

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?

10:06 AM, 18 Nov 2010 by Jade Rubick Permalink | Comments (0)

Rockstars and Ninjas [www.wait-till-i.com]

One of the most annoying memes of late is the rockstar and ninja memes. I estimate that about 25% of the web programming jobs used the words rockstar or ninja to describe who they were looking for.

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?

10:33 AM, 14 Nov 2010 by Jade Rubick Permalink | Comments (0)

Jade at New Relic

It sounds kind of "Indiana Jones"-ish, but I will be Jade at New Relic starting next month.

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.

10:13 AM, 14 Nov 2010 by Jade Rubick Permalink | Comments (0)

Disabling a button after clicking disables the form on Safari Chrome, and maybe IE

Doing something like this:

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());

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?

10:55 AM, 13 Nov 2010 by Jade Rubick Permalink | Comments (0)



You may request notification for Jade's weblog.

Syndication Feed


Recent Comments

  1. Jade Rubick: And... yes and no
  2. Jade Rubick: Using hoptoad
  3. Jade Rubick: Much better
  4. Bodo Tasche: Link changed :)
  5. Bodo Tasche: Better commt emails. Now with color :)
  6. Jade Rubick: Filed a ticket
  7. Vinod Kurup: Wow
  8. Jade Rubick: Then what
  9. Paul Post: Percentages
  10. Paul Post: I might be an ENFJ?