This may be simple, but it allows to start a conversation between two strangers involved into the same craft.
Classes are a blue-print, they may hold data, likely they hold methods; classes are directly connected with an idea of objects, because object is an instance of a class. As objects are first-class citizens in Ruby, there is a main, root class Object, and all classes are inherited from this root entity. Modules, generally, are a tool for mix-ins and they provide something we call a namespace. Modules cannot be initialised the way we can do this with classes, but they provide a multiple inheritance.
This is a tricky question, which may allow you to separate Ruby newcomers (and I’m not saying this is bad) from old-school warriors (and this also may be not so good, as it sounds). Here is why.
‘why the lucky stiff’ (or ‘_why’) is the artist from a past decade, who used Ruby as his brush, and our minds as a canvas. He is both writer, cartoonist, artist, and computer programmer, famous by his contribution to many Open Source Ruby projects, “Why’s Poignant Guide to Ruby” piece of art and who disappeared in 2009. Shoes is a nice OSI project, initially made by _why, and it allows to create nice looking GUI applications using Ruby, for programmers of any age (from 3 to 100 years old). Shoes now are fine and quite active thanks to Shoes Team. You can find it on Github.
Automated testing (especially as the main tool of TDD/BDD) is an absolutely important part of modern applications development. This is your friend during refactoring, development and debugging. This is the way how you understand your codebase deeper, a way to predict bottle-necks, and sometimes it allows you to keep your code maintainable without unnecessary investments for years. In the same time, automated testing could be a source of terrible bugs and fails, as by itself, tests are the same code, as the ‘real’ code. This way, automating testing is an another tool to help your mind keep architecture and abstractions in the form of the code, speed-up things and automate sanity-tests. Which doesn’t mean you always have to pay your attention on manual testing.
You can literally spend an hour talking about lambdas and procs. Here I’ll outline only the main statements.
They are from the same plate, however there are differences. Firstly, Proc is a nameless function, an anonymous method you use very frequently. Procs are objects, Blocks are not. Blocks are ‘business cards’ of Ruby, and they are, in fact, a syntax literals of Proc; they may take and return values. The main difference between Lambdas and Procs is Lambda explicitly check for arguments, while Proc is not. Stabby lambda ( -> ) is nothing more than another Lambda literal, from Ruby >= 1.9, you may easily think of this like of syntax sugar.
5. A practical task: web scraping. The task is to extract some information from some web page (pages). For example, to gather all top comments from some news site, or product's ratings from some online shop.
There is no ‘correct’ answer here (well, excepts this should work as expected). The main idea here is to see how it will be done, and the main pre-request from you is ‘go nuts’. This way, from this, by itself, simple task, you’ll be able to see how candidate does real things with Ruby. If candidate used plain Ruby, or it was done with Rack (Sinatra, Rails, whatever) web frontend? Was one of CLI frameworks used? What about testing? What about documentation? What about fallbacks? What about variables naming? The good thing is that even with this simple task, it allows a candidate to spend form 30 minutes to 3 days, depending on your pre-requests and candidate's mood, which could be a good measurement for you.
It’s all about time zones: with Date.today you’ll have a system date, with Date.current it's system date, plus Rails’ time zone applied. Funny, but Time.zone.today should return you a date with a time zone too.
7. Skinny Controllers. Logic-less (as much as possible) templates. But where we’ll keep this zillions lines of code this way?
First answer could be, we’ll move controller’s code to models. Oookay. But we’ll have Fat Models (tm) this way, right? Then we’ll move everything to Rails’ concerns! And we’ll separate reusable code as libraries and gems. And this is true. The fact is it could be (sic!) even worse than to keep everything in models. One of the ways is, for example, to radically change architecture, introducing Rails' engines (and here you can talk about differences between gem and Rails Engine) or even partially move the code to the separated Rack application, and link your host with Rack app via internal API (here is the good place to talk about general application architecture). Or you can implement Data/Context/Interaction approach (here is the good place to talk about advanced architectural themes). After this, you’ll feel if it is reasonable to talk about Model-Views and Decorators.
Self refers to the current object. The thing is that Class is an object too, this way at class level, self is the class, but at the instance level it is the instance in context, already initialised somewhere in the memory.
Transactions are sets of changes, that must all be made together. It may, or may not change the contents of the database. When we talk about transactions, we usually mean we need to do something with database as single unit execution. A classy transaction is when you withdraw money from one bank account to another, and you need to substract from one bank account and add to another in the same time. In Rails you have ActiveRecord::Base.transaction, which allows you to easily pass multiple actions in a block, and they’ll be executed a transactional way.
This question is good both for the begining and the end of interview. Usually, a good programmer has an attitude to his workplace. This could be a minimalistic approach, like 'I use a raw vim config, no fancy plugins, because it allows me to have ‘my’ workplace on any default config', or candidate could be a tiling window manager fan, hacking his i3/Xmonad/awesome config daily, creating custom emacs themes for every single period of the day, depending of lighting, with the data received from Arduino-based sensor. In any case, you’ll both have some fun, talking about this.