|
A better answer is knowing what kinds of problems tries are good for and being able to recognize them. Same with hash maps, linked lists, stacks. Like you can whine about how "nobody implements basic data structures in real life," but you can refresh almost all the basics of that stuff in a few hours on Wikipedia. If you are given a problem roughly structured as having frequent random read/write behavior, and you throw a linked list up there on the board, that's a problem. It might pass all relevant unit tests but as soon as you throw any real load at it the thing will fall over and die.
|
#
?
Jun 14, 2018 01:41
|
|
|
|
| # ? Apr 23, 2024 11:02 |
|
|
TooMuchAbstraction posted:autocompleting words is the only practical one I can remember off the top of my head. :shh: Don't reveal the interview (it was basically a data structure to do something similar to this via a word problem around a real problem they had seen recently). The thing that kept throwing me off was I wanted to draw and scratch down some pseudocode they wanted me to type code it seemed. Otherwise I would have probably finished it a bit faster. I'm ok with these types of problems, and today was a good experience. Had I gotten bounced I wouldn't have been too upset because I a.) felt like I understood the problem and what structure to use and what modifications it needed b.) will get much better at coding on Coderpad type sites with practice in interview environments c.) my interviewer did a really good job of discussing it with me and picking my brain on things. Good Will Hrunting fucked around with this message at 01:55 on Jun 14, 2018 |
|
#
?
Jun 14, 2018 01:49
|
|
|
I've never been asked any of those weird algo questions in an interview before, and I'd probably not be very enthusiastic about a company that used them. Not to say it would be an immediate red flag, I'd put it in context of the rest of the interview process, but when I think of the employees I'm going to potentially work with and I picture a whole bunch of people who memorised algo trivia for the interview I'm less than enthused.
|
|
#
?
Jun 14, 2018 03:04
|
|
|
Got my agenda for my first on-site tomorrow. It's my top pick place and both teams sound cool. I'll leave knowing if they're cool or not I suppose because it's 6 hours and I'm meeting with 9 people. (Nice) How anyone's brain isn't mush by the end of three hours is a mystery to me. Good thing I live in New York City and my salary affords me plenty of cocaine and addy to blast.
|
|
#
?
Jun 14, 2018 03:10
|
|
|
Good Will Hrunting posted:Got my agenda for my first on-site tomorrow. It's my top pick place and both teams sound cool. I'll leave knowing if they're cool or not I suppose because it's 6 hours and I'm meeting with 9 people. The last two times I went through those all-day interview gauntlets, my brain was total mush by the end. It's way too long, IMO...2 or 3 hours is the sweet spot. Try and stay away from high-carb food that'll make you crash and take it easy on the caffeine. Good luck, you'll do fine!
|
|
#
?
Jun 14, 2018 03:49
|
|
|
a hot gujju bhabhi posted:I've never been asked any of those weird algo questions in an interview before, and I'd probably not be very enthusiastic about a company that used them. Not to say it would be an immediate red flag, I'd put it in context of the rest of the interview process, but when I think of the employees I'm going to potentially work with and I picture a whole bunch of people who memorised algo trivia for the interview I'm less than enthused. It's far more likely that you're working with people who have good CS fundamentals. It's pretty obvious if someone has memorized a solution versus understanding it and that tends to get you rejected. My personal experience, based on two companies who had tribal questions and two companies with algorithm based questions, is that it weeds out the people who can't code, bottom 50, and leaves you with an above average workforce which leads to a much more productive work environment. Also everyone focuses on the odd questions, about tries, red black trees, whatever, but you're far more likely to get questions around hashmaps, graphs, and generic or binary search trees.
|
|
#
?
Jun 14, 2018 04:22
|
|
|
ForrestPUMP69 posted:The last two times I went through those all-day interview gauntlets, my brain was total mush by the end. It's way too long, IMO...2 or 3 hours is the sweet spot. Thanks! I have literally no idea what to expect besides lots of breadth in the interviews. Like 4 of the interviewers are way younger than me, which is strange? But we'll see.
|
|
#
?
Jun 14, 2018 04:23
|
|
|
asur posted:Also everyone focuses on the odd questions, about tries, red black trees, whatever, but you're far more likely to get questions around hashmaps, graphs, and generic or binary search trees. Yeah like 80% of my hard interviews were straightforward graphs and graph algorithms. I think the most obscure algorithm question I got (that I know) was answered by simply identifying a heap sort as the best sorting option in a particular case. Which made me happy because I happen to think heap sort is really pretty.
|
|
#
?
Jun 14, 2018 04:35
|
|
|
So my new job tried to spring a mandatory arbitration agreement on me a month after being hired, and I told them management I wouldn't sign it because mandatory arbitration is fundamentally awful and a blight on society (yes, literally those words). So, I guess we'll see how that percolates out.
|
|
#
?
Jun 14, 2018 04:55
|
|
|
Roadie posted:So my new job tried to spring a mandatory arbitration agreement on me a month after being hired, and I told them management I wouldn't sign it because mandatory arbitration is fundamentally awful and a blight on society (yes, literally those words). So, I guess we'll see how that percolates out. Pretty sure all of my salaried jobs have had arbitration agreements.
|
|
#
?
Jun 14, 2018 05:01
|
|
|
asur posted:It's far more likely that you're working with people who have good CS fundamentals. It's pretty obvious if someone has memorized a solution versus understanding it and that tends to get you rejected. My personal experience, based on two companies who had tribal questions and two companies with algorithm based questions, is that it weeds out the people who can't code, bottom 50, and leaves you with an above average workforce which leads to a much more productive work environment. But if you're testing their understanding of the concepts surely there are much better ways to assess that than relying on esoteric knowledge that even a candidate WITH a good understanding of the underlying concepts may not possess. Like, actually asking them questions about the underlying concepts instead of asking them to recite algorithms.
|
|
#
?
Jun 14, 2018 06:32
|
|
|
a hot gujju bhabhi posted:But if you're testing their understanding of the concepts surely there are much better ways to assess that than relying on esoteric knowledge that even a candidate WITH a good understanding of the underlying concepts may not possess. Like, actually asking them questions about the underlying concepts instead of asking them to recite algorithms. A good whiteboard interview isn't about reciting obscure algorithms or implementing complex data structures, it is about identifying which simple algorithm or data structure can solve a problem. Yeah that may mean brushing up on some simple algorithms like DFS and binary search but that is hardly esoteric knowledge.
|
|
#
?
Jun 14, 2018 12:47
|
|
|
Jose Valasquez posted:A good whiteboard interview isn't about reciting obscure algorithms or implementing complex data structures, it is about identifying which simple algorithm or data structure can solve a problem. Yeah that may mean brushing up on some simple algorithms like DFS and binary search but that is hardly esoteric knowledge. A large number of whiteboard interviews are not good. Not sure whether I prefer the failure mode of the interviewer not understanding their own question, criticizing any solution other than the one they came up with (even if it’s objectively worse), or using the interview as an opportunity to tell the candidate how smart they are more. Though I guess none of those are specific to whiteboard interviews. 
|
|
#
?
Jun 14, 2018 14:06
|
|
|
leper khan posted:A large number of whiteboard interviews are not good. Not sure whether I prefer the failure mode of the interviewer not understanding their own question, criticizing any solution other than the one they came up with (even if it’s objectively worse), or using the interview as an opportunity to tell the candidate how smart they are more. Oh, I agree, most whiteboard interviews are probably terrible but I don't know that those interviewers would be any better with a different format of interview.
|
|
#
?
Jun 14, 2018 14:45
|
|
|
We should start calling them "white bread" interviews so all the millennial techbros start avoiding them.
|
|
#
?
Jun 14, 2018 15:11
|
|
|
asur posted:It's far more likely that you're working with people who have good CS fundamentals. It's pretty obvious if someone has memorized a solution versus understanding it and that tends to get you rejected. My personal experience, based on two companies who had tribal questions and two companies with algorithm based questions, is that it weeds out the people who can't code, bottom 50, and leaves you with an above average workforce which leads to a much more productive work environment. I don't disagree with this outright, but if I went to an interview and you asked me to do something with a trie I'd probably end up saying something stupid like "try what." We wouldn't even be able to advance to the problem solving portion until you drew out the structure for me and told me how it worked. I don't see how using rarely known data structures is anything but a filter for elitists. I think it's worth focusing on the odd questions because apparently people are asking them.
|
|
#
?
Jun 14, 2018 16:22
|
|
|
It was a word problem just FYI. I deduced that the best way to solve it would be a trie-like structure. Nobody ever said "trie".
|
|
#
?
Jun 14, 2018 16:23
|
|
|
Good Will Hrunting posted:It was a word problem just FYI. I deduced that the best way to solve it would be a trie-like structure. Nobody ever said "trie". Fair enough.
|
|
#
?
Jun 14, 2018 16:24
|
|
|
Huh. I encountered tries in high school, college, open-source, interviews, and at work. I'm finding it hard to digest that they'd be considered esoteric. If I were interviewing, I'd consider not knowing that tries exist a major negative signal, though I'd understand people not recalling them exactly since it wouldn't be terribly rare to not encounter them at work/open-source/interviews. Just learn tries. If you have a mostly-static set of data you want to search through, you can frontload the computation and make searching pretty fast, or even ship the trie from a server to a phone as a sort of search index (depending on the size of the dataset of course).
|
|
#
?
Jun 14, 2018 17:59
|
|
|
Doctor w-rw-rw- posted:Huh. I encountered tries in high school, college, open-source, interviews, and at work. I'm finding it hard to digest that they'd be considered esoteric. If I were interviewing, I'd consider not knowing that tries exist a major negative signal, though I'd understand people not recalling them exactly since it wouldn't be terribly rare to not encounter them at work/open-source/interviews. Just learn tries. If you have a mostly-static set of data you want to search through, you can frontload the computation and make searching pretty fast, or even ship the trie from a server to a phone as a sort of search index (depending on the size of the dataset of course). This is the wrong answer and is exactly what's wrong with interviewing in this field. Good generalized questions need to come from more than your own personal experience. A trie is not in the subset of data structures that the majority of our community has agreed represents basic foundational knowledge. If you don't know this you are a part of the problem. Specifically if you think not knowing what a trie is is a negative signal.
|
|
#
?
Jun 14, 2018 18:13
|
|
|
Agreed. Major negative signal my rear end.
|
|
#
?
Jun 14, 2018 18:23
|
|
|
Portland Sucks posted:Specifically if you think not knowing what a trie is is a negative signal.
|
|
#
?
Jun 14, 2018 18:41
|
|
|
I had never heard of tries until I started prepping for algorithms interviews, even then it was so far on my backburner that I decided if I was asked an interview question that involved them I'd just fail the question and move on.
|
|
#
?
Jun 14, 2018 18:49
|
|
|
Jose Valasquez posted:I had never heard of tries until I started prepping for algorithms interviews, even then it was so far on my backburner that I decided if I was asked an interview question that involved them I'd just fail the question and move on. They’re neat. A couple recent white papers use them to increase key value store lookup time. They’re also good for word games.
|
|
#
?
Jun 14, 2018 18:52
|
|
|
In ten years of being a dev I had literally never heard of tries until that post. It's almost as if you don't actually need to know about them unless they're useful for your problem domain? 
|
|
#
?
Jun 14, 2018 18:55
|
|
|
I mean my college CS isn't representative, but high school level CS is seriously not a high bar to clear. "I've heard of tries" is seriously not a lot to ask. I should probably qualify this - I get that there are people whose curriculums missed tries, and it's not disqualifying for consideration, and if I'm filtering on people with a particular set of skills it wouldn't factor in nearly as much as domain expertise/experience. However, if I'm looking for generalists for a small team, and they don't know that tries exist - in the absence of better signal that I don't have to worry - I'm likely to spend more time than I'd prefer thinking about their code. If the team is big enough that someone can cover for that, fine. EDIT: okay so are they actually rare and I've just encountered them in every job I've had by coincidence?
|
|
#
?
Jun 14, 2018 18:55
|
|
|
We have an opening in our team for a sr java dev and we will be interviewing next week. The interviewers will consist of the department head who is the captain of the 15 odd teams here and a java dev 20 years in the workforce, 15 years experience in the IT industry of which the last 3 as a developer. That last guy would be me. I lack any education or training as a developer, completely self-taught. My biggest boon is that I learn super-fast to solve practical problems but other than that I lack anything resembling structure in my programming knowledge. The prior discussion about data structures would have me fail hard on any interview and so far I am surfing the wave of shortage. We have two candidates coming in, both have over 15 years of experience and Master CompSci education. But that is all on paper. How the hell am I to judge these people know what they are talking about? Can anyone share tips / tricks? I know this company is easy to hire, this is why I am here. I am seriously doubting why I am present at these conversations? My imposter syndrome is flaring up again, maybe?
|
|
#
?
Jun 14, 2018 19:03
|
|
|
Keetron posted:We have an opening in our team for a sr java dev and we will be interviewing next week. The interviewers will consist of the department head who is the captain of the 15 odd teams here and a java dev 20 years in the workforce, 15 years experience in the IT industry of which the last 3 as a developer. That last guy would be me. I lack any education or training as a developer, completely self-taught. My biggest boon is that I learn super-fast to solve practical problems but other than that I lack anything resembling structure in my programming knowledge. The prior discussion about data structures would have me fail hard on any interview and so far I am surfing the wave of shortage. As much as this thread hates on Google style interviews -- give them a problem to solve and see how they do through design, some basic coding (seriously for senior people you need to make sure they can actually code, you'd be surprised how many can't) and how they think through it. Doesn't have to be an algorithms problem, just a non trivial one.
|
|
#
?
Jun 14, 2018 19:08
|
|
|
Doctor w-rw-rw- posted:I mean my college CS isn't representative, but high school level CS is seriously not a high bar to clear. "I've heard of tries" is seriously not a lot to ask.
|
|
#
?
Jun 14, 2018 19:08
|
|
|
Doctor w-rw-rw- posted:I mean my college CS isn't representative, but high school level CS is seriously not a high bar to clear. "I've heard of tries" is seriously not a lot to ask. They’re an optimization that is probably not strictly necessary in most situations.
|
|
#
?
Jun 14, 2018 19:24
|
|
|
Ghost of Reagan Past posted:I don't have a CS education. Never taken a CS class in my life. If you asked me to implement a trie I'd probably go "I'm sorry, what?" If you explained it, I could probably implement it. But you're making an awful lot of assumptions about developers here. He said it was a word problem, not "implement a trie", which would be a lovely interview questions. Prefix trees aren't exactly a crazy concept and there's lots of problems you'd probably come up with one for even if you've never heard of a trie. I _love_ algorithm questions in my interviews and I'm not the type to A) study B) remember algorithms I was taught years ago, so I don't expect candidates to either. None of my algorithm-y questions require knowing an esoteric algorithm or data structure off the top of your head, just that you can take a problem and solve it with a computer efficiently.
|
|
#
?
Jun 14, 2018 19:28
|
|
|
I continue to be amazed at how many teams who ostensibly work with Java haver never heard of or used build management tools. My last two weeks so far have been blowing minds with Gradle. Also just had to give a crash course on Mockito.
|
|
#
?
Jun 14, 2018 19:43
|
|
|
i regularly ask my interviewees to implement a trie in bash still looking for that special someone~
|
|
#
?
Jun 14, 2018 19:51
|
|
|
Have the people who've never heard of a Trie heard of a directed acyclic word graph?
|
|
#
?
Jun 14, 2018 20:50
|
|
|
Munkeymon posted:Have the people who've never heard of a Trie heard of a directed acyclic word graph? no
|
|
#
?
Jun 14, 2018 20:51
|
|
|
Ahh yes, it's super important my employees whiteboard a bunch of arcane data structures when 99% of their job is shuffling around calls to a 500 layer deep bespoke ORM. FWIW I've mostly avoided interviews that are bad around this in my career (except a really rough Jane Street interview, which is my only real  interview fail regret). Especially now that takehomes are more of a thing. I don't mean avoided like 'tried to avoid doing' I mean 'applied to good jobs that were smarter about hiring'. It's not *that* crazy out there.
|
|
#
?
Jun 14, 2018 21:07
|
|
|
Keetron posted:We have two candidates coming in, both have over 15 years of experience and Master CompSci education. But that is all on paper. If you code on a daily basis and watch someone else code, you'll probably be able to tell if they code regularly. I've interviewed a lot of people with long experience in development and find that many of them have moved into leadership roles either in process or architecture. I ask a coding question just to watch them work. I don't even care so much about the final answer, because in the real world no one solves these problems and pushes to production without collaboration. I care about how they start to think about the problem and when they start coding I look at their style and how comfortable they are with it. Are they coding to a consistent style of braces, spacing, etc? Are they slopping around and forgetting semicolons, messing up for-loop syntax, or calling static methods without a class context? How far do they get on their own towards the solution and how many good questions do they ask? It's intimidating to interview senior level positions when they have twice or three times your tenure. But then you watch them code and I bet you'll be surprised how fast you'll form an opinion. Let the other two rounds ask the tough systems design questions, concurrency problems, leadership chops (if that's part of the job), nuanced and specific JVM garbage, etc. Tangentially, for the coding questions I ask, I like ones that
As a shortcut, choose one of those traditional algorithm problems and work backward to find a business use case for it and present that as the problem. It doesn't have to be your company's business domain, either. Using one of those problems as-is isn't the worst thing in the world if the interview is coming up and you have nothing, though. e: forums should support markdown instead of this fuckass bbcode poo poo
|
|
#
?
Jun 14, 2018 21:09
|
|
|
Most programmers - especially in things related to web stuff - never really need or encounter that kind of algorithmic formalism. They'll run into the database normalization forms and maybe a bit of set theory, but if you're mostly a Javascript guy and your language doesn't really have a type system (or even an integer datatype at all, for that matter) and the most complex data structure supported natively is a simple string-keyed unordered map, you don't really get much encouragement to think in those terms, not that there is even much of a need for it. That's not to say doing web stuff is easy, though. GUI programming with all its state-tracking is a gigantic pain in the rear end, the web ecosystem is enormous and filled with subtle ways to shoot yourself in the foot, you have to constantly think about security, and there's just heaps of poorly abstracted complexity everywhere. Don't imposter syndrome yourself because you're not familiar with these things, they're really not that complex and you're probably not missing anything significant to your job. If you want to learn more about the theory and formalism though, I found the Destroy All Software articles and screencasts very helpful and easy to follow along with. I myself am self-taught and constantly impostering myself because the more I learn the more I understand I know nothing.
|
|
#
?
Jun 14, 2018 21:13
|
|
|
I'm in my interview and the bonus was, once again, using a trie.
|
|
#
?
Jun 14, 2018 22:02
|
|
|
|
| # ? Apr 23, 2024 11:02 |
|
|
Doctor w-rw-rw- posted:EDIT: okay so are they actually rare and I've just encountered them in every job I've had by coincidence? Maybe! The only application I can think of is autocomplete, so is that something you've had to implement in your job? To give you an idea, I've worked for 4 different household name companies and never had to use any data structures beyond the basics (HashMap, List, etc). I only really learned about tries, red/black trees, etc. through interview prep, ironically. I'm not against all coding in interviews, it just should be relevant to the job. But in my experience with tech companies it's usually something you'd never typically do and they want perfect code and O(1) performance. For example, had an interview with MS recently where they asked me to implement a priority queue. This is for a team that supports internal business apps (aka CRUD), so how is this a useful indicator of anything?
|
|
#
?
Jun 14, 2018 22:13
|
|