Live data from Hacker News

I was asked to crack a program in a job interview

erenyagdiran.github.io

141–150 of 309 posts

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

#141
post #78

Earlier quoted context omitted.

Well, so far I have only heard a lot of FUD and nothing concrete. http://opensource.com/business/14/7/docker-security-selinux seems to have some information. But to refuse the points there, on my system: a) docker containers do not have a /dev/mem b) /sys/fs is mounted read-only c) /dev/sd* is not visible And so on. What's the thing with cgroups? Can a container delete the host's cgroups? Can it overwrite it's own cg…

http://blog.docker.com/2014/06/docker-container-breakout-pro... But nothing is stopping you from creating a binary and running it as root that perhaps mounts those filesystems, or sends ioctls / badness to the kernel. I'm just shooting from the hip here and might be wrong, but I'm almost certain devices aren't namespaced. If you were to mknod a block device with the right major / minor numbers as the host's sda/sdb/e…

afaik, devices are namespaced already.

http://lwn.net/Articles/564854/

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

#142

This is Intro to Systems homework at UChicago (the course is heavily based on CMU's equivalent.) You're given a personalized binary that asks for a series of passwords to complete each level. If you get a password wrong, it phones home to a server run by the professor and decrements your grade. The point is to teach you to reason about assembly using GDB. You can pretty trivially set a breakpoint at the phoning-home…

How did it identify you as a student? Couldn't you alter the routine to bomb someone else's grade?

That's how you get extra credit.

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

#143

Earlier quoted context omitted.

I'd just like to note here that the sysadmins know damn well when a dev tries to blame them for something the dev did ... and we NEVER. FORGET. So don't do that. I'm not sure how to educate devs to think ops. Perhaps have their phone ring at 3am when stuff breaks? I think that would close the feedback loop nicely. (Let me note again: I LOVE the devs who think operational issues, who think end-user issues - what custo…

I'm sorry but 3am ringer is not working on my colleagues. They are still not giving a damn devs. I don't remember how many times I had to debug instead of them or design better for them. By the way, hacker news developer quality is really better than average or even better.

I'm sorry to hear that! Hmm. Have you tried electrodes? 415 volt three-phase can sometimes catch their attention.

(Ahhh, the BOFH stories ...)

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

#144
post #135

Earlier quoted context omitted.

The point is that you'll only get applicants up to a certain level. Once an applicant has enough skill and knows it, and also values his time, he'll take one look at your 14 hour challenge and laugh. So in the end you're only hurting yourself because you'll mostly get naive and easily manipulated people who are fine for the lower ranks but absolute poison once they move up. That's if they don't wise up and leave firs…

he'll take one look at your 14 hour challenge and laugh These things shouldn't be designed to take 14 hours. They should be designed to take one, maybe two or three . . . if you know what you're doing. One of the other posters took so long because he didn't know what he was doing. Well, perhaps that is an uncharitable way to say it, but you know what I mean. :)

I once has one that was designed to take ~20 hours, and was given a week to do it. Needless to say, I didn't get that job.

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

#145

Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information. This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful i…

It's an effective strategy from the employer's side, but what about the applicant who is asked to spend hours on some test for every job he/she applies for? Are you paying these applicants for the time they spend jumping through these hoops? And if your "technical grilling" fails to identify strong candidates, you're obviously asking the wrong questions or, at the very least, not asking the right ones.

I was paid for a days work, when after the initial interview to test that I knew some really basic programming (think Fizz-buzz, but slightly more interesting), they brought me in to solve a real problem in their app. And I did, and they hired me. It was quite brilliant, actually, and they paid me for the days work at a decent rate. I was impressed.

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

#146
post #45

Earlier quoted context omitted.

What kinds of positions are you interviewing for?

Firmware engineers. Basically C programming and working close to the hardware.

My experience with this (as a C and C++ developer who's worked with embedded systems before) is those kinds of job postings tend to require an engineering degree, and most electrical engineers I've talked to want to do hardware not firmware (and didn't like their programming classes).

You could try either relaxing the degree requirements, or reaching a wider audience -- I generally don't see firmware jobs advertised on HN and StackOverflow and those are basically the only two places I ever pay attention to job ads. Depending on your existing volume of applicants you might also ask them to attach a semi-trivial C assignment to their application. Yes, this is accessible to anyone who can google, but you might weed out the disengaged who don't care enough to read the instructions that way.

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

#147

This is Intro to Systems homework at UChicago (the course is heavily based on CMU's equivalent.) You're given a personalized binary that asks for a series of passwords to complete each level. If you get a password wrong, it phones home to a server run by the professor and decrements your grade. The point is to teach you to reason about assembly using GDB. You can pretty trivially set a breakpoint at the phoning-home…

How did it identify you as a student? Couldn't you alter the routine to bomb someone else's grade?

You get a customized binary tied in a server-side database to your campus single-sign-on identity. Everyone gets different passwords, and the passwords are validated server-side to make sure you didn't just GOTO the success reporting routine.

There could easily have been a secret embedded in each bomb, reported on defusal or detonation, to prevent people from detonating each other. The project was graded on an absolute rather than relative scale, so there was little incentive to spend time on something other than defusing your own bomb.

(The project was called "the binary bomb." We all had a great time telling our friends that we were up all night at the library defusing a bomb.)

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

#148

Earlier quoted context omitted.

Yeah, but B5Geek's is a pretty entry-level thing. I've encountered whiteboard tests where you have to recreate an algorithm that someone spent their PhD thesis creating. It seems like a good way to find "geniuses", but it just isn't practical. In a lot of ways, it's a matter of identity crisis for software developers. We're all, industry included, not quite sure whether we're mechanics, carpenters, architects or scie…

True. Testing for sysadmins is easier: you're after a way of thinking . So a competence test ("can you do what you claimed?") with a freeform "keep notes on your thinking along the way" is quite informative. You still need to interview, of course. I confess I don't know how I'd apply this to developers. They pass fizzbuzz, OK - what do you do next?

For developers that have the academics, but not the experience, I've always said that the industry needs to adopt the apprenticeship programs that other trades have. Where you do a mixture of work for the company, and trade schooling run by the industry to teach you the specific skills you need.

For example, an IBEW apprentice will do a lot of gruntwork on the job site. Pulling wire, for instance. But they'll get exposed to how things are done, to trade industry expectations, and what a project looks like from start to end. Part of the week, they spend in a classroom learning the specifics of their trade. Not just the high level theory, but the nitty gritty, based on real world applications and problems. This apprenticeship lasts from 2-5 years depending.

I don't see why this model wouldn't work really well with programming.

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

#149
post #84

Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information. This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful i…

A nice simple test that I like to give as a first-wave elimination: Have a computer setup and running (all properly configured). Pull the network cable out of the jack a little bit (so it looks like it's plugged in but isn't). Ask the person being interviewed to show me an IP being used by microsoft or google. (so ping/dig/nslookup/etc) Let the person know that (a) the computer is in working condition (i.e. no driver…

>Let the person know that (a) the computer is in working condition (i.e. no drivers are missing) (b) the network works (i.e cables are good, switch is good, DHCP is enabled, etc.)

So you lie to them? I don't understand what the point of this test is. My first inclination is to open up a term and ping google but I would be pretty annoyed that your "first-wave" test involved actively lying to a candidate.

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

#150

Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information. This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful i…

> 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…

>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 terrorists and forced to recite how to tar/untar stuff on command? (relevant xkcd, of course)

Post reply on HN