Live data from Hacker News

I was asked to crack a program in a job interview

erenyagdiran.github.io

251–260 of 309 posts

Re: I was asked to crack a program in a job interview

#251

Earlier quoted context omitted.

Totally. YMMV. That's why you look for stuff on the CV like willingness to experiment, play with OSes at home, "describe your home network", etc. This doesn't replace the interview, it just verifies claimed competence and helps show thinking ability.

"Describe your home network" is an interview question now? Jeez, guess I shouldn't leave my job, I'll never get another one. I am going to go ahead and challenge the assumption that your willingness and eagerness to learn on the job is not really correlated with how you spend your time outside your working hours.

I mean as extra points that help the candidate look interesting. It's like the "other interests" section on a CV: you should treat it as an opportunity to market yourself and add a hook to catch the interviewer's interest.

Re: I was asked to crack a program in a job interview

#252

Crackmes (as they're known) can be kind of fun. The late Katja Kladnik once sent me a diskful of 'crackme' virii. I tried to deadlist one of them; it infected me when I did, and dared me to try a less obvious approach. Mangled symbol table => buffer overflow in debugger => arbitrary code. Sneaky .

Your comment prompted me to look up Katja Kladnik. I hadn't expected her to have passed in (edited) 1995 . http://spth.virii.lu/coderz1/lucky.html http://www.st-news.com/rex.htm#lucky The e-zine this is from ( http://spth.virii.lu/coderz1/ / http://vxheavens.com/vx.php?fid=177 ) was pretty interesting, too. Harks back to the time of small, independent online communities with dark webpage backgrounds.

I miss her. :(

Re: I was asked to crack a program in a job interview

#253

Earlier quoted context omitted.

> Real-life tests are THE best thing to send job candidates I agree, but only if you're allowed to use references/google/etc and given a reasonable amount of time to accomplish it. I've had a "real-life" test where I wasn't allowed to verify or look up information, or where I'm giving a very short time to execute, and I've always thought those were absurd. The idea that you would ever have to do something like this i…

It's gets a bit complicated when your job candidates may find your test interesting enough that they post a complete walk-through of the solution online. The candidate was kind enough to avoid posting the name of the company (to hopefully hide the walk-through from Google queries for "crack me hiring test company name ", but an HN discussion might then arise around the walk-through, in which the company would be name…

If you're not changing your tests on every interview batch you're doing it wrong.

You're asking a potential candidate to spend hours cracking your program but you can't be bothered to change it for each batch?

I expect any company applying this interview technique to at least put some effort into it and even then it pays off since a batch could contain hundreds of candidates and you only have to build the program once.

Re: I was asked to crack a program in a job interview

#254

Does this guy have any idea how hard it is to come up with good interview questions? By posting the question and solution online (complete with an md5sum and everything!), he has ruined the question, and his employer will now need to spend a significant amount of time coming up with another way to evaluate candidates.

Ah, the good old security through obscurity technique!

Re: I was asked to crack a program in a job interview

#255
post #218

Earlier quoted context omitted.

I've taken a whiteboard test that asked me to come up with an algorithm that was difficult for me. I got the job even though my solution was horribly inefficient (and I knew it), and the interviewer later told me that the point wasn't to see what algorithm I knew - it was to see if I acted like an ass when I didn't know stuff.

> it was to see if I acted like an ass when I didn't know stuff Surely there's more efficient ways of evaluating that.

On the plus side, it did take a stab at what algorithms he knew, too.

Re: I was asked to crack a program in a job interview

#256

Earlier quoted context omitted.

I believe it was also the part of the key.

Could you change the jmp into a nop, then xor every nth byte of the program with jmp xor nop, where n = whatever offset the jmp was at in the key? The result should be a valid decryption.

Wouldn't that also change the xor-ed instructions? That is, wouldn't the program behave differently?

Re: I was asked to crack a program in a job interview

#257
post #229

Earlier quoted context omitted.

Well if not lying, you should always entertain the possibility they are mistaken. The best confirm and reaffirm constantly. You know what they say about assumptions.

You are going to think your boss is mistaken/wrong/lying in the first hour you meet her/him, during a job interview? Nah. You're not.

To be fair the first thing you do is look for relevant buttons to click on if there are any, the next thing is to google the problem, the thing after that is check it's all plugged in

It's just testing the basics really

Re: I was asked to crack a program in a job interview

#258

Earlier quoted context omitted.

>I agree, but only if you're allowed to use references/google/etc and given a reasonable amount of time to accomplish it. I've had a "real-life" test where I wasn't allowed to verify or look up information, or where I'm giving a very short time to execute, and I've always thought those were absurd. Employers that do this are ridiculous. As are educators, too. What is this, preparation for when coders are kidnapped by…

> Employers that do this are ridiculous. In my experience, they're usually startups or smaller companies that are trying to "copy google" in their hiring practices, but don't fully think out how they're doing it. It's not a good sign.

Well Google does it too. Their 'gang bang' interviews are notorious for weeding out people that don't perform well under short term pressure like that. "just write an algorithm for a stack on this whiteboard with a big O complexity analysis and memory usage pattern in 15 minutes while we all stare at you. What? You don't work well like this? Well this is how elite Googlers work all of the time so GTFO"

Re: I was asked to crack a program in a job interview

#259
post #256

Earlier quoted context omitted.

Could you change the jmp into a nop, then xor every nth byte of the program with jmp xor nop, where n = whatever offset the jmp was at in the key? The result should be a valid decryption.

Wouldn't that also change the xor-ed instructions? That is, wouldn't the program behave differently?

Nah, if instruction "foo" is xor'd with "jmp", then xoring foo with "jmp xor nop" will remove the jmp and add the nop. Then the nop is removed during decryption, because "foo xor nop" xor nop = foo.

The reason this is clean and convenient is because nop is a single byte (0x0f or 0x90), which lets you replace any instruction of any size with nops. But if you had to transform jmp into an instruction of a different size, things could get hairy if the byte sizes don't line up. But you could still replace several instructions with other code.

Re: I was asked to crack a program in a job interview

#260

I have a pretty cool crackme that I programmed and I wanted to offer it as a puzzle to some candidates, but without the proper reverse engineering tools, I think most candidates would really struggle -- especially if you're looking for just general developers. Haven't given it much thought past this.

If you are hiring a "general developer" it may not be the best idea to test them this way.
Post reply on HN