I really don't want to rain on anyone's parade, but:
The "responsibilities" section forgoes real content for buzzwords and generic bullet points. "You mean part of this development job is writing software? And there is a front AND back end?"
The qualifications portray a really narrow scope. They're making a rails app with a NoSQL persistence layer and manage code with git. They'd like it if you already did the exact same thing (though it's not required).
I would focus on a review of fundamentals. You can try to get a handle on Ruby, then RoR, then a NoSQL DB, then bone up on JavaScript, then get a rudimentary understanding of the CSS box model, etc. Then you'll know a little bit, and an interviewer that focuses on any of these will see right through it. I would be perfectly honest about your lack of experience with the tech they use, but express an eagerness to learn (assuming you are, of course).
For algorithms and data structures, I'd try to find a few problems online and work through them. I'd write in Java, as it's nearly universally understood. When you write solutions make sure they are correct, and you know some good test cases to exercise that, including a lot of edge cases. Nulls, empty structures, invalid/incomplete input, etc. Understand the runtime and space complexity. Try to think of ways to compromise one for the other and places to optimize both. Know complexities of common operations on a variety of data structures. Know a few operations for each runtime complexity for 1, logn n, nlogn, n^2. If you aren't familiar with this stuff, try to solidify understanding of what you know before attempting to get a shallow understanding of new things. Be honest about what you don't know. Don't fake it.
If you don't know something at all, you probably won't master it in two weeks. If you want to know something about a subject that's fine, but be honest about having read some info over two weeks.
Read about the company, and know things you want to know that aren't easy to find out. Ask about their culture, especially things that are important to you. Find out if they write unit tests. Find out if they use automation testing. Find out if they do code reviews. See what their release schedule is. Find out about on-call schedules. Find out if they crunch and for how long. Be clear about your standards for this stuff (if you don't have any, get some), and that you want to know so you understand the environment, not because you're unwilling to be flexible on any of it.
2 days before the interview, stop all of this. If you've made some notes you can read them over a few times, but don't obsess. Relax. Understand that this needs to be a good fit for them and for you. Be confident in what you do know and realistic about what you don't. Get some sleep. Eat a decent meal as appropriate for the time of day. Breathe. Don't rush to answer their questions, and ask for clarification and verify any and all assumptions. If you're thinking, let them know and talk through the thought process if you're comfortable doing so.
Good luck
-Lee
