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.
I was asked to crack a program in a job interview
211–220 of 309 posts
Re: I was asked to crack a program in a job interview
#212Earlier 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?
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
#213Earlier 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.
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
#214Earlier 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…
Re: I was asked to crack a program in a job interview
#215This reminds me of the popular binary bomb lab offered in some computer architecture courses: http://csapp.cs.cmu.edu/public/labs.html
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
#216Earlier 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…
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
#217The 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.
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
#218Earlier 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…
Re: I was asked to crack a program in a job interview
#219Earlier 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.
Definitely worthy of glory, but probably harder than just doing the project.
Re: I was asked to crack a program in a job interview
#220Earlier 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.