Snappy Answers to Stupid Programming Questions

Here's a not-so-gentle reminder from David Pickett that some programming interview questions – in this case, "how would you write a routine to copy a file?" – are, well, stupid*:

This is a companion discussion topic for the original blog entry at:

I can’t tell you if think the moving Mt. Fuji questions are good or bad. Personally I enjoy those type, along with “How many pubs in Dublin?” or “How would you go about building a house?”, the type of questions designed to illicit a discussion.

Someone knowing a language or framwork is as low down on my list as if they have a degree. Neither language knowledge or a degree really tell me anything except the person can follow the directions on the side of the box. If I’m looking for just a pure code monkey those might be important but all our developers need to be able to completely architect a project. Otherwise they’re just fleshy codegen units.

I want to know if the person is a critical thinker, if they are open to admitting that they don’t know everything and willing to ask or search for information. Do they take a moment to really digest a problem or do they just saddle up and start cowboy coding, etc. Can they work in a team or are they anxious to hole up by themselves?

It does make the interview process harder though as you really have to create questions that probe people and it also means you don’t get as many easy filters when ploughing through a stack of resumes.

I also don’t find much value in people sitting down and writing programs. I’d rather see great, creative pseudo-code than lukewarm but highly accurate C#.

Forgot to mention one of my favorite interview stories from a friend that made it through several rounds of interviews. During his last interview some of the higher ups were giving him some of the stock questions and the classic, “Where do you see yourself in 5 years?” came up.

Friend: “Still writing code. You know, exactly what I’m doing now though doing more of the architecting but still writing code.”

HigherUps: “What about being a manager? Do you see yourself being a manager?”

Friend: “Oh god no, I’d hate to be a manager. You never get to write code and you are so far removed from the whole project. Nope, that’s one thing I never want to be.”

HigherUps: “You mean… never? You really mean you would never want to be a manager?”

Friend: “You got it. Never.”

dead silence in the room

Needless to say he never got a call back. These people just couldn’t understand someone that didn’t want to climb some ladder towards “Manager”.

Then once the file copy routine is in production, we get these complaints from the user:

  • This program isn’t working; it’s not resetting the archive attribute on the original.
  • This program isn’t working; it’s not (un)compressing the copy.
  • This program isn’t working; it’s not {en,de}crypting the copy.

And if we asked them how long it’s been doing this, they’ll say, “It’s never worked right”; even several months after deployment. That’s why we ask these annoying questions; because the user probably hasn’t.

Buck, these questions are not the annoying questions. It’s the original question “How would you write a routine to copy a file” that is the annoying question.

I once had an interview in which I was asked inane questions as well. I wish I had thought to implode the questions under their own weight like Dave did.

I was once asked in an interview to show how I’d code a linked list, something I had never found necessary and indeed (as my 30th anniversary in programming looms) have yet to identify a need for.

I wish I’d been smart/confident enough then to have simply asked “why?”

Something I’ve been considering trying is asking the candidate to bring a sample of “great code” with them to interview. Not more than a page, and I wouldn’t stipulate that they had to have written it. I was thinking that it might be valuable to see if we were sufficiently similar in our approaches to be able to agree on what constituted great code. I thought I’d be able to form an opinion by having the candidate spend a couple of minutes explaining why they chose the particular extract they brought.

I have also found it informative to ask candidates what relevant books they’ve read in, say, the past 12 months. You’d be surprised (or not) to learn how many have, at best, thumbed through “C++ for DUmmies in 24 hours” or whatever. Others may have an extensive library of technical books without a single one concerning technique.

A more relevant question is, our software has a bug when it retrieves information from a database, how would you go about finding and solving the problem?

Right, let’s have a discussion about SOMETHING RELEVANT TO OUR JOB. Is that so much to ask? :wink:

Although I often wonder how I would move Mt. Fuji… I think it’d look nice in my back yard.

When I got my current job I got asked exactly zero questions about programming. Oh, there were a few tell us about your experiences kind of thing, but nothing specific to coding.

It was all touchy feely stuff. Tell us about a tough situation you were in. Tell us about a time you had to resolve a conflict with two coworkers. Tell us about your team experience.

As to Mt. Fuji, the answer is quite simple really. You move it one rock at a time. As is so often the case though, the answer is simple, execution is the tough part.

You must have a biiiiiiiig back yard…


Haacked, sorry I’m late with a response, I was busy writing a file copy routine. :slight_smile:

I was reacting, rightly or wrongly, to the interview conversation and the feeling of annoyance from the interviewer’s standpoint rather than to the original question. I agree with you that the original question is annoying from the candidate’s standpoint.

I also wish I would have the foresight to break it down as Dave had done and possibly, but tactfully, criticize the interviewer for the lack of forethought and design planning. If he was the end user, I would partially excuse not having complete specs or a design plan, but if he was the business analyst, it would be a cardinal sin.

I’ve also just written about this:
(Testing our programming mettle through the use of under-constrained problem domains is the Trial by ordeal of technical interviewing)

Wow, is my company’s hiring process that strange?

After a basic interview in which we talked about some of my projects and their projects, they gave me a programming assignment. Everyone who wants to work there gets one - something that should take you about a day to write.

They make sure the program works, look at your code, and take notice of what parts of the assignment you considered important to implement.

Judging from the competence level of everyone I’m working with here, I’d say it works all right.

I don’t know why you’d test a programmer by asking them to do anything but program :stuck_out_tongue:

I’ve been a pro developer for 11+ years and only this year looking for contract work have I been running into these so-called “tests” to determine if I can program What a crock of you know what. No test will show whether or not I know how to program or If I understand the big picture.

If you have a track record, professional references, and provide adequate sample code and interview with technical questions should provide and ample idea if a candidate “gets it” and could fit in the team personality wise.

I just turned down a second interview with a company because of a
"test" requirement. Wherein the prospective employer stated they fired someone with 22 years of programming experience after 3 months because he couldn’t put out code - but he aced their test.

I tried to make the point that their example of this person - compeltely supported my position - a test will not tell you if a person can do the work…silence…at which point I thanked them for their interest and asked them to remove me from consideration for the job.

If an employer cannot trust your interview, words and actions - I don’t want to work for them anyway.

Jeff, the file copy question is really just another example of FizzBuzz test. It’s a bad choice, to be sure, but that’s generally the intent.

However, it is in some twisted respects a good question to ask because it should bring forth the kinds of questions the candidate offers. Just asking those questions places them in the top 10% of potentials! Being able to write simple code that meets a specified request puts them in the top 5%.

Crazy, but true.

The “copy file” question is only useful for those programmers designing operating systems.

The simple .Net answer is:

  1. System.IO.File.Copy.
  2. There is a .Net class that handles that already.

A better file.copy interview question might be:

In .Net, you can copy a file by using System.IO.File.Copy. Why can you use File.Copy directly?

Now someone with .Net experience should discuss some information on static methods, which should give you some insight on the candidates grasp on object oriented concepts.

Once I had a quiz with a company who dealt with SQL. I brushed up the night before on SQL-92 and felt pretty good going in. The quiz was 20 questions on a “made up” programming language, no SQL questions at all! Interesting, the HR person came back with the results, 18 out of 20. You needed 19 or better for 2nd interview with someone in the department. At least they validated my parking for the garage.

Quizzes are useful to an extent, but I’d be wary of a company who asked questions like how many quarters equal the height of the empire state building? A more relevant question is, our software has a bug when it retrieves information from a database, how would you go about finding and solving the problem?

Hey, I just wrote about this last month: