Ruby on Rails, XML, AJAX, Perl Good Interview Questions [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, referen开发者_如何学编程ces, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I am trying to devise a set of 15 to 25 questions to ask some of the people applying at our company.

Can you guys throw in some good questions about Ruby, XML, Ajax, or Perl?

This is for Junior position. I want just some easy questions, but at the same time they can be a little challenging. You know small answers, but requiring good knowledge.

---

Can you write "fizz buzz" in Ruby?

---

Some questions for perl:

• What arguments do you frequently use for the perl interpreter and what do they mean.
• What does the command use strict do and why should you use it?
• What do the symbols $, @ and % mean when prefixing a variable.
• What elements of the perl language could you use to structure your code to allow for maximum re-use and maximum readability.
• What is a JAPH?
• What are the characteristics of a project that is well suited to perl.
• Why do you program in perl.

http://www.perlmonks.org/?node_id=53470

---

When hiring for junior positions, we generally avoid making requirements for some specific knowledge (for example, although we are working in Ruby, we weren't expecting the candidate to know it), we are relying for other qualities, such as common IT knowledge, problem solving capabilities and "nerdiness".

So, the first part of interview is usually greatly improvised, talking about previous experience of the candidate: for example we talk about candidate's college projects, trying to find out how devoted he was and how deep he understands the technology beneath. We talk about the platform it was built on, with "real" questions thrown in; if he worked in Java, we talk about OOP, difference between interfaces and classes, trying to get opinions as well ("why did they added the concept of interface in Java") etc. Sole existence of an opinion on a subject is usually a good sign. Then, ask the candidate about some specific problem he had while doing the project, how did he handle it etc. You can learn a lot about the candidate by this kind of "techie smalltalk".

In the second part of the interview, we expect the candidate to solve some small problem from the field we are working in. We leave up to him to choose a tool (usually any mainstream scripting language, or bash or anything he's familiar with). Any simple programming task, parsing a simple CSV file and counting distinct fields in it, for example. We watch him working from time to time, offer help etc. In other words, trying to simulate real working conditions as much as possible.

So, sorry, this answer is not really a "recipe" you were asking for, but may be useful.