big

NOOP.NL | The Creative Networker

The Perfect Job Interview Question

25/04/2008

QuestionmarksA Perfect Job Interview Question is one single question that leads to a perfect assessment of a candidate for a job. I think I have found one for evaluating software developers.

How to Interview a Software Developer in 30 Seconds
When reviewing somebody else's code, what is it that you usually find most disturbing?

It is one of my favorite questions, and I have been using it for over a year. (Together with some questions like "How would you store a color in a database field?", "Why use a Singleton pattern when a static class does the same job?", and "Can you get me a new cup of coffee?".) But it was only yesterday that I noticed the high correlation between the type of answer given by the candidate on the question above and whether or not my interview resulted in a job offer.

All answers given by candidates come in only two forms:

The Syntax & Conventions answers
When being asked to be critical about other people's code, three out of four candidates start blabbering about coding conventions. The candidates drone on about the naming of variables, how class names should be descriptive, and about some arbitrary optimum value for the number of comments throughout the code. Unfortunately, this is not what I hope to hear!

The Design & Architecture answers
Only one out of four candidates answers this question by telling me how he dislikes slow-performing algorithms or insecure code. These people refer to the KISS-principle, coupling vs. cohesion, and how some designs should have been reworked into common design patterns. Those are the people I want!

If I ask a real estate broker about a house, his first reaction should not be his opinion on the quality of the paint, because that is not going to help me as a prospective buyer. I can easily repaint my house I can easily have someone else repaint my house, but I cannot easily change its foundation. Similarly, I don't care about my candidates' opinion on coding conventions. (And before I'm being flamed to cinders… Sure, coding conventions are useful and important! But since the formatting of code is so easy to change, it should not be first on anyone's list of concerns.)

When I realized this yesterday, I started tallying the results of my interviews. So far I have measured a staggering 100% correlation! OK, I admit I had only two job interviews yesterday. But they were a good sample nevertheless. The first candidate mumbled something about the level of indenting he was very concerned about. I'm afraid I don't remember anything else about this person, because my mind slept through the rest of the interview. The second candidate told me how he didn't like inconsistencies in class designs and interfaces. I had to refrain myself from hugging him. So instead, I offered him a job.

I'm going to do some additional testing of my hypothesis, just to be sure. But it looks certain that The Perfect Job Interview Question is going to be major time-saver for me. In fact, the question is so simple I might even let my COO do these interviews in the future.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Top 100 Best Software Engineering Books, Ever
The Single Best Source Control Model
How to Select a Fine Technical Manager

This article is written by on in Knowledge & Experience. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://jfcouture.com Jean-Francois Couture

    I like what you’re trying to find out when asking that question. But there may be a reason if 3/4 of people are answering about syntax.
    That is what I personally find the most disturbing when reviewing, if basic things like indentation and proper naming aren’t there, how am I suppose to even understand the code. That makes it difficult to find design and architectural issues.
    But as I said, I like the idea of trying to find out if a programmer cares more about design or syntax. So you may to rephrase the sentence, or better yet, have them review with you a piece of code.

  • http://www.noop.nl Jurgen Appelo

    Jean-Francois, thanks for your input. You have a good point there!

  • http://bleys.spb.ru/ Alex

    Jean-Francois, the key word seems to be ‘most’ (disturbing). It’s easy to filter out glitches in formatting, just as it’s easy to filter out typos in a plain text (our brain is good at filtering). If the filters get clogged in 30 seconds, the code is probably not worth reviewing it anyway, otherwise it’s much more pleasant to read good ideas with junk formatting, than perfectly aligned BS. For people who FEEL about the stuff they’re doing, at least.
    It brings us to another point that Jurgen feels as well as thinks (as appropriate for his position), and is looking for similar-minded colleagues at the moment.

  • http://jfcouture.com Jean-Francois Couture

    Alex, I think we both agree on this issue, I was just saying that the question is far from perfect (as evidenced by you feeling the need to point out the key word). Human communication is too imperfect to be able to assess a candidate on one question.

  • http://www.noop.nl Jurgen Appelo

    OK, *almost* perfect then. ;)

  • http://www.ideosphere.co.za Richard Dorman

    Jurgen, I agree with your review question, however, questions such as the singleton versus statis class are potentialy dangerous. These questions tend to fall into a “either you know it or you don’t” category rather than “are you smart enough to work it out on the fly”. This may lead to situations where candidates may appear more suitable than they actually are. In my experience interview questions should intiate an explorative dialog between the interviewer and the candidate (which is what I believe your review question does).

  • http://www.noop.nl Jurgen Appelo

    Richard, in my experience the singleton-vs-static-class question has worked quite well, because there are some positive and negative sides to both options. And in an interview people tend to elaborate on that.
    But I appreciate your input, and maybe I’ll rephrase the question later.

  • Mohit

    I think by naming of variables you mean Hungarian, Pascal notation and such. Actually, clear, descriptive names for variables should count as a very good indicator of code quality. Absence of it generally means either the guy only codes for himself or worse, his code has not been reviewed in the past by peers. Plus, it could hint at similar adhoc thought process in the architecture.

  • http://www.noop.nl Jurgen Appelo

    Hi Mohit. In my experience even the worst programmers tell me how important variable names are. So I don’t think this is a good indicator of the quality of their code. There seems to be a big difference between saying how important something is, and actually practicing what you preach.

  • SteveJ

    I know how I’ll answer that question every time. When there are methods that aren’t even used. Nothing worse than working your way through a 200 line monstrosity just to find that it isn’t called by anything anywhere in the codebase. Grrr.

  • http://blog.enginefour.com Shawn Oster

    Great question. I wonder how many people ask questions before answering? My first thought was, “Well, what’s the context? Am I just looking at a single method or an entire body of code? Why am I reviewing this code? Peer review, bug review, paired programming, etc?”
    Like all interview questions the real value is in how they interact with the question and I don’t think either answer is better or worse, depending on why they’re answering that way. Maybe someone is on and on about naming conventions but perhaps the bigger idea they are going for is code maintainability, which is key on any project with lots of hands on deck. Tight code that takes 30 minutes to figure out is worthless. On the other hand someone that goes on about optimizing and performance without ever asking how often the routine gets called could be someone that wastes time agonizing over code at the expensive of the deadline.
    For me the person that wants to know how the code is supposed to fit into the whole and the context under which they’re reviewing is the real candidate and shows they won’t just be some monkey coder churning out well formatted & optimized code.

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Shawn: Yes, those are some valid points. People should understand what’s really valuable in their codebase, given the context.

  • http://onthenose.wordpress.com yossi247

    I used to be a stage manager in theatre, and when my wife was running a theatre company, she was recruiting stage managers, and we worked up a perfect interview question. One of the jobs of stage managers in the low-budget world we inhabited was to beg, borrow or occasionally steal props and set and stuff.
    So here’s the question:
    “OK, we’ve got a show coming up and we need a bathtub for it. Over to you.”
    And you look longingly in the candidate’s direction, waiting for pearls of wisdom.
    The wrong answer is any variant on “I know a guy…”. Or “I could try the home improvement store”.
    The right answer is “What kind of bath? Old? New? What’s the period of the show? Is it a public bathroom or a private one? In what kind of home? Does it need to be practical? Do I need to think about heating water? Drainage? Are we touring the show? Does it have to be lightweight so I can get it into a truck myself?”
    And so on.
    I’ve used the local variant on that kind of question many, many times since.

  • cdr

    Coding standards don’t bother me. Not having *some* standard in use would bother me. Not using the standard conventions of the language/framework would bother me.
    What can really disturb me when I read someone else’s code is an apparent lack of thought or reflection. Superstitious, scattershot, muddled, ugly code.

  • John Robo

    …all I can say, in response to your attitude, is FUCK YOU!

  • http://www.mschaef.com mschaef

    “But since the formatting of code is so easy to change, it should not be first on anyone’s list of concerns.)”
    I think it’s not necessarily a bad sign if a candidate starts out with code formatting, as long as they go on to other, deeper points. Code formatting can be an easy way for a candidate to toss something out at first while getting their bearings on the presented code.
    Also, if the code does have superficial issues with formatting, spelling, etc., I’d be worried if the candidate doesn’t point them out. After all, it’s pretty easy to mention, and good evidence that they actually care enough about what they do to think about those kinds of details.

  • Sergey

    When I see the code that is properly formated, with descriptive names of variables and classes I almost always see good design and architecture. If there is no formatting, if the variable names do not mean anything, then it is very unlikely that I will see any design at all there. Do you have different experience?

  • Ajay

    I dont agree with the fact that formatting of code is not important.
    I *HATE* to see ugly looking code
    this also includes empty lines between “chunks” of code inside a function – I get upset if it looks all messed up – I can tolerate a messy up room with clothes thrown all over – but when it gets to code -
    godliness is *next* to cleanliness.
    Also consistent and meaningful names for variables is super important – its a hint that design could be bad too!
    From my experience doing code reviews, the name one chooses for a variable can show how much thought was put it before the code was written – esp if it is not trivial.
    For straight line code (eg. CRUD) I am not that picky, but when it comes to something more involved – say doing automatic failover which is full of edge cases, I get super picky right from the name of the Class, name of the methods, the comments – everything.
    I walk out of a code review only when the answer to the following question is YES.
    The question: if I was woken up at 3AM and had to find and fix a bug in the code – can I ?

  • kl

    I do care about algorithms, architecture, patterns, clear functional design, etc. but first thing that comes to my mind *is* coding style.

  • Shadow

    Coding style is certainly the most important point when reviewing code for release.
    I don’t really care *what* style, but when there is no consistent style that is “clean” in some sense the code can’t be any good.
    Why not? Every good developer I have ever seen performs some sort of cleanup when he is done writing his code. It’s a mixture of pride and maintenance preperation.
    If a good developer delivers messy code, he *himself* believes that he hasn’t finished yet. Who am I to second guess that?

  • troels

    Naming of classes/variables isn’t a syntax matter, IMHO. One thing that really annoys me, is when people use abbreviations for everything. So you have classes named VI, instead of VoiceInventory and so on. I have a colleague who does that. He also writes 1000-lines long functions. (End of rant).
    Oh, and the singleton-vs-static-question is easy enough; Both options suck.

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    Thanks for all your comments. The key point to consider here is what people *say*, not what they *do*. Sure I can tell good from bad developers by looking at there code. But if someone is only sitting in front of me, without any code for me to verify his claims… what does he *say*?
    Up till now, every single novice/junior/inexperienced developer, fresh from college, tells me that coding style is most important.
    But when someone starts talking about architecture/design/etc. I simply know he’s not a junior.
    Success rate so far = 100%

  • http://1.618034.com Kyle

    I think the key here is most *disturbing*. It’d be tough to find a programmer who doesn’t give a lick about syntax and style, but — short of functions using the foo/bar/baz naming convention — style is rarely disturbing.
    Frankly, style and syntax are the most *irritating* thing about other people’s code, but design and architecture are (allow me to generalize) the only things that approach *disturbing* with any regularity.
    That said, I agree with mschaef: there’s a good chance that someone would start with complaints about format, while they get their bearings. If they don’t delve in from there, that’s trouble.
    Syntax is an irritation, design can be f***ing scary.

  • Pete

    Ah, the silver-bullet solution. I love these, they’re always
    entertaining. :)
    “When reviewing somebody else’s code, what is it that you usually find
    most disturbing?”
    If I was asked that question in an interview, I would honestly have to
    answer “bad (ie. irregular, inconsistent) indentation” – because back
    a year ago when I was primarily maintaining C++ (and to a lesser
    extent Java) code written by people who thought C++ was a weird
    combination of C and Java, that was by far the biggest indicator of
    bad code (now I’m largely writing Python (with *good* programmers), so
    broken indentation isn’t an issue anymore).
    As Jurgen puts it himself, code indentation (and other
    layout/formatting issues) for languages like C/C++/Java are easy to
    *automatically* clean up – though my conclusion would be different
    from his.
    Remember, we’re *reviewing* code in this situation, which (at least to
    me) means that we’re (a) trying to understand what the hell it’s
    doing, and (b) get an idea of likely there are to be problems with it.
    And given that appropriate (consistent) indentation is such a trivial
    thing, it’s a really bad sign if the developer(s) working on the code
    before you couldn’t even be bothered doing that.
    Or, perhaps worse, they were too *scared* to change anything for fear
    of breaking stuff.
    Or, perhaps even worse, they weren’t even aware of the eighteen
    billion auto-indenting solutions easily available to them.
    Another important thing to keep in mind is to make sure the
    interviewer and interviewee both mean the same thing by “reviewing”.
    To some programmers, the term may almost exclusively refer to
    formal code reviews. But in my background it’s almost always meant
    code archaeology, digging through fossilised code written by people
    who left the company months or years ago (or who are still around, but
    wrote the code so long ago that it’s almost like they’ve left :-)).
    And usually the purpose of that so-called “review” is to see if
    you can track down a reported bug. So it’s not *necessarily* a case of
    you wanting (or even being allowed) to generally understand and clean
    up the code, it’s a case of “how deep will I have to dig into the shit
    just to *find* the bug, and then how much will I have to
    change/rewrite/redesign/retest in order to *fix* the bug?”
    Actually, now that I think about it, I believe I’d like to change my
    earlier answer:
    “When reviewing somebody else’s code, what is it that you usually find
    most disturbing?”
    I now think the *most* disturbing thing is if it’s code largely (or
    entirely) written by a developer that you already know is useless.
    Then without even looking at the code, you already know that reviewing
    it is going to be crawling through a sewer into madness. :-)

  • http://nickmudge.info/ Nick Mudge

    Sounds like another hiring miss match to me: http://www.newyorker.com/online/video/conference/2008/gladwell

  • anurag

    You say that there is a 100% correlation between the answer to that question and your selection decision. Similarly, many of us have learnt through experience that badly formatted code has a 100% correlation with the code itself being bad. So that’s what we look at while reviewing – and once we find bad formatting we stop right there.

  • dar7yl

    Did you mean “implement a singleton pattern as a static class”?
    My first response to the code review question would also be consistancy in formatting and variable naming. Although I detest K&R formatting and Hungarian notation, I tend to overlook them as long as the author is consistant.
    The next thing I would look at is level of modularization. Usually the code screams at me if it way past refactoring time.
    Another thing that irks me is over-objectification. (I just made up that word – put it in your dictionary)
    For instance, if they have a class – call it sand – that builds itself into castles, that’s way too much control at the lower levels. Classes should be lean and to the point.
    If I can follow the structure and flow of the program, I would tolerate minor cosmetic faults.

  • Ed Carrel

    Hi Jurgen,
    What about the cases where a candidate expresses concern about both? I may have missed the point where you discuss this and/or someone else mentions it in the comments, but I can imagine cases where someone would discuss the architecture and design of a system they’ve worked on, but would also bring up cases where the syntax and conventions made the architecture completely undiscoverable. For instance, I have a set of vectors describing a particular shape in 3-space, and I want to do a series of transformations (rotations, sheers, movements, etc.). Each of these is a matrix all its own, and unless they have discoverable names, the next person to come along and read that code is going to have to waste time figuring out what matrices do what so they change the appropriate one, especially if they are defined in different places in the code. This may be a sign of a larger architectural issue as well, but all the architecture in the world won’t save anyone from having to go rediscover what the hell this variable named “trans1″ actually does if it’s not spatially local in the code. But then, maybe by carping about things not being named well in a semantic sense, rather than in a conventional sense, I’m actually straddling the syntax/design fence; if I can see the design, then changing the variable names is just a tedious, albeit relatively easy, task, and the primary annoyance goes back to questionable decisions of design. But, in short, I think treating this as a dichotomy is premature optimization.

  • http://brevity.org/ Neil Kandalgaonkar

    Your question might eliminate me. When I see code copying and chaotic syntax and tabbing, I know I’m dealing with a team which does not work well together. If they can’t get together to figure out small issues, they probably can’t get together to do anything right.
    It’s also extremely depressing when you realize colleagues have trouble with basic stuff like this; you have much less chance of explaining why you want to do advanced things.

  • http://brevity.org/ Neil Kandalgaonkar

    Sorry for posting again, but I thought of a better way to explain it.
    When I see code that’s done properly and carefully, but with the wrong algorithm, I rejoice. One email will solve the problem.
    Code that is sprawling and incoherent — especially someone who has been programming professionally — indicates somebody who is not just inexperienced but perhaps *unwilling* to learn.
    I have had just this experience recently. A recent hire, straight out of a good school, wrote in a special case into a function. He documented it beautifully, mnemonic variables, etc. But the solution was wrong, an exception was better. One email… fixed. And I know he’ll never make that mistake again.
    Compare that to another of my colleagues. I have had actual arguments with him over whether code copying was good or bad. He believes it’s good because it’s efficient and you “know” the code will work. He also believes it’s better to have as many globals as possible to avoid passing arguments around. Another of his interesting beliefs is that subroutines are bad; it’s better to have code organized all like a “story” which flows for pages and pages. Needless to say, his code is of the “sprawling” variety and he refuses to believe he’s doing anything wrong. He’s also extremely conservative about changing code — his attitude seems to be that you get one chance to write it and then you have to live with the consequences. But of course you can see why; HIS code really is difficult to change.

  • http://stephan.reposita.org Stephan Schmidt

    Excellent article, though I object to
    “The candidates drone on about the naming of variables, how class names should be descriptive, [...]”
    During my career I’ve seen a lot of code with names of variables and classes which – after several years in production – do not describe the variable or class. This is highly confusing when a class is called A but does B and leads to serious bugs and a major loss in productivity (due to confused developers).
    Peace
    -stephan

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Pete: Great feedback you gave there, thanks! Though I’m glad I’m using an environment that does all the indentation for me.
    @Nick: Maybe. But then, isn’t any interview question a possible hiring mismatch?

  • john

    Job interviews are about personality. The resume tells you what they have learned, where they have worked and what they have worked with.
    Technical questions in interviews should be geared towards proving that the attitude of the person your hiring fits with your team. I.e. you don’t want an advocate for waterfall working in an agile process or you don’t want some one who explains every thing in mind numbing detail when you want just the core and fast response.
    Technical questions to prove knowledge is missleading because the answer may not be the answer you expect. That doesn’t mean they’re wrong. Waterfall works really well in some environments. Also I constantly have mind blanks in interviews but it doesn’t mean I can’t do what I said I can do.

  • raveman

    I think formatting is junior programmer thing, i saw so many bad written code that i even dont care anymore(for some reason i dont even format code, because i like clean svn annotations).
    What is the right answer to Color question? Smart answer would be to store it as int, but i think it should be stored as string(html color if we support all the colors or just “RED” if only a few).
    I hope you are not one of Singleton maniacs, on job interviews I always feel that singleton is the most important pattern. Why they ask about it and not some pattern that is usefull?

  • Chris Collinson

    This so called perfect question is to me a typical example of our industry. Someone writes an article trying to act as an authority on the subject. Someone reads it, and says, ok, that is the only answer. Its like saying there is only one way to write a system. Well you could take the top 5 programmers in the world, sit them in different rooms with the same task and you would get 5 different answers. Does that make 1 better than the others? No. Its just the nature of how individuals works.
    So back to this question. I fully agree that the correct answer is to answer both. It shows someone who cares about all aspects. And whilst you may call it droning on, to me that suggests enough people do agree it is an issue. For me, I will either adapt to a company’s standards, otherwise you produce code that doesnt fit in. Or if the standard is bad or none existent, I will propose the MS ones. I fully agree with the point that badly named variables etc are something that should be mentioned. I worked with a guy who changed the standard on a daily basis and never altered the previous code. So the framework he wrote wasnt intuative to use. So you could argue that actually not using and sticking to a standard is a sign on a bad developer. Also, what is wrong with taking pride in your work?
    I find that people that dont close connections and other resources to also be bad, it might indicate they arent very clued up on how resources are managed. For example. And yes, slow running code that is used heavily is another sign of someone who maybe doesnt fully understand how to write good code.
    My point is this, you could spend hours discussing the answer to this question. There are so many of answers and thats the point. If you focus on the “well it wasnt the answer I wanted” and ignore what the person actually said, then im my opinion, you are probably not that great yourself.
    Also, have you ever considered that people that do not complain about the patterns used etc may not do for a good reason. Imagine you give this perfect answer and the employer thinks “oh god, this person would be rewriting anything they dont agree with”. Not all companies embrace the Refactor mantra. Many use the “if it aint broke” mantra instead. And whilst we may think it is broken, these companies wont agree and you do not appear to be a team player as a result. Having been caught out on this, so I tend to stay clear of it for fear of putting someone off. Yet someone reads your article and adopts it, I wont get the job.
    In an ideal world, I could assume that all interviewers are of the refactor mantra, but this is not an ideal world and maybe writing someone off for not giving that so called perfect answer is a bad idea.
    Judging by the comments you have received on this, I think you have to conceed that our industry has many opinionated people. That is both a blessing and a curse. If any employer were to judge me based on one question, I wouldnt want to work for them.
    I personally think simple question / answer interviews miss the point in a big way. Someone above mentioned a discussion style, and I agree. If I didnt know an answer to a question that doesnt mean I do not know the topic. It may be that I dont understand your question. I prefer to talk to people as a conversation as that generally shows how a person thinks and whether the capacity to learn is there.
    I often find with IT, the person who speaks the loudest believes they are right and everyone just agree like sheep. Remember, people used to believe the world was flat, and to say otherwise was reason to die. Were those people right because they were in authority. No. This could be compared against your 1 in 4 will give the right answer. 3 in 4 may actually agree with you but saying so could be the end of the interview and not the start of a job.
    My advice, listen to what the candidate says and beware of the possibility they know more than you or just simply have different ideas. And remember, its a diverse knowledge that produces the best software, not narrow minded ones!

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Chris: Thanks for you extensive answer. I agree with just about all of it.
    The only thing you may not have understood is that some of my blog posts are meant to be somewhat tongue-in-cheek. I think I have a point. And I enjoy taking it to an extreme.
    Rest assured that my interviews with job candidates usually take an hour…

  • http://blog.jeremyhillin.com Jeremy

    I think this is a great question. I think it shows the difference between a junior – mid developer and a senior developer or architect.
    Keep in mind, code analysis tools can handle the formating and standards reviews. If you are trying to hire someone that can be replaced by a tool, then go with those people. :)

  • Ravindra

    I am totally agree with you. But I would like to add one more thing here is one question is not enough to judge somebody.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Ravindra: True, that is why I now have this post available:
    100 interview questions for developers
    http://www.noop.nl/2009/01/100-interview-questions-for-software-developers.html

  • http://www.orfjackal.net Esko Luontola

    When I first read the question, I was not thinking that much about formal code reviews (such review I have done only rarely), but more about working with and modifying other people’s code. Give that context, my answer is:
    A slow and flaky test suite without good coverage (i.e. not FIRST – http://agileinaflash.blogspot.com/2009/02/first.html ). There’s this one open source project where I’ve written some features, and what brings the most pain to me is that executing all the tests takes 20-30 minutes and there are some tests that always or sometimes fail. That totally kills my TDD workflow and takes away the joy from getting fast feedback of the changes I’ve made. A bad test suite also hinders the refactoring of code design issues.
    The second thing that disturbs me, is the use of the Static Singleton pattern. Global mutable state makes writing well isolated tests very hard (http://www.youtube.com/watch?v=-FRm3VPhseI ). I would replace all such code with the Dependency Injection pattern – create only one instance of the class and pass it to all who use it (DI frameworks make it easy). This also answers the question about Singleton vs. static methods. I would never use the Static Singleton pattern (as described in the GoF book), but static methods which do not mutate any static state are OK (for example java.util.Math.max(int,int)).
    The third thing is big classes (hundreds of lines) that do more than one thing. I prefer small, cohesive classes that focus on doing just one thing (Single Responsibility Principle).
    The fourth thing is long methods (tens of lines) that have code on multiple abstraction levels. Those should be extracted to smaller methods, using the Composed Method pattern, so that all code inside a method operates on the same level of abstraction.
    Also, if I need to add new features or for some other reason modify an existing test suite, what annoys me is poorly named tests. For example testSomeMethod1, testSomeMethod2, testSomeMethodNull – they don’t give an answer to the question “why” and explain what is the behaviour or feature that the test is specifying. If I don’t know why the test was written, I won’t know how to change it when it fails and when it can be removed as outdated.
    Bad indentation annoys me, but I can fix that with the press of a hotkey in my IDE, so it’s not something serious. Mostly it happens on web forums, when some noob posts code without the use of “code” tags.

  • http://www.gopinoy.com Philippine Jobs

    I think it takes one more question to hire a good employee. Though one question can determine the skill of the applicant, the person’s character is not determined. What makes a good employee is not only the skills they have, but also their character and personality.

  • Mozafar

    how do you interview someone and then write the next day about how boring he was??!! you’re arrogant, condescending and kind of immature … I would never work for you, or hire you for that matter of fact

  • http://questionstoaskduringaninterview.net/ Sean

    Thanks for sharing this article, a lot goes into making (and answering) interview questions. very cool so get an inside look at making interview questions.