"199 out of 200 applicants for every programming job can't write code at all."

>This is a little hard for me to believe.
It really depends on the job. I've done interviews in other fields where that's a fairly accurate statement, assuming "can't write code at all" is stated more along the lines of "can't do much beyond 'hello world'". We can blame the IT bubble for the people who try to get a job being woefully under-qualified.

Presently I interview for positions that attract people who know what they're doing, so it's more a case of the majority being decent programmers and picking out the best of them.

Just curious, are there some filtering process that on a normal interview
you might try. For example you might say, write a code to print prime number from 1 to 100, and see his reaction to that statement rather than the code itself. If its a private thing to reveal, then its ok not to.

I prefer "find and fix the bug" problems because they exhibit both problem solving and enough programming ability to debug. It's pretty easy to weed out fakers that way. Besides, having a candidate write code under pressure on a whiteboard isn't likely to be a good test. Most people do poorly in that situation.

After the applicant passing some test, do you ever try to throw
some tricky question, to see if he can answer them, and see how deep is his knowledge on that certain topic( in a sense)? Also is your applicant C, C++ or does not really matter?

I prefer "find and fix the bug" problems because they exhibit both problem solving and enough programming ability to debug.

Have you got any samples you'd be willing to post?

>After the applicant passing some test, do you ever try to throw
>some tricky question, to see if he can answer them?
I try to keep it practical. If I ask a tricky question, it's probably because we've encountered a problem like that before on the job. In those cases I'm looking more for a problem solving methodology than the correct answer.

>Also is your applicant C, C++ or does not really matter?
C, C++, C++/CLI, C#, VB.NET, VB6, Java, Perl, Python, Pascal, and Delphi are the most common languages I use for interviews. Occasionally I get grads who like one of the LISPs. I expect extensive knowledge of the language they'd be using on the job, of course, but a lot of the questions are general and I let them choose which language to use. Sometimes I give problems where an appropriate choice of language is what I'm looking for. :)

>Have you got any samples you'd be willing to post?
One example is the naive atoi implementation that breaks on INT_MAX. It's good for finding and fixing edge case bugs, and a surprisingly small number of candidates are familiar with it. Another good one to see if the candidate keeps with the times is the binary search bug. Something short and sweet but with a non-obvious problem is ideal. That way we can go through a few of them quickly.

Hi
There is one question I would like to ask.
Is it required that after doing my engineering in I.T. department I need to professionalize myself in one particular language?
If yes....what are the languages that most companies prefer from the applying candidates?

>Is it required that after doing my engineering in I.T. department
>I need to professionalize myself in one particular language?
Heh, "professionalize"? :) Anyway, if you're going to be using a language on the job as a programmer, it's best to learn it well enough such that you're competent. Otherwise, programming skills are secondary (or even tertiary). For example, I'd expect a system admin to know basic SQL and some scripting, but that's about it in terms of requirements. The answer to your question really depends on what jobs you want to apply for.

>what are the languages that most companies prefer from the applying candidates?
Reading the classifieds, I'd say you need to be an expert of every language under the sun (including the ones that haven't been invented yet), on every platform since Babbage's analytical engine, and have 10+ years of experience with every buzzword the company can think of. :icon_rolleyes:

A good filtering criteria is asking what the individual has worked on and evaluating him based on the same. This way even the applicant can't turn all defensive and claim that he was being asked unjust questions (something which happens way too often). This is pretty much applicable to everyone -- from fresh-out-of-grad-school kiddos to seasoned professionals.

Oh and BTW, I'm not surprised at all. Ask someone to write a binary search algorithm and he/she might be in a bit of a shock; ask him about architecting enterprise applications and you're in a real treat of design patterns -- ranging from proxy to template to strategy design pattern. :-)

Narue thanks for that binary search bug that was really interesting I had never thought of that.

>Narue thanks for that binary search bug that was really interesting I had never thought of that.
Neither did the rest of us, seeing as how the bug survived about sixty years of close scrutiny.

>Narue thanks for that binary search bug that was really interesting I had never thought of that.
Neither did the rest of us, seeing as how the bug survived about sixty years of close scrutiny.

Oh, I knew it all along.
;)
:P
Not.

Would an alternative (to the linked article's proposed solution involving casts) also be using unsigned ints, or perhaps a size_t, straight away for the indices?

TBH, if anyone asked me to write a Binary Search Algorithm on a whiteboard, I would be terrified. I'd need a few minutes just to sit and think about what to do, and I can't do that with someone else waiting for me to do it. Also, Narue, I have a lot of respect for your methods, as I've heard some horror stories about the crazy questions that get asked.

>Would an alternative (to the linked article's proposed solution
>involving casts) also be using unsigned ints, or perhaps a size_t,
>straight away for the indices?
It's probably better to use an unsigned type for indices unless you expect signed/unsigned oopsies.

>TBH, if anyone asked me to write a Binary Search
>Algorithm on a whiteboard, I would be terrified.
It's notoriously hard to whiteboard all but the most trivial of algorithms under pressure, regardless of programming ability. If I want someone to write code, I'll provide a computer/projector and watch them work in a more realistic environment. Aside from the extra pressure of an interview, that's not much different from pair programming, which gives me extra confidence in the candidate's comfort level working on a team.

>I've heard some horror stories about the crazy questions that get asked
I've been asked crazy questions as well; I'm not a fan. One I particularly dislike is "Design a spice rack for a blind person". My answer is consistent:

I wouldn't waste either the time or the money doing so. Unless the target audience is also olfactory-impaired, any spice rack will do and they can organize it however they want. Otherwise, I'd question your judgment in encouraging blind people who can't smell to do any kind of serious cooking.

Strangely enough, I've completely avoided everything except "tell me about your strengths/weaknesses" type questions and a few questions about code I'd already written. I've only done 3 interviews (since I got a job out of my third, that's where I stopped) so that could be why, but perhaps it is because I'm a college student and easier questions are asked of college students than of professionals.

I just showed up at my interview with my portfolio and letters of recommendation and show them. Then answered the strengths/weaknesses question and got the job.

In my country, you first get a temporary contract when you start a new job. In this time (3 months usually) the company is free to fire you anytime of the day for almost any reason. So this is the period where you really have to prove that you're a good coder. After these 3 months you get a meeting with a few co-workers and the boss and they decide if you stay or go.
I think this system works well, because you can learn a lot more from people when they work 3 months for you, then you would have learned during a 30-minute interview.

A coder who can't program a binary-search-tree might have other qualities that would go undiscovered in an interview.
To be honest, I find the whole: "code this to prove you're good" idea a bit pre-internet. I can't remember half of the algorithms I've learned in college in detail. But I know when to use which . If I can't remember a particular algorithm I'll just google it to refresh my memory. Is googling allowed in these interviews? :)

I kinda like this system, no, really. But I guess this thing won't work if you have a bucket load of *engineers* to be interviewed, something which is quite common in my country. :-(

My first job after completing my post grad was in a very small organisation - I was the eighth guy. So in almost no time I was conducting interviews for potential candidates and was doing so for a long time after that. From my experiences of those days -, I could say that if not 199/200 it was pretty much 150-160/200. We used to hire in a lot of interns and it was one terrible situation.

Also I like the process in niek_e's country very much, you can certainly not fathom every quality of a candidate in a 30 minute process. Especially when he is nervous because of the same reason that he pretty much needs to showcase every weapon in his artillery in that short span of time. But again this isn't a feasible solution in the country that I (and s.o.s) live in.

One of my techniques was to ask the candidate to suggest a few topics that he was strong in, where he feels more confident and then asking questions to check how good he actually is in those areas.

Just about anybody can learn to play the piano, but very few can be a concert pianist. To be good at playing the piano takes real talent and a special mind. The same goes for programmers.

To hire a good one you have to hear them play, or in this case give a coding performance.

>To be good at playing the piano takes real talent and a special mind.
I disagree. Hard work can overcome lack of talent. While a talented pianist can get to the stage faster, an untalented pianist can still get there. The same goes for programming.

>To hire a good one you have to hear them play, or
>in this case give a coding performance.
This is where your analogy breaks down. Programmers don't practice to write code in front of an audience. 99 times out of 100, such a situation makes us uncomfortable enough to make rookie mistake after rookie mistake. Thus a "coding performance" isn't a realistic indicator of how good a programmer you've got.

>To be good at playing the piano takes real talent and a special mind.
I disagree. Hard work can overcome lack of talent. While a talented pianist can get to the stage faster, an untalented pianist can still get there. The same goes for programming.

Averagely speaking, I doubt that a person without skills at say
playing basketball, would put hard work and dedication to make it
to the NBA. Same for programming, I doubt that a person with no
programming talent will have the ambition and the dedication to
become a professional( and actually go through it). In theory, the
dedication over talent argument, sounds plausible, but in practice,
people rarely follow through.

>Averagely speaking, I doubt that a person without skills at say
>playing basketball, would put hard work and dedication to make
>it to the NBA
The NBA is very much a young person's arena. Of course you need talent to reach that level before age starts to take effect. I assume you brought up basketball because professional piano playing and programming don't have that particular restriction, and your argument would fall flat without a straw man. ;)

>Same for programming, I doubt that a person with no programming
>talent will have the ambition and the dedication to become a professional
Now we're talking about something different. The ability to beat talent with effort is quite different from the desire to succeed without talent.

i dont like interviews... i prefer actual exams.

>Averagely speaking, I doubt that a person without skills at say
>playing basketball, would put hard work and dedication to make
>it to the NBA
The NBA is very much a young person's arena. Of course you need talent to reach that level before age starts to take effect. I assume you brought up basketball because professional piano playing and programming don't have that particular restriction, and your argument would fall flat without a straw man. ;)

True that there are different restrictions, but it still takes the same
hard work and dedication to reach the top level, unless you have
special privileges. And my main argument was that your theory only sounds good on paper,
but in practice, it rarely happens.

If someone asked me about the binary search bug, I'd assume they werre talking about a new computer virus being attached to grandma's email. To be honest, if someone asked me to write a binary search routine on a white board, I'd stare at them blankly and assure them that while I had wrote such things in first year programming at college, it had probably been equally as long since doing so, so could I please consult my good friend google. I guess I'm fortunate/unfortunate (depending upon your perspective) of not working on resource intensive applications and being able to just tap into built-in functionality (an example would be LINQ in .NET or, for that matter, retrieving exactly what I want from a database).

If someone asked me about the binary search bug, I'd assume they werre talking about a new computer virus being attached to grandma's email. To be honest, if someone asked me to write a binary search routine on a white board, I'd stare at them blankly and assure them that while I had wrote such things in first year programming at college, it had probably been equally as long since doing so, so could I please consult my good friend google. I guess I'm fortunate/unfortunate (depending upon your perspective) of not working on resource intensive applications and being able to just tap into built-in functionality (an example would be LINQ in .NET or, for that matter, retrieving exactly what I want from a database).

I don't think I wrote a Binary Search until my third year, if at all. But I'm confident in my abilities to do so, since I know the concepts behind it and I'm a competent programmer. But agreed, obviously the whiteboard situation brings one's nerves into play...

A programmer will grow more with time from work experience... so it doesn't always the criteria is to hire super smart programmers. the important quality there is potential.

A programmer will grow more with time from work experience... so it doesn't always the criteria is to hire super smart programmers. the important quality there is potential.

Sure potential is an important quality, but would you hire a dull person
to make a software for you company, even if that dull person has
potential? Or would you hire a "*smart" person for that same job?
Remember its you ass on the line.

------------------------------------------------------------------------------------------
* whatever smart means these days.

Sure potential is an important quality, but would you hire a dull person
to make a software for you company, even if that dull person has
potential? Or would you hire a "*smart" person for that same job?
Remember its you ass on the line.

------------------------------------------------------------------------------------------
* whatever smart means these days.

Depends on how smart he/she is -- If too smart he might get bored with his job pretty quickly and move on to some other place where the grass may be greener. I wouldn't count on such a person except for the short term.