eibaan

I'd try to find out whether the candidate fits the team and shares the same values. So ask what they consider important about software, about their job. What do they consider important. Make sure to point out that there are no right or wrong questions. Find something, the candidate is passioned about and ask to explain that. Someone mentioned that he used to be a blacksmith in a medieval reenactment group. That was fascinating. And you'll see passion. How compare this with the previous statements about software development. I strongly prefer people who are passioned about their craft. We also used always ask whether they prefer Startrek or Starwars. The guy who answered "frankly, none, I'm more of a doctor who fan" got hired immediately. Of course, the candidate should have a basic computer science education and must demonstrate the will to learn. But especially for a more senior position, technical competence should be a given, but social skills are at least as important.

That's not a buzz word, that computer science 101. You should know the difference between imperative and declarative programming. If you want to make sure that the candidate has some kind of formal education, this is a valid question. As is a definition of the halting problem. Another more practical question would be to define OOP explain the three traits that define an object. Or define the different between static and dynamic typing and how this is different from strong typing. It might also to be a good idea to ask whether Dart has a sound type system and then ask for examples for sound and unsound languages.

The whole idea of making the UI a function of your models is that you can decouple UI and models and once you're sure that the UI correctly reflects the model, restrict all further testing to the model layer. A similar argument can be made for networking. Therefore, testing the game (especially for edge cases and race conditions) could (and probably) should be made with "plain old" Dart objects. That should be easier to set up, way faster and you can more easily measure code coverage of your tests.

An application that is written for and/or works on a mobile device can be called mobile app, regardless of the technology used to create it. Actually, you can write crappy apps with any technology. Looks like that you're just ranting to promote your product.

Create an app to suggest app ideas for final year projects. That's a hot topic here, seemingly.