I don't know why Microsoft does it. But if I were hiring, for some positions I might do it; I'd do it because such questions, when they depend on something the applicant has not already seen, can serve to probe cleverness and adaptability of thought. Martin Gardner wrote a book called "Aha! Insight" about this kind of thinking - the "aha!" moment - and how it can be coaxed into occurring more often. Many recreational mathematics puzzle books can serve the same function. This is not restricted to job interviews. In my career as an undergraduate in university, I wrote the Putnam[%] one year. One of the questions was to compute a particular definite integral (of a rather hairy function). The simple answer (which I did not get) was to notice that it had 180? rotational symmetry about a particular point and leverage that to deduce that the answer was exactly half the area of a particular rectangle. [%] The William Lowell Putnam mathematical competition, a *hard* exam held annually for undergrads in mathematics. A good standing on the Putnam can open doors, if you're interested in mathematics in academia. Furthermore... ...well, if you didn't previously get it, whether you can get it during the interview says something about your cleverness and adaptability. If you think out loud at all about it, how you approach it can say a lot more, if the interviewer is good. (And if you did previously get it, that can indicate something too, though it's a much fuzzier something.) Of course, I would never claim that all places that use such questions use them correctly. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

In article <44309D2E.8060009 at DakotaCom.Net>, Don Y <dgy at dakotacom.net> writes: As long as you don't make me write it out long-hand on a pad of paper. God, what a waste of time. Microsoft had me do that too, but I thought at least give me notepad for cryin' out loud. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <200604031024.k33AOjdZ002070 at mwave.heeltoe.com>, Brad Parker <brad at heeltoe.com> writes: I didn't get mad, I just 'dug in' as you say. But I didn't get the "trick" to the puzzle so it just sat there unfinished. Basically I felt it was a waste of precious interview time because while I might often get stuck on this little trick puzzles, I very rarely get stuck while writing software and even then I don't stay stuck for very long. This becomes evident when coding with me or looking at code I've done, but its not evident by shoving random brain teasers in front of me and demanding I solve them in 10 minutes. I'm not a seal in a circus act. ...or maybe not since you presumbaly wouldn't hire the person who was put off by being asked to solve an irrelevant puzzle. This reasoning sounds like a self-fulfilling prophecy. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

Richard wrote: actually, if you 'dug in', as you say, I'd give you 50% credit :-) as I said before, getting the answer isn't the point. -brad

Richard wrote: In the context of a job interview? If you presumed to second-guess what I present as relevant, I certainly wouldn't hire you. Every job I've ever had (and every job I've ever run, for that matter) occasionally involved some gratuitous hoop-jumping. If you're going to get pissy about that and I'm responsible for your performance, that's something I'd like to find out during the interview. Doc

On Mon, Apr 03, 2006 at 06:21:11PM -0600, Richard wrote: So, you've never had to troubleshoot anything on the job? If employed correctly (ie, not pulled from a book, and if the interviewer is intelligent enough to have come up with it themselves), they're a good general intelligence test. There's a lot you can find out about potential employees by asking non-job-related questions. Pat -- Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

---snip--- Hi I often ask questions I don't expect the person to be able to answer. What I want to find out is vary valuable to me. I want to know how that person thinks about problems. I don't reject them because they don't get the answer nor does it mean that much if they get the wrong answer. It is how they approach the problem that I'm most interested in finding out. They can always learn what they'll need to know once they start working. I don't have enough time to teach people how to think. Dwight

On Mon, 2006-04-03 at 22:54 -0600, Richard wrote: I saw something to the effect that many studies showed that when forced to produce a running verbal commentary of solving a given puzzle, they lost almost all solving power. Forcing a person to keep a commentary of what they're doing moves it into a completely different part of the brain, and it would go from "possibly irrelevant" to "completely futile". But, as stated, what matters is less the solution, and more the approach the employee takes, as that shows more of the personality. -toresbe

dwight elvey wrote: Best question I was ever asked in an interview (by a VP of one of the largest hand-tool manufacturers) was how to design a numbering system for their products (hammers, screwdrivers, tape rules, etc.). It had to be one of the most enlightening "unexpected" questions I'd ever heard -- or heard, since! I think that exchange proved to both of us that we could work with each other, despite the actual "answer" to the question. --don

On 4/2/2006 at 8:30 PM Jim Battle wrote: I disagree. Consider that, as a manager, you might be looking at a whole herd of people who have perfect university transcripts and impressive resum?s. That mostly tells me that (A) they knew how to be students and take tests and (B) had a very talented writer for their resum?s. Neither tells me anything about their on-the-job capabilities and more importantly, their ability to program. And I've interviewd enough people who can lay down an impressive line of BS. One of the peculiar aspects of assembly language programming is the ability to hold the details of what each and every instruction does and how to apply that knowledge. So, yes, the problem posed by the CDC problem involves instinctively knowing that there's no way to store a register without clobbering another one. However, the "aha" is knowing that the RJ (return jump) instruction uses no registers but it does modify memory. So you write a list instructions that conditionally jump on the sign bit of a B register around a return jump that records whether the jump for that bit was taken, followed by an add-to-self to shift the B register left by one bit. An assembly language programmer that doesn't have the dscipline to know his instruction sets in detail and use that knowledge either writes horribly bloated code or spends inordinate amounts of time because, for instance, he doesn't realize that the 16-bit increment instructions on the 8080 don't modify any condition codes or that the 8 bit increments don't modify the carry bit. Getting an indication of this right off the bat is much easier than trying to figure out (A) where am I going to find another programmer to do what this guy was hired to do and (B) how am I going to fire the current guy without him filing a dispute with the state department of labor. Cheers, Chuck

On 4/3/2006 at 12:46 AM William Donzelli wrote: Yeah, I know. But I don't want to hire the kid out of school who just did his homework for grades. I want the kid who worked outside of class assignments purely for the fun of it. I want the kid who just can't get enough. In short, I want another me. I believe that any organization benefits most who fit neatly into the hierarchy. But then I'm a great fan of Peter Drucker and Gerard Fairtlough. But yeah, assembly language, keypunches and listings are from days gone by--and they'll not be back. But I'll bet I can still find a way to pick out a dedicated self-starter. I don't even care of the person taking the gimmick test doesn't get the gimmick. But I'd cross him or her off the list automatically if he or she didn't insist on knowing the answer. And you'll note that I used the word "programmer", not "coder". Cheers, Chuck

Don Y wrote: I guess I belong to the 'coders' class. I like quad paper myself. :) Right now I am trying for a clean new 18 bit cpu design that is 30 years late if I ever stop modifying the design. I picked up Knuth for programing ideas rather than sneeky tricks that you find here and there when I write software for this beast. Note I am planning 16k for the OS and 48k for user programs since I only ordered 64k of memory. Ben alias Woodelf

William Donzelli wrote: I have to agree. I do a reasonable amount of paid work on micros and almost all of it is in C. The only exception is PIC's, which are generally done in assembler. don't get me wrong - I love assembler, but most paying customers want the work in C for maintainability. All the AVR and HC11/12 (6800) work I've done has been in C as well as a handful of odd-ball cpus. Even 8085's. And these days most of that is shifting to small pin count ARM SOC's like the SAM7S. The joke these days is that the CPLD next to the CPU has 4x the pins! -brad

William Donzelli wrote: With the amount of PDP-8 emulators I have seen on the web ASM programs are alive and well. :)

William Donzelli wrote: I think you'd be amazed at how prevalent it still is! It depends on the market you are in. For example, do you think the microcontroller in your mouse was coded in anything OTHER than assembler? Or, the microcontrollers in your CD-ROM drive? That's already twice as many processors as there are "computers". Now, look at the thermostat on the wall in your living room. And the microcontroller *inside* your furnace (assuming you have a newer model furnace). My VCR has three microcontrollers in it. I have no idea how many are in my stereo components, television, etc. The code in the gasoline pump up the corner was written in assembly language (unfortunately... it was the perfect application to move to a HLL but... :< ). I know of cameras written in ASM. I have a friend who is just finishing the design of a LIGHT SWITCH -- written in ASM. I haven't check in some years but the biggest volume parts were things like HC08's. Nowadays, PICs (if you treat the entire family as a single 'part') probably are king of the heap. Amazing when you think of how many PC's there are and realize how *small* that number is compared to all these other things! I am just finishing a proposal for yet another product where I am *sure* the client won't want to spend the money to support a HLL. (Of course, he will undoubtedly grumble at the cost of NOT using one, too!) Well, when I look at all of the PRODUCTS out there, I guess us 100 engineers must be writing a sh*tload of code!! IMO, the key difference is you write these applications *once*. There are no bugs (allowed) and no "upgrades". You dare not have to RECALL 50,000 widgets because you made a mistake and need to fix it. So you get it right the first time and then the job is *over*. (e.g., my Nakamichi Dragons have a stupid little bug in the MCU that watches tape motion... no chance in hell that it will ever be fixed -- or even acknowledged!) But, thereafter, your production (and any savings from using a cheaper implementation) just keep adding up. Until you've had to reuse *bits* in a particular *byte*, you're not really dealing with low cost items. :-( It's really difficult to make the transition to resource-rich applications... it's hard not to count clock cycles, measure stack penetration (do people even *know* how deep the stack needs to be on modern desigs? Or, do they just keep bumping it up until the code works??), pare data down to the smallest necessary size, etc. (I still cringe every time I use an int for a bool! :>) Thankfully, most HLL's make bit-banging really difficult. --don

Brad Parker wrote: Exactly. And the code in that application is likely to be revised. The code in your microwave oven, isn't! Great! Here are 256 bytes of ram. Design and implement a LORAN-C position plotter in C. It has to process data in real time (i.e. maybe 1.5 updates per second), run on a *3* MHz CPU and you have 10KB for TEXT. And, that's a "bountiful" work environment! I envy you the clients that give you that much leeway. When I am done, a client usually wants to know how to trim even MORE out of the design (I'm looking at a $20 design now that needs to be a $15 design... and the list of added functions is several pages long! Hmmm, I wonder how much I can save by taking the FOILS off the board?? Or, the leads off the resistors?? :<) Doing decimal arithmetic in C sucks. As does trying to pack 8 bools to a byte (and access them efficiently), etc. Loss of the carry is probably the biggest single pisser in most HLLs. <shrug> Horses for courses... --don

woodelf wrote: There are advantages to simplicity! :> No. That is a (stationary) receiver with dedicated hardware to monitor the incoming RF to make sure it's what and "where" (in terms of *time*) it should be. E.g., it is dedicated to a particular GRI (Group Repetition Interval), hears the Master broadcast (at that period), expects to hear each of the slaves respond (at reasonably fixed intervals in relationship to the Master's transmission, based on where *they* are located and where *it* -- the PDP8 -- is located). The timing of the signals is done in hardware with a high speed counter timer, etc. The waveshape of each pulse is rigidly defined so you can see if it has been distorted by the transmitter, etc. (you track the position -- in time -- of each pulse by watching for a certain zero crossing of the carrier defined within the envelope). All it has to do is worry about stations going off the air and some minor variations in signal timing based on changes in atmospheric propagation (since the transmitters are in fixed locations). A *plotter* takes two or more pairs of "time difference" coordinates (TD's) and converts them to a geographical (Lat-lon) location. The TD's define families of "concentric" :-/ hyperbolae. The intersection of a "line (hyperbola) of constant time difference" for one Master-Slave pair with an intersection of another line of constant time difference determines your location. But, these are hyperbolae, not nice spherical coordinates. And, there can be ambiguties -- a given set of TD coordinates can represent two different points on the globe (sometimes, quite close together, sometimes quite far apart!). So, you have to capture the incoming coordinates, solve the difference equations to map the hyperbolae onto a spherical globe, compensate for the *oblateness* of that globe, do a 2D mercator projection, scale it to the desired user's scale and then drive X & Y motors to move the pen from where you were (last update) to where you *are* (in a straight line, of course) -- without running off the edge of the page, etc. In addition to driving the multiplexed displays, scanning the keyboard (debouncing keys, etc.), interacting with the user, etc. Nowadays, I could code the whole thing in a month or so. But, it sure wouldn't fit in that hardware footprint! (keep in mind, 2Kx8 EPROMs were $50 at the time... $250 just to store the code!) I don't believe any are that tied to the hardware. Even PL/M has no provisions for it *directly*. --don

Brent Hilpert wrote: I thought loran almost died and then something was done to fix the mid-contenent gap and then almost died and then, for some reason made a big resurgence - maybe in response to the need for a "plan b" in case GPS stops working or is jammed... anyway, I thought it was funded again and going strong. Did I make that up? (always nice to have a plan B when cruising at FL 350 :-) no doubt also helpful in the middle of the atlantic) -brad

Brent Hilpert wrote: No, I was only involved in the plotter (CPLOT-2). We had an "all hardware" receiver that predated me. And, a CPU-based receiver that was designed alongside the plotter (but I think it was a white face). IIRC, we used PGD's for our displays (I know the plotter did). I also designed an autopilot "peripheral" (to the plotter) that allowed you to enter geographical coordinates of your desired destination and it would steer the boat *to* that point (instead of just blindly keeping the boat pointed in a certain direction) while compensating for drift, etc. (I also learned that you should never go below deck when in the Atlantic :< ) I *thought* it was decommissioned a few years ago. But, it's been 25+ years (gulp!) since I was involved with LORAN in any way (however, it's the type of thing that, once you get exposed to all the wacky details of how it works, it kind of sticks in your mind :> )

In article <200604050313.k353DEvL019892 at mwave.heeltoe.com>, Brad Parker <brad at heeltoe.com> writes: On the other hand, I've worked on the reverse. A huge assembly language program that should have been written in C. (Hi Fred Brooks!) <STORY MODE="verbose"> It was 1986 and I was so fresh out of UDel's EE department with my degree that the chairs were still warm in the classroom from me sitting on them. I got a contract job with the Glasgow facility in DuPont (yes, *the* DuPont of Delaware). Glasgow was their medical instrumentation division and they had bought out Sorvall, a company that makes high-speed centrifuges. I mean really high speed, like 50,000 rpm? (my memory is fuzzy on the exact number, at least 10k). High speed enough that if the rotor got loose from the motor shaft, it would turn you into hamburger. They deliberately failed one of the rotors in a test chamber lined with 6 inch thick oak. The rotor made a 3 inch dent. But I digress.... They hired me as a contractor as squeeze labor to help get this software done that they had been writing for the front panel user interface. It was a 6809 processor with a membrane keypad (newish idea at the time), some LEDs and a 2x40 character backlit LCD display. It communicated to another 6809 processor that ran the motor. (Thank god the UI guy didn't do the motor code or I would be scared.) This project was being poorly managed and it was also being poorly engineered. The UI panel code had somehow ballooned into 100,000 lines of partly commented 6809 assembly language code. It had a floating-point library and was doing complex scientific calculations and had a fairly elaborate menu for programming in various centrifuge tasks. At one point I analyzed a data path and saw a number get converted from integer to fixed-point to floating-point, do some math on it, floating-point to fixed-point and converted back to integer. This was just one example, the whole thing was a rat's nest of gobbeley gook. When I signed on, we were using a cross-compiler on a PDP-11 (I think it was a /34 or a /45 running something with a versioning file system?) and were not using linkable object modules. Instead if you made a change you had to reassemble the entire 100,000 line mess of source files. It took 8 hours to assemble the output file for the test harness. I reworked all the source files to export the entry point symbols and import the symbols called by that source file. Since there were hundreds of source files, this took a while, but was easy to do. Then I could assemble the .asms into .objs and link .objs together to get my final output for the test harness. This cut the edit/compile/test cycle down to about 45 minutes (it still took a long time to link). The target environment was pretty resource rich on the PROM and RAM side, This was not a machine that was starved for resources, but it was being treated as such. During the time I was there, I could have single-handedly rewritten the entire thing in C using a cross-compiler. Instead I was instructed to use assembly language, which I did. Aside assembly language for anything work related. Had I rewritten it, I'm fairly certain that the ROM image would have been smaller and I'm absolutely certain that there would have been fewer bugs. </STORY> At one point, after having repeatedly embarrassed the lame engineer who was coding the UI by fixing his bugs, he accosted me in the hallway and told me (and I quote): "Your job is not to fix bugs. Your job is to do what I tell you to do." Umm...yeah. That pretty much sums up what was wrong with that project :). -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <4433ED7D.20109 at DakotaCom.Net>, Don Y <dgy at dakotacom.net> writes: In defense of C, its approach to this problem is to allow you to link against a chunk of assembly code that implements any function for which its cumbersome to implement it in C because of low-level bit fiddling, or whatever. Most, if not all, compilers also have provisions for inline assembly in the C source code. So C really does provide solutions for this problem. Its not like Pascal where you're *forced* to do things the stupid way. C lets you use assembly where needed. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

der Mouse wrote: *Exactly*! If you have to do the divide yourself (i.e. in ASM), you end up with both results for free. If, OTOH, you write in a HLL *on this same class of machine*, the compiler writes code to do the divide (typically, just calls a "helper" function), discards the remainder and then goes to work on the modulus operation... :-( (point being, compilers aren't all created equally as processors aren't -- the differences in efficiency of compiled code vs. ASM can vary tremendously depending on what you are working on)

Sean 'Captain Napalm' Conner wrote: Most modern compilers for "big" machines. The point I've been making is that many machines aren't big and have hackish compilers, at best. So, even if you code div() yourself, (as many standard libraries with these hacky compilers are equally hacky! -- implementing div() *as* the code fragment I mentioned above!) there's no way of coaxing the compiler to be smart enough to use it efficiently. C isnt always C (you've got folks like ZWorld claiming to "improve" it, etc.) Again, *big* machines! :>

Jerome Fine replies: About 20 years ago, I wrote some code in C which used a much less than optimal algorithm to locate prime numbers. To make a long story as short as possible, the inner loop made use of code which looked like (I can't remember exactly): unsigned integer i, itemp, k, l NULL INTEGER N ... itemp = l(i) if k .lt. l(i++) then gosub abc else if k .ne. itemp / ELSE IF N gosub def else gosub ghi end if Obviously, when I make the first test, the carry bit is being tested ( Bhis / Bcc ) and a branch made around the subroutine call. This would be in a system where the hardware actually has a carry bit available as well as auto-increment for the compare instruction. However, an extremely clever compiler would also be able to realize that the second test requires ONLY one additional instruction in the form of a Beq around the second subroutine call. What I could never understand was why a null variable was not allowed which assumed that the arithmetic instruction had already taken place and the only requirement was to test the condition code in the required manner. This capability would, in hardware that produced the correct condition codes, allow repeated tests such as for the example above WHERE THE CODE IN CAPITAL LETTERS IS USED INSTEAD. For the actual example, when I wanted to produce a production version, I only needed to edit the assembler version of the code and remove extra instructions which were not needed. In real examples where a sufficiently intelligent compilier is not available, is that is the best way to optomize the code? I would appreciate a comment what attempts to provide an answer to this specific question. As for the use of the mmx instructions, I thought that they allow for the use of 64 bit registers. Doesn't that correspond to: long long integer ivalue As for an assembler that moves instructions around, I have only just looked at the instruction set for the Pentium with a view to using some of the features to speed up the E11 emulator for some PDP-11 routines - UDiv32 and UMul32 are ones that are first candidates. Later I will likely attempt multi-precision arithmetic. by the way, do mmx instructions allow 64 bit integers? Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.

Jerome Fine replies: About 20 years ago, I wrote some code in C which used a much less than optimal algorithm to locate prime numbers. To make a long story as short as possible, the inner loop made use of code which looked like (I can't remember exactly): unsigned integer i, itemp, k, l NULL INTEGER N ... itemp = l(i) if k .lt. l(i++) then gosub abc else if k .ne. itemp / ELSE IF N gosub def else gosub ghi end if Obviously, when I make the first test, the carry bit is being tested ( Bhis / Bcc ) and a branch made around the subroutine call. This would be in a system where the hardware actually has a carry bit available as well as auto-increment for the compare instruction. However, an extremely clever compiler would also be able to realize that the second test requires ONLY one additional instruction in the form of a Bne around the second subroutine call. What I could never understand was why a null variable was not allowed which assumed that the arithmetic instruction had already taken place and the only requirement was to test the condition code in the required manner. This capability would, in hardware that produced the correct condition codes, allow repeated tests such as for the example above WHERE THE CODE IN CAPITAL LETTERS IS USED INSTEAD. For the actual example, when I wanted to produce a production version, I only needed to edit the assembler version of the code and remove extra instructions which were not needed. In real examples where a sufficiently intelligent compilier is not available, is that is the best way to optomize the code? I would appreciate a comment what attempts to provide an answer to this specific question. As for the use of the mmx instructions, I thought that they allow for the use of 64 bit registers. Doesn't that correspond to: long long integer ivalue As for an assembler that moves instructions around, I have only just looked at the instruction set for the Pentium with a view to using some of the features to speed up the E11 emulator for some PDP-11 routines - UDiv32 and UMul32 are ones that are first candidates. Later I will likely attempt multi-precision arithmetic. by the way, do mmx instructions allow 64 bit integers? Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.

Fred Cisin wrote: Depends on the job they are applying for. If they are writing code to maintain a manufacturing database, nope. If they are writing code to implement a "tape ruler" (i.e. retractable plastic/steel ruler used in construction) then most probably. (unless the processor chosen does all it's arithmetic in BCD!)

On Tuesday 04 April 2006 08:53 am, Don Y wrote: *boggle* Why? <...> Sounds a lot like the way I tend to approach things, too. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

Sean 'Captain Napalm' Conner wrote: Why? If you got real big iron,you can dim your lights the CORRECT way? Now if they had a sensor to tell if you left the room for a couple hours that would be great for me as then lights could itself turn off. :)

On Tuesday 04 April 2006 04:07 pm, Sean 'Captain Napalm' Conner wrote: Heck, I did better than that -- I took a standard 4 inch electrical box, got a plate for "switch and duplex outlet" and stuck a dimmer in there. Originally this was to save the hassle of a xmas tree which had a lot of very old fashioned lights on it from drying out quite as rapidly, but shortly after that the thing ended up in my bedroom and has been on my night table ever since. And I did that back in 1973 or so! I guess newer ain't always necessarily better, eh? Yeah, well... Maybe if I can change the software if I don't like it. :-) -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

I wouldn't want to waste 32 bits for a simple boolean data type. But I also wouldn't try to cram 8 booleans into a byte. The and'ing and or'ing you have to do isn't worth the space savings, unless your data is primarily on/off. Everything depends on the situation.

On Tue, 4 Apr 2006, Chuck Guzis wrote: "Nobody programs in assembly any more, nor ever will again" - Clancy and Harvey (UC Berkeley lower division undergrad CS)

On Tue, 4 Apr 2006, Don North wrote: They are Lisp/Scheme fanatics. I doubt that they really know where their compilers come from.

In article <200604050325.k353PmK5023470 at mwave.heeltoe.com>, Brad Parker <brad at heeltoe.com> writes: beware lispers, for they are subtle and swift to (AND (CAR))? -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <200604041755420357.2FCF5B55 at 10.0.0.252>, "Chuck Guzis" <cclist at sydex.com> writes: Wasn't there an AMD chip that devoted two "registers" to the hardcoded values 0 and 1 in the architecture? -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

On Tuesday 04 April 2006 10:47 pm, Don Y wrote: Nice trick! -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

Chuck Guzis wrote: The only problem with this is that most kids out of college learn this stuff *at* their first jobs. I knew many aspects of my field very well out of college, but it didn't "click" until I had to use them at work. -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

At 09:33 AM 4/3/2006, Jim Battle wrote: Companies feel free to waste entire days with applicants this way. It's rude. You think they'd worry about false negatives and false positives, the frequency of which I would think would increase as the questions get trickier and the applicants get smarter. It relies too heavily on the smartness of the interviewer, too. Phrase the question icorrectly and you'll get a "wrong" answer. Interpret the answer incorrectly or fail to recognize a second correct answer, boom, this method goes out the window and now you've rejected a very smart fish. And it's not as if the companies are pulling these questions out of their own brains. They're cribbing them from other sources. It's as if applicants need to study the canon of tricky questions as well as the fundamentals they're based on. All this for the pleasure of "And if you don't think it's acceptable to ask you to work on Saturdays, then don't bother showing up for work again on Sunday morning." - John

In article <6.2.3.4.2.20060403100456.04e7f130 at mail>, John Foust <jfoust at threedee.com> writes: Yes, because the questions are cribbed I've seen books documenting the kinds of 'brain teasers' that MS and its imitators like to use. So not only are the questioners cribbing these puzzles from standard sources, the "prepared" interviewers are cribbing the puzzles (and answers) from the same sources. I would not be surprised that if you made a concentrated effort to study all these brain teaser puzzles and their solutions that you could breeze through this part of an interview. But what would it show? For game companies, that's definately true. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

Chuck Guzis wrote: Ah, this is funny. I was once asked the following trick question. Say you have a singly linked list. This list might be a simple chain, or it might loop on itself. For reasons that can't be explained, you are allowed to use only two memory locations to decide if the list loops or not. After a couple questions to clarify, it was allowed that speed wasn't important and that the size of an integer and a pointer were the same. A 0 pointer marks the end of the list. I quickly answered with a dumb, brute force solution: one location is a pointer, one is a counter. Increment the counter every time you advance the pointer. If the counter hits a maximal value, you know the list loops, otherwise you'll hit the end of list value first. (and no, the counter can't overflow even with a maximally long list since at least two of the 2^N locations are used by the scratch locations). The questioner was peeved with me. I had answered it and he agreed that it satisfied the question, but I could tell he discounted it because it wasn't the clever answer that he had in mind. In fact, I'm sure he hadn't even though of my answer, and I'm also sure he wasn't the clever person who thought up the question. At some point he heard this problem with the clever answer and from then on he looked down on anybody who hadn't heard it yet. The clever answer is to have two pointers. At each step of the algorithm, one pointer advances two steps and the other pointer advances three steps (any relatively prime pair of increments would work). After the pointers are advanced, check if they are the same. If there is a loop, eventually the two pointers will coincide, even if they have to race around the loop a few times before their phases align. Never mind the fact that actually coding it is a bit of a mess since at each of the places where the pointers must be advanced, each intermediate step must be checked for the end of list condition.

der Mouse wrote: OK, this just confirms this is a "well known" trick question. If someone was to ask me this question again in an interview and I answered it in four seconds, does it mean I'm any smarter than I was a few years ago when I first heard it? As an example of a good question (and one that is on-topic for this list), I was asked this during an interview in 1986. The interviewer was Carl Alsing, whom you might recognize as the manager of the microkids in the book, The Soul of a New Machine. He asked if I had a bunch of Apple II programs and wanted to continue to use them but my Apple II had died and all I had available was an IBM PC, what could I do about it. After answering, "write an emulator," he probed with questions about how long I thought it would take to write, what parts if it I thought would be the hardest, how would I validate it, what speed I could expect to achieve, etc. That type of interview requires that the interviewer be an active participant that has to think on his/her feet as well, and recognizes that in the real world there are often multiple approaches to the solution having varying tradeoffs. The black and white world of clever interview questions is typically irrelevant. As an aside, I did take that job and had a cube directly across from Carl's office. I had read The Soul of a New Machine a few years before but the details were hazy, and anyway, I didn't know for a few months that Carl was in the book until a coworker told me. I then went back and read the book again. The section where the author summarizes Carl's appearance and the impression he first makes was just startling -- in a paragraph the author really did capture truths that I hadn't realized fully myself (such as giving the impression of being a lot less tall than he is). Being the only point of reference that I could verify, and finding it so dead right, it made me much more inclined to believe the rest of the book was accurate.

It was thus said that the Great Jim Battle once stated: [ snip ] Gee, I think I could do that in one memory location---cache the value of the first pointer. Keep following the list, checking each address against the cached value. If you hit 0, it terminates, otherwise if the address matches the cached value, you have a loop. The above method is cleverness (not) for cleverness sake. -spc (Or are you *forced* to use two memory locations?)

That works only if the place you start from is part of the loop. If there is a non-loopy part which runs into a loop, your algorithm will compute forever when started in the non-loopy part. Consider A->B->C->D->E->C, started at A. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

I have. Not *deliberately*, mind you, at least not often. :-) Most of the loop detectors I've written have been in debugging output code, which shouldn't fall over even if the linked list is mildly corrupt. As for deliberately building such lists, I can see uses for them if you have mapcar, or something like it, and want to feed certain inputs a repeating pattern with a nonrepeating initial part. (Relatively rare uses, admittedly.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[Modified Wilson Gearbox description snipped -- incidentally, I have some repair information for the standard version on the bookshelf...] Yes, back when engineers actually thought about things and didn't attempt to 'solve' problems by throwing computing power at them. -tony

It was thus said that the Great woodelf once stated: Either I'm not that smart, or in all my years as a programmer, I've never come across a linked list where part of it is in a loop, not all of it. -spc (Perhaps I'm lucky?)

In article <Pine.SUN.4.20.0604031657110.3983-100000 at osfn.org>, William Donzelli <aw288 at osfn.org> writes: Another example is a sequence that starts out nearly chaotic, but eventually settles into a period N attractor loop. When you iterate orbits on the interior of the Mandelbrot set, many will have this characteristic. They look chaotic initially, but are attracted to a periodic attractor inside M and become periodic. There are also periodic attractors with arbitrarily large periods, so they may look "chaotic" to your finite buffer size :-). -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <20060404010103.EFBD873029 at linus.area51.conman.org>, spc at conman.org (Sean 'Captain Napalm' Conner) writes: The algorithm is the same, whether its arrays or linked lists is simply an implementation detail :-). (Famous last words for a programmer!) -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

On 4/3/2006 at 4:35 PM spc at conman.org wrote: never I've certainly seen it in DOS FAT entries; before that in other allocation mechanisms. In other words, the problem described does occur in the real world. Linked lists are very useful tools, but it's prudent to guard against corruption by real-world hardware and programs. Cheers, Chuck