I'm not the most experienced guy when it comes to interviews, but this is my opinion on the subject.
I like to separate personal interviews and assignments.
For me personal interviews are mainly about two things:
Discovering problem solving capabilities
The first one is quite obvious. Is the person a good fit to the team?
The unit tests on the server side usually focus on the models. In Ruby these are the rspec or test unit tests and are written in Ruby.
The unit tests on the client side are frequently written in Jasmine. Sometimes Konacha. They will often stub out the ...
Unit tests have nothing in common with MVC. You run your unit test independently of Rails.
Unit test execute your code for models etc, but you don't call them from web framework which is there to serve web pages.
It seems to me that you need to improve your general programming skills too. Persevere, and it all the puzzle will fit, eventually.
I recommend you hire some dedicated people to write automation and focus on it providing quick feedback to developers (as opposed to separate verification test automation later in the process).
You will need teachers, guides, coaches and mananagement buy-in for new practices at the director level at least and probably C-Suite.
The main tool to use is your ...
You have a described a situation where there is a lot of technical debt from having no tests.
My approach would be:
Change things for all code (new or updated) going forward to have tests.
This doesn't just mean 'require tests', it will mean investing in lots of education, training and introduction of a changed development philosophy and ...
Think about the three steps for every test
Ideally this is done for every test and the database strategy used between tests is truncation.
Frequently this is deemed not possible and seed data is used which would slow down the tests too much if deleted each time.
In those cases each test should use the database strategy of rolling ...