|
Everyone has, dude. But my point is that I (and most developers) don't need to think about the bit-twiddling algorithmic side of things. Of course, it's important to know that a certain way of doing things is O(n^2) and so will perform terribly, but I want to think about problems in functional ways and let the compiler/library/whatever decide the algorithmically best way to implement that.
|
#
?
Mar 16, 2018 15:48
|
|
|
|
| # ? Apr 23, 2024 14:11 |
|
|
I'm not trying to debate what should/shouldn't be asked in interviews, I'm just discussing what the most common interviews entail and how to prep to make yourself the most likely to land the arbitrary job interview. In this case, algos are the best way to do such.
|
|
#
?
Mar 16, 2018 15:50
|
|
|
The most common interviews for Silicon Valley tech companies, maybe. It's probably a cultural thing on that side of the pond, as I've never been asked to do anything like that in any interview, nor have I ever asked someone to. Pair programming something simple is a good enough predictor (in my experience) of whether someone is a joker or not.
|
|
#
?
Mar 16, 2018 16:03
|
|
|
Naar posted:The most common interviews for Silicon Valley tech companies, maybe. It's probably a cultural thing on that side of the pond, as I've never been asked to do anything like that in any interview, nor have I ever asked someone to. Pair programming something simple is a good enough predictor (in my experience) of whether someone is a joker or not. I agree 100%, but in my experience (New York) it's largely the same. Of my last round of interviews, some had pair-sessions, some had take-homes, but every single one had whiteboarding of some sort. From things like "do this string algo, then do it recursively" to "write a DAG validator for Gradle".
|
|
#
?
Mar 16, 2018 16:05
|
|
|
Naar posted:Everyone has, dude. But my point is that I (and most developers) don't need to think about the bit-twiddling algorithmic side of things. Of course, it's important to know that a certain way of doing things is O(n^2) and so will perform terribly, but I want to think about problems in functional ways and let the compiler/library/whatever decide the algorithmically best way to implement that. The compiler can't decide fundamental data structures to use for a problem. A really simple example is if I have a collection of values, and I want to check that collection of values to see if a certain value is already in it, I can implement that fine with a linked list but it is the wrong data structure. Nothing is going to stop me from doing it inefficiently in a linked list, it'll even work! But it isn't the right data structure and it won't scale. The whiteboard interview when it is done well is checking to see that you have tools in your bag and that you can correctly identify when to use them. If you can't identify when it is best to use a HashSet vs an ArrayList or when it might be useful to use a binary search vs a sequential search then you are lacking some very clear fundamentals that are important when you are building software at scale. You might be able to talk up the projects you've worked on and make them sound great but you're probably not going to tell me that your get requests take 30s because you chose the wrong data representation for your problem.
|
|
#
?
Mar 16, 2018 16:10
|
|
|
I agree that you have to know when something is going to perform badly. However, I disagree that a good way to check whether someone knows that is to make them implement a search algorithm on a whiteboard.
|
|
#
?
Mar 16, 2018 16:25
|
|
|
Naar posted:I agree that you have to know when something is going to perform badly. However, I disagree that a good way to check whether someone knows that is to make them implement a search algorithm on a whiteboard. So what would you make them implement? The only reason these sorts of things get picked is because they are small enough to implement quickly, but not so brain dead trivial that you find nothing out. Oftentimes, it's because your interviewer was asked to do the interviewer the morning of, and the only guidance they got was googling "compelling interview questions". Interviews in this industry are generally broken, but no real definitive "how to interview correctly" ever really came out, so it is what it is now.
|
|
#
?
Mar 16, 2018 16:36
|
|
|
BurntCornMuffin posted:Interviews in this industry are generally broken, but no real definitive "how to interview correctly" ever really came out, so it is what it is now. There's a fundamental problem, which is that if you figure out a good interview problem, it will get leaked and people looking to get hired will learn how to answer that specific question and look intelligent while doing so. That's why there's such a huge variation in question quality -- everyone's trying to come up with questions on their own that they can be confident haven't been specifically studied.
|
|
#
?
Mar 16, 2018 16:51
|
|
|
I was rather happy with my recent rounds of interviews for NVIDIA: they tailored the technical questions both to my resume (asking about the languages and experience I have on there) and to the job (systems programming stuff mostly concerning C, kernel programming, etc.) I was really expecting at least a first round of generic string manipulation or graph traversal questions but was pleasantly surprised. Way to go, NVIDIA. Star War Sex Parrot fucked around with this message at 17:06 on Mar 16, 2018 |
|
#
?
Mar 16, 2018 16:52
|
|
|
On that tangent into the mystical realm of interview philosophy: - First off, I read their CV. How many years experience do they have? What would I expect them to know, given that? I tend to assume they are competent developers after a few years and I don't need to actually ask things like 'when would I use a vector over a list', but it does help me gauge whether they know more/less than I think they ought to. - Get them to do a pair programming exercise with me, in a vaguely TDD kata style. Very generic problems like 'hey, a bank wants to implement a bank account' tend to work well, but you can also go to classic programming things like the Game of Life if you want to tease out data structures a bit more. - Watch how they write code. Are they actually able to function on a basic level as a developer? Surprisingly many people aren't. Do they write tests? Again, bizarrely many people don't. Are they pleasant to work with? Is their code actually nice, or is it a mess? - When they're finished, push them a bit. How would you extend that example? Why did you use data structure x over y? - Get them to draw an architecture diagram for a system they've worked on. Can they explain it properly? Can they say which bits could be improved? - Generic chat about the company/whatever, the secret aim of which is to check whether they've been bothered to show enough interest to think of decent questions and can sometimes throw up red flags if they ask things that no reasonable person would ask. I'd be interested to hear how others interview candidates!
|
|
#
?
Mar 16, 2018 16:58
|
|
|
I got asked during a phone screen “can you tell me how to implement a red-black tree?” and my answer was “no.” But I gave its rough performance characteristics and described when I would use it and said that if I needed to actually implement one myself I could just go look it up. Made it to the on-site (but failed that).
|
|
#
?
Mar 16, 2018 17:19
|
|
|
The only interviews I've conducted so far are the "review a candidates submission" - type. I usually ask about why they have so few tests or why the tests suck poo poo. The answer is always the same "this is a takehome assignment and I got lazy". Hiring for my team is going great!
|
|
#
?
Mar 16, 2018 17:24
|
|
|
Naar posted:I agree that you have to know when something is going to perform badly. However, I disagree that a good way to check whether someone knows that is to make them implement a search algorithm on a whiteboard. I agree to an extent. I don't think implementing a binary search on a whiteboard is too much, but something like quicksort is a bit much. I would personally even be ok with an imperfect binary search that has off by 1 issues or something. I would say implementing a DFS or BFS is fair game, but I wouldn't expect someone to implement Dijkstra or A*. Even with DFS and BFS I'd care more about identifying that they are the appropriate algorithms to use for a problem rather than a perfect implementation from memory. Inverting a binary tree is simple enough that I would expect even the maker of homebrew to be able to do it 
|
|
#
?
Mar 16, 2018 17:25
|
|
|
Jose Valasquez posted:Inverting a binary tree is simple enough that I would expect even the maker of homebrew to be able to do it  All of the things you listed are fair game, to me. I wouldn't go into an interview at this point not knowing them, save for maybe A*.
|
|
#
?
Mar 16, 2018 17:29
|
|
|
I would add toolset, test, process/methodology questions for good measure. Weaknesses I frequently see slip through the cracks at my employers and clients include: - Not knowing how to use Git/scm or poor commit habits. - Poor/no testing habits. This includes lack of automated tests, lack of knowledge of static analysis toolsets. - Lack of knowledge in toolchains (i.e. Build management tools, packaging and distribution methods). - Lack of mindfulness in modifying existing code (does this fix the root cause? Are there side effects? Is there tech debt and how much? Will the next developer want to kill me after working with my code?) I always seem to end up being the guy who has to push for and eventually implement and administrate development cycle governance, then train my peers on Git (had a few people who never used scm before), code review tools, and general DevOps (much as I hate to use the word). I'm not sure if it's an industry thing, an outside the Valley thing, or just me having higher expectations than normal, but it's definitely a concerningly recurring pattern in my career so far. What's bad is, as I'm studying the infosec/adversary space in my own time, I'm finding even further concern regarding this because lovely attitudes about code quality and life cycle governance seem to be a big part of how these headline grabbing vulnerabilities and attacks are made possible. BurntCornMuffin fucked around with this message at 17:54 on Mar 16, 2018 |
|
#
?
Mar 16, 2018 17:40
|
|
|
In the London Ruby scene there is one take home test that was invented 13 years ago at a company I later worked for, and I have given or been given that same coding task dozens of times as it then spread throughout London. Same fundamental hiring problem, just a different set of expectations. (FYI that coding test asks you to implement a few classes and rules to see how you do it, what data structures you use, and whether you write good tests) Oh and, yeah, I don't even know what a red/black tree is. I know A* has something to do with pathfinding. I can remember what bubble sort is but I don't know what quicksort is. I know the performance tradeoffs of a hash(table) vs an array vs a linked list (even though my language doesn't distinguish between the two) and *that's it*. I'm (genuinely) curious what work you do that requires that knowledge. Jaded Burnout fucked around with this message at 18:09 on Mar 16, 2018 |
|
#
?
Mar 16, 2018 18:06
|
|
|
Quote is not edit.
|
|
#
?
Mar 16, 2018 18:08
|
|
|
Jaded Burnout posted:I'm (genuinely) curious what work you do that requires that knowledge. Nothing, but it's something that might be asked so I better know it if I want to find a job that pay$$$$ the bill$$$ good. I'm sure I could find other jobs, I'd just rather over-prepare to minimize the amount of time I have to search. Which begs the question: do you really know how good the job will be based on the interview process? (No) Our take-home assignment is "distributed grep". Once again, I'll post it when I leave because the reqs are pretty ridiculous for a take-home.
|
|
#
?
Mar 16, 2018 18:19
|
|
|
Good Will Hrunting posted:Nothing Then it kinda feels like you saying a bunch of algos are "fair game" to be asked is some kind of Stockholm Syndrome / cargo culting / "pay your dues" mentality. "I need to know them because someone might ask them and someone might ask them because I need to know them"
|
|
#
?
Mar 16, 2018 18:28
|
|
|
Jaded Burnout posted:In the London Ruby scene there is one take home test that was invented 13 years ago at a company I later worked for, and I have given or been given that same coding task dozens of times as it then spread throughout London. Quicksort is used by std::sort in C++ and Arrays.sort in Java in some cases. I'm most familiar with A* from my college AI course for pathfinding for games, but it can be used for other kinds of graph traversals as well.
|
|
#
?
Mar 16, 2018 18:34
|
|
|
Jaded Burnout posted:Then it kinda feels like you saying a bunch of algos are "fair game" to be asked is some kind of Stockholm Syndrome / cargo culting / "pay your dues" mentality. These are fairly standard questions to be asked in back-end interviews at my experience level, at a wide range of companies, and I'm fairly certain if we polled this thread or HN or some arbitrary source of interviwers and interviewees we would get a way higher than 50% "yes" for these being standard interview questions. Whether they're "good" is an entirely different question. They are essentially necessary, in my experience. I'll be more mindful of sharing each and every interview I have with the thread this go around 
|
|
#
?
Mar 16, 2018 18:38
|
|
|
Good Will Hrunting posted:
Are you allowed to use existing map reduce tools?
|
|
#
?
Mar 16, 2018 19:15
|
|
|
mrmcd posted:Are you allowed to use existing map reduce tools? We've gotten two implementations and they've both been super basic and didn't ask to use any existing tools. The assignment specifies that you must design the RPC functionality, but I don't know what my boss would say if someone asked to use Hadoop. Most people just tell us to gently caress off.
|
|
#
?
Mar 16, 2018 19:29
|
|
|
Good Will Hrunting posted:We've gotten two implementations and they've both been super basic and didn't ask to use any existing tools. The assignment specifies that you must design the RPC functionality, but I don't know what my boss would say if someone asked to use Hadoop. Most people just tell us to gently caress off. So most people get it right
|
|
#
?
Mar 16, 2018 19:31
|
|
|
Jose Valasquez posted:So most people get it right Really, are you paying them for their time lol
|
|
#
?
Mar 16, 2018 19:50
|
|
|
The honor to complete this assignment and work for my VP is enough. Also, he continues to not request my review on PRs, even on code I've touched or written, ever since our little verbal altercation. My team lead knows it's a passive-aggressive move, we've talked about it, but he's too much of a wimp to bring it up to management. It's a real bush-league move on VP's part but not surprising from a huge petulant loving man-child.
|
|
#
?
Mar 16, 2018 19:59
|
|
|
What would people regard as a good take home? I would imagine about 8 hours of work involved, maybe a simple webservice+front end? That way it's thorough, but no more invasive than a big 5 interview.
|
|
#
?
Mar 16, 2018 20:11
|
|
|
If a company asked me to spend a full work day on a take-home, I'd tell them to gently caress off. Something that's estimated to take two hours is pushing it a little for me, but I might play ball if I like the company.
|
|
#
?
Mar 16, 2018 20:24
|
|
|
fantastic in plastic posted:If a company asked me to spend a full work day on a take-home, I'd tell them to gently caress off. Something that's estimated to take two hours is pushing it a little for me, but I might play ball if I like the company.
|
|
#
?
Mar 16, 2018 20:25
|
|
|
fantastic in plastic posted:If a company asked me to spend a full work day on a take-home, I'd tell them to gently caress off. Something that's estimated to take two hours is pushing it a little for me, but I might play ball if I like the company. I'm not saying it's right or wrong; I'm just saying that other people will -- so you're basically self selecting out of the position.
|
|
#
?
Mar 16, 2018 20:45
|
|
|
After my last job I had so much to talk about that I didn't feel the need to do take-homes to prove myself. I've done such little work at my current job, that I'd probably welcome a take-home to prove my chops.
|
|
#
?
Mar 16, 2018 20:55
|
|
|
Pixelboy posted:I'm not saying it's right or wrong; I'm just saying that other people will -- so you're basically self selecting out of the position. I sure am! Those other people are welcome to whatever delights await beyond the 8 hour take home assignment.
|
|
#
?
Mar 16, 2018 21:02
|
|
|
BurntCornMuffin posted:What would people regard as a good take home? I would imagine about 8 hours of work involved, maybe a simple webservice+front end? That way it's thorough, but no more invasive than a big 5 interview. I've heard of companies doing either "addition" assignments or "code review" assignments - ie, here's a webservice, add a new endpoint + frontend for x feature. Or, here's a lovely implementation of x feature, refactor it to fix x problem. Both are much closer to what you would actually do at those companies so you're testing people on things they would actually be doing, but there are a couple of problems. If the candidate is not familiar with the framework, they could be tripped up by small weirdnesses and come off looking much worse than they would with a generic algo problem. Secondly, and more importantly, you absolutely can't use any of the features the candidates come up with unless they're being paid for their time. This can be a hard sell for some management, and it can be difficult to find a "good" example problem. We tried to do a test that was a simple (or so we thought) command line program that took user input and played a game with the user. Think tic tac toe. The results we got were all over the map, and almost none of them ran. It was clear that we didn't define the problem nearly as well as we thought we did, but some of the solutions we received were simply odd. For example, one candidate was setting up some complicated "difficulty settings" module but hadn't even gotten a working prototype done when we received it. Another partially set up a large lobby of players to play each other, complete with authentication. (We very clearly specified that it was only going to be player vs. program) The only time I've had a take home that I liked was when I was assigned a dev at the company as a code reviewer. It was supposed to take about 8 hours (spread out over a week) and I was allowed to check-in something like 3 times IIRC. That really helped, bc I was able to get some quick feedback like "We're actually more interested in how you solve x problem" and "How would you allow y param to scale?" which cleared up some parts of the problem.
|
|
#
?
Mar 16, 2018 21:04
|
|
|
BurntCornMuffin posted:What would people regard as a good take home? I would imagine about 8 hours of work involved, maybe a simple webservice+front end? That way it's thorough, but no more invasive than a big 5 interview. The catch is that there's only 5 big 5s, but there's thousands of other places. Stack 10 of them up in two weeks and you're hosed. And if you're not applying to 20 places in the hope of getting 2 good offers then what are you even doing. It's also going to be a place that biases towards a monoculture of young single people because that's the only people who a) have time for that b) don't know better.
|
|
#
?
Mar 16, 2018 21:05
|
|
|
Jaded Burnout posted:The catch is that there's only 5 big 5s, but there's thousands of other places. Stack 10 of them up in two weeks and you're hosed. And if you're not applying to 20 places in the hope of getting 2 good offers then what are you even doing. Yep. It's self selection for the wrong type of employee for a long-term successful company.
|
|
#
?
Mar 16, 2018 21:18
|
|
|
BurntCornMuffin posted:What would people regard as a good take home? I would imagine about 8 hours of work involved, maybe a simple webservice+front end? That way it's thorough, but no more invasive than a big 5 interview. By preparing for the Google interview I also prepared for every other whiteboard interview. Yeah, it took a ton of free time and a take home assignment probably would have taken less time for that one interview, but if I hadn't gotten the job I would have been immediately prepared to interview at any number of places for no additional effort. All that prep time is transferable whereas take home assignments aren't.
|
|
#
?
Mar 16, 2018 21:42
|
|
|
My favorite two interviews were the ones where they had in depth blogs about their newly refined interview process and the actual interviews were nothing like that and were, in fact, substantially worse. One was Betterment in NYC, which felt like finance bro central. "You'll pair up on a project across 6 hours" turned into "some stupid whiteboard bullshit and SQL optimization trivia" and "30 minutes of TDD pairing (fine) followed by terrible system design questions".
|
|
#
?
Mar 16, 2018 21:51
|
|
|
fantastic in plastic posted:I sure am! Those other people are welcome to whatever delights await beyond the 8 hour take home assignment. Some people may have forcing functions placing immediate employment somewhere above ideal employment.
|
|
#
?
Mar 16, 2018 23:13
|
|
|
Good Will Hrunting posted:My favorite two interviews were the ones where they had in depth blogs about their newly refined interview process and the actual interviews were nothing like that and were, in fact, substantially worse. One was Betterment in NYC, which felt like finance bro central. why were the system design questions terrible
|
|
#
?
Mar 16, 2018 23:13
|
|
|
|
| # ? Apr 23, 2024 14:11 |
|
|
BurntCornMuffin posted:What would people regard as a good take home? I would imagine about 8 hours of work involved, maybe a simple webservice+front end? That way it's thorough, but no more invasive than a big 5 interview. So I found some dumb code I had written, polished it a bit, and sent it off. Accomplished two things: improved the code to make it do the things better (which was something I was planning to do anyway), and got to send them some sample of code that I thought was indicative of my style. So all in all I spent maybe 2 hours that I was planning on spending anyway on it. That's about as much time as I'd give a take-home anyway, so it shows a lot of respect for my time to just ask for code I've already written -- because a lot of people, even those that aren't big on coding in their spare time (that's me, hi, how are you, this code was from 4 months ago) will have a few hundred lines of crappy code sitting around.
|
|
#
?
Mar 16, 2018 23:26
|
|
