Interview question



  • @PedanticCurmudgeon said:

    You're not as funny as you think you are.
     

    It's never funny when you're the one using apple juice for oil.



  • @dhromed said:

    @PedanticCurmudgeon said:
    You're not as funny as you think you are.
    It's never funny when you're the one using apple juice for oil.

    On a scale from 1 to 10, where 1 is the movie Hobgoblins, and 10 is that video of a shrimp running on a treadmill, how funny do you think I am?



  • @blakeyrat said:

    On a scale from 1 to 10, where 1 is the movie Hobgoblins, and 10 is that video of a shrimp running on a treadmill, how funny do you think I am?

    Wait, there is some information missing there, what is the direction of the "fun" vector? How much precision is required? What about edge cases where the fun vector is reversed or even perpendicular to the observer? Rounding errors? Standard deviation?



  • @blakeyrat said:

    @dhromed said:
    @PedanticCurmudgeon said:
    You're not as funny as you think you are.
    It's never funny when you're the one using apple juice for oil.

    On a scale from 1 to 10, where 1 is the movie Hobgoblins, and 10 is that video of a shrimp running on a treadmill, how funny do you think I am?

     

    That's both zero funny, so why are you asking?



  • @dhromed said:

    That's both zero funny, so why are you asking?

    Body snatcher!

    SUPER BONUS MODE: Accidental awesome



  • @blakeyrat said:

    On a scale from 1 to 10, where 1 is the movie Hobgoblins, and 10 is that video of a shrimp running on a treadmill, how funny do you think I am?



  • @Weng said:

    I ask this question in interviews. It's one of the few of our stock question bank that actually has what we consider a correct answer.

     

    "Please rank the following 3 attributes of a program in order of importance. Most important to least. Just number them. No explanation is needed.

    - Efficiency. As in the resource footprint of the code on the hardware.
    - Supportability. As in how much work it takes to maintain, how buggy it is, and how traceable/auditable the data is.
    - Compactness. As in how elegant the code looks."

     

    I've done more interviews in the past month than I care to count, and I think I've heard the right answer 3 times. And no, I'm not going to tell you guys what the correct answer is (right away, anyway) - because I want to know what you think it is, just in case I'm totally off base.

    I know developers and I bet you think the answer is supportability. Here's why I think that's wrong: most code never gets supported, and a significant number of software projects arrive too late to actually fill their anticipated goal. Why? Well, probably because orthodox interview Weenies like you are too busy doing it "right," while someone else is just doing it. Get it out the door and doing its thing, I say. How do you know you can do it right if you don't even know if you can do it? If it's difficult to maintain, at least you've now got a high-class problem (whiny neckbeards) instead of a low-class one (zero sales).



  • @bridget99 said:

    too late
     

    Who gives a fuck about deadlines? Maintainable code is important because I wish to remain sane and happy instead of grinding my face into the desk while making unholy noises. Unsupportable code is the mark of an asshole.



  • @dhromed said:

    Unsupportable code is the mark of an asshole.
    I think you've just figured out why bridget99 spouts shit.



  • @dhromed said:

    @bridget99 said:

    too late
     

    Who gives a fuck about deadlines? Maintainable code is important because I wish to remain sane and happy instead of grinding my face into the desk while making unholy noises. Unsupportable code is the mark of an asshole.

    I'm posting from the premise that if developer A is working on a problem, or a product, then some competing developer B is, too. The developer who does things "right" will end up with a product that conforms to his own preconceived notion of good, maintainable code. Unless the other developer(s) working independently made similar, speculative investments in maintainability, though, they will have long since finished their product, it will be in use already, and all that "good" code will get thrown away.



    This is not some speculative scenario I've thrown together. I've seen it played out. You probably have, too. Consider Windows, or any flavor of UNIX. They're basically big, procedural C programs full of obscure passages, magic numbers, and hacks. The good thing about UNIX and Windows was not (and is not) the elegant maintainability of each OS's code base. Rather, these are the OSes that arrived to market quickly and cheaply. You don't hear much about Multics, or GNU Hurd, or OS/2, or Plan 9, or any of the other "good" OSes written with a "take your time/do it right" philosophy. No; the OS you actually use is probably the one that has ugly looking API overlap built around preprocessor hacks (e.g. MessageBoxA vs. MessageBoxW), and/or the one that thinks everything is a stream of ASCII text, and makes you recompile shit to turn features on and off.



    The developers of UNIX eventually built their approach into a sort of philosophy. There's a paper available on the Web called something like "Worse is Worse," and another paper written in response titled something like "Worse is Better." A lot of what's in these papers is in jest, but there's a truth hidden in them that's both profound and uncomfortable for many developers: doing it "right" seldom actually is "right." Doing things "right" doesn't give us UNIX. It gives us Multics, or Plan 9. Or, it fails to give us GNU Hurd, even after decades of "work" on getting it "right."



    Meanwhile, the easy thing (*nix) is out there running on more systems than any of us could list, changing lives for the better, and doing so cheaply. That's the difference between a good philosophy and a bad one (regardless of one's perspective on "right").



    Is all that code difficult to maintain? Sure; but it also presents tremendous difficulties in areas like source control and (!) actually getting crap to work consistently to begin with. Yet most of you don't say things like "the most important thing about writing code is to write it so that it's easy to do source control" (or "the most important thing about writing code is to just make it work as quickly as possible "). No; in a fit of presumption, you all assume that your code will be around long enough to justify large, speculative bets on the software maintenance expenses of your employer, which you assume to be basically limitless.



    Beyond all that, my experience as a craftsman is that "easy to maintain" is a subjective, even deceptive, goal. What I prefer is something that sounds similar but that also produces a different result in its application. What I strive for is code that is "easy to read." The code should be legible. If someone finds a crumpled printout of a page or two of your code, will they get anything out of it? Or, will they get little more than "I really need to see a bunch of other type declarations and source code files to understand this" ? I pose this question because the perspective of the maintenance programmer on your code will not be that different from the perspective of a student finding a crumpled printout of it.



    My reformulation of the rule warns against all sorts of overengineered OO generality and action-at-a-distance. Conversely, the "easy to maintain " formulation seems to positively encourage such things. That's the heart of the matter for the actual maintenance programmer, in my opinion. I've been a maintenance programmer many times. Much of that effort expended toward maintainability has quite the opposite effect in my experience.



    Having discussed this with a lot of developers, I know that many people take exception with the notion that there is some competing developer, or team, developing an alternative to their own work.In my experience, there always is. If nothing else, the end users will eventually work around your failure using Excel, Sharepoint, Access, Word, and who knows what else. Or, management will just eventually fire someone who does not produce.


    The laws of Economics still apply, even to computer programmers.



  • @veggen said:

    #1 Supportability - By far the most important. No exceptions.

    #2 and #3 depend on the context. If the app can potentially be under a heavy load, efficiency would be more important than compactness. Beautiful code won't make the app responsive. On the other hand, for apps that do not take much punishment, compactness gets #2.

    Agree totally with #1, but I'm not even sure what #3 is supposed to mean.

    First of all, compactness != elegance; elegance is about stating an idea clearly and without cruft. Sometimes the elegant solution is more compact than a ham-fisted solution, but code golf isn't elegant, either (in a production application).

    Secondly, isn't elegance intertwined with supportability? If the intention and working of a program are clearly stated and easy to discern by other readers, then that enhances supportability.

    I think a better question would be to rank maintainability, performance, and UX. Performance is still obviously the red herring, but prioritizing maintainability (for the developer's pleasure and productivity) and UX (for the user's pleasure and productivity) is probably a more thought-provoking question.

    Edit: God the motherfucking text editor on this forum kills me.



  • The big issue I have with this question is that Supportability and Compactness or whatever seem to be the same thing: well written code.

    Code that is not maintainable does not look "elegant" to me.

    Sometimes you need code that looks messy. However it should be hidden away in the background.

    Separation of concerns is a big issue to me. Business logic code should not be parsing XML files. The XML files, if you have to have them, should be pre-parsed into data and then business logic runs on that data. If you don't want to extract the data from the XML right away then have some class that holds the XML and retrieves on demand.

    Efficiency of the system is an important issue but code that is written in a poor manner will not be efficient either.

    I generally concentrate on low coupling and extensibility. The code may look a bit more complex in order to support these, but my feeling is that it makes things more maintainable, not less, as you can add new functionality without breaking what is already there.

     


  • Considered Harmful

    @Cbuttius said:

    I generally concentrate on low coupling and extensibility. The code may look a bit more complex in order to support these, but my feeling is that it makes things more maintainable, not less, as you can add new functionality without breaking what is already there.

    I tend to agree here. In a sense, all programming tasks are about managing complexity. The best model is the one that produces the least entropy, that is, one where every component is neatly organized and more can be added without disturbing what is already there. This also means minimizing side-effects and interactions between unrelated components.



  • @joe.edwards said:

    @Cbuttius said:
    I generally concentrate on low coupling and extensibility. The code may look a bit more complex in order to support these, but my feeling is that it makes things more maintainable, not less, as you can add new functionality without breaking what is already there.

    I tend to agree here. In a sense, all programming tasks are about managing complexity. The best model is the one that produces the least entropy, that is, one where every component is neatly organized and more can be added without disturbing what is already there. This also means minimizing side-effects and interactions between unrelated components.

    All that emphasis on organization seems to me to hint at a codebase full of ten-line source code files and action-at-a-distance, and a development process hobbled by BDUF.



  • @bridget99 said:

    a development process hobbled by BDUF.
     

    I have been waiting for this day.


  • Considered Harmful

    It's not unlike hooking up a high end entertainment center. You have might have dozens of wires running to various consoles, speakers, displays, et cetera. The fastest way to wire them up is to run the wires in a straight line directly to where the unit you're connecting sits; except if you do that, your living room looks like a ball of yarn, and if you need to troubleshoot a connection or replace a faulty wire or upgrade something, you have to waste an hour or so untangling the mess before you can begin - or you can yank one out and hope nothing shorts out and a fire erupts.



  • @joe.edwards said:

    It's not unlike hooking up a high end entertainment center. You have might have dozens of wires running to various consoles, speakers, displays, et cetera. The fastest way to wire them up is to run the wires in a straight line directly to where the unit you're connecting sits; except if you do that, your living room looks like a ball of yarn, and if you need to troubleshoot a connection or replace a faulty wire or upgrade something, you have to waste an hour or so untangling the mess before you can begin - or you can yank one out and hope nothing shorts out and a fire erupts.

    With sweet talk like that, I bet you've managed to find a pretty good job.



  • @dhromed said:

    @bridget99 said:

    a development process hobbled by BDUF.
     

    I have been waiting for this day.

    1 foot, 8 inches tall and 441 pounds, huh? Did you find that little guy on Match.com?


  • Considered Harmful

    I'm pretty sure it says 44.1 pounds.



  • @bridget99 said:

    Did you find that little guy on Match.com?
     

    It feels good when I fuck it in the ass.


  • Trolleybus Mechanic

    @dhromed said:

    @bridget99 said:

    Did you find that little guy on Match.com?
     

    It feels good when I fuck it in the ass.

     

    Super effective.

     



  • @joe.edwards said:

    I tend to agree here. In a sense, all programming tasks are about managing complexity. The best model is the one that produces the least entropy, that is, one where every component is neatly organized and more can be added without disturbing what is already there. This also means minimizing side-effects and interactions between unrelated components.

    (Emphasis mine.) I agree 100% and I've been saying exactly that for years. I believe that managing complexity is the fundamental activity of modern software engineering. Unless you are working on something like a AAA game title, or embedded code that runs on a pacemaker, the greatest obstacle to the program's success is managing the growing complexity that comes with any moderate-to-large software project.



  • @savar said:

    Unless you are working on something like a AAA game title, or embedded code that runs on a pacemaker, the greatest obstacle to the program's success is managing the growing complexity that comes with any moderate-to-large software project.
     

    Why do you make an exception for two random things that are also programming? 



  • @dhromed said:

    @savar said:

    Unless you are working on something like a AAA game title, or embedded code that runs on a pacemaker, the greatest obstacle to the program's success is managing the growing complexity that comes with any moderate-to-large software project.
     

    Why do you make an exception for two random things that are also programming? 

    Thank you! Few things annoy me more than the pervasive assumption that everyone's writing enterprise bloatware in Java or some imitation thereof... or even that the majority of people are. All of this auto-garbage-collected crap is really just one part of programming. It's not the good part, but apparently it's the loud, annoying part. I wish businesses would just go back to using typewriters and fax machines and shit, instead of trying to do everything using crapware.



  •  I wish you'd start drinking again so your posts become funny.



  • @dhromed said:

     I wish you'd start drinking again so your posts become funny.

    I wish the women I deal with on a daily basis were more like Shania Twain and less like Roseanne Barr.


  • Discourse touched me in a no-no place

    @dhromed said:

    @savar said:
    Unless you are working on something like a AAA game title, or embedded code that runs on a pacemaker, the greatest obstacle to the program's success is managing the growing complexity that comes with any moderate-to-large software project.
    Why do you make an exception for two random things that are also programming?
    I'm guessing in the first case, the main problem with an AAA game title is persuading management to give you enough time to actually finish the first cut at the code before throwing you under the bus. In the second case, the main problem is getting the code past the FDA.

    More seriously, games tend to have problems with bizarre hardware issues (because people insist on overclocking and using bizarre beta-quality drivers and so on) and pacemakers are so resource constrained that the source management problem gets eclipsed. I'm glad I don't do either.



  •  @bridget99 said:

    I wish the women I deal with on a daily basis were more like Shania Twain and less like Roseanne Barr.

    ...

     

    *drinks*


Log in to reply