Live data from Hacker News

I was asked to crack a program in a job interview

erenyagdiran.github.io

211–220 of 309 posts

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

#211
post #84

Earlier quoted context omitted.

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.

"Check connections" used to be the first rule or something of debugging

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

#212

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?

>>They pass fizzbuzz, OK - what do you do next?

Algorithm tests only measure the number of man hours the candidates spend on career cup daily. Or how good they are rote memorizing things.

There are many ways to check how good a candidate is at doing their actual work. For instance you can take a candidate to a code review and see what kind of inputs they contribute to the discussion. This alone will give you good deal of idea on how well they understand code and quality. There are other ways, like say asking them to write unit test cases for a class- That would give a lot of idea on how they think with regards to breaking and fixing things.

One more way I have after doing basic checks is pair programming, or picking a totally new problem and working with the candidate to see how they think, how they work and how good their communication skills are.

There are many other ways too. Recently I've been given coding assignments for very practical applications, though those turn out to be a little difficult and time consuming. And at times the expectations are very high. Like asking the candidate to complete a whole application in very short times. It can be hectic with your current job, and a family. But generally those are a good indication of how good the candidate will do at their actual work.

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

#213

Earlier quoted context omitted.

Seems like this sort of test should be very effective at finding people who are already reasonably good at the job you're hiring for, but gives you little to no information about how quickly they learn, their willingness to try new things, etc. Given how fast things change, even if you imagine the person staying for only a year or three, learning abilities are nontrivial.

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.

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

#214

Earlier quoted context omitted.

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

That exists, its called a co-op. I couldn't graduate without doing x months of co-op.

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

#215
post #4

This reminds me of the popular binary bomb lab offered in some computer architecture courses: http://csapp.cs.cmu.edu/public/labs.html

That lab was the most fun I've ever had with a homework assignment (too bad my own school didn't offer it...). I got it off the CMU website as well.

A couple of years ago I did a (mostly) full walkthrough of the Binary Bomb, and it still gets a lot of hits during the semester. If anyone is curious: http://www.vedranb.com/post/19338235616/phase-1

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

#216

Earlier quoted context omitted.

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

Do you know if they did anything to mitigate replay attacks? If not, you could potentially capture someone's first call-hope and replay it until they fail.

Presumably no one would want to, but people still like messing with one another for fun. Also, if you discover a vulnerability like that, you could plausibly claim that someone exploited it to bomb your grade, particularly if you used it against a bunch of people.

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

#217
post #71

The post started very well but with the first screen shot, my mind started tingling: What the heck a security engineer is doing in a root shell? An unknown binary sent via an email is run in a root shell. There is also no mention of email source tracking. Hey you are a security engineer you know about weakness of smtp right? Even if this is a virtual machine, I would really reconsider employment of him or sit down an…

First, you don't know if he downloaded the file from this machine. It could even be networkless. Second, instead of a VM, it could be a livecd with no permanent storage attached. That's what I'd do if I had to debug potentially malicious binaries. It's fine to ask, but it's wrong to assume.

Old school virii that could burn your display card comes to my mind. Working with root is always a threat. A livecd is consience but still does not make it fully secure.

I told I am being picky. Most of my concerns may be handled but their are not shown to be.

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

#218

Earlier quoted context omitted.

Yeah, this is an open-book test. Of course, there's tests like user:B5Geek's, where the candidate gets a PC with a slightly-unplugged network cable and has to realise this fact.

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…

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.

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

#219

Earlier quoted context omitted.

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

Do you know if they did anything to mitigate replay attacks? If not, you could potentially capture someone's first call-hope and replay it until they fail. Presumably no one would want to, but people still like messing with one another for fun. Also, if you discover a vulnerability like that, you could plausibly claim that someone exploited it to bomb your grade, particularly if you used it against a bunch of people.

You would have to be in a position to pcap another person's attempt, which would itself be a fairly intense project on a WPA2-EAP network.

Definitely worthy of glory, but probably harder than just doing the project.

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

#220
post #65

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…

You should be assuming Docker is insecure until proven otherwise. Fully isolating a root user with a shared kernel is very difficult.

How do you prove something is secure?
Post reply on HN