4 ms·

To offer an alternative viewpoint: I have a degree in pure mathematics from a highly ranked institution. I published research as an undergraduate. I went to mu

• EnderWT 8y ago
  I interview for my company, too, and don't ask these kinds of algorithm questions because the reality is these problems aren't typical of day-to-day work for the positions we are hiring for. I'm interested to know what your interview process is. If you wouldn't mind sharing, how does the interview process work at your company?
  • nilkn 8y ago
    We have the candidate sit at a workstation and write a functioning program to solve a relatively realistic but self-contained problem using the language of their choice. It usually involves extracting and working with some data from a few big CSV files -- we have pretty legitimate datasets set aside just for the interview. There really aren't any restrictions during this: the candidate can use any resources they would normally use, including Google or Stack Overflow. We don't have the interviewer watch everything they're doing over their shoulder. They're allowed to just work on the problem on their own.
• kamaal 8y ago
  >>You mention diff(1), but who's to say the author(s) of that tool would've necessarily solved this problem on the spot? I think this is the gist of the all problems facing the current interview process. There is a big difference between inventing a solution to a problem, and learning the solution to a problem which some one invented. The latter shows nothing about the ability or even the way in which a person thinks or even works. It just shows the person was able to scale multiplication table memorization skills to other things as they grew up.
• saulrh 8y ago
  If you really want to compare science dicks... Read GEB in fourth grade. Started and ran a high school robotics club that repeatedly sent multiple teams to FTC national championships. Degree in computer science from a highly-ranked institution and I do mean CS, not software engineering; I focused on AI and CS theory. Published research as an undergraduate. NSF GRFP fellowship. Health issues and my professor's sudden death are why I didn't finish a PhD in Robotics. I agree that software interviews are fundamentally broken. I agree that the "traditional" tech interview is optimized to minimize false positives and that this feels unfair. I agree that small companies can do a slightly better job, mostly because there's a chance for a small team to have zero bad eggs and because they're more likely they send architects to interview interns. But small companies also give some of the worst interviews because they don't have enough good people to suppress the assholes. I've also heard of small companies going bad because they accidentally hired an asshole who then contributed to more hiring errors. I haven't heard of a single company that can believably claim to have a solution that is scalable, error-tolerant, and not slightly distasteful. Honestly, if your company can consistently hire good people at scale, what are you still doing writing software? Go do that for Microsoft or IBM or Google and collect your blank check. I worked in Atlanta for a few years; the demand for software engineers was maybe just a tiny bit elevated. The company I was at laid off its entire ATL R&D office due to an amazing communications fuckup at the C-level, >50 software engineers with zero warning. Recruiters were calling peoples' cell phone before the meeting was over, most people were getting an offer from every interview. Aaaand every single offer was a ninety-day contract-to-hire. Ultimate accuracy, right? Time to settle in and ramp up, time to see you at your best, etc. Yeah, turns out that most places can't really evaluate the quality of software engineers they've had for years, much less after ninety days. Politics, discrimination, "forceful personalities", the difference between productivity and churn, blah blah blah blah blah. Plus those ninety-day contracts can be flat-out abusive if not handled well, subpar pay and benefits and so on. On "deep thinkers" - Yes, there are people that can do magical things when given time. But I've never met such a person who wasn't also damned good all around. The fantastic mentors and master engineers and world-class professors all did magical work partially because they could blow through the chaff to expose and then engage the important parts. They got better when they had time, but I wouldn't have said they'd ever be at a disadvantage due to time pressure. But I suspect that that's not actually who you're thinking of here. Rather, I've met a bunch of brilliant people with crippling anxiety and stress disorders. Them? Yes, they are absolutely at a disadvantage in the traditional software interview. They're also spectacularly disadvantaged in interviews in every other field, ranging from fast food burger-flipper to professor, and in every other test-type setup you can think of. Like you said, you need to give them some space and maybe a couple weeks to relax. They are why I don't like interviews in general, same way I dislike standardized testing and such. I'm just not sure what would be better. Certainly something where they have more time and less pressure, but you can't back off too far because then you run into contract-term abuse and unpaid-internships-as-interviews. :/ Edit: > many developers who wouldn't necessarily ace them in 40 minutes under tightly controlled conditions can nevertheless come up with perfect solutions in a normal work context, should the problem actually arise. I'll note here - when I interviewed with Google, I did get an offer despite clearly flubbing a couple of their questions. I think that many people, when they're thinking about or imitating the Google interview, miss that they aren't looking for your answers. They're looking for your thinking. Flawlessly regurgitating the answer gives them no useful information about how you'll do "in real life". Same with producing an answer that you can't explain. Which exposes another subtlety that I think people miss; you must choose problems that wouldn't come up "in real life" because you can't go around giving huge advantages to people who are lucky enough to have actually encountered and addressed them. So you have to find questions that must be engaged with the way a real problem would be but are exotic enough that they wouldn't come up. Which I expect is also why you tend to see weird theory questions; it's a much broader solution space to sample from. There's a reason that I started my comment by saying that I use that kind of thing all the time. :P