31 comments

[ 4.6 ms ] story [ 75.2 ms ] thread
This was an interview question at both Square and Braintree. Its weird that interview questions trend from year to year.
To implement it or describe what it's for?
I was asked to implement it on a whiteboard for a developer gig at an ad agency in like 2009. I thought it seemed disproportionately hard compared to what the job was likely to require.
Really? It seems like a trivial programming exercise to me.
I've actually done it myself for fun in Haskell; it's one of the CodeWars challenges.
It's trivial if you are told what the algorithm is. If you're expected to randomly remember it perfectly and implement it that way, it's hard.
Certainly. That's a very poor interview process.
implement in both cases, after a clear definition.
It was also on the UK GCSE IT syllabus when I were a lad. The IT syllabus was actually incredibly good. I get very sad when i see the state of the modern one.
Huh? GCSE ICT was about learning to use Microsoft Office.
Same here, I did mine in 2005 and it consisted largely of Microsoft Frontpage...
yea.. in the 90s it was much better
Speak for yourself. I found the GCSE IT syllabus absolutely atrocious (this was 10ish years ago). I do remember this though, so that's something, but broadly speaking it was awful. And I mean truly, truly awful. I find it difficult to put into words. I'm so glad they're actually starting to teach programming now.
When did you do it?
Around 2004/2005 I think. I'd always been interested in computing, and wanted to learn some programming. I'd seen these posters up with BASIC code on them and naively assumed that's the kind of thing we'd do, only to turn up and literally to given print-outs going step-by-step how to use a word processor. "Click Start" (screenshot), "Move the mouse to Programs" (screenshot), etc. It was completely demoralizing for someone young and curious. And the teacher had zero interest too--no desire to hold a conversation or explain anything. (Not sure what those BASIC posters were about after, maybe that was for A level students).

I understand that perhaps you wouldn't teach programming in ICT, but I'd at least have hoped to learn more about computing generally. The whole thing was just a very sad experience. No one there learnt anything new. Most spent their time playing games or being bored.

The only good thing it taught me was that I was better off teaching myself when it came to computing, at least given the alternatives available to me back then.

Edited to add: The sad thing, for me, is that I chose ICT over a foreign language (I couldn't do both in my school), while I was then top of my class in German and would've liked to continue it. But I didn't, and I'm mildly irritated about that to this day--I'm only now picking up German again. My school offered very little guidance, all things considered, but I took it for granted at the time that that's just how the system worked.

It's one of our interview questions too... I swear we did not get it from Square or Braintree. Very wierd.

It's a nice one because it is easy to understand and you can TDD it fairly easily.

Many of us from the pre-stripe era have implemented Luhn once or twice I'd say, very often in Javascript and web scripting languages! However, you really should avoid re-implementing this sort of thing, and particularly additional credit card checks as it's easy to make spurious assumptions (eg. credit card prefix should equal country of address of credit card, or of mailing address) which are in fact invalid. This stuff prevents actual sales and frustrates your users.

For a slightly out there and arguably more interesting financial checksum algorithm, and one that is actually amazingly effective, do some statistics on mod97's performance. Realizing how good it was, a few years back for a cool hack in my IBAN library I wrote a mistranscription error suggestion system, which plays off the strengths of mod97. See https://github.com/globalcitizen/php-iban/blob/master/trunk/... and https://github.com/globalcitizen/php-iban/blob/master/trunk/... - for a quick hack, it's amazingly effective.

PS. I am available for remote gigs doing creative or challenging stuff in finance-land at the moment, if anyone appreciates this sort of thing.

This threw me 14 years back. First year high-schooler hanging out on Moroccan websites of pure html with a black background and rotating skeletons (funny fact: it was called c00l-hack), and this stuff was there. Right with phreaking, lock-picking and that kind of things. They had a good community over there and we didn't.

I still have some of those files I suppose (downloaded on a dozen floppy disks I carried with me everywhere from cyber café to the other).

I remember "credit card generators" - they'd create a credit card number to pass luhn checking.

For a few years people could get Compuserve access by using a fake number and fake details.

I remember this. One (in sweden) could dial a freephone bbs number and enter a fake credit card only to get a temporary working account, that worked for like 24 hours or until you hung up. Helped me from being killed by parents for huge phone bills around 1995
I wrote a bit of code that generates a random number that passes the Luhn test.[0] It was one of those random things I did in high school when I was learning to program.

[0]: http://bradconte.com/cc_generator

I had come across this while generating test credit card credentials while integrating a payment gateway. Had written a small Python utility for that. Here - https://github.com/ratpik/luhn
I wish more common numbers had a built in check-code like that.
I find the most interesting thing about the algorithm is that, as mentioned in the article, it was originally designed to be computable by a simple mechanical device.
Luhn is also used for the last digit in Swedish social security numbers, https://en.wikipedia.org/wiki/Personal_identity_number_%28Sw... which makes me remember doing this in school around age of 10. i wish the teacher then would call it an "algorithm", so one wouldnt grow up thinking "algorithms" is something complex and hard to understand
It's also used in South African ID numbers, although it's applied backwards.
The first time I've seen the Luhn algorithm was on a compromised web server. The cracker has put several fake ebay login/registration pages, as well as a couple of Javascript files.

The pages were obviously intended to be used for phishing. However, what really made me go "wow" was the extra mile they went: one of the Javascript files contained methods that took the credit card number from the fake registration page and checked its validity w/ the Luhn algorithm before emailing it to a random email address. If the number was invalid, the user got an error and they forced him to re-enter.

I didn't know about the algorithm at the time (this was around 2005), so I was a bit baffled what the heck they are trying to do.

This was great for getting a free month of AOL every month for years back when that was how many people connected to the internet. You just came up with a fake number that worked with this algorithm and you were good. There were even lots of automated applications to do that for you near the end such as AOHell: https://en.wikipedia.org/wiki/AOHell