30

This is a somewhat subjective quesiton but I'd love to hear feedback/opinions from either interviewers/interviewees on the topic.

We split our technical interview into 4 parts. Write Code, Read & Analyse Code, Design Session & Code on the white board.

For the last part what we ask interviewees to do is write a small code snippet (4-5 lines) on the whiteboard and explain as they go through it. Let me be clear the purpose is not to catch people out. We're not looking for perfect syntax. Hell it can even be pseudo-code. but the point is to give them a very simple problem and see if their brain can communicate the solution to us. By simple problems I mean "Reverse a string", "FizzBuzz" etc...

Note that we always ask for an explicit language first. We're a .NET C# house. we've only said "pseudo-code" where someone has been blanking/really struggling with the code.

My question is "Is it inappropriate / unreasonable to expect a programmer to write a code snippet on a whiteboard during an interview ?"

Eoin Campbell
  • 2,118
  • 1
  • 17
  • 17
  • 13
    Quite reasonable IMHO (and would have prevented some pretty bad hires at my former employer, if only it were implemented). – Piskvor left the building Nov 11 '11 at 09:26
  • 3
    It is a really depressing thing to do from the interviewer perspective. How can people who claim 5 years programming experience not have these basic skills? and 90% do not. (thats 90% after weeding out 70% of CV's immediately, and a 70% failure rate at telephone interview) – Michael Shaw Nov 11 '11 at 09:49
  • 18
    `We're not looking for perfect syntax.` makes it reasonable, in fact I'd say recommended! It is *unreasonable* to criticise syntax errors on whiteboard coding. – Qwerky Nov 11 '11 at 10:11
  • 16
    also don't expect perfect handwriting. Whiteboard writing is a skill most people don't have, and most programmers in my experience have atrocious handwriting to put it mildly, writing vertically only makes that worse. – jwenting Nov 11 '11 at 10:58
  • @Jwenting - I have horrible writing on paper but actually am not to bad on the whiteboard. But I have had alot of practice and I write for other people on a white board most of my on paper writing is just notes for me. – SoylentGray Nov 11 '11 at 14:58
  • I agree with the "don't expect perfect syntax" sentiment, but as an interviewee, I have to ask: Give me a specific language, and don't say pseudocode. For some problems, the thought process itself is different in, say, C and Python, and not knowing which way to go will trip me up. – Izkata Nov 11 '11 at 15:25
  • @izkata If it's pusudo code it doesn't work as an interview technique. You loose the ability to judge how familiar someone is in a particular language and any unusual coding can be waved away with it's just psudo code – Michael Shaw Nov 11 '11 at 15:40
  • @EoinCampbell On what grounds do you think that it might be inappropriate? What's the basis for this question? – Caleb Nov 11 '11 at 16:42
  • 1
    @Caleb - that it might be unfair to a developer to expect them to be able to code without an IDE and it puts them under even more pressure. – Eoin Campbell Nov 11 '11 at 17:14
  • 2
    It's entirely reasonable to put a developer under a bit of pressure at the interview. Sometimes developers need to be put under pressure at work with deadlines and so assessing how they cope with a little pressure at interview is part of the process. Knowing that a candidate does not cope with pressure will affect how you would manage and support them in the job, so assessing that at interview is completely fair. – Michael Shaw Nov 11 '11 at 17:21
  • 1
    @EoinCampbell Weeding out the folks who have to rely that heavily on an IDE is exactly why you ask candidates to write some code during an interview. You wouldn't hire a loan officer who couldn't write do a compound interest calculation on paper, right? Look for other ways to reduce pressure: smile, avoid 'gotcha' questions, offer a bottle of water, make the interview a conversation instead of an interrogation. – Caleb Nov 11 '11 at 17:26
  • @Ptolemy Yes... I think you @ ed the wrong person, I said "don't say pseudocode", it was the OP that said "it can even be pseudo-code". – Izkata Nov 11 '11 at 19:08
  • @Caleb - Why not I really prefer my bankers not try to do the math manually. Though I agree with the rest. – SoylentGray Nov 11 '11 at 19:32
  • 3
    Appropriate, yes. Effective, no. The one weak developer I've personally hired did brilliantly at a whiteboard. – pdr Nov 11 '11 at 21:18
  • Writing full algorithms on a whiteboard can be clumsy if you don't use pseudocode. But for writing most database queries, whiteboards have worked very well. – Chris C Nov 11 '11 at 22:14
  • I can't code on whiteboards. Well, I _can_, but I'd be the only one able to read the code. I can also write legibly, but I'm quite slow at it and it takes effort which distracts me from the actual coding task. What's wrong with putting them in front of an IDE to write those short snippets? Then you could see their actual workflow, and you can also test how they deal with unknown IDEs or languages (by using obscure ones). – configurator Nov 12 '11 at 21:20
  • 1
    On reading the comments on here it seems clear that quite a few people seem to think this interview technique is about the code. It is NOT about the code. It is about the person. How do they think? What are their internal processes like? How much support they will need in the role? The code the candidate writes is just the starting point in the process. It is possible to write perfect code and to fail the interview, likewise you can make mistakes and pass with flying colours. – Michael Shaw Nov 13 '11 at 22:07
  • Not just reasonable, but mandatory. – nohat Nov 17 '11 at 21:23
  • "simple" and "reverse a string" in one sentence? IMO that's quite a difficult task, and I'd need extensive documentation checking(and probably googling) to do that. So many subtle corner cases... – CodesInChaos Mar 22 '13 at 10:05
  • possible duplicate of [Engineering interview candidate refuses to use whiteboard](http://programmers.stackexchange.com/questions/188381/engineering-interview-candidate-refuses-to-use-whiteboard) – gnat May 03 '13 at 23:39
  • @pdr That is fascinating and surprising. In what ways were they a weak developer? (Dangit, that syntax just made me question my commitment to "singular they"...) – Kyle Strand Dec 04 '14 at 18:38
  • 1
    @EoinCampbell, Do you make it clear up-front that it's the demonstration of the developer's thought-process that counts, not whether or not the code would actually compile without error on the first try? Particularly in a language like C# that has a vast standard library, it's probably not reasonable to expect a developer to have memorized the exact name of every function or class they might need for the problem, so it should be made clear to the interviewee that you're not expecting that. – Kyle Strand Dec 04 '14 at 18:43
  • @KyleStrand: It was weird. He totally managed to model the problem I gave him in the interview, but he couldn't apply the same thinking to the business. But, also, he had a more general problem with laziness, so perhaps it was more that he wouldn't than couldn't. And perhaps that's the lesson to be learned, with 5 years of hindsight: technical tests are all well and good, but can't identify a fundamental character flaw. – pdr Dec 05 '14 at 12:12
  • @Ptolemy I was gobsmacked recently, my current employers introduced a coding test for the first time and we thought our question would be a trivial task for anyone with a year's SQL experience - a one-liner if done right. We even let the candidates use Google and StackOverflow unmonitored if they wanted. But, half couldn't do a simple GROUP BY and one didn't even know where to start looking. I blame all the recruiters who big-up their candidates to ridiculous degrees for giving both sides false expectations... – Julia Hayward Jan 13 '15 at 09:43

13 Answers13

46

In my view, It is very appropriate. If you are wanting a job to do a particular skill, then it is entirely appropriate to be expected to demonstrate that skill at interview.

The effect of this technique on the recruitment process is very noticeable. 90% of candidates fail this task. but the developers recruited are good, and the developers will be respected inside the company.

If as a candidate facing this technique, first of all relax. Its about assessing you as a programmer and your thought processes. It is not about your perfect syntax. If you make a syntax error then I might play the role of a compiler and tell you that the code fails to compile on a certain line, and give you an error message, and see how you respond. Likewise if you add a ; onto a loop or an if statement that would compile, I'd play the debugger and talk you through a single step through the code. Again, its not about the mistake, its about how you would cope with the mistake, and are your thought processes good.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
  • 1
    thanks for the feedback ptolemy. much appreciated. you're answer describe exactly what i'm looking for as well as how I'd approach helping the candidate through the problems. But as you also pointed out, I'm flabbergasted by the number of people applying for 5+ year roles who can't do this. – Eoin Campbell Nov 11 '11 at 09:34
  • 1
    The biggest danger in this, is that frustration sets in, and you offer a job to someone who has failed the programming task but did well on the other apsects of interview like a technical test. The reality is, these candidates have read a book and have a good memory. Are you recuiting people to read books? or to write programs? – Michael Shaw Nov 11 '11 at 09:38
  • @EoinCampbell, if communication skills are important to you, then this is entirely appropriate. –  Nov 11 '11 at 21:10
  • easy to say "relax, small errors don't matter". In reality, more often than not they do matter, subconsciously, to both of you. The interviewer gets a feeling that the candidate is failing, the candidate gets corrected and starts thinking "oh well, better stop wasting my time and give up, I've failed". – jwenting Feb 21 '14 at 09:39
  • 1
    so, as a candidate, you make a mistake, I then a little later (not straight away) bring that mistake to your attention. You will feel under pressure at that point. This is a key part of the interview seeing how do you respond? Can you cope with the pressure of a typo at an interview? If you melt under that pressure, what are you going to do when we as a team are under pressure to deliver software to a deadline? – Michael Shaw Feb 21 '14 at 10:29
  • Far more's at stake during a job interview, for the candidate that is. Unless maybe you're in the business of writing missile control software while the missile's in flight and needing to fix a bug in it before it hits and sets off a 500KT nuclear bomb. – jwenting Feb 21 '14 at 16:08
  • The time scale may be different, but in the job, if you cannot deliver quality software that customer is willing to pay for before either the employer runs out of cash reserves, or the customer gets fed up of waiting then everyone of your new co workers is out of a job. – Michael Shaw Feb 21 '14 at 16:39
  • +1 for 'acting as a compiler'. Being able to understand error messages is a really important task, and if you can add this aspect of programming to an interview, that's brilliant! – Chris Cirefice Oct 27 '14 at 17:25
  • 1
    I've used whiteboard coding, the positive part is that it finds really good junior programers. The negative of whiteboard coding is the high failure rate, but those people aren't very good to start with. I've asked people to write as little as one line of code on the board and still had very high failure rates. On the other side I have been asked whiteboard questions as an interviewee and I've always found the questions reasonable. I much prefer whiteboard coding to listing off peoples favorite algorithms for specific problems. – Michael Shopsin Jan 13 '15 at 17:23
15

My question is "Is it innappropriate / unreasonable to expect a programmer to write a code snippet on a whiteboard during an interview ?"

It's very reasonable. An alternative to a whiteboard might be a laptop and a beamer, since programmers are more used to writing code on a keyboard than on a whiteboard. Just make sure a development environment like Eclipse or VS or Idle is already running with a blank project when the candidate starts, so she doesn't have to waste time searching through your installed applications.

nikie
  • 6,303
  • 4
  • 36
  • 39
  • I deliberately do not use a computer in interviews because of the intelisense effect. An inexperienced candidate programs by pressing the . and selecting something from the list. A whiteboard makes this very obvious... – Michael Shaw Nov 11 '11 at 12:13
  • 5
    @Ptolemy: Do really think so? For a typical whiteboard-exercise like "program a depth-first search through a tree", what use would Intellisense be? – nikie Nov 11 '11 at 13:02
  • 2
    Whiteboards/papers don't crash, and everyone knows how to write on them. If you give me IDLE to solve a problem I'm going to assume you're an idiot, and if you give me Eclipse I'm going to spend half my time fighting the default keybindings. –  Nov 11 '11 at 13:38
  • @nikie: having intelisense can make people appear more familiar than they really are. If they claimed on their CV to have 3 years dot Net experience then I would expect them to have a certain familiarity with DotNet. Not having that would raise questions on the accuracy of their CV. When recruiting you do find such inconsistencies between claimed experience and demonstrable capability. – Michael Shaw Nov 11 '11 at 13:47
  • 7
    Intellisense (and other IDEs' autocomplete features, too, I'm sure) can be turned off. Or you can give them Notepad (or a nicer alternative such as Notepad++ which does syntax highlighting but has no autocompletion or the like). Sure, it can crash, but realistically: how many showstopper bugs have you encountered in Notepad? – user Nov 11 '11 at 15:39
  • 4
    Even if it's just notepad.exe it's so much easier to work with than paper or a whiteboard. You can insert or delete lines, which is a huge pain on physical media. – CodesInChaos Mar 22 '13 at 10:14
  • @CodesInChaos One way to delete lines on paper/whiteboard is by crossing them out. Inserting lines is done by markup like carrots and arrows, circling, etc. When this starts to get too messy, you rewrite it in a cleaner way. – Brandin Jan 15 '16 at 10:17
10

It is not inappropriate, but know that it might NOT always reveal the true insights into the programming or problem solving abilities of the person you're interviewing. And I guess that's exactly what you're after.

Secondly, note that there's always the fear of failure, constantly nettling the person's brain. "What if I screw up?", "What if I make a silly mistake". The greater share of the person's brain is busy constantly inspecting how they're coming off -- only few can hold the nerves.

So, in this kind of situation, even the very best might end up faltering.

For the last part we ask interviewees to do is write a small code snippet (4-5 lines) on the whiteboard and explain as they go through it

That's OK. But again, just because somebody could not explain something properly does not mean they don't know it well. (Explanation is an art of speech).

If I were you, I'd do this For the last part...

Hire them for a very tiny (but realistic) project. See how they code, take decisions, assimilate the working conditions and team members, etc., and then based on that, make the final decision.

treecoder
  • 9,475
  • 10
  • 47
  • 84
  • 6
    If part of your recruitment process is to offer a standard fixed term contract for 3 months, how many people would really resign from a perm role to take up your offer? – Michael Shaw Nov 11 '11 at 12:06
  • 1
    I meant last in the sense that it was the last item on my list. I mix up the order of things in the interview depending on how the conversation part has progressed and where I think their strengths and weaknesses are. As for offering them a short term contract... that's just not realistic in a real world small company. I don't have the time/resources to be taking 3 month punt-risks on people who might not work out and as Ptolemy pointed out, I doubt the candidates would be too keen either. – Eoin Campbell Nov 11 '11 at 14:45
  • "The greater share of the person's brain is busy constantly inspecting how they're coming off -- only few can hold the nerves." I always felt like this is important to note, especially with some new folks in or coming out of college. I know I was a wreck in my first few interviews, worrying about that to the point that I messed up some of the easiest questions just cause I was so nervous. Granted, there's not much you can do. All I could do was just move onto the next interview, eventually becoming comfortable with the process. – The Jug Nov 11 '11 at 15:45
  • 1
    @TheJug completely agree and we'll be alot gentler with Juniors & Grads to make sure they're not overwhelmed by the process but we've had senior (7-8 yrs exp) devs struggling with this. – Eoin Campbell Nov 11 '11 at 16:27
  • Hiring someone implies a certain level of commitment from both parties -- don't do it if you're not committed. You wouldn't marry someone to help you decide if you enjoy spending time with them, right? If you want to try someone out in a role, that can be okay as long as the terms are made very explicit up front. Many employers like "contract to hire" arrangements for this reason. Be prepared to have such an offer rejected, especially by candidates who currently hold a permanent position. Trading stability for instability isn't always a winning proposition. – Caleb Nov 11 '11 at 16:50
  • 1
    "Hire them for a very tiny (but realistic) project..." - do you suggest you should "hire" e.g. three of the candidates who applied for a position, even if you only plan to keep one? This seems very unfair to me! It probably wouldn't improve team spirit, either. – nikie Nov 11 '11 at 18:23
  • -1 Strongly disagree that explanation is an "art of speech." If the candidate can't explain their code or their thinking they do not understand it. – user949300 Feb 21 '14 at 06:05
  • @Caleb "Hiring someone implies a certain level of commitment from both parties -- don't do it if you're not committed" nice in theory. In practice it normally means a commitment on the part of the candidate, the company makes no commitment at all. – jwenting Feb 21 '14 at 09:41
  • @jwenting Disagree. New hires often take weeks or months before they can really start to make a positive contribution, and usually require equipment and training, so there's an up front commitment of time and money. *Certain level* means just that -- both enter into the relationship planning to make it work out, but neither party's commitment is absolute. – Caleb Feb 21 '14 at 13:35
  • @Caleb I mean that a company can tell a new hire he's terminated at any point with no consequence, while if the employee quits he's branded a 'traitor' and it looks bad on his resume because recruiters start to think he's unreliable and a 'job hopper'. – jwenting Feb 21 '14 at 16:06
  • @jwenting: If I heard that a company had played games like that with new hires in the past, I would not apply. – Kevin Dec 04 '14 at 19:20
8

Not inappropriate, but remember that some people (and maybe a greater share of the programmer crowd) can be very stressed out in an interview. I think most of us know the guy from the office who is a brilliant coder and a very trustworthy person, but he would melt down in such a situation. His performance could not be measured in such a test, so don't make this a go/no go test.

Tamás Szelei
  • 7,737
  • 7
  • 38
  • 42
  • 7
    I don't know that guy, because he wasn't hired. – kevin cline Nov 12 '11 at 15:52
  • 5
    @kevincline to the company's detriment, unless you earn money by having people hold their nerves. – JayPea May 04 '13 at 00:16
  • 1
    @JayPea: how do I know a person is brilliant coder if I can't seem them code? The only alternative would be a recommendation from someone already on staff. Everyone loves to hire on trusted recommendations, but that is a pretty small group. – kevin cline May 06 '13 at 15:24
  • 1
    @kevincline Read my answer, I'm not saying you shouldn't do whiteboard coding at developer interview. – Tamás Szelei May 06 '13 at 20:47
  • @JayPea I'm pretty sure that having employees who don't get nervous in high-stress situations *is* an important factor in many companies' financial success. – Kyle Strand Dec 04 '14 at 18:46
5

I think it's not a reasonable thing. We try to find candidates, which are good at the task we want them to do. Writing code on a whiteboard is not one of them and I don't think it's a valid filter to find good candidates.

  • Good code doesn't get written, it gets rewritten. A whiteboard is pretty much immutable, as it's hard to change once you wrote it. It should be as easy as possible to change your mind as soon as you understand the problem better.
  • Being in an interview is a stressful situation as it is, there is no need to put additional pressure on the candidate. Many computer people don't have a good handwriting. Modern IDEs provide lots of tools that you're used to. And being able to google something the minute you need it is also part of the working style of most programmers. Why take all these things away and create an artificial environment, that they'll never have to work in if you make them an offer?
  • We're also very interested in the ability to write good tests, maybe even do TDD. This is not possible to see during whiteboard coding.

Most of the clues that you could get out of a whiteboard coding session you also could get out of a pairing session - And I believe, pairing is a much better tool to get a feeling, how a candidate solves a problem and how he works. He can bring his/her own computer and work in an environment he's/she's comfortable with. And it's much easier to apply to the task you want them to do once they join. We for example have a large legacy code base, so we ask them to refactor some extracted code for the real project. And we actually pair as much as possible in our daily work, so it's well fitting.

While a whiteboard session probably helps to filter out bad candidates, it probably also filters out many good programmers.

iGEL
  • 159
  • 1
  • 3
  • 1
    Whiteboards are immutable? You just wipe something off and rewrite it on a whim, that's what makes them useful, especially teaching. You must live in an alternate universe. – whatsisname Dec 04 '14 at 23:52
  • Maybe immutable is the wrong word (I took it from https://medium.com/dima-korolev/whiteboard-and-the-coding-interview-9eddf98bde18 - who thinks it's an advantage). Still, compared to an editor it's hard to add something you haven't left space for. – iGEL Dec 05 '14 at 10:45
4

I personaly think that this is one of the best things you can do. As you said you don't look for correct syntax or something similar the most important part here is to see if someone can communicate... I have seen so many good developers who can only work alone inside their own space... Unfortunatly this isn't possible in a huge amount of cases so having a skilled guy who also is able to TELL what he thinks in a clear and concise way is a more valuble member of the team then someone who thinks:"They won't understand it anyway, I'll just do it myself and demonstrate later".

Communication, communication, communication that's something that is the foundation of every medium to big sized project (even smaller once need it)

Ivan Crojach Karačić
  • 547
  • 1
  • 4
  • 12
  • well it's more than communication. they need to be able to comm, sure, but they also need to be able to tell me their solution to the simple problem. – Eoin Campbell Nov 11 '11 at 14:43
4

Personally, I'd walk out on any interviewer asking me to do FizzBuzz. I don't know when this became the new industry standard, but it's really a waste of time. FizzBuzz is a filter that can be used ahead of an interview, although personally I think if I had to pick from N candidates of which enough have some open source code or a blog I can look at, I'd definitely prefer that as a filter.

Simply put, I think in an interview for a programming position (except maybe for juniors or internships), it should already have been established/determined that the interviewee can program.

But yes, whiteboard is perfect, although I think you should take a different set of problems. Throw them a real-world problem and have them draw a bunch of UML-ish squibbles to explain their overall strategy to solve that problem. Give them a computer with internet, so they can look for 3rd-party libraries they could use as black-boxes in their squibblescape.
Within a few minutes, you will really see how they tackle problems. You can actually make this a very interesting thing, by picking problems that you don't necessarily have a solution for in mind and attempt to "solve" them together, to see how well they communicate and how well they can incorporate input (however don't push them too hard - some people might just freeze if you do). And then add a few requirements on the fly. This is kind of like software development without implementation and -most importantly- without debugging, so 15 minutes is a lot of time.

back2dos
  • 29,980
  • 3
  • 73
  • 114
  • "it should already have been established/determined that the interviewee can program" - how? Either you have a pre-interview, in which case the OP's question becomes whether whiteboard coding is appropriate in a pre-interview, or you effectively take the candidate's word for it, which is inviting disaster. Recruiters and CVs can (and do) lie, blogs and github repos can be plagiarised. – Julia Hayward Jan 13 '15 at 13:53
  • @JuliaHayward: Establishing a candidate's basic coding abilities in a pre-interview is a different thing. You don't actually have to invite somebody *on site* to do that. You can send them a small problem that they can solve. Possibly discuss that solution (or github code) in person. Most imporantly: It's highly unlikely you will find a candidate able to gracefully master the type of problem I suggest, while not being able to solve fizzbuzz type problems. The interview should be used to determine how able the candidate is to deal with the complexity typical of real world problems. – back2dos Jan 13 '15 at 15:25
  • You may not have to have someone on site, but at least you should be on the phone to the candidate talking through their coding exercise, whatever you use. Just handing out a question and waiting for a zip file to be sent in still has all the risks of impersonation; as an extreme example I did the test for FooCorp one time, then just out of interest googled "FooCorp coding test" afterwards - and found someone had published a pretty good solution. – Julia Hayward Jan 13 '15 at 16:04
  • @JuliaHayward: If you give every applicant the same problem, then of course the response becomes google-able. Not surprising, is it? But again, my answer remains: do not do whiteboard coding on fizzbuzz level in an interview. It just shows that you didn't bother preparing a good and interesting problem. As you have said yourself, there are ways to establish basic programming abilities *way before* you invite the candidates to your whiteboard. – back2dos Jan 13 '15 at 23:37
3

Let me respond with another question:

Does writing code on a white board offer any real advantage in assessing programming ability, compared to typing and executing the code on a computer?

I think it's absolutely appropriate to ask a candidate to write code in an interview. However, to me, being able to execute the code is a critical part of the feedback loop that makes up programming. On a white board, you're tying one hand behind my back, and you're not getting the full picture of how I work through a problem.

Kevin C.
  • 139
  • 1
  • is this only your opinion or you can back it up somehow? – gnat Feb 21 '14 at 05:40
  • 2
    @gnat I'm just posing a question. The latter half of the answer is my opinion, yes, but that should be pretty clear by the language used. Furthermore, the question itself starts off by acknowledging that it's subjective, and specifically **requests opinions** on the matter. I don't think the downvote was warranted. – Kevin C. Feb 21 '14 at 06:02
  • @Kevin C. I think that regardless of your wording, you are making a very good point here. Whiteboard coding is different from computer coding. Is this an opinion? Certainly not, as long as whiteboards are unable to run code. – Leandro Caniglia Jan 13 '15 at 21:09
2

No, but IMO a better approach would be to use the whiteboard for its intended purpose and use UML/sketches/notes for some fictitious project, rather than the old "write me a sql query to get all records" or "write a method that reverses a string".

One of the best interviews I had was spending like 20 minutes discussing with the lead developer the architecture (non-software) for a mad scientist's mansion (complete with secret hideout, death ray and dog kennel). He got to see my approach at solving problems, and the problem was something fun not typical rote programming 101 stuff that's been solved by modern languages a thousand times over. Incidentally I also did a piece of code like this before, but I felt much more "under pressure" than with the architecture part.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
2

These days, a lot of programming is done in teams. For teams to work, people have to be able to communicate. A big part of this is being able to communicate in front of a whiteboard (brainstorming, mentoring, code reviews proposed fixes, etc.)

I would look for whether the candidate explained how to go about the solution to a programming problem using whiteboard code to assist. If the explanation is good enough, the other good programmers in the room will mentally auto-correct any typos/mistakes on the board.

For most types of team positions, it would be unreasonable NOT to expect a candidate to be able to explain and scribble their attempt at a solution.

hotpaw2
  • 7,938
  • 4
  • 21
  • 47
0

No, it is a good thing to code for an interview, but you should allow code in any reasonable language as it is usually easier to train a coder competant in another language than to get a a so-so coder in the language you want, up to a competant level.

Paddy3118
  • 617
  • 1
  • 5
  • 10
0

I would say it is appropriate, but in most cases it isn't an efficient way to find out who is good in programming and who isn't. If you want a job done (= hire somebody who is capable), then the interview should focus on measuring real-life skills. So far the best interview I had worked like this:

  • Greetings, welcome by HR.
  • Few words about me, about the company, etc... and she explained the rest of the interview.
  • She gave me a laptop with a program which missed few parts, had failed unit tests because of that. The missing parts were commented there as texts, it was about implementing a basic task, like create connection between few classes, and introduce a simple business logic.
  • If everything went well, the unit tests became green.
  • Saying good bye, and agreement of coming back in few days.
  • On that day the leader met up with me, and asked about the finished program, what did I do, and why.
  • Also this leader asked about my past experiences, and few other questions.

So to summarize: if you are looking for workforce into a production code, test their skills in real environment. If you are curious about their theoretical knowledge, it is better to ask them about these things. If you are stripped from IDE, or you are nervous because you have to program on white board on front of somebody, I can understand, especially in IT people are sometimes introverted and many of us can't handle these situations well, so on white board our efficiency will look worse than it actually is.

CsBalazsHungary
  • 1,389
  • 3
  • 13
  • 15
-1

I don't find it unreasonable unless the interviewee has a bad bad handwriting(or i should say boardwriting) :-) . Besides the only difference in your approach is the use of a board and marker. In some cases interviewers do this thing but they give a paper and a pen instead. Incase there are 3-4 persons conducting the interview, i would say your approach will be much better and suited.

Pankaj Upadhyay
  • 5,060
  • 11
  • 44
  • 60
  • 1
    *"Mostly or all interviewers do this thing"* it's pretty rare IMO. – Kirk Broadhurst Nov 11 '11 at 09:11
  • I guess everyone does that. It's rare that they present with a PC or a laptop just to check whether you solve a particular coding problem. But maybe, things are different in ur place. If you want i can edit this thing in the answer ?? – Pankaj Upadhyay Nov 11 '11 at 09:14
  • see i'd agree it's pretty rare... I've held 4 jobs in the last 9 years and never been asked to write code on paper/wb. Any coding has been at a IDE. which is why I'm wondering is it inappropriate. I'd expect a dev to be able to bang out "Reverse a string" code in a couple of minutes at most without IDE/Intellisense assistance. – Eoin Campbell Nov 11 '11 at 09:16
  • I have made the edit based on your experience. At two interviews i had been too, they gave me a pen and paper to write how to print a Fibonacci series and algorithm for mergeshort. So, i thought mostly things go in this way :-) – Pankaj Upadhyay Nov 11 '11 at 09:20
  • Should point out I've never had to write code at a computer; I've had to write code on paper *twice* (both when I was a junior) and I had to draw an architecture diagram on a whiteboard *once*. That's out of around 20 interviews... – Kirk Broadhurst Nov 11 '11 at 09:22
  • LOL....that's too much of an experience mate....And dats why i edited my answer on your suggestion. Thanks :-) – Pankaj Upadhyay Nov 11 '11 at 09:27
  • @Eoin: The problem with an IDE is that you'll spend a lot of time seeing how they adapt to the IDE (and the keyboard!) and less how they think about coding. IDEs and keyboards are easy to learn though, but they take time to pick up; a whiteboard isn't any problem at all, provided you're forgiving of handwriting. (IMO: Bonus points if they draw a helpful diagram while figuring it out.) – Donal Fellows Nov 11 '11 at 10:08
  • +1 to pointing out the problem with writing on a whiteboard. I've serious problems with it myself :) A good alternative is letting people explain their thought processes while coming to a solution on paper, just thinking aloud. – jwenting Nov 11 '11 at 10:55