[chiph]

Software can have jobs where the work involved is "crank the handle, produce output", but the majority of them do indeed require the ability to solve problems.

I interviewed one candidate several years ago, and the question was: "How do you ensure that your program works as intended?". Hoping to get answers like "I write unit tests, integration tests, test scaffolds" or even "I exercise it with different inputs", what I got was "I use Visual Studio". After rephrasing my question a couple of times and getting more or less the same answer each time, I came to the conclusion that the candidate felt that Visual Studio doesn't allow you to write bugs.

Crank the handle, produce output.

[enry_straker]

I actually blame the people who hire such idiots. Their lack of knowledge is not the problem. Their lack of curiosity is. Their lack of self-motivation is.

Even for "crank the handle, produce output" type of jobs, it's a bad strategy to hire idiots since they will not be doing such jobs for the rest of their lives. Projects change. clients change. Technology changes, and only people with at least a minimal amount of adaptability wlll thrive.

And to answer your generic interview question: By running it. If you probe further, things like unit test coverage, integration test coverage, debugging, seed data etc can come into the picture but that depends on your specific question.

[chiph]

Right - the question is pretty open ended, with lots of potential areas to explore after getting a basic answer.

As a potential employer, I'm happy to help them learn, but I'm not going to spoon-feed them. If someone is profoundly incurious, maybe they'd be better off working somewhere else. Or in another career field.

[enry_straker]

Right-o.

Good to go with open ended questions. It's hard for candidates to memorize answers.

Sadly i see lots of these kinds of idiotic strategies on their part :-)

When i started my first company in 95 or thereabouts, i remember a person who just would not open his mouth during the entire interview. I didn't know what to make of him. I then asked my receptionist to talk to him, find out if i was being too rough or intimidating etc.

Turns out that the interviewee did not trust his own command over english enough to answer back.

Once i learned that, i just handed him a free PC, told him to try writing whatever program he wanted in the next few hours and did not set any time limits.

When i came back after lunch, i saw that he had written a complete game ( This was in the DOS days where writing a game was really difficult since there were no high-level game engines around )

The guy eventually turned out to be one of my best programmer.