I don't know where you find candidates that can even approach this level of skill or desire to solve puzzles. Most people I interview struggle with a few lines C program coding.
I've found that your job post determines the types of candidates you get. If you describe a really hard programming job, people self select out. If you describe an easy one, everyone applies. iOS developer? Floodgate. Crypto expert? Trickle.
I was asked to crack a program in a job interview
221–230 of 309 posts
Re: I was asked to crack a program in a job interview
#222Earlier 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…
For any person who claims to have years of Unix experience, they can easily do anything they want using man pages. Though I agree with you on the general premise though. One must be allowed to look up information they need to solve a problem. >>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 absur…
By complex, I mean the question should be difficult enough that you can't easily hold every parameter, case and step in your head: I want to see how you deal with situations that you have to mentally walk through and issues that you might lose track of.
By potentially elegant, I mean both brute-force and optimal solutions should be able to fit on a small whiteboard, without requiring more than 2-4 variable declarations and no more than a nested for loop (or some sort of recursion). The optimal solution shouldn't require putting together pieces that they aren't really expected to know/use, i.e. no more complex than arrays, maps, strings and ints, and any other "data structures" the candidate ought to know, given their background. For instance, if they claim to be a crypto expert, they should know how to use a black box that gives them private and public keys.
By straightforward I mean, you don't want the candidate to have to have an "aha" moment. If you're asking for them to write a max-flow variant, you'd better be explicit that you don't mind a really brute-force solution, or most of the interview will be spent trying to remember complex algorithms. Is the algorithm one that you can understand by walking through test cases/figuring out what steps you took in your mind to go from input to output? If it takes more than that, you're going to get a few false positives, i.e. "Wow she was great! No one's answered this so fast!" (because she just spent 20 hours doing this on a homework), and many false negatives.
Re: I was asked to crack a program in a job interview
#223Real-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…
You should always remember that hiring is as much about persuading the best person to say yes to a job offer as it is about weeding out the bad people.
Re: I was asked to crack a program in a job interview
#224Earlier quoted context omitted.
>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.
All he said was that everything was in working order. He didn't say that the cable was fully seated into the receptacle. Your first inclination would challenge your assumption and you would likely follow the stack down to the wire. At that point you'll note that the link lights are off and reseat the cable.
This means - to me - that the network... well, works. And it clearly does not. If this was a Windows machine I'd probably wonder what the hell was going on with the Ethernet (!) sign in the bottom right of the tray and if it was a decent version of Ubuntu (11.x or earlier) then you'd also notice it quickly.
But still. He's pretty obviously leading the person astray by giving him the solid impression that the machine is in good working order. (which it is not) If you mean to say that he didn't CLEARLY specify that the "cable was fully seated..." I don't know what to tell you. That's a "gotcha" question. Not a good diagnostic one. Unless this is for a $12/hour CSR position. In which case, OK fine.
Re: I was asked to crack a program in a job interview
#225Earlier quoted context omitted.
>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
#226Earlier quoted context omitted.
>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.
If this is a user-facing tech-support position, then it is a hard job requirement that the candidate be able to handle being lied to by the user. I don't care what they say, they didn't check the cable, they didn't reboot, and they most certainly didn't not do anything that might have caused the problem.
Yes, I agree. Are we supposed to also assume that our bosses and interviewers lie to us, too? At no point does he say that he is emulating a user that needs support help.
Re: I was asked to crack a program in a job interview
#227Earlier 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.
If you can't solve a problem with only some information, and some of it incorrect, then how are you supposed to be able to help?
Re: I was asked to crack a program in a job interview
#228This 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…
That's clever, although I would have just pulled the plug. Server handshake so you can't run the program while offline? Well, that can be analyzed.
Re: I was asked to crack a program in a job interview
#229Earlier quoted context omitted.
If this is a user-facing tech-support position, then it is a hard job requirement that the candidate be able to handle being lied to by the user. I don't care what they say, they didn't check the cable, they didn't reboot, and they most certainly didn't not do anything that might have caused the problem.
>If this is a user-facing tech-support position, then it is a hard job requirement that the candidate be able to handle being lied to by the user. Yes, I agree. Are we supposed to also assume that our bosses and interviewers lie to us, too? At no point does he say that he is emulating a user that needs support help.
Re: I was asked to crack a program in a job interview
#230Earlier 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?
The ability to solve common problems acts as a good proxy for experience, If they can't google how to fix a retain cycle or a broken constraint, we know they probably don't know what they're talking about.
The ability to build a good, small system on top of the broken app acts as a good proxy for development talent. If they can't easily set up a dead-simple delegate to do an asynchronous web call, they can't hack as a mobile developer.
Most importantly, if they don't care enough about the job to take two hours to whip up a super-simple app, then we don't have to waste our time interviewing them.