Sure, Ruby on Rails. I literally start with something like:
"You've just created a new Rails app and you change into that directory. What are some of the directories and files you find at that top level?"
"What do you find in Gemfile? Gemfile.lock? What's the difference between the two?" Maybe some discussion of resolving dependencies/versions.
There are numerous "right" answers to which files/directories are at the top level and I don't care which ones they get, but they'll get some and it gets the flow going. Most of them can be taken to greater depth. If I want to guide it away from views into models, at least they know the level of detail we're working at.
Rails is a problem interview, too, because there is so much which is take it or leave it. There are Rails apps with no front end, and someone may have not worked with views for years, or the backend may be Api based and they haven't worked with models in the same way. I've worked on a project where 95% of the work was in the workers, and the user facing code was just nudging things between work states. So I use this to guide the conversations and draw out examples of their experiences when possible.
"You've just created a new Rails app and you change into that directory. What are some of the directories and files you find at that top level?"
"What do you find in Gemfile? Gemfile.lock? What's the difference between the two?" Maybe some discussion of resolving dependencies/versions.
There are numerous "right" answers to which files/directories are at the top level and I don't care which ones they get, but they'll get some and it gets the flow going. Most of them can be taken to greater depth. If I want to guide it away from views into models, at least they know the level of detail we're working at.
Rails is a problem interview, too, because there is so much which is take it or leave it. There are Rails apps with no front end, and someone may have not worked with views for years, or the backend may be Api based and they haven't worked with models in the same way. I've worked on a project where 95% of the work was in the workers, and the user facing code was just nudging things between work states. So I use this to guide the conversations and draw out examples of their experiences when possible.