RoR Job Interview

Hi ,
Got an upcoming job interview as a RoR programmer, just thought If you have good ideas
for questions that might come up during such interview, post them here,
I will try to send back one reply with what I would have answered hopefully this will open some debate,
and might help (me) and future programmers before a Ruby job interview.

Regards,
Yonatan Gross.

Yonatan Gross wrote:

Got an upcoming job interview as a RoR programmer...

If your interviewer has previous experience with ASP.NET, PHP, or
Tomcat, you can get them ranting about them and score some points.

Just don't abuse the trick... :wink:

Phlip wrote:

Yonatan Gross wrote:

Got an upcoming job interview as a RoR programmer...

If your interviewer has previous experience with ASP.NET, PHP, or
Tomcat, you can get them ranting about them and score some points.

Just don't abuse the trick... :wink:

By the way, I wouldn't be surprised if your recruiter is on this list :stuck_out_tongue:
Cheers
..mohit.

first , thanks for your replies.

mohit,

I guess he is on this list… still started to think about it today, and thought it would trigger
a nice discussion.

I read Jan Martin’s post , and it’s definitely handy to have a list of question to sit down with yourself

before a job interview. However, I was thinking more in the direction of the technical aspects of the

interview. I guess there are many ways to approach this, one interviewer would like to check,
If I get the overall picture of the whole framework, another could just focus on the Ruby syntax,

and so forth, I would have put the emphasis on the personal experience.

I guess I revise the question to -

what you would look for in a rails developer ?,

what questions you would have asked, if you were conducting the interview ?

(i’ll go first)

what was the most interesting code you wrote with rails ?

with this question I would like to see that a potential candidate has some non-trivial experience,

that he has it’s own creative approach.

thanks again for your time,

Yonatan Gross.

Yonatan Gross wrote:

mohit, I guess he is on this list... still started to think about it today,
and thought it would trigger
a nice discussion.

Here's a good interview question: "Do you know how to work 'net forums?"

The kind of boss worth working for knows that's an important skill...

Yonatan Gross wrote:

I guess I revise the question to -
what you would look for in a rails developer ?,
what questions you would have asked, if you were conducting the
interview ?

It depends on what I'm looking for, but these come to mind as
conversation starters:

Rails background:
1. What are migrations and why are the useful?
2. What is AJAX all about?
3. How does Rails apply the MVC pattern?
4. How do you know when to write unit tests, functional tests, or
integration tests?
5. What are the different ways of storing sessions with Rails?
6. In Rails, how does a given url result in a controller method being
called?
7. What is REST all about? Why is it an important design pattern?

Hopefully the answers will lead to more useful follow-up questions with
the candidate.

Ruby specific:
1. What are common methods used from the Enumerable module?
2. How do you subclass and override methods?
3. Describe a problem you solved by using missing_method appropriately.
4. What are singleton methods all about?

Again, these are not be all and all, but often provide good
conversation starters to find out how much the candidate knows.

Does this help?
Jeff
softiesonrails.com

Just remember that when you are interviewing for a job, they are going
to ask questions on how you can benefit them, so they are going to pick
apart both your best and worst qualities. Most of the interviews I've
gone on, only 25% of the interview is technical (ie. Ruby/Rails Related)
the rest of the questions are usually trying to find out how you were
able to help your last team, and what it is that you are capable of
doing for the job being interview for.

It's all about them, not you.

Matt

Got an upcoming job interview as a RoR programmer, just thought If
you have good ideas
for questions that might come up during such interview, post them here,
I will try to send back one reply with what I would have answered
hopefully this will open some debate,
and might help (me) and future programmers before a Ruby job interview.

Jan's response is a good list of what interviewers should ask in an interview.

Of course, they'll make a decision based on whatever attributes they
feel an emotional connection to. Ideally, you'll find out that during
the interview.

Me, when I'm interviewing people I'm looking for raw talent (how fast
can you learn?), attitude (are you going to act in the company's
interest?) and personality (are you going to drive us all nuts, or be
happy you're around?).

Everything else is just window dressing.

The "How fast can you learn" is important in techies but particularly
important for Rails because the technology is evolving quickly - which
is part of the reason we're using it. But that means we need techies
who can pick it up as they go along, not wait for the next training
course. (I have a personal bias that anyone who needs to be taught
isn't worth employing, and any technology with a training course
delivered by generic IT trainers is probably obselete).

The attitude issue is just a reflection of the fact that a techie
position is one that carries a lot of responsibility. Sure, we can
mentor you, but we can't micro-manage you. If you're the kind of
techie who can't see beyond their immediate horizons then there's
probably not a lot we can do to get you with the program.

The

Jeff wrote:

Rails background:

Ooh thanks I love these.

1. What are migrations and why are the useful?

Refactoring Databases is bloody hard. There's a book about them, which
I haven't read yet. If I wrote it, it would say for each new DB
version you must write a script that migrates live customer data
forward and backwards. So Rails provides that out of the box (and, as
usual, with only 75 lines of code, not the 75,000 that Brand X
requires).

2. What is AJAX all about?

Decoupling parts of your web page from each other so the server can
update them indepentantly, without forcing a page refresh and loss of
context.

3. How does Rails apply the MVC pattern?

Rails encourages MVC by enabling a 3-layer architecture, with
different available facilities in each one. True MVC is up to the
programmer, just as you can still write non-OO code in Smalltalk by
cramming everything into one long method.

4. How do you know when to write unit tests, functional tests, or
integration tests?

Uh, you write them and see.

Better, you prefer unit unless you need the extra test capabilities in
the functional library; again you only move up to integration if you
need its capabilities.

This matches the rationale for placing code. Put it in its nearest
model unless it needs a controller's abilities, etc.

And if you invent a new system of your own, it should have test suites
that match its architecture.

5. What are the different ways of storing sessions with Rails?

Cookies, the Session variable, or as IDs that go round-trip thru the
view and into the database, as hidden fields.

6. In Rails, how does a given url result in a controller method being
called?

The dispatcher calls routes.rb, which deconstructs the URI (not "URL")
and generally matches controllers and actions by name.

7. What is REST all about? Why is it an important design pattern?

That's on my "see how long I can successfully ignore" list. :wink:

Ruby specific:
1. What are common methods used from the Enumerable module?

Ruby is so easy to use that I have successfully placed that one on my
"ignore" list. Uh, something to do with overloading the spaceship <=>
operator so you can sort automatically.

2. How do you subclass and override methods?

You subclass classes and override methods. The keyword def is a
command, not a delimiter, so a class responds to messages with the
last-declared method with its name.

3. Describe a problem you solved by using missing_method appropriately.

I used Builder::XmlMarkup, and it just seems to read my mind. Its
verbosity is directly comperable to the XML or HTML that it replaces.
But it's easier to refactor!

4. What are singleton methods all about?

Sometimes when you put the barrel in your mouth you just can't reach
the trigger, huh? They are about making your code a pain in the balls
to unit-test. Resist the temptation of their syntactic sugar!

Gmail send this on a keypress outside the edit window... before I
finished... so I'll reply with the rest... (sorry)

> Got an upcoming job interview as a RoR programmer, just thought If
> you have good ideas
> for questions that might come up during such interview, post them here,
> I will try to send back one reply with what I would have answered
> hopefully this will open some debate,
> and might help (me) and future programmers before a Ruby job interview.

Jan's response is a good list of what interviewers should ask in an interview.

Of course, they'll make a decision based on whatever attributes they
feel an emotional connection to. Ideally, you'll find out that during
the interview.

Me, when I'm interviewing people I'm looking for raw talent (how fast
can you learn?), attitude (are you going to act in the company's
interest?) and personality (are you going to drive us all nuts, or be
happy you're around?).

Everything else is just window dressing.

The "How fast can you learn" is important in techies but particularly
important for Rails because the technology is evolving quickly - which
is part of the reason we're using it. But that means we need techies
who can pick it up as they go along, not wait for the next training
course. (I have a personal bias that anyone who needs to be taught
isn't worth employing, and any technology with a training course
delivered by generic IT trainers is probably obselete).

The attitude issue is just a reflection of the fact that a techie
position is one that carries a lot of responsibility. Sure, we can
mentor you, but we can't micro-manage you. If you're the kind of
techie who can't see beyond their immediate horizons then there's
probably not a lot we can do to get you with the program.

The personality issue is just a reflection of the fact that we've got
to run a business and part of that is getting on with everyone else.
So this will depend on where you're going - in our case, we don't
isolate techies from the rest of the company (in fact, we encourage
mixing) so we really do expect you to sit next to sales or support and
be good co-workers in every sense. So we're looking for a well-rounded
personality, tolerance, etc.

In addition, we look for potential - ideally you'll be with us for a
while, and realistically you'd want to upgrade your contribution....
so we'd look to where you can grow. Can you get into marketing, sales,
management etc. So anything that shows you're more than just a geek
who sits in his room coding is all good.

Hope that helps,

Simon

> 3. How does Rails apply the MVC pattern?

Rails encourages MVC by enabling a 3-layer architecture, with
different available facilities in each one. True MVC is up to the
programmer, just as you can still write non-OO code in Smalltalk by
cramming everything into one long method.

When I think of 3-layer architecture, I think of the separation
between database, application, and web server. So yeah, Rails does
enable a 3-layer architecture in that regard. As far as MVC goes,
it's a lot simpler - it cleanly separates the model, view, and
controller.

> 4. How do you know when to write unit tests, functional tests, or
> integration tests?

Uh, you write them and see.

Better, you prefer unit unless you need the extra test capabilities in
the functional library; again you only move up to integration if you
need its capabilities.

This matches the rationale for placing code. Put it in its nearest
model unless it needs a controller's abilities, etc.

I don't really agree with this. Integration tests are good for
writing acceptance tests, and you definitely need to have those. They
don't just apply "if you need its capabilities."

Functional tests (at least in Rails parlance) are for testing
controllers. Unit tests are for testing your model. Pretty simple,
and there's no reason you should try to push EVERYTHING into the
model. Just what belongs there - business logic. Coordinating logic
should definitely go in the controller, thus be tested in functional
tests.

> 5. What are the different ways of storing sessions with Rails?

Cookies, the Session variable, or as IDs that go round-trip thru the
view and into the database, as hidden fields.

I think the interviewer is probably looking for temp files, AR session
store, and SQL session store.

> 7. What is REST all about? Why is it an important design pattern?

That's on my "see how long I can successfully ignore" list. :wink:

Well that's short-sighted and will bite you in the butt :slight_smile:

> Ruby specific:
> 1. What are common methods used from the Enumerable module?

Ruby is so easy to use that I have successfully placed that one on my
"ignore" list. Uh, something to do with overloading the spaceship <=>
operator so you can sort automatically.

You've got it confused with Comparable...implementing Enumerable
requires that you implement the each method, which gives you a bunch
of other stuff for free.

> 4. What are singleton methods all about?

Sometimes when you put the barrel in your mouth you just can't reach
the trigger, huh? They are about making your code a pain in the balls
to unit-test. Resist the temptation of their syntactic sugar!

I'm going to assume this is a joke.

Pat

This is key. If you have to lie to yourself or just aren't
comfortable in order to get the job, how much are you actually going
to like the job itself?

Though to tell you the truth I bet the interview will be cake...I mean
hell you're gonna get to code Rails! Surely your enthusiasm will
shine.

Pat

Wow, that's funny I just wrote up a blog post on that very subject:
http://warneronstine.com/blog/articles/2006/12/21/passionate-programmers

We are currently hiring developers for the Kuali project at the UofA
(in Tucson, AZ) and that was one of the deciding factors between two
candidates.

-warner

Pat Maddox wrote:

When I think of 3-layer architecture, I think of the separation
between database, application, and web server. So yeah, Rails does
enable a 3-layer architecture in that regard. As far as MVC goes,
it's a lot simpler - it cleanly separates the model, view, and
controller.

MVC means elements in each layer can observe (via messages of some
type) elements in other layers.

When I change a field in a database table, its image in the view
doesn't automatically update. I have to do just a little bit more than
patch-cord fields to images.

I don't really agree with this. Integration tests are good for
writing acceptance tests, and you definitely need to have those. They
don't just apply "if you need its capabilities."

"acceptance" means matching a customer specification. "integration",
in Rails, means the test can access more than one browser context. The
kinds of tests overlap. A Rails "integration" test could be a "unit"
test if its failure implicates only one unit.

The distinction is between the syntax of the test case and the
semantics we need it for.

(BTW this is the kind of conversation I generally shouldn't have
during interviews;)

Functional tests (at least in Rails parlance) are for testing
controllers. Unit tests are for testing your model. Pretty simple,
and there's no reason you should try to push EVERYTHING into the
model. Just what belongs there - business logic. Coordinating logic
should definitely go in the controller, thus be tested in functional
tests.

If a function doesn't need a controller, then it only needs one model,
so it goes into that model. This follows from simple refactoring -
finding the leanest solution for a problem.

Models don't exist in isolation from our application, unless they do,
in which case they should only contain their shared methods, and their
application-specific methods should just get mixed-in.

> > 4. What are singleton methods all about?
>
> Sometimes when you put the barrel in your mouth you just can't reach
> the trigger, huh? They are about making your code a pain in the balls
> to unit-test. Resist the temptation of their syntactic sugar!

I'm going to assume this is a joke.

Singletons are not an excuse for a global variable.

Pat Maddox wrote:

> When I think of 3-layer architecture, I think of the separation
> between database, application, and web server. So yeah, Rails does
> enable a 3-layer architecture in that regard. As far as MVC goes,
> it's a lot simpler - it cleanly separates the model, view, and
> controller.

MVC means elements in each layer can observe (via messages of some
type) elements in other layers.

When I change a field in a database table, its image in the view
doesn't automatically update. I have to do just a little bit more than
patch-cord fields to images.

I know what MVC is. I was just saying that, to me anyway, a 3-tiered
architecture is something completely different.

> I don't really agree with this. Integration tests are good for
> writing acceptance tests, and you definitely need to have those. They
> don't just apply "if you need its capabilities."

"acceptance" means matching a customer specification. "integration",
in Rails, means the test can access more than one browser context. The
kinds of tests overlap. A Rails "integration" test could be a "unit"
test if its failure implicates only one unit.

The distinction is between the syntax of the test case and the
semantics we need it for.

I said integration tests are "good for writing acceptance tests." Not
that they are acceptance tests. They are for me, because that's how I
choose to use them. You should use acceptance tests though, and using
the Rails integration tests for that is great because it's built right
in.

> > > 4. What are singleton methods all about?
> >
> > Sometimes when you put the barrel in your mouth you just can't reach
> > the trigger, huh? They are about making your code a pain in the balls
> > to unit-test. Resist the temptation of their syntactic sugar!
>
> I'm going to assume this is a joke.

Singletons are not an excuse for a global variable.

You're confusing the singleton pattern [1] with a singleton method
[2]. DA Black's book, "Ruby for Rails," is very good for gaining a
deep understanding of Ruby.

Pat

[1] http://en.wikipedia.org/wiki/Singleton_pattern
[2] http://www.rubycentral.com/faq/rubyfaq-8.html
http://www.rubyist.net/~slagell/ruby/singletonmethods.html

I don't like the idea of preparing specific set of questions for an
interview. Just be yourself and you'll pass your interview if you
deserve to!

Yonatan Gross wrote:

I guess I revise the question to -
what you would look for in a rails developer ?,
what questions you would have asked, if you were conducting the
interview ?

It depends on what I'm looking for, but these come to mind as
conversation starters:

[...]

3. Describe a problem you solved by using missing_method appropriately.

I wouldn't close the door to Ruby programmers who have never used
method_missing. It's a pretty specialized technique -- not
specialized in the sense of advanced, but in the sense of not likely
to be of much genuine use except in writing frameworks and programming
tools and such "meta" things.

David

dblack@wobblini.net wrote:

I wouldn't close the door to Ruby programmers who have never used
method_missing. It's a pretty specialized technique -- not
specialized in the sense of advanced, but in the sense of not likely
to be of much genuine use except in writing frameworks and programming
tools and such "meta" things.

Absolutely - sorry if I implied otherwise... I just thought it might be
one way to find if they are familiar with it, or if they've at least
seen it used somewhere (like by reading some of the Rails source, or
something). I didn't mean that it should be used to weed someone in or
out.

I remember when I first "got" the idea of method_missing, and how it
got me to start thinking in terms of messages being received instead of
methods being called. (Coming from C++ and later C#, I always thought
of a method as just a pointer to some function that must already exist,
so the method_missing concept was weird for me at first).

Jeff

Pat Maddox wrote:

I know what MVC is. I was just saying that, to me anyway, a 3-tiered
architecture is something completely different.

And all Rails is, out of the box, is 3-layered. Not true MVC, and not 3-tiered.

> > > 4. What are singleton methods all about?
> >
> > Sometimes when you put the barrel in your mouth you just can't reach
> > the trigger, huh? They are about making your code a pain in the balls
> > to unit-test. Resist the temptation of their syntactic sugar!
>
> I'm going to assume this is a joke.

Singletons are not an excuse for a global variable.

You're confusing the singleton pattern [1] with a singleton method
[2]. DA Black's book, "Ruby for Rails," is very good for gaining a
deep understanding of Ruby.

I suspect /Working Effectively with Legacy Code/, by Mike Feathers, has a good discussion about singleton abuse. I should know, because I'm cited as a reviewer in it.

But I have simply never seen a situation improved by a Singleton. Not a joke, not a citation, just an observation.

I'm not doubting that you know what the singleton pattern is. I'm
just saying you clearly don't know what a singleton METHOD is. Either
that or you didn't read the question.

Here's the simplest case of a singleton method:
class Foo
  def self.foo
    "This is a singleton method on Foo"
  end
end

foo is a singleton method on the class Foo. You might also know it as
a class method. I generally find them helpful, and not in the context
of trying to shoot myself.

Here we define a singleton method on an object.
o = Object.new
def o.foo
  "foo"
end

which could also be
class << o
  def foo
end

Singleton methods are, quite simply, methods defined on the singleton
class of an object. They have nothing to do with the Singleton
pattern.

I have a feeling that since Java, C++, and C# don't even have
singleton methods, your review and Feathers' discussion probably
didn't cover them.

Perhaps it's unfortunate that the names are the same. Singleton
classes and methods in Ruby (which are completely different from the
Singleton pattern) are a very powerful and useful tool.

Pat