Should have sent them a password locked program called *DoorHasBeenCracked". The only thing it does is post passwords to an http server that you control. There is a good chance they try their own password on it. New school phishing attack. /s
I was asked to crack a program in a job interview
201–210 of 309 posts
Re: I was asked to crack a program in a job interview
#202Earlier 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?
> I confess I don't know how I'd apply this to developers. They pass fizzbuzz, OK - what do you do next?
I know what I would do, just have a 10 minute conversation with them about technology. I can easily figure out just where a person is in regards to their development as a programmer just by listening to them talk about what they're paying attention to in the tech landscape. If they don't blink when I mention Hacker News, I know they're on the right track. Do they know what Go is, or Haskell? Do they have an opinion about Node.js?
These criteria are intended to gauge motivation and enthusiasm in the absence of an impressive track record. If they're capable but not highly motivated, then that's fine so long as you're only hiring them to do stuff inside their comfort zone. We have a Microsoft guy just like that. If they're motivated but not capable, then with coaching they'll be able to do anything. The best way to discover someone's motivation is to get a gander at what they're thinking about when they aren't working.
If you're looking for someone who is motivated and capable, you can eventually find someone like that, but you'll have a hell of a time keeping them. Developers have so many options these days that you need to have at least 3 of: competitive salary, decent perks, fun work environment, a glamorous field; in order to hold on to them for longer than a year.
Most companies are lucky to manage one, if they're very lucky two. Since salary is often the easiest thing to manipulate and honestly the most important to the employee, err on the side of paying too much. It's expensive but not having competent developers is far more expensive.
Re: I was asked to crack a program in a job interview
#203Earlier 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.
yeah! screenshots and logs or it didn't happen!
Re: I was asked to crack a program in a job interview
#204Earlier 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.
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.
Re: I was asked to crack a program in a job interview
#205Earlier quoted context omitted.
> 90% of participants just try to open a web-browser and type in "what is the IP address of google" Oh god.
I don't know why this is downvoted. This is Hacker News, a hacker always uses the least amount of effort (the least number of lines of code for example) to achieve his goal. Windows key + R / "cmd" / Return / "nslookup google.com" then when that fails, "ping 8.8.8.8" and when that fails, "Ipconfig /ALL", then ask "Do you use Dhcp or are ip's assigned?" as I reboot the computer and check the physical connections at th…
dig @8.8.8.8 www.google.com
Re: I was asked to crack a program in a job interview
#206Earlier 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…
As both a developer and admin, it's a little hard for me to not think across the aisle. However, I can think of developers that basically refused to think outside their solo - they tend to fit the type of person that really doesn't like to go too far outside the bounds of their workday tasks. Not saying that everyone is this way, but you wouldn't ask John Carmack to try to think about continuous integration and deployment stuff while he's stuck reading physics books and reading a bunch of papers, would you? Yes, good devs tend to have the curiosity and, more importantly, the concern to think beyond just their immediate day to day concerns of hyper focus and in-depth knowledge.
Sometimes you just need to hire more people or ask the rest of the team to accommodate someone that's that one random oddball. A management book I read mentioned Phil Knight talking about how the Bulls had room for one Dennis Rodman and only one, and made it clear that nobody else can pull the stunts he does without disrupting the harmony.
There's a huge difference between a dev that does something a bit out of ignorance and one out of indignance.
Some companies have developers spend some time in SRE (I believe Google practices this sometimes) so they can gain some insight, but it may not be the best idea for a lot of orgs. It's part of why most orgs that do some form of devops well tend to remove a lot of concerns off the table by using stuff like AWS. Meanwhile, silozation helps people maintain some sanity and focus in larger orgs where there's so much BS work on top of your technical duties.
Sometimes the culture is short-sighted and people are at odds with goals though. I've been penalized by managers and peers for not paying enough attention to my dev duties (which were pretty meh) when I was busy helping support and sales help bring in and retain $2 million in accounts that they later named me on calls as their informal engineering MVP.
But really, being aware of what other people care about in their job is a contentious issue that I mostly think boils down to personality and general ideas of teamwork.
Re: I was asked to crack a program in a job interview
#207Real-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…
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 absurd.
You certainly haven't worked at major IT services firms here in India. I spent early part of working years (around 2006) coding by purely reading books and discussing things with folks on internal mailing list. Because only managers and levels above were allowed internet access.
>>The idea that you would ever have to do something like this in a bomb-diffusing type of scenario with no internet and a ticking clock, would only test if you have already solved the problem before, not whether you could investigate a new problem.
This is unfortunately true even for coding interviews. Most algorithm questions are impossible to answer unless you have rote memorized the algorithms and their implementations.
Re: I was asked to crack a program in a job interview
#208Earlier quoted context omitted.
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".
That quote from Shykes could be paraphrased "it's safest to assume breakout by uid0 is possible." I understand the academic/hacker interest in identifying the exact avenues for breakout, and why vague articles are disappointing. My point is, it's important everyone understand it's not to be considered secure, even if we can't/don't name the vulnerabilities off the top of our heads.
Fair enough. I agree with you.
Re: I was asked to crack a program in a job interview
#209Re: I was asked to crack a program in a job interview
#210This 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 really cool