Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hiring Is Broken – My interview experience in the tech industry

medium.com

Post reply on HN
Print view View original

661–670 of 693 posts

Re: Hiring Is Broken – My interview experience in the tech industry

#661

Post by p4wnc6 »

ktRolster wrote: post #657
p4wnc6 wrote: post #655

Earlier quoted context omitted.

It's what Netflix does, so your dismissal seems badly placed.

It looks like Netflix has a fairly lengthy interview process, including technical questions: https://www.glassdoor.com/Interview/Netflix-Interview-Questi... They fire people quickly, sure, but they don't "just hire them" either.

Only one or two of those interview descriptions mention anything like the bullshit tech trivia this thread is about. Most describe take-home problems, extended design conversations, and technical sessions that are more like extended conversations.

You seem to infer that the phrase "just hire them" means you do absolutely zero interviewing, which was not my intention.

When I said "just hire them" I meant "do some obvious stuff, like talk about their experience, ask a high-level question and expect a discussiony answer, not short, commoditized trivia, and if based on that stuff it seems reasonable, then just hire them and don't obsess over cramming more dumb trivia filters into the process."

I took it for granted that everyone reading this would understand that basic interview (e.g. talk to someone, ask about their resume items, have a discussion) is always necessary.

The "just hire them" part is meant to say that people should not get stuck up their own ass with trying to put together a ridiculous number of commodity filters up front before getting to that conversation stage, and that the conversation stage should function more like a rolling basis hire than like a process in which you tediously examine every candidate first, then go back and eliminate and re-interview, etc.

I think the Netflix process fits what I'm saying very well.

Re: Hiring Is Broken – My interview experience in the tech industry

#662

Post by chillacy »

dclowd9901 wrote: post #585
chillacy wrote: post #584

Earlier quoted context omitted.

How would you demonstrate that you're capable of implementing that algorithm? Isn't the best way to have them implement that algorithm? (I will admit that this is best done when the candidate has their favorite text editor and internet, and I have had an interview in the past where this was the case, which went well)

I would suggest that you provide the algorithm in process or through formulae, and have the candidate implement it. That's what they'll be doing anyway.

What kind of job do you have where someone tells you the algorithm? I can't imagine my PM saying "Let's count recent events by storing it in a hashmap and using a linked list to track which elements have expired, can you code that up?"

Instead, the PM might say "We need a system which can count how many unique events of each type has occurred in the last 100k requests, with small impact to time, high accuracy, and up to 100mb of space"

But even that would be unusually specific. It would usually be: "the service breaks sometimes, can you figure it out?" And then the engineers figure out that it's because of unusual event distributions, and they figure out what needs to be done, how much space / time they can afford to do it, etc. For instance, do you trade off accuracy by having a periodic job flush old events out of the map? Do you quantize by time to save space at the cost of resolution?

That's what I do at my job, and that's the kind of question I see in interviews. If a candidate is expecting to have the algorithms dictated to them, then I would not consider them to be a software engineer.. coding up a program from a specification would have been a technician's job 30 years ago (now largely automated by compilers, synthesizers (for HDLs), and other tools). The software engineer should be coming up with solutions, which often involve using algorithms and data structures.

Re: Hiring Is Broken – My interview experience in the tech industry

#663

Post by ktRolster »

p4wnc6 wrote: post #661
ktRolster wrote: post #657

Earlier quoted context omitted.

It looks like Netflix has a fairly lengthy interview process, including technical questions: https://www.glassdoor.com/Interview/Netflix-Interview-Questi... They fire people quickly, sure, but they don't "just hire them" either.

Only one or two of those interview descriptions mention anything like the bullshit tech trivia this thread is about. Most describe take-home problems, extended design conversations, and technical sessions that are more like extended conversations. You seem to infer that the phrase "just hire them" means you do absolutely zero interviewing, which was not my intention. When I said "just hire them" I meant "do some obvi…

When I said "just hire them" I meant "do some obvious stuff, like talk about their experience, ask a high-level question and expect a discussiony answer, not short, commoditized trivia, and if based on that stuff it seems reasonable, then just hire them and don't obsess over cramming more dumb trivia filters into the process."

There's a big difference between the words "just hire them" and what you meant by those words.

Re: Hiring Is Broken – My interview experience in the tech industry

#664

Post by hawkice »

tptacek wrote: post #408
neurobashing wrote: post #397

Earlier quoted context omitted.

I recently bombed an interview with a graph theory question. I hadn't done any real from-scratch implementations of that stuff, but I do know enough to discuss it and pseudocode it. They were disappointed, they wanted to see runnable code right there on the whiteboard. I think you're right, you should know basic conceptual computer science. I felt like I did a good job of explaining that I understand enough to do a r…

I spent 2 years writing multicast routing algorithm implementations for an overlay multicast startup I cofounded. The moral equivalents of PIM sparse and OSPF. I wouldn't do it this way again, knowing what I know now, but we did LSA forwarding between nodes the same way a Cisco would flood LSAs over a set of unruly PPP DS1 links. The hard way, is what I'm trying to convey here. Anyways, I interviewed a company my fri…

> The next interview asked me to implement Towers of Hanoi non-recursively.

What? Obviously this isn't a great interview question, but this seems massively pointless. I don't think there is an obvious way of doing this that doesn't just turn the call stack into an explicit stack (which, again, is pointless). And the recursive code is the only code that could possibly be understood by someone whose whole world isn't dominated by understanding those ~12 lines.

EDIT: also, ya know. Who cares. I have not even heard of a software engineering legend where solving anything remotely similar to towers of hanoi was necessary.

Re: Hiring Is Broken – My interview experience in the tech industry

#665

Post by soham »

Context and disclaimer: I run a bootcamp for technical interview prep: http://InterviewKickstart.com.

Your frustration is understandable. But you also have to ask and understand how our industry has come to this point. There are concrete reasons for it, and despite this process not being the best, it's the least evil when hiring is done at scale.

The process is here to stay. If you want to work at some of those companies, don't overthink it. Just prepare for interviews. It'll also give you a refreshing perspective to software development.

Re: Hiring Is Broken – My interview experience in the tech industry

#666

Post by p4wnc6 »

ktRolster wrote: post #663
p4wnc6 wrote: post #661

Earlier quoted context omitted.

Only one or two of those interview descriptions mention anything like the bullshit tech trivia this thread is about. Most describe take-home problems, extended design conversations, and technical sessions that are more like extended conversations. You seem to infer that the phrase "just hire them" means you do absolutely zero interviewing, which was not my intention. When I said "just hire them" I meant "do some obvi…

When I said "just hire them" I meant "do some obvious stuff, like talk about their experience, ask a high-level question and expect a discussiony answer, not short, commoditized trivia, and if based on that stuff it seems reasonable, then just hire them and don't obsess over cramming more dumb trivia filters into the process." There's a big difference between the words "just hire them" and what you meant by those wor…

I disagree. It's pretty obvious that no one would mean to literally hire someone with zero screening of any kind. It's unreasonable to read "just hire them" to mean something that extreme.

Re: Hiring Is Broken – My interview experience in the tech industry

#667

Post by coderKen »

I really do know the feeling of no feedback. I agree that hiring is really broken, only 2 months back I went on various interview rounds for a Front-end position and couldn't quite understand how an Algorithm would help one with CSS floats. I think I was lucky to interview with a Startup that really knew what they wanted and all I had to build was an app. I got the job and I love the job, I don't think I've ever been more in love with my job like this.

PS: The startup's not American, American startups have an inflated ego.

Re: Hiring Is Broken – My interview experience in the tech industry

#668

Post by lawrjone »

p4wnc6 wrote: post #638
lawrjone wrote: post #631

Earlier quoted context omitted.

What the hell sort of library would you crack out to do a breadth first search traversal? This is my main problem with the OP, BFS isn't some arcane complex cryptic algorithm, it's a way of moving through a data structure that becomes natural and very obvious when you think about how you can effectively traverse it for some tasks. If I were ever to want to traverse something in a breadth first search manner, then I w…

> we've still avoided adding another potentially crappy dependency to our project. No, you've just added the crappy dependency == your off the cuff implementation (which is even more work since you have to handle issues and unit testing for it too). > What the hell sort of library would you crack out to do a breadth first search traversal? In Python I would use networkx probably, unless there was a good reason I coul…

In the case where you'd require a bfs to traverse a graph, you're already doing something that is algorithmic, and will otherwise be prohibitively costly if explored in a dfs manner. The most complicated part of this algorithm is highly unlikely to be the bfs itself, with it's highly likely 10 lines of code in total.

In this case, someone who didn't have the time to visualise exactly how the bfs is operating shouldn't be writing the algorithm. Pretending like you don't need to know the details of how it traverses the tree when you needed to choose the specific implementation for this algorithm to be performant is a lie. It's not like Guassian elimination, where the concept is far more abstract, this is a concrete idea of how you're moving through the graph and shouldn't be some black magic.

On top of this, who writes this code and doesn't test that it does what you expected it to do on sample data. If you bfs implementation was bust, then you'd miss nodes or revisit them, which becomes immediately apparent from testing the algorithm you're writing.

> It ought to require an exceptional circumstance to stoop to implementing it myself.

Maybe the problem here is that I see a bfs as a fundamentally simple algorithm. Saying writing it yourself must be an exceptional circumstance sounds about as crazy to me as saying no-one should ever use for loops, they expose you to making mistakes with an index you may forget is zero-based, please use anonymous iterators instead. When something takes 5m to write, is heavily tested by default (as it will be a feature under test anyway and possible flaws will be highly obvious) and is at the same level of abstraction as the code you'll be writing around it, then just write the damn thing.

EDIT - Try writing a BFS that operates on an acyclic graph that outputs the value of each node, that compiles and runs and prints at least two node values that has a bug. Try writing bugs into this, it's actually difficult to screw up.

Re: Hiring Is Broken – My interview experience in the tech industry

#669

Post by dclowd9901 »

chillacy wrote: post #662
dclowd9901 wrote: post #585

Earlier quoted context omitted.

I would suggest that you provide the algorithm in process or through formulae, and have the candidate implement it. That's what they'll be doing anyway.

What kind of job do you have where someone tells you the algorithm? I can't imagine my PM saying "Let's count recent events by storing it in a hashmap and using a linked list to track which elements have expired, can you code that up?" Instead, the PM might say "We need a system which can count how many unique events of each type has occurred in the last 100k requests, with small impact to time, high accuracy, and up…

And, again, I ask "are you under some kind of arbitrary time constraint when you have to create a novel problem solving approach?" Listen, most data theory problems have been solved, but for the ones that haven't, in work, we're asked to come up with a solution, but not in any weird arbitrarily short amount of time.

If your goal is to simply know how someone explores a problem, fine I guess. I don't agree with your approach but I can see your point. But if you expect a working implementation, that's unreasonable in my opinion and I believe you'll be rejecting many fine candidates using that method.

Re: Hiring Is Broken – My interview experience in the tech industry

#670

Post by hunterloftis »

hunterloftis wrote: post #618
stegosaurus wrote: post #4

Is it even just hiring? Every employer I've worked for has made the experience farcical. If not at the start, then over time. You interview for one job, and eventually end up doing something else. A full time career that doesn't pay enough to buy a home. And they say software developers are overpaid. I think the end-game for me is to just go camping with a laptop or something. I'll code for fun, rather than trying to…

> A full time career that doesn't pay enough to buy a home. And they say software developers are overpaid. The average salary for a "software developer" job posting in my city (Charlotte, NC) is $101k. The average income in Charlotte is $53k. The median home value is $167k. 60% of the value of a home in a year is pretty good. I've also lived in Sydney, Mannheim, San Francisco, and Seattle, and I noticed similar econo…

I should also note that the $53k income is household income. Median personal income is $32k, meaning that a software developer makes over 3x the salary of a normal Charlotte resident.
Post reply on HN