I have fond memories of hiring someone once who sounded great in the interview. He could talk about all the latest technologies and techniques. My only fear was that he would be upstaging

real_aardvark · 2008-04-13 Reply Admin

j6cubic:
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."

I am now going to spend the rest of the week-end memorising this, so that I can use it in my next job interview.

A small correction: YAGNI implies that you build the lavatory first. Useful things, lavatories. Aside from the basic function, you can also "shower" in them, read in them, phone from them, and, indeed, live in them. I haven't got around to cooking in them yet, and I suspect that eating in them should be done in strictly regimented shifts, but no, you ain't gonna need no living room. (Whatever Adolf said.)

2008-04-13 Reply Admin

Anon Fred:
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.

shrug I guess we just disagree.

2008-04-13 Reply Admin

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

Frankly my answer would be:

Spend 5 minutes finding a ravenous carnivorous predator, lead it to bridge, cross the bridge.

Anybody not willing to step on up and cross that bridge in a jiffy, no longer a problem.

2008-04-13 Reply Admin

woohoo:
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.

But there's no objective evidence that your point is at all correct. You're assuming that the odds are greater when asking brain-teasers. But there's nothing underpinning that assumption.

Considering the mental requirements of being a software developer today, which is certainly made much more complicated than 20 years ago when all you needed to know was RPG or Cobol, isn't it entirely possible that the brain-teasers are completely superfluous? That all candidates would be effective in the job regardless of how well they do on the brain-teaser?

woohoo:
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.

No you didn't. I did. Why? Because these brain-teasers are entirely of the kind that do come up in cocktail parties.

Then again perhaps I need to stop associating with engineers in my off time.

woohoo:
And "technical" questions or small talk do that job better? C'mon...

I think so. If I can describe the project or task in one single sentence spanning no more than say 25 words and the candidate can outline what's needed to complete the project and any significant issues that might arise, then I'd say that person has a pretty good grasp on things.

woohoo:
A few? Aha, so you perhaps beat me here, it's only two decades for me ;o)

shrug I started at age 13. Doesn't mean all that much since nobody has needed a Z-80 assembly programmer pretty much since then.

The real funny thing is that now for some reason I'm kinda jonesing for an old TRS-80 so I can go back and goof around with Z-80 assembly. A trip down memory lane I guess.

woohoo:
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...

I used extreme examples in order for there to actually be a choice. Otherwise what would the examples be? "Decently creative and a reasonable memory" for both?

You're looking at the wrong end of the process. You're assuming the memory issues would come up post-production. My point is that memory issues would come up pre-production and during production.

Here's a test for you. For one single week look up each and every single class, property and method that you use.

I think you'd be rather amazed at just how much you absolutely depend on your memory.

woohoo:
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.

You've never run into an example where the programmer forgot about an interface? Forgot to include a component? An analyst or architect who left out a significant portion of a design? You've never run into a situation where the developer came up with some goofy solution where a library call would've done it faster?

woohoo:
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.

shrug but you will only look for the information if you remember that you need it and why you need it. And by the by "understanding" also implies memory.

Yes libraries/APIs do change, but not that frequently. Standardizing on a specific version is pretty common so it's not that rare for older software versions to remain in use for years because the quirks are well known.

It's absurd to you but IMO it's what I've seen over the years. Like I pointed out before. Test yourself for a week.

woohoo:
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.

No having to always refer back to documentation will cripple you.

woohoo:
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.

Sorry but OO paradigm isn't exactly the hardest thing to "absorb". Really you're assigning a mountain to the default property of a molehill.

woohoo:
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.

It's true that knowledge doesn't necessarily imply skill. But you simply cannot have skill without knowledge.

So we come back around to memory again.

woohoo:
Of course you have every right to do so. Still, he had the better arguments ;o)

Not really. He didn't offer any objective evidence that using brain-teaser questions actually resulted in anything useful. That he ended up with decent candidates, I assume, could have resulted entirely in that his entire cast of potential candidates were all capable. And that his use of brain-teasers amounted to little more than eeny-meeny-miny-moe.

woohoo:
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.

I can, and have. If you know your stuff then you should be able to as well. shrug it's the difference between being an expert or a bullshit artist. Professionally experienced or merely a resume padder.

Have you really encountered people who simply could not adapt to new tech or situations? Sure there's a ... calcification process that happens to some developers when they age to where they simply refuse to learn new tech. But how often does that come up?

And with very few exceptions most modern tech is based on earlier examples. Not totally revolutionary but rather evolutionary. Have you seriously encountered experienced programmers, who haven't hit the point where they're contemplating retirement, who simply could not "absorb" OO? Web tech? .NET? Java?

Are you telling me that you've found individuals who couldn't grasp XML? Frankly I find that hard to believe.

... As for the working within a team and communicating, that discussion is outside the parameters of this one.

woohoo:
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)

If Rope Bridge isn't your cup of tea then point out which silly brain-teaser you'd prefer. And yes, I do think they're silly.

2008-04-13 Reply Admin

Isn't the whole schtick of this question...:
... See also some of the famous Microsoft questions, like "why are manhole covers round?"

They're not. There are triangular and square manhole covers.

2008-04-14 Reply Admin

Easter Bunny:
woohoo:
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.

But there's no objective evidence that your point is at all correct. You're assuming that the odds are greater when asking brain-teasers. But there's nothing underpinning that assumption.

About as much as objective evidence as there is for your point (i.e. the opposite), but I can at least say from personal experience that people who are flexible and sharp thinkers tend to score much better at questions like this. Do you really have different experiences? Frankly, I'm surprised.

Easter Bunny:
Considering the mental requirements of being a software developer today, which is certainly made much more complicated than 20 years ago when all you needed to know was RPG or Cobol, isn't it entirely possible that the brain-teasers are completely superfluous? That all candidates would be effective in the job regardless of how well they do on the brain-teaser?

Au contraire! Right because of the increasing complexities we need flexible and creative minds, not code monkeys.

Easter Bunny:

woohoo:
And "technical" questions or small talk do that job better? C'mon...

I think so. If I can describe the project or task in one single sentence spanning no more than say 25 words and the candidate can outline what's needed to complete the project and any significant issues that might arise, then I'd say that person has a pretty good grasp on things.

I don't know what size your typical projects are, but if they should be the size I'm talking about (and where we do need the good devs, not just code monkeys) then you have nailed down a genius if he can name "what's needed to complete the project and any significant issues that might arise" after a 25 word sentence about said project. Congrats! ;o)

Easter Bunny:
*shrug* I started at age 13. Doesn't mean all that much since nobody has needed a Z-80 assembly programmer pretty much since then.

You said something about "a few decades in the industry". When we count from the start, it's easily 3 decades for me as well, I started a little younger ;o)

Easter Bunny:

woohoo:
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...

I used extreme examples in order for there to actually be a choice. Otherwise what would the examples be? "Decently creative and a reasonable memory" for both?

I wasn't making up the corner cases ;o) Again: You were saying "99% memory" - I never doubted that a good or even decent memory does not help. But the best memory in the world does not even out deficiencies in other and IMO a lot more important areas, which make up much more than 50% of the whole package you need to be a good dev/technician/lead/architect/whatever.

Easter Bunny:

You're looking at the wrong end of the process. You're assuming the memory issues would come up post-production. My point is that memory issues would come up pre-production and during production.

It is not an issue at all provided that you do not have a pathological memory disorder ;o) and have strict discipline in commenting and documentation if you know that you are not exactly a memory artist.

Easter Bunny:
Here's a test for you. For one single week look up each and every single class, property and method that you use.

You are again constructing corner cases. You assume that "programming is 99% memory" and you obviously assume that I think a good or decent memory does not matter at all. I did not do that. I said that a bad memory is much easier to overcome than a lack in your "1%" (whatever you meant that 1% to be). I'd give "good memory" perhaps a 15% relevance, if you do want a number at all cost.

Easter Bunny:
I think you'd be rather amazed at just how much you absolutely depend on your memory.

My memory for names is in fact lousy compared to others I know. None of them is particularily a genius in his field (IT and non-IT), though - not because of their memory, at least. And I know real wizards in their respective field who have average memory at best (also IT and non-IT).

Easter Bunny:

woohoo:
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.

You've never run into an example where the programmer forgot about an interface? Forgot to include a component?

So what? Errare humanum est...

Easter Bunny:
An analyst or architect who left out a significant portion of a design?

Not because of "bad memory", no. But definitely because of a lack of understanding, though they knew the requirement documents nearly word by word (in one specific example)...

Easter Bunny:
You've never run into a situation where the developer came up with some goofy solution where a library call would've done it faster?

Oh yes. Frequently. But what does *that* have to do with good memory?? Most of the time the dev in question never cared to RTFM in the first place. Perhaps he would have remember it with his great memory, yes, if he had ever known it...

Easter Bunny:

woohoo:
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.

shrug but you will only look for the information if you remember that you need it and why you need it. And by the by "understanding" also implies memory.

Why, yes. *Normal* memory. As everyone has it who did not get a knock on his head recently. Still this does not make "good memory" your "99%" necessity for a good developer.

Easter Bunny:
Yes libraries/APIs do change, but not that frequently. Standardizing on a specific version is pretty common so it's not that rare for older software versions to remain in use for years because the quirks are well known.

Yes, just like the whole industry is not changing frequently, right? ;o) Yeah, I know, we still do need some PL/I and COBOL devs, but come on, the rest of us is moving fast... It might be that I have different experiences, because I think I have already *forgotten* around 15 past programming languages ;o) apart from the 5 I'm using more or less frequently right now (not counting markup languages and related technologies like stylesheets etc).

Easter Bunny:

It's absurd to you but IMO it's what I've seen over the years. Like I pointed out before. Test yourself for a week.

Ah well... I obviously do have have different experiences.

Easter Bunny:

woohoo:
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.

No having to always refer back to documentation will cripple you.

Sorry, but this is just nonsense... and as I said, I'm talking of *normal* usage of documentation, not again pathological corner cases like looking up very single method.

Easter Bunny:

woohoo:
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.

Sorry but OO paradigm isn't exactly the hardest thing to "absorb".

Ha ha ha ha... that was a good one ;o) I really wish that was true, because then it would not be so hard to find really good people and not the usual ones who do not know half their bit - good memory or not.

Easter Bunny:
Really you're assigning a mountain to the default property of a molehill.

Hm? I'm sorry, english is not my first language and I'm afraid I do not get that one... ;o)

Easter Bunny:

woohoo:
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.

It's true that knowledge doesn't necessarily imply skill. But you simply cannot have skill without knowledge.

True indeed. Still that does not support in the least your point of "programming is 99% memory".

Knowledge != just remembering stuff well ...

Easter Bunny:
So we come back around to memory again.

I'm repeating myself: Knowledge != just remembering stuff well

Easter Bunny:

woohoo:
Of course you have every right to do so. Still, he had the better arguments ;o)

Not really. He didn't offer any objective evidence that using brain-teaser questions actually resulted in anything useful.

He offered his professional experience. And I read his other posts, which IMO indicated a very professional attitude and profound understanding.

And you did not have any more objective evidence, at that.

Easter Bunny:

woohoo:
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.

I can, and have. If you know your stuff then you should be able to as well. shrug it's the difference between being an expert or a bullshit artist. Professionally experienced or merely a resume padder.

Now you're getting personal, hm? I know that I *do* know my stuff - and I know that the systems I'm working on definitely do not have many parts that can be used as quick interview questions easily. And if they do, questions of similar complexity (which are not part of the system) can be made up easily. And that of course does say something about the interwievee, but not enough - you did e.g. not go into my points about the prospective employee being able to fit into the team, being able to adapt to new exigencies, and all sorts of other skills which are not discovered by "programming questions".

Easter Bunny:
Have you really encountered people who simply could not adapt to new tech or situations?

Are you serious? Where do you live, next door to the mensa club?

Easter Bunny:
Sure there's a ... calcification process that happens to some developers when they age to where they simply refuse to learn new tech. But how often does that come up?

It's not only about refusing to learn something. Many people are simply not cut out for certain jobs, but the industry is "cool" and demands lots of manpower, so you do not only get the ones who are.

Easter Bunny:
And with very few exceptions most modern tech is based on earlier examples. Not totally revolutionary but rather evolutionary.

But if you didn't get the first step of the evolution, you're not likely to get the following steps. And if I had one dollar for everyone who says something to the effect of "dunno what we need all this newfangled stuff for, my familiar language/technology/skill is much better anyway...", I'd have resorted to my own tropical island by now... ;o)

Easter Bunny:
Have you seriously encountered experienced programmers, who haven't hit the point where they're contemplating retirement, who simply could not "absorb" OO? Web tech? .NET? Java?

You haven't? Luxury... But perhaps it is because I'm also in the teaching business, and therefore I know that it is not so easy for many to grasp concepts which seem easy if you started with 13 years of age (or 10, at that).

Easter Bunny:
Are you telling me that you've found individuals who couldn't grasp XML? Frankly I find that hard to believe.

Frankly I find it hard to believe that you haven't - I'm constantly meeting people who think of XML (and HTML...) as programming languages - and that's how their markup looks. Or the other way round...

Easter Bunny:
... As for the working within a team and communicating, that discussion is outside the parameters of this one.

Definitely not. We are discussing the eligibility of non-technical questions for candidate assessment - at least I am ;o) And I do not want to hire secluded looney coding whizz kids, because there is no use for such outside of kernel hacking or similar fields.

2008-04-15 Reply Admin

The house analogy with software is complete bullshit, and I just want to stop hearing about it. A house is a real-world physical object. Yes, you can do some work to it, but over time it remains what it is - a house. The whole point of software, and why it is so difficult to work with, is that you are modelling real world objects in software so you can come up with all sorts of hypothetical scenarios that are impossible in the real world, but are mighty useful. For example, you might have a system for keeping track of three bedroom detached houses, but your construction company only starts building bungalows. You won't turn all of the three bedroom detached houses into bungalows, but you will change your software to handle bungalows.

2008-04-15 Reply Admin

woohoo:
About as much as objective evidence as there is for your point (i.e. the opposite), but I can at least say from personal experience that people who are flexible and sharp thinkers tend to score much better at questions like this.

The problem is, you want flexible and sharp thinkers who can react to real world problems that you have right now. The real sharp thinkers ask themselves the root question "What is the point of this and why are we doing it?" The bullshitters who go through convoluted explanations for scenarios that don't exist will code in exactly that manner when you hire them.

The best programmers and developers in software are lazy, and will first ask themselves "What is the point of this, and why are we spending time, effort and money on it?" Why not use a real-world software problem that you actually have, rather than using crappy subterfuge that is bound to end in failure?

Do you really have different experiences? Frankly, I'm surprised.

How does bankruptcy feel?

Au contraire! Right because of the increasing complexities we need flexible and creative minds, not code monkeys.

You won't even get code monkeys using this brainteaser method. Why? Because you're not testing their coding skills either! That situation is even worse.

Frankly I find it hard to believe that you haven't - I'm constantly meeting people who think of XML (and HTML...) as programming languages - and that's how their markup looks.

That sentence alone tells me that you're surrounding yourself with, and recruiting, totally the wrong people.

And I do not want to hire secluded looney coding whizz kids, because there is no use for such outside of kernel hacking or similar fields.

That tells me that you really are hiring the wrong people, and being taken for a ride. While you want 'developers' who can contribute a lot beyond simple code (and logically, to do that they have to understand what's involved in coding), if you don't test peoples' ability to actually write code and answer questions around it then you will get bad systems. It's as simple as.

2008-04-15 Reply Admin

woohoo:
We are discussing the eligibility of non-technical questions for candidate assessment - at least I am ;o)

When interviewing for a technical discipline, technical competence is a pre-requisite before anything else.

And I do not want to hire secluded looney coding whizz kids, because there is no use for such outside of kernel hacking or similar fields.

Incidentally, I've seen managers come out with sentences exactly like that as an attempt to cover up for their own lack of technical knowledge and competence, and to avoid being shown up and embarrassed for who they really are at a later date. That's usually the root reason why these kinds of idiotic questions get asked at interviews (they're developed for dumb recruitment agencies as well). If you don't understand what's fundamentally required in the job you are interviewing for it's certainly feasible that you shouldn't be interviewing, and possibly should be in the position that you're in.

No one is talking about hiring lone coders. Whatever, what is required is a level of technical competence that you have to talk about in an interview as a pre-requisite. You can easily do that by asking them about past projects, the problems they had, the problems they solved etc. You know, relevant stuff?

2008-04-15 Reply Admin

err... is it just me or is everyone missing the point with the house?

surely what the interviewer is getting at is the need for a spec & the ability to deal with clients that keep changing their mind?

real_aardvark · 2008-04-15 Reply Admin

woohoo:
Easter Bunny:
<snip/>
So what? Errare humanum est...

... perseverare diabolicum.

Ring any bells? Personally, I wouldn't hire either one of you; no matter how old and experienced you might be.

Want to kiss and make up?

Earl Purple · 2008-04-15 Reply Admin

This didn't end up as another brainteasers topic although quite a few made their way back here. No "hats" brainteaser, so how about this, a variation of last years:

In last year's, you had 3 contestants, actually working as a team, each of whom would be given a hat, picked at random by a toss of a fair coin. Nobody would be able to see the colour of their own hat but would be able to see the colours of the others hats. They could discuss a prior strategy but once they are given their hats there is no communication allowed. They must simultaneously (i.e. without knowing how the others will answer) choose to either guess the colour of their hat or pass. They all win a share of the money if none of them give an incorrect answer and at least one of them gives a correct answer.

Suppose we change the rules so that all of them must make a guess. And all 3 must be right to win the prize. Once again their guess is simultaneous (i.e. they cannot know how the others have guessed) and there is no communication of any kind, in fact let's assume they do not even see each other, they just know the colours of the others hats.

Now please pick their best prior strategy.

I'll give you a hint: with a picked strategy they get a lot better odds than 1/8, though not as good as 3/4 we had in the first rules where they were allowed to pass. (If you don't believe it's 3/4, go and find the other comments by following the link from this one).

2008-04-16 Reply Admin

Actually David's initial question was the correct one: "what do you want your house to look like?". This gets a conversation going with the customer where he imparts what basic design ideas he has on what he wants.

After that, you ask specific questions like 'how many floors' to firm up the design.

2008-04-16 Reply Admin

Jon B:
After we finish designing the house, we'll figure out that it's way over budget and won't be ready until years after we need it. We'll suggest building a smaller house (limiting scope), but that won't go over well. So we'll decide to ignore best practices (building code), exception handling (smoke alarms), and security (door and window locks). We'll even farm much of the work out to low-cost, offshore workers. When it's still not done in time, we'll just go ahead and have the owner move in anway (who needs drywall and flooring) - we'll call it a beta.
Did I pass?

Aaaah! you should surely get a job at MS.. that's the way they work i guess!!

2008-04-16 Reply Admin

If you ask these questions then you've probably got the "answer" right as you've not started your design with a bunch of implicit assumptions.

DrCode · 2008-04-18 Reply Admin

Michael:
Anon Fred:
Sanity:
The rope bridge one took all of two seconds of thought to realize that you just go yourself (you're the fast guy) and ferry everyone across.

You might want to give a few more seconds of thought.

His method takes 19 minutes, you have a better one?

A=1 B=2 C=5 D=10

So they go:

AD -> 10 min A <- 1 min AC -> 5 min A <- 1 min AB -> 2 min

This may be the most unintentionally funny comment I've ever seen on this site, especially considering that in the original problem, the requirement was that you only have 17 minutes.

The correct answer, if you're the fast guy, is you just go across yourself, then wave at the others, shout, "You're all gonna die, suckers!", throw the light into the gorge, and run off.

2008-04-21 Reply Admin

real_aardvark:
woohoo:
Easter Bunny:
<snip/>
So what? Errare humanum est...
... perseverare diabolicum.
Ring any bells? Personally, I wouldn't hire either one of you; no matter how old and experienced you might be.

Want to kiss and make up?

Yeah right. I know latin too. But you obviously did not understand Seneca. The rest of his citation does not mean that one should not stand up for her or his opinion.

But, I'm sorry, of course you are the only one really in the know, aren't you?

It is easy to discard other people's viewpoints or judge them apodictically. But this does not really indicate that it'd be a great idea to hire you to work on a team, especially in a leading position.

kiss ;-)

2008-04-22 Reply Admin

A skilled interviewer can probably tell a lot about the candidate by asking them anything that gets them talking. The interviewer in the story was clearly not in that category, though, and just kept plowing through his clever little puzzle-question script even though the candidate was uninterested to the point of wanting to leave the interview.

Earl Purple:
Suppose we change the rules so that all of them must make a guess. And all 3 must be right to win the prize.

They have 1/4 odds if they guess that all the hats are the same color. I haven't thought of a better strategy than that.

real_aardvark · 2008-04-26 Reply Admin

woohoo:
real_aardvark:
woohoo:
Easter Bunny:
<snip/>
So what? Errare humanum est...
... perseverare diabolicum.
Ring any bells? Personally, I wouldn't hire either one of you; no matter how old and experienced you might be.

Want to kiss and make up?

Yeah right. I know latin too. But you obviously did not understand Seneca. The rest of his citation does not mean that one should not stand up for her or his opinion.

But, I'm sorry, of course you are the only one really in the know, aren't you?

It is easy to discard other people's viewpoints or judge them apodictically. But this does not really indicate that it'd be a great idea to hire you to work on a team, especially in a leading position.

kiss ;-)

I was not aware that I was either discarding your viewpoint or making a judgement based on logical certainty -- which I hazily recall is your premise through the use of "apodictically."

I don't know Latin, as it happens. I hate the language. Insofar as I understand Seneca the Younger's point here, it isn't a question of standing up for your opinion as much as it is a question of admitting to your mistakes. Translate the relevant wisdom into, say, Ancient Greek or Swedish, and I might have a better handle on it.

In the mean time, I'll go for "Cuiusvis est errare, nullius nisi insipientis in error persevare." The same point, but a little more humane, I think (although I'd not normally use the word "humane" in connection with Cicero).

You'll be relieved to know that I am extremely unlikely to waste your time by applying for a position on your team, leading or otherwise. I don't think we'll be kissing any time soon, either ... although the original comment was clearly intended to mean that you should kiss Easter Bunny. Which is a pretty frightening thought in and of itself.

Mainly, I was just complaining about the several screen-fulls of crap you two were putting out. Don't get me wrong. Each individual thought is a pure gem, sparkling in the moonlight. Taken together, repeatedly, several times, without editing, they're just fucking annoying.

I'm not interested in bossing people around. I'm not really that interested in vacuous fragments of philosophy. Just to quote an apposite one from Gorgias, however:

جلوبة التخلف والدين والظلا

2008-05-09 Reply Admin

I had a boss just like this. He would add stuff to my resume and not even tell me. He would give me college degrees I didn't earn, experience I don't have, and projects I didn't write. It was so humiliating when I'd tell the interviewer that the particular piece of information was erroneous. I even got yelled at because I "made him look like a liar". I suffered through what I had to get some experience and left.

2008-05-14 Reply Admin

Here here! :)

Anytime. :)

They'll all tell you the same thing: I'm a freak (I talk to myself when I work), my best ideas come while I'm on the pot, and I can't think worth a damn if I'm not sitting on my ass. ;)

2008-05-14 Reply Admin

You know what's really funny though. The day this article came out, I had an interview with another company. The guy who interviewed me had read this article earlier that morning, so we had a good laugh during the interview. Small world. :)

2008-06-05 Reply Admin

Jon B:
After we finish designing the house, we'll figure out that it's way over budget and won't be ready until years after we need it. We'll suggest building a smaller house (limiting scope), but that won't go over well. So we'll decide to ignore best practices (building code), exception handling (smoke alarms), and security (door and window locks). We'll even farm much of the work out to low-cost, offshore workers. When it's still not done in time, we'll just go ahead and have the owner move in anway (who needs drywall and flooring) - we'll call it a beta.
Did I pass?

Hi, its Steve Ballmer from Microsoft here. You sound perfect for a role in our company!

2008-09-18 Reply Admin

DeLos:
Herr Killjoy:
Okay, time to be a German grammar and spelling nazi. (Would there really be any other kind?)
Guten Tag.

One 't', and both words capitalized.

Make this a featured comment. We've already got two more people chiming in.

btw - did you know it should be "Guten Tag"?

Nazi should also be capitalised in this context as it is being used a noun :p

2008-09-27 Reply Admin

class House { public : House(int nFloor, int nWindow, int nDoor, /* snip */);

// snip

private : int nbFloor; int nbWindow; int nbDoor; // snip };

Captcha : saluto Hello! How do you feel?

muthu22 · 2009-01-18 Reply Admin

I’m actually not a big fan of the navigation bar at the top of the page. Perhaps I’m biased towards a sidebar, but I think that there is too much going on at the top, too much text to choose from. If those 20 options could be condensed somehow or integrated into some kind of app, it seems to me the whole design would be easier to look at.

Muthu

MLS

swansi · 2009-01-31 Reply Admin

I have fond memories of hiring someone once who sounded great in the interview. He could talk about all the latest technologies and techniques. My only fear was that he would be upstaging

swansi

visit

Flat Fee MLS

swansi · 2009-01-31 Reply Admin

.hello I like football game. But I don't know the game rules. When whose any one playing foot ball i will watch very interestly. I knew some things about foot ball that is in game must want patient, hard work, concentrate.

swansi

visit Flat Fee MLS

2009-02-04 Reply Admin

Hi, I would suggest you to navigate about this one, on internet. There is lots of information available on this. CSK Flat Fee MLS

2012-11-14 Reply Admin

I actually just got asked this question last week and I still fail to see what it has to do with a Business Analyst position. Metaphors or not I don't see the relevance. They are not testing programming skills, they are not testing, problem solving skills because you can just make up pure BS and feed it to them. Are they looking for a BS artist? and how discriminating is this question to a young person who may be coming out of college that knows nothing about "building a house", permits etc. I did know quite a bit about the house building process but I still don't think I got the job..so what the bleep! Note: That was the only interview question.

Design Me A House

I have fond memories of hiring someone once who sounded great in the interview. He could talk about all the latest technologies and techniques. My only fear was that he would be upstaging

.hello I like football game. But I don't know the game rules. When whose any one playing foot ball i will watch very interestly. I knew some things about foot ball that is in game must want patient, hard work, concentrate.

Leave a comment on “Design Me A House”