In my mind, those three titles would do the same thing, as they both are responsible for the interface experience of a product. The only difference is the company that is hiring decided to name it something different. I suppose an Interaction Designer might be more focused on the look and feel of something vs the experience. Your best bet would be to compare the job descriptions of various jobs with these titles, but if I was looking for a product design job, I would open up any UX Designer and Interaction Designer jobs as well. As for your second question, again I think it depends on the organization. For my current company, designers interact with engineering (among others) throughout the design process, showing them their progress and getting feedback. Once we are confident on a design, our front end engineers create a prototype for us to further test with customers and check for any issues in front end implementation. Once all of that is complete, another front end engineer embeds with the engineering team and helps them get it hooked up to the back end.

The fold was never relevant online. This is a legacy from print that was incorrectly applied to digital. Should you put your most important content first? Of course! But you shouldn't be worried that users will not check out the stuff below the scroll line, especially if they feel that your site has the information that they need. If anything, trying to force everything above this mythical fold makes for a WORSE user experience, as you will end up either having too much information competing against each other, or hiding it behind something like an accordion or carousel. In those cases, the information is actually less accessible than if a user has to scroll to get it. On top of this, in today's multidevice world, WHERE IS THE FOLD? On a desktop it is one place, but on a phone it is another. If a user browses with the window full screen it is here, and if not, it is there. Designing for content to be "above the fold" is impossible. So ignore the fold. Structure your content properly, but don't worry if users have to scroll a bit to get to it, because they will. Additional reading: http://uxmyths.com/post/654047943/myth-people-dont-scroll

As someone who works in house for a SaaS company, we have been migrating away from Bootstrap and to our own framework that we have built on top of Bourbon, which is sort of a framework for building your own framework. We did this for two reasons, primarily. First, we didn't want to carry the weight of the entire framework - both CSS and JS - on every page. Yes, I know you can pick and choose, but for us, it was easier to build up to what we needed rather than eliminate down. And even if we were to cherry picked, we would still be left with bloat. Take the grid, for example. We only need maybe four or five layouts, almost all of them based around breaking the page in to thirds. Why should I carry the code for all the other column layouts if I only need a couple? This leads to the second reason, which is rolling our own allowed us to customize to our needs specifically, as opposed to either living what we were given or having to hack around it. For instance, our modals look the way we wanted them to look, using the class names that make sense to us. Bootstrap in particular can be a bit overly tag heavy in my opinion. And overriding something like a modal can be a significant investment - one that has the chance to break every time you upgrade Bootstrap. So we roll our own, using the BEM naming structure and Bourbon (and its related libraries) as our helpers. Does this mean we have to do a bit more hand holding with people who are not as experienced in the front end area? Absolutely. But that is a cost we are willing to pay to ensure that the front end code adheres to the guidelines we want to follow. All that being said, Bootstrap and Foundation are great if you want to just throw something together quickly. Rolling your own takes time and a solid understanding of where the overall design is headed. For prototyping or even getting the first version of something out quickly, you really cannot beat a framework. The benefits in those situations easily outweigh the costs. But if you have the team and the right situation (long term maintenance of an app), I suggest you consider taking the time to do it yourself.

Job fit should be obvious from their portfolio, so I would focus on questions that would help shortlist designers for their culture fit. Culture fit is way more important to the long term success of both the designers and the company. To do this, though, you need to get them talking about past experiences. See how they describe previous jobs and managers. Do they take ownership of failures, or is it always due to someone else? Do they have a history of being unhappy, or is every experience a positive one? Answer is probably a bit off topic, so sorry about that. But we have four separate interviews for our designers, and only one focuses on abilities, and that is more just to ensure that what they say they did in their portfolio is actually their own work. The other three interviews are focusing on how they fit our core values. I have done this three times in the last year, and I haven't regretted my hires yet.

I would say that the answer is still "yes" in those cases. Good interface design is understanding the user and how they prefer to interact with technology to accomplish a task. That doesn't necessarily equate to a beautiful interface in every instance.

From the user side, does the app work? And are those users generally satisfied? If the answer to both of those questions is "yes," then a wholesale rewrite could bring about issues that could put those users in jeopardy in terms of satisfaction and loyalty. Couple that with the fact that rewrites ALWAYS take longer than estimated, the safest bet is to refactor in chunks, either as you jump in to that code to add a new feature, or as a stand alone "let's refactor" issue.