Live data from Hacker News

I was asked to crack a program in a job interview

erenyagdiran.github.io

131–140 of 309 posts

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

#132

Earlier quoted context omitted.

Yeah. I'm thinking of Joel Spolsky's 199/200 who are just the same bozos cycling through interviews until someone hires them by accident ... "devops" is fighting words in our team. Damn, if I could get our devs who'd like "devops" on their CV to give a hoot about the "-ops" half of that buzzword ... when a dev shows awareness of ops issues with their shiny new thing, I make a point of mentioning their name positively…

:) When devs are in the loop it always comes to "working in localhost" debate. I like to say developers are working or living in their isolated bubble. And whenever their code comes out of that bubble and reach the real world ops are on fire. Always the ops guys are in fault. I think every developer should be given sysadmin 101 and 102 lessons.

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 customers are actually like - who think "developer of the whole thing from go to whoa" and not just "coder on my PC." As I'd hope we all do here.)

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

#133

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…

I love this approach. I am good at what I do, and appreciate the opportunity to prove it directly. Spending a couple hours solving a technical problem or writing an essay is much easier for me, not to mention sending a more reliable signal, than trying to figure out what networks / buzzwords / whatnot various people in an opaque organization are going to want to see. Not to mention, it communicates to me that the people doing the hiring know what they want and how to get it, which is encouraging.

I believe there is a happy synergy here, by the way. A candidate who welcomes this type of test -- who sees a direct work sample as the easy and efficient way to prove themselves to you -- is probably someone who knows their work is good.

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

#135

Earlier quoted context omitted.

Nobody puts a gun to applicant's head and forces him to take a test, so... Business is not for people to have jobs but to make profit.

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. :)

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

#136
post #133

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…

I love this approach. I am good at what I do, and appreciate the opportunity to prove it directly. Spending a couple hours solving a technical problem or writing an essay is much easier for me, not to mention sending a more reliable signal, than trying to figure out what networks / buzzwords / whatnot various people in an opaque organization are going to want to see. Not to mention, it communicates to me that the peo…

It depends on the job (see elsewhere in this thread), but if it works then it works really well.

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

#137

Earlier quoted context omitted.

:) When devs are in the loop it always comes to "working in localhost" debate. I like to say developers are working or living in their isolated bubble. And whenever their code comes out of that bubble and reach the real world ops are on fire. Always the ops guys are in fault. I think every developer should be given sysadmin 101 and 102 lessons.

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.

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

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

What if they just tell you, because they've memorized the IP address of Google? You hire on the spot then?

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

#140

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…

When the creators themselves are saying they don't consider it secure, I don't think it's "FUD".

Sorry, I didn't imply what Shykes said is FUD. I meant most of the articles out there about docker security have little to no information other than "breakout is possible".
Post reply on HN