Lately, I have started becoming more and more interested in job interviews. Part of that might be because I’m in the finishing run of my diploma thesis, and so I’ll likely start my first real job the next months.

NOOP.NL has an article on the perfect job interview question. A question that can single-handedly decide the fate of an interviewee (at least at the linked shop ;)).

The question: When reviewing somebody else’s code, what is it that you usually find most disturbing?
Some people will rant about a programming style guide, but few will mention the architecture.

I found the reasoning behind it all the more interesting. The thing is, while architecture is obviously a pet field I love to be in, I think I wouldn’t have given it as answer to the “perfect question”: In most situations, you can’t even determine the system architecture from just looking at one person’s code.

Maybe the question is just short on details. The question is interesting, the answer to why it is important is kinda non-negotiable, but the process of weeding people out solely because of their answer to this is… well… questionable.

Choosing the Right Infrastructure for your Project

Are you interested in reading more from CodingClues?
Then subscribe to new postings via RSS or via E-Mail.

Viewing 2 Comments

    • ^
    • v

    My answer: lack of tests.

    Kind Regards

    • ^
    • v

    that is an terrible answer. I have seen too many (often young students) look at a piece of code (such as part of Eclipse) and say the architecture is bad. Only to look back 3 years later (and now using, extending, and working with eclipse), and say, WOW, this is so well designed.

    It is very difficult to see the forest through the trees, especially when you are looking at a small part of the system. What if you were reviewing someones implementation of a sort algorithm, or collection of SQL queries; does the architecture matter here? Is it good if they use the latest architectural style or quote something from design patterns? Architecture and design is very subjective and always in the eye of the beholder.

    Honestly, the thing I find most disturbing when reviewing someone else's code is when they can't explain what they did, or why they did it. Be-it a small (few line change) or a refactoring of the "architecture", if the developer cannot explain (without a lot of hand waving and well-you know, kinda, like, you know, it does the, you-know so we can, you-know cache or something) what they did... alarm bells go off immediately.

    just my $0.02.

close Reblog this comment
blog comments powered by Disqus