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 was asked to crack a program in a job interview
251–260 of 309 posts
Re: I was asked to crack a program in a job interview
#252Crackmes (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.
Re: I was asked to crack a program in a job interview
#253Earlier 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…
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
#254Does 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.
Re: I was asked to crack a program in a job interview
#255Earlier 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.
Re: I was asked to crack a program in a job interview
#256Earlier 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.
Re: I was asked to crack a program in a job interview
#257Earlier 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.
It's just testing the basics really
Re: I was asked to crack a program in a job interview
#258Earlier 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.
Re: I was asked to crack a program in a job interview
#259Earlier 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?
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
#260I 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.