5 ms·
> Take note of the time and let them do their thing. Answer any questions they might have as they go. The moment the program outputs the correct answer, take no
by void_mint 5y ago
> Take note of the time and let them do their thing. Answer any questions they might have as they go. The moment the program outputs the correct answer, take note of the time again.
Gross.
> If you decide you want to hire the candidate, the interview must last at least six hours (with an hour break for lunch). Have your engineers interview the person, one by one, for about 45 minutes to an hour each.
Gross. The hardest pass.
> First, the candidate needs to feel they've earned the privilege to work at your company.
Gross. Equally hard pass.
> Second, your engineers need to feel they know the measure of whoever they're going to be working with.
Gross. Random engineers aren't qualified to assess talent or fit. Random engineers _may be_ qualified to pick candidates that match their gender/race biases though.
> and more importantly spend time having a little trepidation about how they did.
I would go so far as to say "Fuck you" to this author.
- tibbar 5y agoHa, I read your comment first and thought you were somehow overreacting, but then I read the piece and I agree with you. The author doesn’t seem to realize that the flavor of interview he’s running is deeply trainable, and that one can become very, very good at tic-tac-toe style questions after a year or two of intense study. But who would do that? Well, a whole lot of IOI/ICPC contestants did. So, he’s mostly just hiring for people who joined the same club as, I assume, himself.
- pedrosorio 5y ago> So, he’s mostly just hiring for people who joined the same club as, I assume, himself. Not so. From the article: > First, I cannot myself pass this interview. Last time I tried, I got the correct answer after about forty minutes or so. I could get it down with practice, but it doesn't matter-- I think slower than I type. That's a no hire. The point of the interview is to hire extremely talented engineers, not engineers as talented as me.
- tibbar 5y agoI think this is mostly a sign that he’s out of practice - he’s a former PhD student working on database tech, the man has spent plenty of time writing algorithms. I’m claiming that he’s under weighting the effects of practice on how well (specifically, how fast) candidates perform here. When people are coding at typing speed, it usually means they’re not really thinking at all - rather recalling a similar template from memory.
- virgilp 5y agoHe even says "I could get it down with practice", it's quite astounding that he doesn't get the importance of preparing for this specific type of test. I've been doing competitive programming in highschool, was decently good at it (got to IOI, got some medals). First year in uni they wouldn't allow us to compete in ACM, by the second year I felt like I was competing with my hands tied due to the lack of practice. One year of pause is all it took. There's _some_ truth in some things that he says though, even though HN doesn't appreciate it. Like, anecdotally, I have a friend who refused a Google offer (when Google was much smaller but still a big-ish name) and went for a startup because the interview problems at the startup were very difficult and he thought they were going to have interesting problems to solve. I took note of that and made sure my interviews were as difficult as the candidate could take it - like, go progressively harder until the candidate is stuck, then back off. This works fairly well especially with just-out-of-university hires, there's a certain type of people that notice it and like being challenged. And they're often very good employees. (of course, what the author suggests in the article is WAY over the top, I'd agree his process is broken).
- lostcolony 5y agoIt's funny. The older I've gotten, the more code I've written, and the slower I am to write code. When I was fresh out of college the 'obvious' approach just appeared, and I was off to write it. Now, any problem I am slow to peel apart in my mind, decide what the best way to approach it is, based on the language I'm using, what I'm feeling right now, readability, maintainability, etc. Tic Tac Toe? Interesting; should I store board state as a 2d array, or a single array? The obvious approach would be to try and play every possible game with backtracking, but perhaps instead it would be simpler to just generate every possible permutation of 5 Xs and 4 Os? Would that work; on the one hand a badly playing O might lose after just 3 Xs, but we could still fill out the board if we 'kept playing', so it maps one to one, so maybe! Of course, then you risk situations where both X and O wins, so maybe not? Also, what about rotations; we could reduce our work by ensuring we didn't try to solve for cases that are just rotations of one another, but is the book keeping of that more work than just brute forcing it, given the constrained nature of the problem? Etc etc. Writing working code matters, yes. But if you're looking for people who think just a few seconds before typing anything, and then seem frustrated they can't type fast enough, you're optimizing for juniors. I hope it's all satire.
- pedrosorio 5y ago> every possible permutation of 5 Xs and 4 Os? Would that work xox --- --- corresponds to two different games depending on where you placed the first x, so no
- lostcolony 5y agoI wasn't actually asking or pondering over it (the answer would in part be determined by what is meant by a "valid game"); I was just presenting a train of thought akin to what I would have in such a situation, examining the question in various lights as to ways to solve it, and generating clarifying questions to ask or ideas to explore.
- enricozb 5y agoBoard state can also be stored as as sets of X positions and O positions.
- b9a2cab5 5y agoIOI contestants (and people that can memorize lots of difficult algorithms) tend to have high intelligence. If you're looking to hire really smart people and you don't care about false negatives, it's a good way to approach the problem. The entire point is to hire people that 1) are interested in exploring algorithms on their own time (i.e. they're interested in more than just getting paid for a job, they're interested in interesting problems too) 2) are competitive and want to win 3) are hard working and intelligent (i.e. they had to study for these competitions and do well in them). You might miss a lot of smart people but it's pretty likely if you ask really hard algorithm questions that you'll filter out any not smart people. If you're reacting badly to this style of interview, that's because you're not their target talent pool.
- tibbar 5y agoActually I’m a fan of algorithms questions! Of course, getting an engineering staff full of IOI medalists is a wonderful situation and will attract more talent. But I and others here are recognizing the role played by practice and grinding on this specific flavor of problem. The author states that intelligence is unchangeable and divides candidates into talent bands - but actually, his test is significantly impacted by factors other than intelligence. His framing is just weird, to be honest. “People who think faster than they can type” isn’t really a meaningful category, yet he’s turned it into a theology of interviewing.
- systemsignal 5y agoWhat a nasty thing to say a random/typical engineer is too stupid to assess talent and is basically racist… Who are you to say such a thing? Is there even a shred of evidence?
- lostcolony 5y agoQualifications != intelligence. Everyone has pre-existing biases.
- void_mint 5y ago> What a nasty thing to say a random/typical engineer is too stupid to assess talent and is basically racist… Quote me in my post where I said these things. Otherwise please don't misquote me. It's text after all, it's pretty easy to copy and paste.
- qPM9l3XJrF 5y ago"Gross... Fuck you" Serious question... how did these kind of fifth grade playground insults become normalized on HN? It's a blatant violation of the guidelines https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and yet somehow comments like this get upvoted.
- void_mint 5y agoYou're welcome to flag my post if you think it's inappropriate. The author of this post is either ignorant or malicious. Some of their behavior is so ignorant or malicious that it warrants direct adversarialism. This blog post is gross. Curious, what about my post included a "playground insult"?
- dang 5y agoThat's obvious: "Gross... Fuck you". Would you please not post like this to HN? It's not what this site is for. No matter how strongly you disagree with someone about $topic, it's not ok to dump poison into the ecosystem. If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
- happythen 5y agoDoesn't read as fifth grade to me. Just has a little spiciness to it, I appreciate that. Think about it, the person could have linked and linked and linked to other articles to back up some point of disagreement. But instead, they shared their own opinion, relatable, easy to follow, and refreshing.
- mikeymz 5y agoI would also go that far
- dang 5y agoPlease don't post like this to HN. It's directly against the site guidelines, which ask you not to fulminate or call names. Maybe you don't feel you owe people who you consider wrong about engineering interviews better, but you definitely owe this community better if you're participating here. I'm sure you can make your substantive points thoughtfully, so please do that instead. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html