• Easter Bunny (unregistered)

    Hmmmm.

    Just mess with the interviewer's head and explain that software doesn't have a physical existence separate from a computer or storage medium. Therefore drawing a house would be inappropriate. Instead the interviewer and interviewee must maintain the existence of the house design in each person's memory in order to really emulate the process.

    Then build away!

  • Easter Bunny (unregistered) in reply to pythonic
    pythonic:
    The point of the exercise is not to actually design a house in 5 minutes. The point is to see what kind of questions the interviewee asks and how they would gather requirements and understand use cases.

    Son of a gun!

    I guess that's why I got the funny looks when I pulled out the suitcase full of Legos.

  • Easter Bunny (unregistered) in reply to David V. Corbin
    David V. Corbin:
    I have to chime in on this one...

    Your dime.

    David V. Corbin:
    As a developer for over 35 years, (and even having worked for MSFT for a while) I completely AGREE with the technique of asking "brain-teasers" and "non-programming" questions on my interviews.

    Been programming for 30+ years, but never for MSFT. No idea if that's a good thing or a bad one.

    Personally the whole "brain-teasers" leave me flat. The purpose is to produce solid, dependable, stable applications. And anything that doesn't lead to this end result is a waste of effort. And I really don't see the connection between "brain-teasers" and programming.

    IMO 99% of programming is having a good memory.

    David V. Corbin:
    For many years I have utilized a completely ficticious language for all programming samples that take place on the interview.

    Shrug isn't that a complete waste of time? The whole point behind using a standard programming language in the interview process is to have a common frame of reference. Both the interviewer and the interviewee understand the syntax, limitations and libraries involved with this language.

    Throwing some pseudo-language that you created into the mix doesn't appear, to me at least, as an optimal solution. Instead all it could do is drag the whole interview process out. Either the interview takes longer than it should, in order to explain the nuances of this new language, or time limitations will restrict the depth of the interview process.

    David V. Corbin:
    In the long hual, I am much more interested in how a person thinks and how they address situations they have never seen before.

    shrug Most of the programming I've encountered has pretty much either been similar to stuff I've done before or at best an evolution of older technology or techniques. In the world of business programming there really ain't that much new under the sun.

    IMO I'd rather have someone with a depth of experience and a good memory. And if the person isn't a complete sociopath, emotional flake or has passed the egomania phase of programming, which we've all had to deal with, then that's a total bonus.

    David V. Corbin:
    I would much rather have and employee who can quickly aquire and then utilize new knowledge rather than an in-flexible expert in a specific knowledge domain.

    Well you're in the minority then. Sorry.

  • Easter Bunny (unregistered) in reply to Sanity
    Sanity:
    That's why I answer with "I would hire an architect." If he insists that I'm his architect, I would answer, "I would go to the library and read books on architecture."

    Hmmmm.

    I would answer "I was interviewing for the Senior Software Developer position but since I'm now interviewing for an Architect position ... I want a raise."

  • Easter Bunny (unregistered) in reply to Aaron
    Aaron:
    It actually just occurred to me that a "fully customizable" house as per interview spec would probably violate several bylaws in most cities. So my answer to that question might actually be "I'd choose not to build your house because I think I could make more money by suing you."

    Me I'd point the guy at a geodesic dome. No interior walls are load-bearing so do whatever the hell you want.

  • ajk (unregistered)

    The real WTF is the ads displayed by AdSense from Google - ads about housing architecture LOL

  • Lynx@Work (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    In The Pragmatic Programmer, the author talks about how programming is more like a garden.
    I agree. Sometimes you deal with fertilizer all day and really need to spread it around to make sure your project can get to where you want it. Just like application development.

    :D :D

  • NewbiusMaximus (unregistered)

    My lands, why keep playing along if you've already decided the interview is over? If the interviewer is going to be rude about it, follow suit and just stop answering questions and/or walk out of the room.

  • Mef (unregistered) in reply to Tim

    Guys, i actually dont know what's the problem to design house? The interviewer asked some simple design skills like:

    class Room { };

    class Floor { Vector<Room*> rooms; public: bool MoveWall(int wallID); };

    class House{ Vector<Floor*> floors;

    };

    or something like that. Its up to creation skills of candidate. Add some methods and discuss about that. That's the same as "how much cars in the US?" - interviewer dont ask for exactly value but he would like to see how the candidate thinks. nothing complex.

  • some guy who does job interviews (unregistered)

    Actually ...

    Not sure of how the rest of the world sees these riddle parts, but when I am interviewing people for positions on my team I always put in at least one of these things or even rather non-sensical tasks.

    Actually having the balls to include "well, i don't see how this is relevant for the job, but..." along with some fun or creative answer are the top scorers for me.

    The approach and reaction to the situation are waaay more important than the actual answer. Businesslife offers sufficient non-sensical and frustrating situations that you just have to go along with occasionally that including such a situation in an interview seems rather correct to me.

    And considering that I still have never rued getting anyone on my Team so far I guess the approach is sound enough.

    Just my two cents on the issue.

  • nat42 (unregistered)

    Hey, I had "draw me a house" this week too. And I did, no questions asked!

    However the interviewer was concerned I didn't ask any questions.

    And I had to explain that "the draw me a ..." business just doesn't work like that. First you show a sample of what you can do, and only then do you start discussing what someone wants.

    Would you go to one of though street portrait drawers that had no sample pictures up? Do you order a couch in your choice of fabric, without fabric swatches or seeing what that style of couch may look like? Would you order custom Nike joggers (Nike ID) without any idea what the final product may be like? -> Did you mean when you order multiple pumps you didn't want the footwear to resemble a darlek?? No. You would not order or set out specs for these things without a clue as to the final outcome.

    It's like a user interface mockup. It's a throw away "here what I'm thinking" to let your client know - a) your drawing skills: are you the be interviewee to be hired to draw houses, is it pointless given the lack of drawing skills to specify the species of grass they want drawn for the lawn b) Something that can then be discussed to meet the spec. Your client , the interviewer, is probably only dabbles in the drawn house industry and likely will be aided by a model to discuss. They may realise more specs from the mockup they they had not thought to include initially c) They may have only half read the "Draw-me-a-house" interview pattern and misunderstand what it demonstrates...

  • M.I.K.e (unregistered)

    Reminds me of the time when my boss "corrected" my experience in OS-9 to OS/2 on my resume without asking me if that was a typo or if there really is a difference between the two systems.

    For those who don't know:

    OS/2 is a PC operating system that was developed by IBM and Microsoft, but then Microsoft decided to push Windows instead.

    OS-9 was originally designed by Microware for the Motorola 6809 in the pre-MS-DOS days. Nowadays it's used as an embedded system for different architectures and is sold by Radisys.

  • Sjaak spoiler (unregistered)

    One should definately ignore companies that ask for references. I've seen a major company go bankrupt because of a manager hired after our HR manager inquired all his references. After turning a small yearly profit into a multi million dollar loss, my collegue just Googled this chap's name and it turned out he already left a trail of bankrupt and devastated companies in the past. So much for references.....

  • Cope with IT (unregistered) in reply to Koun

    Or may be they werer just entirely nuts (as well as not watching their typing) and were talking about a mark on some sort of drain (gutter tag).

    Have a nice morning/day/evening - whenever you are

  • NeoMojo (unregistered) in reply to Khanmots
    Khanmots:
    send 1,2 across (2) send 1 back (1) send 5,10 across (10) send 2 back (2) send 1,2 across (2) done! (in 17)

    Send 1,2 across (2) Throw torch across bridge (<1) send 5,10 across (10) done in 12

  • JB (unregistered)

    I don't thing that bombarding the interviewer with more irrelevant questions would get the point accross. I get the feeling that this simpleton would delight in the idea that you are ingaged in this his inane exercise. In the end he'd just flip every question into "how can you be flexible enough to handle every option?"

  • Addie (unregistered) in reply to Franz Kafka
    Franz Kafka:
    Khanmots:
    However, some things like weighing a jet... why waste your candidates time?

    How is weighing a jet different from weighing the front and back two sets of tires (with attached jet)? If you really need to know, it becomes a mechE problem - design a scale that you can sit a jet on.

    No no no. Float the jumbo jet in a giant pool of mercury. Measure the change in depth of the pool. Depth times cross sectional area times mercury density - bingo.

    And then replace all the aluminium parts of the aeroplane.

  • tinkerghost (unregistered) in reply to Easter Bunny
    Easter Bunny:
    Aaron:
    It actually just occurred to me that a "fully customizable" house as per interview spec would probably violate several bylaws in most cities. So my answer to that question might actually be "I'd choose not to build your house because I think I could make more money by suing you."

    Me I'd point the guy at a geodesic dome. No interior walls are load-bearing so do whatever the hell you want.

    My thought was post & beam for the same reason. Plus you have vertical outside walls, which simplifies tacking on additions.

  • woohoo (unregistered) in reply to Easter Bunny
    Easter Bunny:
    The purpose is to produce solid, dependable, stable applications. And anything that doesn't lead to this end result is a waste of effort. And I really don't see the connection between "brain-teasers" and programming.
    Flexible thinking. Thinking out-of-the-box. Dealing with the unexpected. etc etc ...
    Easter Bunny:
    IMO 99% of programming is having a good memory.

    WHAT? You must be a code monkey, no kidding...

    Software architects and good developers very much depend on different skills.

    No real skill that requires intelligence depends 99% on good memory. That's what we have documentation, lexicons etc. for. I refuse to remember the APIs of 3000+ classes, when it is much more important to have really absorbed the paradigms of OO.

    Unfortunately it is very often the other way round. Reminds me of the people that completed university physics exams by learning the complete book by heart without understanding anything, but perfectly replicating all derivations on request - often with better grades than the ones who tried to understand what they were doing... I would not count on the former to solve a new problem, though.

    David V. Corbin (whose attitude you criticised in your post) has it spot-on.

    Easter Bunny:
    Personally the whole "brain-teasers" leave me flat.

    Well, that might be part of the problem... ;o)

  • (cs)

    Obviously the the house problem was to see if the candidate could write modular software, and handle interconnection or reorganisation.

    Rooms could be individual units, with wiring and plumbing that stack or be combined with each other to make larger rooms. Then you wrap it in a nice pleasing skin (like a UI?).

    Kitchen inherits from room, has sink, cooker which are Appliances.

    (This would of course be a bitch to make unless it were made of something like lego. Though I've just googled and modular houses exist! Damn)

    I talk shit [in interviews]. That's all they've ever seemed to want. Maybe I'll be a manager some day.

  • (cs) in reply to Easter Bunny
    Easter Bunny:
    David V. Corbin:
    I would much rather have and employee who can quickly aquire and then utilize new knowledge rather than an in-flexible expert in a specific knowledge domain.

    Well you're in the minority then. Sorry.

    Don't be so sure. Particularly in this field (IT), knowledge becomes obsolete very quickly. I was once an expert in VB6 and ADO. With the advent of .Net, that knowledge became obsolete, and I had to learn the .Net platform and C# language (a company preference over VB.Net). More recently I've been studying Ajax, WCF, SQL Server Reporting Services, and Generics, with LINQ and Silverlight waiting in the wings. An employer who hired me simply for my knowledge in a specific area would be foolish. Better to know that I keep studying to stay abreast of developments in this field.

  • Asiago Chow (unregistered) in reply to LieutenantFrost
    LieutenantFrost:
    Asiago Chow:
    (Long explanation involving remote controls and nuclear weaponry...potentially taking place in space)
    I'm not sure if you're joking or not. Is that The Real WTF?

    It's a bit strange but a WTF? Shrug.

    Clue 1: Answers to hypothetical questions are hypothetical. Hypothetical answers are not constrained by normal physical, legal, and economic limits; they are constrained only by the terms of the hypothetical question and the capabilities of the answering party. This hypothetical question did not set any real constraints beyond the most basic: design me a house. Ergo the answering party is free to set the terms at will. You could correctly answer with, "I'm going to design you a bounce house. It will be inflatable, economical, and fun! Most importantly it can be expanded with duct tape and more bounce houses, and can be used most anywhere so long as you avoid sharp pointy protrusions and women with high heels."

    Clue 2: A joke, in the context of a job interview, can be a very serious answer.

  • Easter Bunny (unregistered) in reply to woohoo
    woohoo:
    Easter Bunny:
    The purpose is to produce solid, dependable, stable applications. And anything that doesn't lead to this end result is a waste of effort. And I really don't see the connection between "brain-teasers" and programming.
    Flexible thinking. Thinking out-of-the-box. Dealing with the unexpected. etc etc ...

    shrug and "brain-teasers" will identify those people for you? So someone who is good at what are effectively cocktail party games is who you want developing applications for you?

    Well then. Bring on the Pictionary!

    My negative view about these "brain-teasers" is that they're irritating, useless and frankly don't really show whether or not someone really is flexible or capable of thinking out of the box. All it offers is the opportunity for the interviewer to annoy the hell out of the interviewee and to waste some more time in the interview process.

    woohoo:
    Easter Bunny:
    IMO 99% of programming is having a good memory.
    WHAT? You must be a code monkey, no kidding...

    shrug I code. I architect. I really can't say I care overly much which. It's all enjoyable to me.

    Frankly there really isn't much new under the sun when it comes to business programming.

    woohoo:
    Software architects and good developers very much depend on different skills.

    Really? I have been in the business for a few decades so I do know the difference.

    Here's your choice:

    A. Architect, very creative but lousy memory

    B. Architect, not so creative but perfect memory

    IMO "B" will win out every time. Why? Because a creative application or system is nice, but users want stability more than anything else and, IMO of course, someone with a perfect memory is less likely to create a monstrous pile of rubbish.

    woohoo:
    No real skill that requires intelligence depends 99% on good memory. That's what we have documentation, lexicons etc. for.

    Yes we do. But if you can't keep this stuff in memory then what good are you? Particularly if you're having to deal with multiple systems in widely differing languages all of which have their own unique syntax and, more importantly, their own particular set of libraries.

    Consider concatenating a string. Every damn language has its own particular style of concatenating a string. Every stupid SQL engine likewise. It's a silly example but if you are having to deal with legacy systems along with a host of other established systems in your application then being able to remember the specifics does frankly help.

    woohoo:
    I refuse to remember the APIs of 3000+ classes, when it is much more important to have really absorbed the paradigms of OO.

    'Cause remembering the paradigms of OO are so hard?

    No offense but remembering the paradigms of OO isn't all that hard.

    woohoo:
    Unfortunately it is very often the other way round. Reminds me of the people that completed university physics exams by learning the complete book by heart without understanding anything, but perfectly replicating all derivations on request - often with better grades than the ones who tried to understand what they were doing... I would not count on the former to solve a *new* problem, though.

    Now you're introducing a strawman.

    woohoo:
    David V. Corbin (whose attitude you criticised in your post) has it spot-on.

    shrug I disagree

    woohoo:
    Easter Bunny:
    Personally the whole "brain-teasers" leave me flat.
    Well, *that* might be part of the problem... ;o)

    Not really. They simply bore me. When/if I encounter them in an interview I pretty much lose interest at that point. If they want someone experienced who can get the job done then they can stop fucking around with idiotic "brain-teasers" and actually present the problems they want to hire me to solve.

    Seriously. You'd rather hire someone who gives reasonable answer for the "Rope Bridge" nonsense rather than someone who can jump right in on discussing the problem at hand and offer an intelligent discourse on what the issues are?

    shrug good luck with that.

  • Easter Bunny (unregistered) in reply to FredSaw
    FredSaw:
    Easter Bunny:
    David V. Corbin:
    I would much rather have and employee who can quickly aquire and then utilize new knowledge rather than an in-flexible expert in a specific knowledge domain.

    Well you're in the minority then. Sorry.

    Don't be so sure. Particularly in this field (IT), knowledge becomes obsolete very quickly. I was once an expert in VB6 and ADO. With the advent of .Net, that knowledge became obsolete, and I had to learn the .Net platform and C# language (a company preference over VB.Net). More recently I've been studying Ajax, WCF, SQL Server Reporting Services, and Generics, with LINQ and Silverlight waiting in the wings. An employer who hired me simply for my knowledge in a specific area would be foolish. Better to know that I keep studying to stay abreast of developments in this field.

    That's just the cost of doing business as a developer.

    Sure I did the same thing. Programmed VB, ADO and a pile of other things. Hell I started programming on a TRS-80 Model I, if that matters at all, and had to change to programming RPG went I got a job coding IBM midrange.

    Sure there's a lot of new technology out there. But a lot of it is an evolution of previously existing technology as well.

    And tell me that an excellent memory isn't helpful in learning new tech. You're not are you?

    As for the rest. shrug employers hire you for what you can do now, not what you can do in a few years. Otherwise we could go into an interview, answer the silly-ass "Rope Bridge" nonsense and get a job right then and there. Because it wouldn't matter that we had no knowledge of the tech needed in the job, we can learn pretty damn quickly eh?

    It's nice to dream, but reality is somewhat different.

  • (cs) in reply to Sjaak spoiler
    Sjaak spoiler:
    One should definately ignore companies that ask for references. I've seen a major company go bankrupt because of a manager hired after our HR manager inquired all his references. After turning a small yearly profit into a multi million dollar loss, my collegue just Googled this chap's name and it turned out he already left a trail of bankrupt and devastated companies in the past. So much for references.....
    Asking for references is something stupid. Maybe the person who gets called won't even remember you or even worst, confuse you with someone else. IMO anyone who works with computers have left something behind, either a webpage, a blog, something. So just google the name, ask for his IRC/MSN/Quake/SecondLife nickname (which btw, is something to be studied because there's got to be a very close relationship between a nickname you *choose* and your personality) and see what pops ups.
  • NiceWTF (unregistered)
    Like most sane people, I absolutely despise the whole Job Interview 2.0 thing.

    http://www.phdcomics.com/comics/archive.php?comicid=993

  • ForcedSterilizationsForAll (unregistered)

    If ever asked to design a house in an interview, I would tell the interviewer that I am an Application Developer, not an architect. Then I'd tell him if he wanted me to design a house, I'd subcontract the work out to experts in a third world country.

  • (cs) in reply to M.I.K.e
    M.I.K.e:
    Reminds me of the time when my boss "corrected" my experience in OS-9... *snip* OS-9 was originally designed by Microware for the Motorola 6809 in the pre-MS-DOS days.
    Oh, man, I loved OS-9! Used to code modules for it in Assembler and Basic09. I learned C on that machine, too, but the modules took up so much of my 256k of memory that I generally stuck to Assembler. I was devastated when the CoCo finally faded from the scene, relegated to obsolescence by 16-bit machines. That was about the time I decided to go to college and switch my occupation to programming.

    I was one of those who got our first copy of OS-9 from the Rogue game diskette, before the OS was officially released. Man, those were happy days! I should have moved up to the 68xxx series instead of going with Intel. But of course the university, and later, the businesses with programmer positions were all using Intel/Microsoft. And my C++ was waved aside for RAD using VB4. I haven't been back to C++ since.

    I can't say that I would include OS-9 experience on a resume, though. Too long ago, and too obscure.

  • (cs) in reply to Easter Bunny
    Easter Bunny:
    And tell me that an excellent memory isn't helpful in learning new tech. You're not are you?
    Memory is obviously useful; so is Google.
    Easter Bunny:
    As for the rest. *shrug* employers hire you for what you can do now, not what you can do in a few years.
    Probably, some do; others have more insight. I'm included in the interviews for positions on our team, and of course we're looking for people who are currently skilled in ASP.Net and SQL (and others). But we're looking beyond that, too. In addition to personality fit, we're interested in what they've done before, how they've adapted to changes in technology. This, specifically because we want to know how well they will adapt to future changes as one of our employees. Our company provides us a little training here and there, but for the most part we keep up on our own. New team members need to have that habit, too.
  • Easter Bunny (unregistered) in reply to FredSaw
    FredSaw:
    Memory is obviously useful; so is Google.

    Google is only useful if you can figure out or remember the specific keywords that'll actually return a useful response. Or at least one that isn't completely overwhelmed by useless nonsense.

  • Anon Fred (unregistered) in reply to Easter Bunny
    Easter Bunny:
    David V. Corbin:
    I would much rather have and employee who can quickly aquire and then utilize new knowledge rather than an in-flexible expert in a specific knowledge domain.
    Well you're in the minority then. Sorry.
    I'm sure it looks that way to you.

    However, there are lots of shops where general knowledge is important. It's not so much that you need to know the answers. It's that you need to know the questions.

    Of course, there's a lot of money to be made off of people who've never read The Mythical Man-Month and think "we need 10 .NET developers with LibFoo 1.3.98 experience RIGHT NOW!" The project is doomed, but if you can convince the clueless manager that he needs to hire you as a contractor, you'll do fine.

    Just make sure you get paid up-front.

  • Mot (unregistered) in reply to Khanmots

    The truly parallel method.

    1 - Carry 10 across on his back (1) send 1 back (1) 1 - Carry 5 across on his back (1) send 1 back (1) 1 - Carry 2 across on his back (1) done! (in 5)

  • Nick (unregistered) in reply to Mot

    Hmmm is 2 female and Cute, cross with 1 & 2, torch bridge...

  • (cs) in reply to Fraggle My Rock
    Fraggle My Rock:
    "Design me a house," the interviewer cheerfully demanded."

    See this was your mistake in not taking "the out". What you should have said was "You betcha!" and quickly walked out of the interview and said nothing more.

    Then after about six weeks you could have sent some pictures of some housing complex construction site that you had taken (or jacked from Google) and sent a lengthy fax outlining expenditures broken down based on materials, labor costs and given a bank account number for deposit for "works rendered". To add icing on the cake, the report would have a good old fashioned Italian name on it with emphasis on "Family Business", "We get the job done no matter what", and "We kill the competition" references.

    That would have taken good care of Mr. HR Know-it-all.

    Fail! You're missing the pond. Fish need somewhere to sleep too, you know...

  • (cs) in reply to WhiskeyJack
    WhiskeyJack:
    xtremezone:
    Whether this particular interviewer was calculated or insane is anybody's guess, but the job of the person(s) hiring is to figure out which candidate is most fitting for the position, not who claims to know the answer to every question asked in an interview. Saying you don't know is a valid response, unless the thing you don't know is critical to the position (in which case you probably shouldn't be applying).

    I found out some time after I was hired that one of the reasons was because I was honest when answering the question: how do you feel about round-trip software engineering? (E.g. with Rational Rose)

    How do I feel? I think it's a neat idea in theory but totally impractical in the real world of iterative development and refinement. Far more efficient to have a high-level overview design and not try to design out the minutia until you've got something that works well, then back-fill the details. Designs for the stuff in between are better left to whiteboards, doodles and face to face discussion, not CASE tools.

    My interviewers looked at each other and smirked when I gave my answer. Seems they'd been doing exactly that, until upper management recently came down with a directive to use the CASE tools. They liked that I was familiar with the subject and realistic in my assessment of theoretical benefits versus reality.

    Well, it works with a suitable AST.

    Unfortunately, very few programmers code directly to an AST.

    Even more unfortunately, Rational Rose is very far indeed from being an AST.

  • (cs) in reply to nat42
    nat42:
    Hey, I had "draw me a house" this week too. And I did, no questions asked!

    And I had to explain that "the draw me a ..." business just doesn't work like that. First you show a sample of what you can do, and only then do you start discussing what someone wants.

    I must be the only person here who immediately thought of Tracy Kidder's book "House." (Which I thoroughly recommend. Franz Kafka, are you still listening?)

    I'd say that it encapsulates the folly of using house-building as a metaphor for software beautifully. Not that it's a bad metaphor; simply that it's a perfect real-world example of how "only then do you start discussing what someone wants" fails miserably.

    Mind you, bringing that up at an interview would probably elicit nothing but blank stares. Human Resources people are such uninquisitive folk that I'd be surprised if they even read a book. Which is a shame, because they have almost no other visible skills, other than decent dress-sense and a nice set of pearly whites.

  • Kuba (unregistered) in reply to WhiskeyJack
    WhiskeyJack:
    PosterDude:
    I would introduce a house builder monad parameterized over a housing structure type. I'd be sure is was left adjoint to the foundation functor.

    Wow, you sound like some of the guys I work with.

    So, you work for INRIA, Microsoft Research or Jane Street? :)

  • Franz Kafka (unregistered) in reply to wilko
    wilko:
    Obviously the the house problem was to see if the candidate could write modular software, and handle interconnection or reorganisation.

    Rooms could be individual units, with wiring and plumbing that stack or be combined with each other to make larger rooms. Then you wrap it in a nice pleasing skin (like a UI?).

    If they wanted something modular, then they shouldn't be designing a house - houses aren't modular (unless they're trailers).

    By the way, reconfiguring plumbing without getting the results approved (every time) could land you in jail - connect waste to supply and you can poison a whole neighborhood.

    real_aardvark:
    I must be the only person here who immediately thought of Tracy Kidder's book "House." (Which I thoroughly recommend. Franz Kafka, are you still listening?)

    Heh, nice. Looks like a good read.

  • Kuba (unregistered) in reply to Franz Kafka
    Franz Kafka:
    wilko:
    Obviously the the house problem was to see if the candidate could write modular software, and handle interconnection or reorganisation.

    Rooms could be individual units, with wiring and plumbing that stack or be combined with each other to make larger rooms. Then you wrap it in a nice pleasing skin (like a UI?).

    If they wanted something modular, then they shouldn't be designing a house - houses aren't modular (unless they're trailers).

    By the way, reconfiguring plumbing without getting the results approved (every time) could land you in jail - connect waste to supply and you can poison a whole neighborhood.

    I call BS on that. Waste systems are usually unpressurized, and usually incompatible (pipe diameter and fitting-wise with supply lines). It'd take an idiot to confuse them.

    I presume that in most places they are not done like in the US. In the US sewer piping is often done to supply-standards (could in principle withstand supply pressures, if you'd plug everything), but in e.g. Poland, the waste piping is not designed to be pressurized, and most seals would probably leak like hell.

    If I were to directly attach a freshwater pipe to a waste pipe, all I'd get, in almost any place on the planet, is a huge waste of fresh water, and that's it. No cross-contamination due to relatively fast flow.

    Cheers, Kuba

  • C. F. Martin (unregistered) in reply to Tom

    Best comment ever

  • Brad B (unregistered)

    I had a previous boss use the house metaphor, I never understood the use a this. I know 100 times more about building software than construction, and I do my own plumbing and electrical. Metaphors are useful when they put the unfamiliar in familiar terms, and this does the exact opposite.

    A useful metaphor would be if I hired a carpenter to work on my house, and when I said I couldn't understand them, they explained as "It's like a C++ program..."

  • woohoo (unregistered) in reply to Easter Bunny
    Easter Bunny:
    woohoo:
    Easter Bunny:
    The purpose is to produce solid, dependable, stable applications. And anything that doesn't lead to this end result is a waste of effort. And I really don't see the connection between "brain-teasers" and programming.
    Flexible thinking. Thinking out-of-the-box. Dealing with the unexpected. etc etc ...

    shrug and "brain-teasers" will identify those people for you?

    At least the odds of identifying such people are higher with "brain teasers" than with questions directly referring to special technical/coding skills. Many of the existing good questions that do refer to special skills are "brain teasers" in their own right, only in the context of said skill.
    Easter Bunny:
    So someone who is good at what are effectively cocktail party games is who you want developing applications for you?
    I did not say anything about "cocktail party games". Of course there are lots of inadequate "brain teasers", but this holds equally true for all technical/special questions as well.
    Easter Bunny:
    Well then. Bring on the Pictionary!

    My negative view about these "brain-teasers" is that they're irritating, useless and frankly don't really show whether or not someone really is flexible or capable of thinking out of the box.

    And "technical" questions or small talk do that job better? C'mon...
    Easter Bunny:
    woohoo:
    Easter Bunny:
    IMO 99% of programming is having a good memory.
    WHAT? You must be a code monkey, no kidding...

    shrug I code. I architect. I really can't say I care overly much which. It's all enjoyable to me.

    Frankly there really isn't much new under the sun when it comes to business programming.

    woohoo:
    Software architects and good developers very much depend on different skills.

    Really? I have been in the business for a few decades so I do know the difference.

    A few? Aha, so you perhaps beat me here, it's only two decades for me ;o)
    Easter Bunny:
    Here's your choice:

    A. Architect, very creative but lousy memory

    B. Architect, not so creative but perfect memory

    If you take such pathological border cases like "lousy" and "perfect", you always can construct a case that makes your argument win. I care to disagree nevertheless. "Lousy" memory can be compensated with discipline in commenting and documentation. "Lousy" thinking (creativity is only one part of it) can not be compensated that easily...
    Easter Bunny:
    IMO "B" will win out every time. Why? Because a creative application or system is nice, but users want stability more than anything else and, IMO of course, someone with a perfect memory is less likely to create a monstrous pile of rubbish.
    That is complete nonsense... Every pile of (software)rubbish I have encountered was always the fault of people not knowing their stuff or thinking about the problem from wrong perspectives - never was bad memory the reason - or did "perfect memory" save anything, at that. I know more than one developer who is able to recite vast parts of the APIs in question, but creates complete garbage when coding. On the contrary, people with a less-than-perfect memory but good understanding tend to be *much* more disciplined when it comes to commenting and documentation, because they simply *have* to be.
    Easter Bunny:
    woohoo:
    No real skill that requires intelligence depends 99% on good memory. That's what we have documentation, lexicons etc. for.

    Yes we do. But if you can't keep this stuff in memory then what good are you? Particularly if you're having to deal with multiple systems in widely differing languages all of which have their own unique syntax and, more importantly, their own particular set of libraries.

    Even more important it is then to *understand* these systems and better know where to look for the information you need than knowing all of it (you never do that anyway...) by heart. With increasing complexity it is neither possible nor desirable to keep all the details (especially pertaining to libraries/APIs) in memory, because this informations change frequently anyway. And mind you, you were talking about "99% is memory" - I would not have reacted so strongly if you'd not have taken this absurdly extreme notion.
    Easter Bunny:

    Consider concatenating a string. Every damn language has its own particular style of concatenating a string. Every stupid SQL engine likewise. It's a silly example but if you are having to deal with legacy systems along with a host of other established systems in your application then being able to remember the specifics does frankly help.

    It does help, yes. But it does not make you a better developer/architect. Never. Most likely it makes you only a little faster than the other guy who has to look stuff up.
    Easter Bunny:
    woohoo:
    I refuse to remember the APIs of 3000+ classes, when it is much more important to have really absorbed the paradigms of OO.

    'Cause remembering the paradigms of OO are so hard?

    No offense but remembering the paradigms of OO isn't all that hard.

    You'd be right if I'd have said "remember the paradigms". I said "absorb the paradigms", which means not only remembering them, but most importantly *understanding* them and putting them to (correct!) use over and over again. It takes years to become a really good developer, good memory or not.
    Easter Bunny:
    woohoo:
    Unfortunately it is very often the other way round. Reminds me of the people that completed university physics exams by learning the complete book by heart without understanding anything, but perfectly replicating all derivations on request - often with better grades than the ones who tried to understand what they were doing... I would not count on the former to solve a *new* problem, though.

    Now you're introducing a strawman.

    I was only trying to illustrate the fact that knowing many (if not all) things by heart does not necessarily make you good in a certain field of knowledge.
    Easter Bunny:
    woohoo:
    David V. Corbin (whose attitude you criticised in your post) has it spot-on.

    shrug I disagree

    Of course you have every right to do so. Still, he had the better arguments ;o)
    Easter Bunny:
    woohoo:
    Easter Bunny:
    Personally the whole "brain-teasers" leave me flat.
    Well, *that* might be part of the problem... ;o)

    Not really. They simply bore me. When/if I encounter them in an interview I pretty much lose interest at that point. If they want someone experienced who can get the job done then they can stop fucking around with idiotic "brain-teasers" and actually present the problems they want to hire me to solve.

    Come on. You can't seriously present a real problem from a real system (apart from very simple or small ones) in an interview and expect to get meaningful information from that. Most importantly, you will never know if the interviewee will be able to adapt to new technologies and requirements which have nothing to do with the problem du jour...

    And programming skills are not everything, moreover. The times of monad wizards hacking together whole systems on their own is over - the new employee has to fit in your team structure and be able to work autonomously as well as closely with others and communicate the things he has accomplished.

    Easter Bunny:
    Seriously. You'd rather hire someone who gives reasonable answer for the "Rope Bridge" nonsense rather than someone who can jump right in on discussing the problem at hand and offer an intelligent discourse on what the issues are?
    Please show me where I said that the "Rope Bridge" is a good assessment tool? But assessing skills is more than asking for technical knowledge in a special field - you can do that additionally, yes, but it does not show you what kind of brain you are going to hire ;o)
  • Horace Finklemeyer (unregistered)

    "Um, I'll need 30% of the construction costs up front..." Holy cow, I wish software was like that!

  • olie (unregistered)

    While I follow that many people give crappy interviews, and your examples demonstrate some of this, "design me a house" (or, better, "let's design a house") is actually a fairly useful interview question.

    Brain teasers like "arrange 7 matches to form 8 equilateral triangles" tell you nothing about a candidate, but going through the preliminary design of something you both understand (a house, a car, a bridge, etc.) does.

    Similarly, "how would you determine how much a 747 weighs" is a crappy question, while "how much would you guess a 747 weighs?" is a useful one (demonstrates back-of-envelope estimation skills, which are useful on the job.) The variant I use is "how many chairs do you suppose there are in San Jose?" (hint, if needed: "there are about 1 million people") or "how much do we think this office building weighs?"

    Joel (you DO read Joel, right?! #1 interview question for coders: "so, what do you think about Joel?" :) does a good bit on this subject, and how to do it right and how to screw it up. Search "guerilla interviewing guide."

    Anyway, put me down as a fan of "interview questions like that", but only if done well.

  • tom (unregistered)

    Clearly you should have just given him a HouseBuilderFactory.

  • fuggo (unregistered) in reply to evilghost

    are there any leans against your property?

    It's "liens". No job for you.

  • (cs) in reply to fuggo
    fuggo:
    are there any leans against your property?

    It's "liens". No job for you.

    You don't know that. Ask for context. He might be talking about a lean-to shelter.

  • Ethan Patchouli Frumparino (unregistered) in reply to Zylon

    Don't call people losers, especially when they aren't clearly losers. It's not nice.

    I noticed that others also didn't instantly nail the source of the quote, though it sounded familiar. And Blade Runner is one of my favourite movies, ever.

    Only losers call other people losers. Trix are for kids.

  • (cs) in reply to Tim

    Septic field. Pssh. First off, I would tell him that it's going to cost about 700,000 Dollars after buying the land and that he won't be able to build in a tornado/hurricane/earthquake area because as a German I don't believe in the garden shacks Americans call houses and building codes in such areas might forbid a German-style house. The house would neccessarily have...

    • a paved basement (cellar optional)
    • aerated autoclave concrete outer walls with a brick or plaster facade
    • double glazing in all windows
    • mineral wool under the roof
    • a direct connection to the city's sewer system (none of that barbaric leach field nonsense)
    • a construction time of several months

    Of course, that only applies if he doesn't want a zero-emission home. There's also a lot of further neccessary questions:

    • How much emissions are tolerable?
    • Would a grass roof be acceptable? How about building the house into a hill?
    • What's his electricity provider's policy on buying back excess electricity (affects whether or not to add solar panels to the roof)?
    • Central vacuum cleaner or not?
    • Should the heating unit use electricity, natural gas, oil or wood pellets? Is district heating available? Would a solar hot water panel be feasible? How does he feel about a co-generation unit?

    Just because it's a brain teaser question doesn't mean you don't have to apply best practices and carefully plan everything. If he doesn't want to think about that he shouldn't build a house.

    On the other hand, applying software design patterns might be fun, too.

    "Following an agile process, we'll build the living room first and then add more rooms as neccessary." "You don't get a house per se, but a house factory. Whenever you feel the need to go home, you call the factory and request them to contruct a house instance. Once you leave your property, the house will go out of scope and be destroyed. I advise against storing personal belongings in your house." "A persistence framework will be added in a later release and require a database server and offsite storage for copies of your belongings. References to these copies will be created when your new house instance is delivered by the factory." "We will construct three identical houses; one for development, one for deployment testing and one for production use. Please make sure your lot is big enough for all three of them." "Following the Singleton pattern, we will construct one house which will be shared by the entire town." "The house will be made available after a three-month testing period. However, if construction starts late in the year, we might skip testing and part of the implementation in order to deliver in time for the Christmas rush." "By entering your house you agree to the EULA you will find in the living room." "THIS BUILDING IS PROVIDED 'AS IS' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE."

  • Isn't the whole schtick of this question... (unregistered) in reply to Tim

    ...to get you to realize that it's supposed to be a dog house, and that all these assumptions for a house for a human are just assumptions?

    I've gotten that one, at any rate, and if I'm ever asked to design a house for an interview, I'll start by asking "is this the one where the punchline is 'it's a dog house?'"

    See also some of the famous Microsoft questions, like "why are manhole covers round?"

Leave a comment on “Design Me A House”

Log In or post as a guest

Replying to comment #189456:

« Return to Article