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... 
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...
By the way, I wouldn't be surprised if your recruiter is on this list 
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.
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.
Well that's short-sighted and will bite you in the butt 
> 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] Singleton pattern - Wikipedia [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
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks