I've started including a small variation of FizzBuzz as part of our developer screening test - varied so you can't copy and paste from google. Very loose guidelines, pick your language, access to the internet, etc. We even give a general outline of what will be tested 24 hours out, and no hard time limit.

3 out of 4 people so far were unable to do the test. One guy boasted 20+ years of development experience and I used to work with him, he didn't even attempt it?!? Frankly, I expect candidates of any worth to feel insulted we are asking them to write this. The guy that did complete it wrote it in Bash, and wasn't strong in that to begin with. Bonus points for learning a language on the fly, that's what I'm looking for.

That matches my experiences. The first time I heard of FizzBuzz, I laughed it off as ridiculously easy and not worthwhile for screening. I've since changed my mind.

If a candidate laughs and writes down a canned answer off the top of their head, I count it as "passed" and we move on to other questions. I've been horrified at how often it's been a show-stopper, though.

> The guy that did complete it wrote it in Bash, and wasn't strong in that to begin with. Bonus points for learning a language on the fly, that's what I'm looking for.

I'd give that a double thumbs-up for resourcefulness.

jeremyjh did a good job explaining this. I work for a company that supports the card issuance side and previous to that I worked for one of the largest drivers of ATM's for small and regional banks.

This has nothing to do with transactions in the sense of database transactions or a transaction manager managed by an app server, these may still be used behind the scenes.

jeremyjh did a good job explaining this. I work for a company that supports the card issuance side and previous to that I worked for one of the largest drivers of ATM's for small and regional banks.

This has nothing to do with transactions in the sense of database transactions or a transaction manager managed by an app server, these may still be used behind the scenes.

What happens here is the ATM sent a withdrawal request over the network, that was recorded by the issuing bank - a memo to that account - the bank recorded a debit. Subsequently, the ATM/network/something failed and a second 'reversing' request was sent over the network to the issuing bank, this reversal credit rollsback the initial credit - this may or may not get memo posted to the bank account in real time because reversal transactions can be processed at a lower priority.

During the end of day settlement process, the ATM network 'settles' up with each Bank, during this time the debit/credit markup transactions are dropped and replaced by the REAL activity posted by the ATM network (STAR/Pulse/Cirrus/etc).

ATM systems are a lot more complicated than a simple database transaction, and even I left out several of the steps and possible events that could occur during the process.

During the end of day settlement process, the ATM network 'settles' up with each Bank, during this time the debit/credit markup transactions are dropped and replaced by the REAL activity posted by the ATM network (STAR/Pulse/Cirrus/etc).

ATM systems are a lot more complicated than a simple database transaction, and even I left out several of the steps and possible events that could occur during the process.

I work in the debit side of things (well for only about the next few months) so my experience is a tad bit different, I'll approach it from a debit perspective, credit should be somewhat similar.

The device you swipe your card at Best Buy is a merchant device. Best Buy has made an agreement with the device vendor to route its traffic over a specific network, say First Data.

When you swipe the card the network(gateway) decides where to 'route' the request based on the BIN (typically first 6 digits of the card number, can be more depending on how the card profile is setup). The network has BIN tables setup so they can easily identify which cards go where. After the merchants gateway has determined where to route the card, the request then propagates to the issuing network, from there it is sent to the issuer to approve/deny the request.

This is a simple high level overview and by no means complete.

Ex. path

User swipes card @ device -> Merchant devices sends transaction to First Data (where FDC is the merchant device gateway) -> First Data routes transaction to issuing network (Visa, MC, Cirrus) -> Issuing Network forwards request to issuer (issuance processor) for approval

In debit world, it used to be that the more 'hops' a request took to route back to the issuer, the more that interchange that was incurred.

There are all sorts of scenarios that can occur, for example, I'm working on a project that would circumvent the networks if the transaction is for a card issued by our bank (closed loop transaction), which avoids interchange fees paid to the network.