I was on a forum recently where softwhere developers complained about exercises they were given to solve on job interviews. I mean, the company gave them some little problem that they were supposed to write a program to solve. And they complained that the assignments they were given were dumb.
One programmer said he was asked to write a function to calculate a square root. As he related the conversation, it went like this:
Applicant: I'd just use the square root function from the math library.
Interviewer: Suppose there is no square root function in our math library.
Applicant: I'd find something on-line and download it.
Interviewer: Our Internet connection is down.
Applicant: I'd go to a bookstore and find something.
Interviewer: There are no bookstores in town.
He went on like that a bit. Pretty clearly, the interviewer was saying that he had to write a program to solve the problem. He kept trying to come up with ways to solve the problem without writing a program, and the interviewer kept shooting them down so that he would have to write the program.
Another programmer said he was given some small quiz problem to solve, and, he said, he demanded of the interviewer, "What department wants this and why?"
Well, and so on. Many programmers jumped into the conversation saying how they were given some quiz problem to solve and they refused to solve it, on the grounds that it was not a practical real-world problem.
And I was left wondering ... Did these people refuse to solve the problem because they had no idea how to solve it and were looking for excuses? Or did they really think that it was somehow illegitimate for an employer to give them a hypothetical "quiz problem" rather than a real-world problem?
Do I really need to explain why an employer would use such a problem in an interview? If you give an applicant a problem like, "Find all prime numbers less than 50", you could expect a competent programmer to do this in, what, less than an hour? If you tried to give a real project on an interview, like, say, "Our sales system presently only handles sales tax for this one state. Modify it to calculate sales tax for any state in the US" -- that would require the applicant to study your sales system to find where to make the change, to talk to users about what the screens should look like, to determine where to get the data (tax rates and rules), and to figure out a hundred details of the requirements. It would likely take days of work, especially for someone who has never seen your current sales system before. Maybe with a little creativity one could come up with a real-world problem that has the right level of complexity to be solvable in the amount of time you are willing to spend on this in an interview. But why? Why not just invent an abstract problem?
I wonder if the guy who was given the square root problem just had no idea how one would go about finding a square root and didn't want to admit it, so he tried to deflect the problem by challenging the question rather than answering it. Personally I know off the top of my head several ways to calculate a square root, so I wouldn't have had a problem with that one. But I can easily imagine plenty of problems where I wouldn't know the formula or algorithm. Perhaps if this fellow was given an algorithm for finding square roots he could have written the function. If that's the case, then it was a poorly-designed question. Presumably the point is not to test the applicant's mathematical knowledge but his programming skills.(Unless this was a job requiring both programming skills and mathematical knowledge, but let's assume not.)
But in that case, a reasonable response would not be to get belligerant about it, but to honestly say, "I'm sorry, off the top of my head I don't know an algorithm for finding square roots. If the point is to test my programming ability, can I look up an algorithm on the Internet or find one in a book? If the point of the question is to test my mathematical abilities, okay, I'll see if I can figure something out. How much time do I have?"
I think the perfect interview quiz problem would be one that can reasonably be solved in the time available for an interview, like maybe an hour tops, that tests some basic programming skills, and that doesn't require any non-programming knowledge beyond what is given in the question. Like I mentioned as an example earlier finding prime numbers. If the applicant doesn't know what a prime number is, maybe that's such a gaping hole in his education that that would disqualify him, or maybe you just give a 30 second explanation of what prime numbers are.
Unless a relevant job qualification is that the applicant must have extensive knowledge of a particular library or API, I'd avoid questions that get into that. Like, if an essential job qualification is that the applicant know how to manipulate bitmaps in dot net, okay, a quiz that relies on knowing the dot net image library might be a good idea. But mostly, if I gave such a quiz I'd be testing if the applicant knows the basics: how to declare variables and do arithmetic and write a loop and so forth.
But as an applicant, if an employer asked me to solve some abstract text book problem ... I'd say "sure". I don't expect to solve a real problem that the company really needs solved in an interview. That would likely be wildly out of scale.
© 2022 by Jay Johansen
No comments yet.