I'm currently working for a small company as a website/software developer. I mainly write the server side code; the interfaces I create for the website are bland and don't really interact with the user.

I tried to learn JavaScript, J-Query and Ajax but it seemed too much because I rarely had time for anything else.

My company decided to hire a few client side developers who can write the client side code. We are going to conduct a face-to-face interview in about 3 days with the interviewees.

The problem is there is no one that is good at that so they asked me to test the technical skills of the interviewees.

The only thing I am good at is the basics of JavaScript. I don't think the interviewees will have any problem answering the questions that I put in front of them as it's all basic scripting.

How can I best interview people when I do not have the necessary skills to determine whether they will be able to perform the job?


I have sometimes been pulled into interviews for positions where I'm not particularly skilled, and as a specialist I've often been interviewed by people who don't know my area very well. Here are things I've seen work:

  • Before interviewing anybody, try to learn the "101" stuff in the relevant area. For Javascript, there are assorted resources online. Note: this isn't so you'll be able to ask good questions; you probably won't. The purpose of this is so you'll be able to spot BS.

  • Ask behavioral questions that get them talking about the technical issues. "What was the hardest bug you've had to solve?" is a good one; you can ask them to explain what the problem was, what approaches they took, what they ultimately did, and so on. This may or may not tell you about the quality of their code directly, but it will tell you a lot about how they analyze, break down, and ultimately solve problems. And if they drop implementation details you can take notes and maybe do a sanity-check later.

  • Ask them to talk in some detail about a significant project -- architecture, design, UX considerations, testing, deployment, maintenance, etc. It almost doesn't matter what language the code is in for most of this; you're trying to answer the deeper question of "can this person write software we'll want to live with?".

  • Ask for a demo. Pick something interesting and ask for a walk-through of the code behind it. As the candidate is explaining what it does you should be looking for the usual code-hygeine things -- comments, clear organization, comprehensible names, and so on. If he struggles to explain it that's a source of concern. (A quick look at the code and "oh yeah, that's where I put that" is fine; I mean if he's stumped.)

  • Be sure to get technical references, not just managerial ones, and ask them about the candidate's technical strengths and weaknesses.

  • 4
    I do pretty much the same - another one I consider almost a must is to ask them to explain something I don't know - "just cover the basics of what X technology is and when it is most useful" - if they can't do this in a short span of time and a comprehensible way, this isn't a good fit. Particularly where your team doesn't have an expert already - any "expert" you hire had better be able to explain to non-expert some simple concepts so you can interact successfully. – bethlakshmi Jul 8 '13 at 19:12
  • @bethlakshmi, that's an excellent point; whoever is hired into this position is going to need to be able to explain his design/implementation decisions in ways everyone else can understand, well enough that they can ask relevant questions and get answers. – Monica Cellio Jul 8 '13 at 19:16
  • yep. Worse mistake I ever made was hiring a guy who seemed to make sense to other experts, but who made no sense to me, the non-expert. Turned out, the guy was smart, but very bad at communicating - so he made complicated things that were of no use but worked perfectly within their own flawed assumptions – bethlakshmi Jul 8 '13 at 20:14
  • Now I'm still trying to remember which was the worst bug I've encountered... those caused by the infamous PHP #29992 might win, but I'm not sure. – o0'. Apr 2 '14 at 13:14
  • Goo answer. I just wish that you were still around to appreciate my up-vote :-/ – Mawg says reinstate Monica Sep 27 '20 at 10:23

I'd recommend you incorporate fundamentals of software development in your interviewing strategy. As a discipline, regardless of language, there are several concerns that cut across software development/engineering:

  • Design Patterns: A decent project will use some kind of design pattern. A decent developer should be able to identify a specific pattern and must have implemented it at some recent point in the past. I'm no javascript ninja myself but I can hazard a guess that with frameworks like Node.js, an experienced javascript developer would have a grasp of basic software design principles

  • Performance: No matter the language/platform, there's usually an efficient way to do stuff and a wasteful way to do something. In java, there's the BufferedXXX family of classes intended for better I/O programming and any java developer with 6 months of experience will know this. Look for such fundamental performance principles in JavaScript that a seasoned developer should know. Have a look at this article for guidance

  • Frameworks: As a corollary to the first point, you could look up one or two javascript frameworks and skim thru the introduction (particularly what these frameworks can achieve). Now design one or two interview questions around those. The objective here is simple: either the interviewee has used these frameworks before and can demonstrate a level of comfort that surpasses your own OR, hasn't used the framework in question BUT the person should be able to provide alternatives to the frameworks and what they can achieve

  • Working Problem: Thoroughly research a specific problem in javascript (you can start by looking thru one of the top voted javascript questions on SO), understand the solution and present this problem to the interviewee. It could be a bare-bones,how-to-code question or a more conceptual one, regarding best practices. The bottom line is you should know the answer and why it's the answer (in the event the interviewee is wrong or provides an alternate approach)

Ultimately, what you want in a developer is flexibility and intelligence, by-products of a firm grasp of fundamentals of software development


It's probably a good idea to ask them some of the 101 stuff and see how they do with it anyway - you'd expect them to answer it pretty confidently but I'm sure a few won't.

I'd also try and think of a real scenario they may work on at your company and ask them what approach they would take to solving the problem - then either research the problem yourself or maybe ask that same question on stack or another message board and see if their answer has it's merits.

Always remember to have staff on a probationary period too whereby you can get rid of them if it isn't just a good fit. Sometimes it's not about having the absolute best coder but someone that is willing to learn more and works well in a team.

  • I think most interviewees will be nervous and think that there is a hidden catch in the 101 questions. Then they will start thinking about it too much and falter :) – Juha Untinen Mar 26 '15 at 10:02

I ask developers to code in front of me. Ideally I know the language, but I'll accept something where I don't. If I know in advance I don't know the language, I look at the relevant details/APIs in advance to know what to expect. I'll also try to ask questions about the aspects of the technology that I do know. If I don't know in advance what the language will be (an intern knows a few languages and they don't overlap mine), that's fine. I can still check for logic in watching code and look at it in more detail later if I want.

For JavaScript, you could have the candidate code on a computer in front of you. You'll see what libraries the person uses, how he/she thinks, does research, asks about requirements, etc.

As you said, you care that the candidate can do the job. So why not give them something similar to the job. Not the actual job because that would be like getting free labor. But a made up example that uses similar skills.


Some may think this doesn't answer your question, but I think it offers some strategies to solve the problem of hiring a qualified client-side developer. Is there a law that says you have to do this yourself?

  1. Work on the details for this job. Writing client-side code and UX are not the same. You may want some of both, but decide the ratio. This is the first step in getting the right person for the job. There are many devs that learn javascript, CSS & html, but couldn't design a command prompt.
  2. Get examples of their work.
  3. Hire a contractor on a part-time basis. If you make a hiring mistake, you can correct it easily by getting rid of the person for a lot less than a full-timer.
  4. As an option to #3, use a hiring agency. You can create a temp-to-hire situation if you want to gain a little freedom. Many people may question some of these agency's abiliy to identify technical talent. Some of better than others.
  5. Reach out to people in your tech. community and try to get some recommendations. Why just wait and see who applies.

As part of the interview process, focus some of the questions on the problem areas you've had. Either put them on the board to mock up some diagrams and code, but ideally get them infront of a keyboad and see what they've got. Can they write code? See what tools they use. Do they bring up browser compatibility issues? Have they seen similar problems. I was dabbling with a webfront end and met someone at a coffee shop who was able to dazzle me in less than 15 minutes. I would hire this person on the spot.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .