I was incredulous when I read this observation from Reginald Braithwaite:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
I was incredulous when I read this observation from Reginald Braithwaite:
Notice from @riking:
Please put all solutions to FizzBuzz âhereâ instead of in this topic. Alternately, donât do it at all - weâve clearly had enough proof that itâs possible.
(Existing comments from before Discourse containing only solutions were moved there.)
*The original post by @Toepopper follows. *
Very very common, alas. I once interviewed a candidate for a VBA job (yes, you can stop booing for the peanut gallery) whom I asked to swap two variable contents without using a temp variable. Itâs the standard a=a+b, b=a-b, a=a-b problem. His answer? Well, I canât do it in VBA, but if you let me use Excel I can put the values in two cells and swap the cellsâ contents using a third cell.
We hired the guy who said, well, âif theyâre integers, then Iâd do it by a=a|b, b=a^b, a=a^b. But I donât know how to do it if theyâre strings.â
Iâve been making a decent living from programming for over ten years, and if I may say so, I write some damn good code.
However, I have never once used - or had call to use - recursion to solve a problem, since I learned about it at university. Does this make me a bad programmer? Or is it simply that people program in different ways for different problem spheres?
I simply canât believe that the other 199 people tested who canât write a simple forâŚloop have no career as some kind of programmer ahead of them.
Does that mean that every one of those people who do program but donât use (say) recursion is a bad programmer?
Or is it that you canât rely on any one testing method (like writing simple programs) to prove either way that the person can program effectivley or not?
The most obvious way to decide - for me - is to run through these tests, emply the person you like the best and then look at the code theyâve produced after a week. Then youâll know if they can do what you need.
The bottom line is, you can always learn to pass interview tests of any kind - that doesnât mean you can program or not.
I think the use of recursion probably depends on the particular field that you code in.
As a web developer I also have very little cause to use it. The only time I use it is when I need to search through the file system.
Isnât the code for that âŚ
int main() { ExitPaperBag(); return 0; }
Iâm not sure ⌠copied it from somewhere
Thereâs a cynical voice in my head that says âbecause no-one has ever asked them toâ.
Where I work we spend a long time looking before we hire someone, because itâs so hard to find them. We use a walk-through test that has a sequence of âquestionsâ leading to a simple app and are willing to argue the toss (I was hired despite arguing that the test had significant flaws: âwhy would I do that? Thatâs stupid becauseâŚâ when they wanted me to code a solution that led to the next question).
I fear that any take-home or pre-interview component would lead to plagarism or âhelpedâ solutions, so we make candidates perform in front of us.
Thatâs got our ratio up to 3/4 good hires.
shenpen - Unfortunately that wouldnât be a valid solution (in VBScript) because WScript.echo adds a CRLF. In another language it might work though.
Sorry, but if someone were to ask me how to swap two variables w/o a temp variable Iâd ask them to give me a good reason why.
Not being able to answer that particular question certainly doesnât preclude someone from being a good programmer. Thatâd be like asking a C# programmer how to do modulo 16 using only a logical and. Why the hell would they need to know that, and how does that help you determine that they understand the ASP.Net framework, etc.?
shenpen: As you point out, your solution doesnât handle line breaks. It also doesnât print out the original number!
shenpen, for shame. Read the spec again.
I donât think Iâve ever interviewed a programmer quite that bad, but I did have a conversation with a contractor I was replacing once: Iâd introduced a class into the monster spreadsheet heâd been maintaining and he looked at it and remarked âI wish I knew how to do thatâ. He was picking up about GBP400 a day (call it about $650 at that time) for this.
As Iâm about to start looking for a programmer I shall be able to implement my long-cherished plan of asking candidates to submit a page or so of what they consider to be âgood codeâ. I donât mind if they wrote it or not, I want to see if we agree on the look of âgoodnessâ. If we get that far, I can find out if we agree on why itâs good.
This is nasty but itâs technically a one-liner:
1.upto(100) { |n| puts n % 3 == 0 ? n % 5 == 0 ? âfizzbuzzâ : âbuzzâ : n % 5 == 0 ? âfizzâ : n }
WOW! (and not the vista kind).
I canât believe there are people out there applying for jobs in software that cannot write a fizzbuzz program.
Itâs true that knowing how to do modulo 16 using AND doesnât relate to understanding ASP.Net.
On the other hand, do you want an ASP.Net technician, or someone who understands the theory behind it? Can you really call the candidate who only knows ASP.Net, but nothing about a basic logic a programmer (or a computer scientist, or a software engineer, or a coder), or is he just some guy who knows ASP.Net?
James: itâs amusing to me that any reference to a programming problem-- in this case, FizzBuzz-- immediately prompts developers to feverishly begin posting solutions.
The whole point of the article is about WHY we have to ask people to write FizzBuzz. The mechanical part of writing and solving FizzBuzz is irrelevant.
Any programmer who cares enough to read programming blogs is already far beyond such a simple problem. Itâs the ones we canât rerach-- the programmers who donât read anything-- that we have to give the FizzBuzz test to.
But itâs OK, I mean no offense. Itâs just funny. I know how software developersâ minds work.
My point is that what youâre asking for isnât âdomain knowledgeâ strictly speaking. Using an XOR to swap two variables w/o a temp variable is only really useful when memory is expensive (embedded programming, et al). If youâre not interviewing for an embedded programmer why are you worried about it?
Same with the modulo trick. The first time I ever encountered that I was writing a Perlin Noise Generator based off of someone elseâs work. Outside of routines that need to be highly optimized thereâs no reason for it.
Are you trying to hire an ASP.Net programmer or an embedded systems programmer? Granted, the XOR trick is pretty well known, but not knowing it off the top of your head says nothing about your abilities as a programmer (whereas the fizzbuzz example does).
No one can know everything. I would expect that type of attitude from a non-IT person, but not someone who is interviewing programmers.
Ha ha! I see what youâre saying Jeff.
I hope I didnât come across as feverish though. I sincerely thought that a solution may be of interest to someone who couldnât write one themselves.
Perhaps you have readers who aspire to be programmers but are still learning?
Perhaps a future Google search for âFizzBuzzâ will bring back this page? (And the Googler might be after the solution).
Interestingly, the use of a technical test in interviews can actually work both ways. In my recent hunt for a new job I automatically turned down any vacancy where I was not given a technical test. My reasoning behind that is that I know I can program, but do I want to work with other programmers who havenât been tested?
The harder the test I was given, the more excited I was about the vacancy.
If anyone out there is looking for a new job I urge you to bear that in mind.
Instead of using recursion, itâs often faster to use a Stack.
Thereâs always âSurvivor for Developersâ for those who donât make the cut.
http://techtalkblogs.com/blog/archive/2007/01/26/1837.aspx
I once heard of a development group where every three months a vote was taken and the bottom ten percent of the group were replaced by newcomers. It sounded a bit like Survivor - Development.
A common immediate reaction is to assume that it would become a popularity contest but that wasnât the case. The group had very specific KPIâs to achieve and those that helped achieve those goals were well respected in the group, regardless of âpopularityâ. Really anti-social folk tended to get removed though. (In our company, one of the tests we use during the hiring phase is lovingly called the âno axe murderersâ test. I think we have Chris Hewitt to thank for that awesome terminology.)
When working as a manager, I always felt that Australian laws made it very difficult to remove the dead-wood out of teams. Clearly, having a tribal council and an eviction for certain development groups wouldnât work, but on this Australia Day public holiday, ask yourself this: If your team had a vote yesterday, would you still have a job on Monday? If not, do something about that now.
At the end of each week, you vote the worst dev off the island.
Itâs just performance anxiety.
Most people are terrified/stressed out during interviews.
Not âCan you X?â -
âCan you X whilst terrified?â
AndyToo wrote:
âHowever, I have never once used - or had call to use - recursion to solve a problem, since I learned about it at university. Does this make me a bad programmer? Or is it simply that people program in different ways for different problem spheres?â
i think you missed the point: if ou were explicitly tasked to write a algorithm using recursion, would you be able to do it ? would you be able to recognise the use of recursion while reading someone else code ? and most important, the one i struggled teaching to newly hired guys and which most people dont learn at school: do you understand the principles behind recursion ?
every good programmer knows there are plenty of ways to avoid recursion, but being able to avoid it implies that you know what recursion is.
and that is the point of such a question during an interview.
Damnd thing took me three minutes to write in php. I am getting slower with old age
if ($x/3 == floor($x/3) ⌠and so on.