Successful technical interviews with a single question

The hiring process

A big part of my previous job was to conduct technical interviews. That process was straightforward:

1. An interview conducted by HR determined if the candidate is a serial killer
2. An interview conducted by technical experts determined if the technical skills
3. An interview conducted by big boss determined how low the candidate was willing to get paid.

I interviewed two types of people: interns and FTEs. Interns only went through #2 while the others went through all three steps. In the span of 2+ years working at that company, I have performed more than 200 technical interviews. It was a learning and enriching process for me. The company was located in France, where it is near-impossible to fire people. Hiring the wrong person means paying a high price and being stuck for years. I have to say that while it was a tedious process, I loved every part of it.

Iteration One: the lottery quiz

I conducted my first tech interview in 2008. The company already had a working process that I had to follow. Interviews were one hour: 30 minutes to answer a 15-questions quiz, then 15 minutes to discuss their answers and the remaining 15 minutes to discuss the job responsibilities. That questionnaire was simply not great. It’s actually quite a challenge to come up with something worse. It contained five easy generic questions and then ten hard items that were specific to the frameworks we were using at the time.

It went from

- What is the difference between a class and an object?

to

- What is the purpose of the execAndwait interceptor in 
  the Struts 2 framework?

Those were all random and I don’t think anyone in the company actually knew all the answers. A lot of them were specific to old versions of Java frameworks we were using. I definitely couldn’t explain or expand on most of those, and I was praying to not get asked to clarify the questions themselves! We needed something better. I went online and compiled hundreds of proper interview questions. At that time I believed in the quiz format, it just had to contain the right questions in order to reveal how good people were. The right quiz for the right people.

Iteration Two: Go Generic

I came up with the best 50 questions I could find online. I felt they were good questions because they could be answered in any language, and they were provided in a smooth crescendo of difficulty. I scattered the 50 and ended up with 5 sets of 10 questions that I would hand out randomly.

Sample question:

What is a singleton and when would you use it / not use it?

This was better, or so I thought… I would also usually get decent signal, and this went on for a few weeks, but it didn’t lead to stronger hires. While the questions tested familiarity with programming theories, they left me somewhat clueless with regards to the candidate’s ability to write code. I realized that those questions had two major flaws:

1. The questions were too generic. By not going into language specifics, I couldn’t talk about SQL, front-end specifics, etc.
2. The quiz was too short, way too short.

I needed a lot more questions, with things that were more specific to the responsibilities at stake…

Iteration Three: Quiz manager 3000

Okay, this is where things got a little out of hand… I went ahead and created an entire quiz application, crafted to embrace the company’s hiring process. I injected hundreds of questions. After the first interview, HR would select 3 topics related to the job description. The tool would then automatically create a multiple choice question quiz with 3 x 20 = 60 random but specific questions with a difficulty matching the person’s years of experience.

Sample question:

(javascript)
var i = 0;
function a(){
  var i = 2; 
  i++;
} 
a(); 
alert(i);    =>    0 ? 2 ? 3 ?

One could see the candidate’s score updated live on the intranet app as the answers were selected. After completion, the tool would generate a report and email it to HR, with elements such as percentile, hiring risk assessment, etc. I was quite proud of myself. I had crafted the ultimate tool. It seemed perfect… until we tested it on our own developers…

Turns out that most of our engineers were getting the same score as people we had refused. I had spent so much time building the tool that I completely overlooked a huge flaw: my desire to fully automate the process had constrained me to only ask multiple-choice questions. As a result, the questions ended up being mostly trick questions… I wasn’t really testing software development skills! I had to swallow my pride, and admitted that the tool was counter-productive. It provided the wrong signals…

Iteration Four: let them code

I started researching how successful US software companies did their screening process. This led me to try out another method: just have them code. No more automation, we were simply going to write code. I would give out three algorithms. Candidates could pick the language of their choice and had access to a machine that was offline throughout the interview. The questions included classic problems found online, such as dealing with string operations (reverse words in a sentence), recurrence (calculate a term in fibonacci’s suite), and collections (order this list).

This was a pretty big step up. It became easy to see who was comfortable writing clean and correct code. It provided good signal on coding proficiency and provided means for good discussions and deep dives. I was initially happy with the results and we kept on going for a couple of months.

However I couldn’t shake off the feeling that I was still missing something. While it had become easier to spot those could solve algorithms, it didn’t always result in hires being great software engineers. Is the quality of an engineer only defined by how well they can solve a math problem, or how fast they can sort a list? There are so many more dimensions to being a great engineer…

Last iteration: a single question

I easily remember when I first started programming. QBasic was shipped with MSDOS 5.0 way before windows 3.1 came out. It contained its own self contained help screen with all of the functions and keywords of the language. To this day, I distinctively remember the feeling that grasped me every time I hit F5 and saw my programs execute before my eyes. A single printed line, a prompt for a name, some colors, a puzzle… I was in heaven. I remember putting line numbers before each command, filling my code with horrible GOTOs, learning with excitement and fascination something new everyday. I loved programming. I would spend hour after hour creating games, solving problems, showing stuff to my parents and friends. Years went by, I went from QBasic to Turbo Pascal to VisualBasic, wrote custom games for our BBS “Atomic BBS” that we ran from our home phone line through a 2400bps modem. I wasn’t a great programmer, in fact my code was pretty terrible… But oh man did I love it!! I just couldn’t let it go…

I’m assuming that some people feel that type of adrenaline rush the first time they sail a boat, go bungee-jumping or fly a plane… For me it was programming, compiling, executing. I gained that feeling 25 years ago, and it has never left me since. I was born for this. I’ve always been a programmer. I’ve always been convinced that those who are passionate about code can overcome any hurdle in software engineering. And so it was, that after a full year of trial and error, I completely stopped handing out technical tests. I simply sat down with the candidate and asked them:

“Will you please tell me about the best project that you’ve ever created?”

That simple, unique and non-judmental question was really powerful. While some provided vague answers to some obscure projects they had a hand in, others became suddenly alive and excited. They would talk passionately about the game they were creating, the website they had made, the open source projects they had contributed to, the utilities they made after being stuck in the middle of nowhere without any internet access. They were always proud to show me their work. I would ask them for technical details, complex technical challenges they had overcome, placing myself in their world rather than the opposite. As they talked at length, it was impossible to miss: I could see that light in their eyes, the same excitement that a child gets from compiling and running their first hello world. I would know right then that we had something in common. They were programmers too. Most of them didn’t know details about Struts, Apache Richfaces or other specific frameworks we were using. Yet, once they got the job, they always ended up being fantastic developpers. They learned faster, they produced better code, they inspired others with their creativity and positivism. They were coders at heart. In the end, that’s all that really matters.

55 Comments

Brian says (July 26, 2014 at 7:48 pm):

Great article – I completely agree with your thoughts and will use this question in the future – if I am ever on the other side of the table.

Utkarsh Singh says (June 25, 2018 at 2:17 pm):

But its always good to assess their basic skills first, right?
Try searching Interview Mocha for assessing candidates according to the job profile.

Pratap Singh says (June 26, 2018 at 8:38 am):

Just like Brian, even I am going to use your insights from now on but I also use Interview Mocha to assess basic candidates skills, so that I interview only the best candidates.
Hope this helps others.

Ryan Fernandez says (October 30, 2019 at 4:31 pm):

I like interview mocha! It has a wide range of test subjects. On the other hand, I also use Kandio (https://kand.io) since it’s free and the assessment questions are quite challenging and filters out most of my candidates.

Phasma Felis says (July 26, 2014 at 8:40 pm):

We’re discussing this on Hacker News, and the big question seems to be: Are you only interested in personal/non-work projects, as your examples seem to imply? Or are you willing to accept any exceptional work that the applicant is proud of and excited about?
There’s lots of really excellent programmers who don’t have a lot of time for exciting personal projects, but still get really excellent work done on the job. When I read your question, the first thing that popped to mind was a data-processing script I wrote in three twelve-hour days that saved many hundreds of person-hours in manual work. The data set came to us with a lot of errors that needed to be corrected from context; two of my coworkers, better general programmers than me, had said it was impossible without human judgment; but my particular perspective let me see the cracks in the problem and get in done in one long push. I’m proud of that, and excited about it, and I could happily talk your ear off about how I did it; but I did it for money, and after it was done I went home and played video games.
How would you evaluate that response?

Nicolas Bize says (July 26, 2014 at 9:03 pm):

I’m in my car right now. I didn’t expect this thread to escalate, so I’ll answer in depth later. The question included all type of projects. It led to a lot more questions about specific details on the project architecture and design. It wasn’t perfect but if one could speak with passion about his experience as a programmer it was always an excellent sign.

Nicolas Bize says (July 26, 2014 at 9:47 pm):

Also the main advantage is that I was setting myself in the candidate’s ground. No surprises, nothing he wouldn’t be able to answer because it was his project, and by taking 30 minutes to go in depth into it, I could grasp a good sense of the person’s knowledge as well as his excitement for code.

Christian Walde says (July 26, 2014 at 9:18 pm):

I’d strongly recommend not asking “best”, but “proud of”. This is important because quite a few people have projects that are extremely important to them, do amazing things, use amazing techniques, but have shitty code you wouldn’t inflict on anyone else.

Jose says (July 26, 2014 at 9:28 pm):

Nicolas, this article is priceless and should be shared without moderation.
I have been thinking about it for a long time also and recently read an article on Quora about having people talk about what they do but you nailed it.

rawat says (July 26, 2014 at 10:16 pm):

you wrote and expressed, what I have felt all alonf Brilliant.

Pierre Clouthier says (July 26, 2014 at 11:27 pm):

You are absolutely correct. I have been programming since 1965. I was hooked at 16, and never lost the thrill. This month I’m learning Python.
Did Picasso retire? Did Casals cease playing? You never stop programming.
The best employees I ever hired all had taught themselves programming in high school.

Kevin says (July 26, 2014 at 11:39 pm):

I just left school two years ago in hope to find a company that appreciate exactly the things you describe. However I ended up somewhere where it is more important to talk about things and buy every IT-stuff you need. I guess I would feel much more comfortable in your company. Thank you for this inspiring post!
PS: Recently I sat in a training and wanted to tell the other (mostly non IT) guys why I love what I do. I tried to describe my feelings when I make my git push to the release version, but they were not able to understand. “i guess some people feel that type of adrenaline the first time they fly a plane, sail a boat, smoke weed, eat at in n out…” is a nice metaphor for this.

Chris Imhoff says (July 26, 2014 at 11:57 pm):

I totally agree with you. I performed technical interviews for 3 years for a consulting company I was working for at the time. The interviews were done after hours on own time. I really can’t add anything to what you’ve already said. I can only say that are exactly right. That question alone will help you find the real enthusiastic programmers you want.

Bill Torpey says (July 27, 2014 at 2:07 am):

Nice article – thanks!
FWIW, my approach is similar to yours, with just a few questions, but the intent is the same I think: to see if someone has a “fire in the belly”.
Anyone who cares about their work is golden.

Pichler says (July 27, 2014 at 3:16 am):

That’s a really good article! You just discovered the most important question. I want to never forget it.
This applies for any profession.

peterquest says (July 27, 2014 at 3:17 am):

This is so true. The thing I consistently end up saying when talking about anyone I work work: “Attitude is everything.”

Philip says (July 27, 2014 at 3:22 am):

Damn, looking back, that’s what got me hired

Scott Smith says (July 27, 2014 at 4:16 am):

+1
That is my favorite question too.
In addition to bringing out their enthusiasm, you find out quickly if they are motivated to do useful things. If the thing they are make proud of brought value is key.

auraham says (July 27, 2014 at 5:36 am):

great post and good night lecture but I don’t understand why did you say this:
“now it is important for you to note that this occured in france, where you simply cannot fire people.”
TML says (July 27, 2014 at 5:43 am):
I personally prefer the Monopoly interview – from both sides of the table. Reg Braithwaite put it much better than I could, I encourage you to check out his article on it: http://raganwald.com/2006/06/my-favourite-interview-question.html

Nicolas Bize says (July 27, 2014 at 5:43 am):

@auraham: over there you don’t have the flexibility to fire someone who isn’t doing his job. More than anywhere in the world, the screening process in france has to minimize the risk of hiring the wrong people.

Nicolas Bize says (July 27, 2014 at 5:49 am):

@TML: I had read about it! That’s a great question IMO. The only downside I would see is that some good programmers might be blocked (brain fart) by the whole interview context even though they would be able to create great answers given a more relaxed context.

Calladus says (July 27, 2014 at 6:01 am):

As an electronic engineer I’ve been part of the hiring process of quite a few technicians. What astonished me is that some of the technicians I interviewed had BSEE degrees, and had never worked in their field since graduating. In a couple of cases for 5-7 years!
My go-to question was, “How have you used your knowledge of electronics for a fun project?”
Blank stares. One person told me that he plays video games for fun. Two of the engineering graduates had never used their education after graduation, with their Senior project being the last thing they ever worked on. One of them worked in my company as a forklift driver, and told me he was never given the chance to move to Engineering (but we have in-company job openings all the time! This was the first time Engineering ever saw a resume from this guy – I checked!)
One guy built a transistor radio several years back.
My best hire was a woman who had built and programmed a robot based upon the Basic Stamp. She made the bump sensors out of push buttons and wire, she used a light sensor as an edge detector, and she modified off-the-shelf servos for the wheels. She did use a couple of off the shelf parts for robots, but that stuff was expensive, so she tried to find cheap alternatives.
That little robot worked great. And she worked very well for us for several years before she moved out of state.
I have had one objection to my preference that technicians (and engineers!) build something for fun – even on their own time. The objection is that specialized engineering tools, (like oscilloscopes) are expensive – so they don’t have the ability to try this sort of thing.
Which is a bunch of BS.

Paddy says (July 27, 2014 at 6:29 am):

It is only half of the perfect interview questions.
The other half is for the interviewed, after taking half the time to answer your question, should then sit back and state: “Will you take the rest of the time to show me what you would do for me”.
Unfortunately the young can be naive; the young who recognise that they can be paid for doing their hobby: doubly so. (But maybe less-so in the future after reading this answer).

Fredrik Haikarainen says (July 27, 2014 at 10:29 am):

Beautiful article, this really hit home! I’d let you technically interview me any day.

Lobo says (July 27, 2014 at 10:47 am):

I recognize a lot of the process you’ve been through! I’d like to quickly share my approach with you, as I believe it to be a mixture of some of your approaches and worked so well that it quickly became the standard where I as working. First I would ask some technical questions any engineer should know, like what is the ASCII table? This was only meant to weed out the candidates that really weren’t worthy and would only take 15 minutes. Next we would take half an hour ‘peer programming’ with some code the candidate brought along. In advance we sent an e-mail to the candidate asking to bring code that makes him or her proud. Then I would suggest a setting in which we pretended to be collegues and would peer program to improve or extend upon the code. With some candidates this would trigger passionate debates that lasted well beyond the half hour I’d set and with some we would just get into a defensive argument. During this process the level of knowledge, passion and coorporation of the candidate always became crystal clear. I’ve never mishired since using this process.

Aaron Junod says (July 27, 2014 at 2:23 pm):

Having done a TON of interviews as well, the 2 most valuable discussions in all of them are..
“Tell me about your favorite project”.
“Tell me about your least favorite project”.
I ask that early, sometimes they become the whole interview, and that’s ok. If they are too fast with these, I’m likely not interested in continuing anyway.

Inderjeet says (July 27, 2014 at 3:29 pm):

While asking what is your favorite project is good, what if he don’t have one? Some people are good programmers despite the fact that, they don’t work out of office on programming projects. So, for sure, it is not a silver bullet to screen for good programmers. But what if these passionate programmers cannot show the same level passion in their official work.
How many people crib about their professional work which don’t give a challenging work. So, looking for passionate programmers, for sure have negative effects as well. So, in my opinion ( I have about 10 years experience in interviewing) I agree no questionnaire is perfect – as you mentioned they have serious problems. But, we could ask him how he would solve a particular problem. We might ask him what was his challenging time being a programmer. Also, throw some design questions and see how he responds with out worrying about the answer. You may be able to find some traits of a good programmer from their responses. But the biggest drawback is we can’t test is his learn-ability. Most of the job gets done if he could learn new things on the job. This is something often neglected as well as most difficult thing to test. I think a guy with good attitude with a programmers mind and willing to learn new things has a good probability being a good hire.

Elan Engel says (July 27, 2014 at 3:53 pm):

A resume can give us a general idea of technical exposure if not some level of capability, but there is no quiz to measure passion. I made a hiring mistake early on by weighting a resume too heavily in my process. The candidate we hired was, on paper, excellent, but in reality we struggled with communication and productivity issues and I never was able to find a way to make the relationship work. The next hire, I almost did not look at the resume at all after it had been vetted for minimum qualifications. We were successful on take two and the contrast between the processes has left an enduring impact in how I will evaluate new hires in the future. Our second attempt was similar to your approach and worked out very well.

Joe Bro says (July 27, 2014 at 4:13 pm):

I hope that your shift key gets well soon.

Levon Shabagyan says (July 27, 2014 at 4:31 pm):

What a beauty! Wow.
Simplicity and genius on so many levels.
Can’t stop rewinding my 20 years in java development and realizing how different it would feel to create or work in teams created by this genius principle.
IT IS the spark in the eyes that we had to look for!
If I only hired those with the sparks in their eyes and never hired the brainy guys with no passion, the ones that end up as HR stats at big trendy billion dollar tech corps…
Imagine a team of 5 or 10 devs fully built by this principle? This is how success is born.
This is how you end up loving your work because you are surrounded by people who love it as much as you do.
So many levels…
Thank you Nicolas.
P.S.: Now that “Bize theorem” is out in the open beware of fake sparks. Spark is a vector 🙂 Need to recognize the direction and length, filter out meaningless from real.

Uri Schonfeld says (July 27, 2014 at 7:09 pm):

Thanks for the article, I agree that it is one of the more important questions. I ask that question too when interviewing.
When I was a graduate student, I guided students through their final projects. I always used this to motivate them telling them that in interviews people will ask them about a project they are proud of or enjoyed and they better have something good to say.

Redge says (July 28, 2014 at 12:51 am):

An excellent article. I recall my first interview and the question asked was, “Tell me about your tech report”. I hire ACE’s – Attitude, Character, and Enthusiasm.
What you know is taught, what you understand is learned. A personal “best” can bring out the passion in anyone – well … almost.

Javin says (July 28, 2014 at 6:32 am):

This is probably the oldest method to check any skill, if one is passionate enough on what he does, then almost all the time they would do better than those who does that just as work, but same time Its not easy to master any programming language in say 2 month or 3 month or even 6 month. It takes years of experience to build that expertise which is required by real world applications, and of-course you cannot afford someone trial and error coding your mission critical application. So, I like to go for an hybrid approach of all the things you mentioned. Remember, their is no silver bullet 🙂

Chris says (July 28, 2014 at 12:39 pm):

Can you put up your 50 awesome generic questions?

Nicolas Bize says (July 28, 2014 at 5:33 pm):

Hey Chris!
I’ll try and see if I can find them in my archives.
Thanks for reading!

Ken Bolton says (July 30, 2014 at 1:36 am):

I really like this. I like a similarly open-ended question: Can you teach me something?

Steve says (August 3, 2014 at 7:12 pm):

Great article. I’ve been working in IT for about 20 years, and I started using this approach a while ago.
It doesn’t automatically get you the ‘star programmer’ (I think there’s all sorts of stuff that needs to line up for stars to shine), but it really does separate those that have “the spark” from those that don’t.
Where I work, we still use a technical test to try and identify the skills that we need, because having enthusiasm without any experience is nearly as bad as having experience with no enthusiasm…

scott says (August 26, 2014 at 5:47 pm):

Tried this, didn’t work very well. Once that half hour was up and I got them to explain some code to me I had printed out and they would stumble. Think I will start with the code next time…

Nicolas Bize says (August 26, 2014 at 6:01 pm):

Hey Scott! What did you feel about the person once the half hour was up? Were you surprised to see them stumble with some code because after the first 30 minutes part you thought they were really good? Talking deep about a project should usually get you a very good idea of how someone handles code.

Nicholas Barns says (December 1, 2014 at 2:54 pm):

Hey Nicolas, first I want to say I’m really glad you mentioned your starting point (QBasic) because we have that in common. Ohhh those were the days…
You know even today I remember that feeling when I wrote my first QBasic commands, it printed olympic rings and I felt so accomplished 😀
Also in that first try I also learned the meaning of “bug”, I used incorrect color order 😀
Anyway back to an article, some time ago we also used the approach that you mentioned in “Just let ’em code” section, but I found that a problem with this approach is that you are presenting a commonly known coding questions and candidates who invested even a few hours in interview preparation would find this or a similar questions on the web and would prepare them self for it.
So the problem is that although it seems that a candidate demonstrated a good problem solving skills, or algorithmic thinking, or coding conventions… actually he just demonstrated his memorisation capabilities without us even realizing it, until it was too late.
That is why we currently use various small and straightforward coding tests for a elimination process (for example something like the programming tests from TestDome), followed by an interview and last the pair programming is conducted.
Now regarding the single question approach, I do like the idea and it does sound logical. I mean when a person is passionate about his work then he is not confined with just a work experience but with a personal experience as well. Also I need to point out that when I encounter a candidate that has contributed to an open source project I immediately put him as one of the favourites.
But I can’t help myself to feel that something is missing here, to me this is not enough for the evaluation process…
Also few of my acquaintances come to my mind that would just fail at something like this, even though they are a great developers they are just not passionate about it. They treat it as a work, nothing more and nothing less. Yes it is true that they do not inspire anyone, but then again they do not have to.
I would really like to believe that every passionate programmer is great at it, but I’m afraid that is not true. I have a friend who just had a bad luck at his early job positions. He ended up learning a very poor coding conventions and terrible practices and this kind of knowledge at the early stage sticks with you for a very long time… Even though he loves programming the problem is that because he had a series of bad mentors they left a nasty scar in his knowledge. This also resulted in decreasing of his learning capabilities for new technologies, because his learning curve consisted of correcting the previous understanding and adding an enchantments to it…

Nicolas Bize says (December 1, 2014 at 7:32 pm):

Hey Nicholas,
Thanks for your feedback! I did find the similar issue with the coding interview. Also, I’m sure some great developers don’t think we take them seriously when presented with problems like FizzBuzz.
Regarding passion, it’s definetely not a 100% success method, otherwise noone would try to perform interviews otherwise. But I found it to be more successful than the other methods I had tried, even though I’m sure I missed on some great developers out there using it.

Ed Baker says (December 1, 2014 at 4:50 pm):

Your article makes me want to tell you all about my favorite project! Does it matter that I wrote it in 1975 on a time-sharing computer?
My experience has shown that good programmers can learn whatever they need to perform well in a job. The point of the interview is to find a good programmer. I don’t care if he doesn’t know the language and tools that we use.

Nicolas Bize says (December 1, 2014 at 7:46 pm):

Haha tell me all about it, I love vintage computer stories 🙂

Steve G says (December 1, 2014 at 6:40 pm):

Many years ago, I was in a similar position at a small company, interviewing and hiring programmers for my team. What’s interesting is that I basically used the same format and asked the same question. An interview with me was spent going over their resume and then asking them to tell me about their projects, what their role and what their contribution had been.
It was interesting to see people with “good” resumes flounder when asked what they’d actually done, and to watch others come to life – even over what might be considered “small” or “side” projects.
So – Here’s a hearty +1 and confirmation from someone who came to the same conclusions you did.

RandyM says (December 1, 2014 at 9:22 pm):

Thanks for sharing great insights, Nicolas.
I also like balancing it out with “tell me about a project you worked on but least enjoyed” to bring to surface some other traits the candidate may have.

roger says (April 6, 2015 at 8:52 pm):

My question is…if they’re passionate about their [hobby or job] project, does that equate to “you’ll be a good worker for me”? Like high productivity? Get along well with the team? 🙂

harshit rastogi says (April 10, 2015 at 7:26 am):

Singleton is my favorite question too. Great write up !!

joe says (September 5, 2015 at 5:11 pm):

pls note that this site isn’t mobile friendly. specificly the quoted questions get cut on the left and on the right

Don Reba says (October 10, 2015 at 8:02 am):

Ahm, why screen out psychopaths? Lots of them are successful people.

T Tak says (February 1, 2016 at 4:00 pm):

Asking someone about the past projects has always been a question for me. I have been asked that question quite some times. And I have also asked it to others. And making a person comfortable for the first 5 minutes is the key to successful interview.

Swathi says (July 20, 2016 at 2:26 pm):

I can sense the passion you have as a coder! Very nice article indeed…

Jack Gleeson says (November 28, 2016 at 2:36 pm):

Excellent article.
We’re going through all the same pains you describe that come with the multiple choice & show us your code interview process.
I’ve always thought we could do it better but wasn’t sure how. I think your golden question is what we’re missing

Jorge says (April 26, 2017 at 12:09 am):

That’s really nice that you create QM (quiz manager) by yourself. However you currently can find many services which create this kind of test professionally, like https://tests4geeks.com or codility.
Foobar task is also awesome, especially when candidate already found a solution and you ask him to optimize it as much as possible.
You could also ask about implementing some simple task, like you have a school. You need to implement the list of students, the list of subjects and the array of marks. So you can edit everything.

Online Interviews says (June 19, 2017 at 4:51 am):

Interview, for the candidates its the first step to enter into there professional life its should be in perfect way, for the interviewer its also tough job to identified correct person for the job, thank you for sharing experiences.

Comments are now closed

Categories: programming, recrutement