How should I pick a web application software engineer?  The (permanent) position is to rewrite the client of an existing desktop client server application.  The pages will not be generated dynamically on a server, but the server will expose a full API in whatever way is needed, for example JSON RPC calls, and can make static files available.  It will replace a client that people have to download and install, so requiring a decent browser with reasonable settings (e.g. JavaScript enabled) is fine.  Almost all use cases are for a desktop P.C.  It will not be accessible to search engines (it is an enterprise application).  We can go so far as to write the whole thing in a single page, but don't have to.  It would pretty much all be written by the web application software engineer in question.  The exact open source libraries to use is also up to the engineer, within reason.I'm specifically looking for advice on what qualifications to look for/verify in an interview, since picking a web application software engineer in general is just too broad a topic.Edit - The position would be purely in-browser JavaScript programming (and be responsible for HTML and CSS) - other developers would develop the server but this position could request facades over the API.  There is no Ruby, ASP, JSP, etc. because the web server layer is very thin and just translates calls to the business layer API and returns them as JSON (or whatever, but JSON seems easiest).  
How to pick a web application software engineer?
web development;web applications;hiring
As a web developer who mainly works on enterprise apps dealing with legacy systems, I can offer a few suggestions as to what makes me successful, and hopefully that will help.I'm not sure whether you're looking for a temporary/consultancy situation to provide you with one app, or an FTE to develop and maintain this long-term, but these should apply in either case, I think.I primarily use Ruby. This makes rapid prototyping very fast and easy, and Rails makes it simple to bootstrap a new project. Now, I don't know what your environment is like, whether you have institutional mandates re languages, platforms, tooling, but if you can hire a developer who is proficient in a modern, flexible language/framework that makes writing DSL's to deal with foreign API's relatively quick and easy, that's a plus. Basically, any of the languages with the Lisp-nature will be superior in this regard. Also, hiring someone proficient in a language with good ecosystem of open-source libraries to deal with common abstractions is a must. If you can find someone used to dealing with legacy systems and abstracting their idiosyncrasies, that's rare and you should explore it. Most devs are used to building projects from the ground up (or getting brought in to maintain existing projects) and building something new to interface with something old takes a certain... not skill set, per se, but approach.When you say the server will expose an API in whatever way is needed, that's rather vague, but I'm guessing you mean there are existing developers who can implement the API on the server? I would make it clear that the position will involve working with those developers to specify the API. If you can give an example of the type of interaction required, and ask the candidate their initial thoughts about how to implement it, that might be telling. I think the fact that your initial thought was JSON RPC shows you are leaning in the right direction, so watch out for anyone who has visions of complex XML and XSLT interactions.If you can expect decent browser JavaScript support, look for someone experienced with JS frameworks like Backbone.js, JavaScriptMVC, etc. You could in that case do the entire app (basically) in-browser and maybe serve it with Node.js or something... so look toward good JS devs. If they say they prefer to write their JS in CoffeeScript, they're probably even better JS devs.Just some thoughts from my experience in the trenches, but if my department were hiring a new developer, this is what I would tell them to look for.I wish my department had the budget for another developer...