Live data from Hacker News

I was asked to crack a program in a job interview

erenyagdiran.github.io

261–270 of 309 posts

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

#261

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

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

> What is this, preparation for when coders are kidnapped by terrorists and forced to recite how to tar/untar stuff on command?

:-D you never know!

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

#262

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've been in two interviews where they asked me to code without googling or looking at the reference.

Personally, I think it's as absurd as writing shell scripts on a computer with no `man`, or without being able to refresh your memory with ` --help`. Good luck with that!

I was in an interview where they asked me to configure specific firewall rules on a notepad with no access to a terminal, so I couldn't check man iptables for stuff like how to match certain sources/destinations hosts/IPs. And I was not too familiar with the opts (was it --dest, --dst, or -d? and how do calculate the network mask for this range of IPs?). It was also for a junior position so I thought they were taking a piss at me and simply told them so.

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

#263

Earlier quoted context omitted.

http://8.8.8.8 just times out. Why not point it to http://www.google.com or just serve a little javascript redirect or something? Sloppy work Google.

And a DNS server should have an open port 80 (and so an additional attack vector) because...?

DNS over websockets, obviously!

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

#264
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.

No statement in that list is a lie; the computer is in working condition, the network itself works, the cable works, the switch it is connected to is working, DHCP on the computer is enabled. The cable being unplugged doesn't break any of those.

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

#265
post #45

Earlier quoted context omitted.

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

Hmm, as andrewljohnson said, I expect that the posting impacts who applies, but I would expect that to disproportionately turn up applicants who can write C. Another dynamic at play is the fact that those who don't have useful skills apply more often as they continue to be out of work, that doubtless accounts for some of it. Still a bit strange.

In my interviewing experience (looking at the time for something not dissimilar), lots of people think that 'knows C' and 'embedded systems' are the same as "I took a single module involving C at university, and by the end of it, my things were only randomly segfaulting maybe 70% of the time."

Or they've never touched either C or an embedded system in their life, but somehow it ends up on their CV and they tell you about how passionate for learning they are. Which may well be true, but it raises questions about your honesty and/or capacity for introspection. Also, bare-metal embedded really isn't the place to learn C[1], given that most failure modes are "It doesn't work. And maybe something caught just fire."

[1] Ask me how I know...

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

#266
post #253

Earlier quoted context omitted.

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…

If you're not changing your tests on every interview batch you're doing it wrong. 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 onc…

What do you mean by "batch"? Most companies have rolling hiring.

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

#267
post #253

Earlier quoted context omitted.

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…

If you're not changing your tests on every interview batch you're doing it wrong. 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 onc…

This ^ "You only get out of it, what you put into it." goes both ways - employers should expect to extend some effort if they expect their candidates to extend some effort.

I strongly suspected that sometimes goals of the person responsible for hiring are not quite aligned with the company they work for. Example:

Company's goal: Hire an exceptional candidate.

Lazy or overworked hiring manager's goal: Reduce the size of the stack of 1000's of resume's I have to go through using any means possible that will make it appear like he/she actually did the work to find the candidate.

"Lemme see, use keyword search to ditch the ones without 'Github' on their resume'. Now ditch the ones who don't have a college degree. Still some resume's left? OK, how about tossing the ones without a CS degree?"

Run a filter with enough conditions and you can get that pile down to nothing pretty fast. If that is still not enough filtering, ask the candidates to do something very time consuming. This a great way to weed out people who are very busy or exceptional at what they do and don't need to jump through your hoops.

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

#268

Really nice overview of the process. I was hoping to get into debugging and breaking code, but my career took a wild turn away from that part of the job. It's still something I would like to learn, so I'm reading as much about it as I can. I'm going to take this way off topic here, but it's a curiosity of mine. Please don't take this as an insult; it seems to be very common and as a language learner myself I'm just w…

As an additional anec-datapoint here, I've noticed it's a relatively common habit amongst native english speakers who have some degree of dyslexia. I've asked about it once or twice, and the most consistent answer is something like 'I don't even notice I'm doing it; when I finish a word I insert a space, then think about the punctuation and add it on...'

This is not to suggest that this structure indicates dyslexia of course, the rest of this thread has plenty of other good reasons for non-native english speakers and otherwise.

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

#269

So the only way for programs to get data from the outside world is to poll with system calls? I always thought that programs defined a "holding area" that the kernel would write into when it had data - the program still might poll, but it's polling (potentially very small, perhaps a single register) local data rather than making a system call.

Largely, yes. Which is why strace is so useful as a debugging tool. It's also why you want to do buffered IO (read/write in kB at a time) to minimise call overhead.

There is mmap[1] (controlled, unsurprisingly, by syscalls), which will give you a memory region that may be updated transparently for you by the kernel, but in general, it's all syscalls.

The other nice thing about the syscall interface is that it gives the kernel an opportunity to suspend the calling process and schedule something else if it can't fulfill their request right now (hence, blocking IO), so you're not actually polling. Of course, a preeemptive scheduler (like everything actually is) can step in and suspend you anyway, but the syscall is a nice place to do it cooperatively.

[1] https://en.wikipedia.org/wiki/Mmap

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

#270
post #218

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…

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.

Not sure that's a good test either. When tasked to figure out something as part of a job, by a manager one knows and trusts, who takes feedback of "I don't know how to do this but I will investigate it", a person may act one way, whereas being tasked with someone's PhD thesis by a stranger on an interview may lead to a very different response.

I know I am far less tolerant of bullshit interviews than I once was, and would have far fewer qualms vocalizing what I'm thinking - "I don't know. If I saw this in real life I'd check Google, because it reads exactly like the sort of contrived problem used in interviews and thus is well documented, and likely solved quickly by those who have memorized it. I am not one of those. I'll take a stab at it now if you just want to see how I reason through it, but if coming up with an efficient, correct implementation is part of your criteria we can probably save both of us the trouble" - is that considered acting like an ass?

Post reply on HN