Andy Lester's got a great article over at the New Relic site which makes me realize how lucky I was in college.
I graduated in 1979; our computing platform was a 360/75, late upgraded to a 370/145 (I think) still running OS/360 in a VM under VM/360. This meant that for our own projects, we actually ended up doing a number of the things that Andy talks about as a matter of survival.
We did not have a version control system at all; we ended up using ="http://ww…
Over at ImperialViolet, there's an interesting
argument observation on Apple's recent SSL/TLS bug in iOS. This is the code in question:
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
if ((err = SSLHashSHA1.upd…
I've been experimenting with something in the interviews I've been doing most recently. Turns out it works quite well, so I'm sharing this in the hope that it will help you as much as it has me.
One of the most important things on a software team is code reading comprehension and communication: the ability to read code, whether yours or someone else's, and walk through it, explaining to someone else what it does. Sometimes you'll be reading your code and explaining it to someone else; sometimes you'll be reading someone else's code and explaining it to yourself, sometimes you'll be lo…
I will no longer be participating at Perlmonks.
So the tech interview is starting to change. I am very glad to see the end of the "puzzle palace" interview. Had a number of those and never did very well at them.
To quote the meat of the article:
Quickly filter out the technically inept by asking half a dozen basic technical questions – Atwood calls this “the FizzBuzz filter.” Ideally you can do this online. You’ll be amazed how many people fail. (If they’ve been recommended to you, you can skip this step.)
Talk to them–i…