|
Jose Valasquez posted:The time spent practicing leetcode carries over to any interview that does algorithm questions. Homework projects are just sunk time that is only applicable to 1 interview This is weird, but are there any tips for take homes? I admit that I might have a bad sense of what a good solution vs a bad solution is. (Hopefully it's not just cultural issue, like if you use this library, you're an idiot)
|
#
?
Apr 16, 2021 00:14
|
|
|
|
| # ? May 9, 2024 23:05 |
|
|
Tezzeract posted:This is weird, but are there any tips for take homes? I admit that I might have a bad sense of what a good solution vs a bad solution is. For open ended stuff, if for some reason you very much want a position at the place giving you the take home, over-deliver. Otherwise just solve the problem in a straightforward manner documenting any assumptions you're making, etc. For timed stuff just practice leet code.
|
|
#
?
Apr 16, 2021 00:51
|
|
|
Tezzeract posted:This is weird, but are there any tips for take homes? I admit that I might have a bad sense of what a good solution vs a bad solution is. People often tell me I've provided their all-time favorite take home submission (and then don't hire me after I fail to implement a red black tree under white lights in a laboratory) and here are the things I do: 1) My submission does exactly what the prompt says. 2) I have a clear readme with instructions on running the project and running tests. 3) I write a few tests that demonstrate I know what I'm doing, and I comment them saying what I would do to make them more robust if I had more time etc. 4) I have a makefile to run the project and run the tests, instructions for using the makefile are in the readme in addition to whatever the normal invocation is for people who don't want to use a makefile. 5) If the thing is an any way a UI I try to make it "nice". If it is a CLI I'll add a little bit of color or something. If it is a website I'll at least make it look reasonable. I do not spend a lot of time on this, just a basic css reset and good use of basic HTML elements. 6) Avoid external deps at all costs and opt for simple, readable solutions with lots of comments in your code. My thinking, having reviewed a ton of these, is I want the reviewer to have as pleasant an experience as possible. No 2gb npm installs, no deps that fail in my dev environment, no 800 line functions with 2 character variables and no comments. The most important thing, imo, is not that you impress them with your coding prowess or doing more than what they asked for - it is just that you two can have a nice time going through your project. I guess finally, if possible, try to anticipate where they might want you to add some feature so you can be ready for that when the time comes during the interview.
|
|
#
?
Apr 16, 2021 01:26
|
|
|
raminasi posted:One time on a phone tech screen I got asked to implement a red-black tree and I said "No. I know that they are a way to implement a efficient dictionaries but I cannot implement one for you off the top of my head. If I had to do that on the job and my standard library didn't have one I'd look up how to do it." I was expecting to get bounced for that but they brought me onsite anyway (where I actually got bounced). When I was applying for my current position, the initial screen asked me implement Dijkstra's algorithm in 45 minutes in a sandbox where I couldn't even run code. I submitted it empty after 5 minutes, with a note that I was confident I could implement it after looking it up to refresh my memory and I knew what it was and what it was used for. To my great surprise they actually responded and gave me another question to try and I ended up getting the job. Here I am 2 years later and I have never had to think about Djikstra's algorithm in any context except for telling this story.
|
|
#
?
Apr 16, 2021 02:29
|
|
|
Achmed Jones posted:if you hear "implement autocomplete" and don't think "trie" that's kinda bad. Idk man if I'm asked to implement autocomplete I'm going to find an existing implementation that suits the business need and finish the ticket. There's very little reason, unless the requirements are drastically different from most autocompletes, to consider spending the time and energy implementing it yourself. Algo-heavy interviews that focus on technical problems as a proxy for a capacity to solve business ones are just flat out a poor way of determining whether an engineer will be able to contribute to the team.
|
|
#
?
Apr 16, 2021 12:43
|
|
|
The March Hare posted:People often tell me I've provided their all-time favorite take home submission (and then don't hire me after I fail to implement a red black tree under white lights in a laboratory) and here are the things I do: Thanks, this is really helpful.
|
|
#
?
Apr 16, 2021 13:22
|
|
|
And if it’s “pick your own language” then don’t assume the reviewer is familiar with the stack you picked. I’m much happier if someone includes a dockerfile than spending my time having to work out if I have to install a more recent version of Ruby or how to do the package installs.
|
|
#
?
Apr 16, 2021 13:58
|
|
|
Blinkz0rz posted:Idk man if I'm asked to implement autocomplete I'm going to find an existing implementation that suits the business need and finish the ticket. There's very little reason, unless the requirements are drastically different from most autocompletes, to consider spending the time and energy implementing it yourself. Likewise. I don't even know what a trie is, but I have built and shipped successful products that use react-select's autocomplete dropdown.
|
|
#
?
Apr 16, 2021 18:36
|
|
|
i worked for two years at a company that did autocomplete all day every day and we used a doubly acyclic weighted graph w learned weights (reeeeeeal confusingly, there's a dawg that's a directed acyclic word graph in wikipedia that's a separate data structure also useful for autocomplete all day erry day) bob dobbs is dead fucked around with this message at 19:32 on Apr 16, 2021 |
|
#
?
Apr 16, 2021 18:41
|
|
|
dantheman650 posted:Likewise. I don't even know what a trie is, but I have built and shipped successful products that use react-select's autocomplete dropdown. I mean that's fine but "I just use the tools without understanding them" will put serious limits on career growth in tech. There's a big line between not reinventing the wheel and not understanding why wheels are good or being able to think about them. I'm not saying you're doing that specifically but it's a common problem in tech job threads that people simultaneously act smug about not being able to understand stuff and frustrated they can't pass interviews.
|
|
#
?
Apr 16, 2021 18:54
|
|
|
That doesn't mean the interviews are good.
|
|
#
?
Apr 16, 2021 18:55
|
|
|
ultrafilter posted:That doesn't mean the interviews are good. Nope, but it also doesn't mean they're always the problem.
|
|
#
?
Apr 16, 2021 19:07
|
|
|
Tries are a fundamentally simple data structure and implementing one or using in an interview for autocomplete or something as a peer exercise seems like a perfectly reasonable session. I'd rather be pushed towards understand the fundamentals of ubiquitous stuff like that (even if I don't write my own) as opposed to some dumb pet algo question with one weird trick.
|
|
#
?
Apr 16, 2021 19:29
|
|
|
You don't even need to get them to implement a trie, just ask them to pronounce it
|
|
#
?
Apr 16, 2021 19:46
|
|
|
xtal posted:You don't even need to get them to implement a trie, just ask them to pronounce it You mean have them try to pronounce it.
|
|
#
?
Apr 16, 2021 19:52
|
|
|
apseudonym posted:I mean that's fine but "I just use the tools without understanding them" will put serious limits on career growth in tech. There's a big line between not reinventing the wheel and not understanding why wheels are good or being able to think about them. I understand this to an extent, but I guarantee you use tools every day that you don't understand. You can't possibly have deep knowledge of the internal implementation of every single tool you use. It's a little like how I can drive a car and even be a professional driver without knowing how an engine works. In this specific case, what it means to understand my tool is that I know the react-select API inside and out, and I understand the business logic and UX of the page I'm building, and I know that I need an auto-complete dropdown and can use the one provided react-select. It's important, given limited mental energy and time, to choose which topics to gain deep understanding of and which to simply graze the surface. Computer science and programming are basically infinite topics, and it feels arbitrary to gatekeep on the knowledge of one particular data structure. apseudonym posted:I'm not saying you're doing that specifically but it's a common problem in tech job threads that people simultaneously act smug about not being able to understand stuff and frustrated they can't pass interviews. Is acting smug about ignorance really a common issue? I haven't encountered this attitude and I hope I wasn't coming across as smug. Harriet Carker fucked around with this message at 20:06 on Apr 16, 2021 |
|
#
?
Apr 16, 2021 20:03
|
|
|
As somebody working in the web world, I find somebody particularly useless about interviews for web-related stuff doing random algo questions and never things that actually relate to the web app work they're hiring for. I've done all sorts of wacky stuff for web apps all the way down to reimplementing some aspects of TCP connection handling in JS for a truly weird Chrome OS app†, but I've literally never had to do anything similar to interview algo questions in actual work. It just makes it obvious that the companies asking them for those kinds of positions don't actually have any idea of how to actually test for the sort of work they're doing. † bigcorp API specifications are completely hosed up sometimes
|
|
#
?
Apr 16, 2021 20:25
|
|
|
Asking a question where the answer is "I'd use a trie" is a pretty mediocre interview question. It's such an obvious answer in the places where it's applicable that you're really just asking if they've heard of a trie before and that's a very strange thing to judge a candidate on.
|
|
#
?
Apr 16, 2021 20:46
|
|
|
I'm curious whether something like this constitutes a one weird trick problem. Looking at it originally, I had a few ideas in mind - the brute force and then one I got stuck around where you could track the first biggest found item index (when you encountered numerical card value ties) from either side, and then backtrack on that to keep accurate indexes for the circular window (subtract from either side index accordingly to make your indexes accurately reflect that biggest found blah blah). But, when I finally saw the actual ideal solution, I realized how dumb my original solution sounded and just had to laugh at myself, and the hour+ of my life I will never get back trying to implement something absurd. Starting to feel the same frustration I felt the last time I was prepping for interviews. A ton of these problems aren't just writing code to solve a challenging word problem. They're problems that have an obvious brute force solution, maybe some sort of clear-ish hash table index storage solution, but usually some sort of tiny ideal implementation that, if you don't figure out quickly enough, really makes it borderline impossible to finish in interviews. This one, I happened to have seen something similar and it still took me an hour to even get to my :eureka: moment. The frustrating component of this, to me, is that I'm starting to question whether an hour of smashing my head into a question without seeing the obvious answer gives me any sort of tangible level of competency to work towards. I'm sure getting better at writing solutions that work for a large number of cases but not all of them, where the final case or two present a terminal problem that makes my entire work null! Good Will Hrunting fucked around with this message at 21:38 on Apr 16, 2021 |
|
#
?
Apr 16, 2021 21:34
|
|
|
Plorkyeran posted:Asking a question where the answer is "I'd use a trie" is a pretty mediocre interview question. It's such an obvious answer in the places where it's applicable that you're really just asking if they've heard of a trie before and that's a very strange thing to judge a candidate on. I mean, one of the questions I ask essentially boils down to: can you use recursion or tokenize an input? They have like 20-30 min really to write everything up after questions/intros/descriptions. The questions are almost uniformly trivial in some way.
|
|
#
?
Apr 16, 2021 21:36
|
|
|
Good Will Hrunting posted:I'm curious whether something like this constitutes a one weird trick problem. Looking at it originally, I had a few ideas in mind - the brute force and then one I got stuck around where you could track the first biggest found item index (when you encountered numerical card value ties) from either side, and then backtrack on that to keep accurate indexes for the circular window (subtract from either side index accordingly to make your indexes accurately reflect that biggest found blah blah). But, when I finally saw the actual ideal solution, I realized how dumb my original solution sounded and just had to laugh at myself, and the hour+ of my life I will never get back trying to implement something absurd. Immediate thought for i 1 to k count just taking from left and just taking from right. Take the bigger side. Loop. O(k^2)  Should be easy to write up, I'd have to think on whether it's correct. Probably there's something better. E: I think you can memoize your lookup so you pay constant time to index after the first look on each side. Just track a couple pointers and walk them out while subtracting the totals per side E2: uhhh proof by induction for correctness. If you're input of length k includes an innermost, it must be taking all k from left or all k from right. At some point, the maximal input must be entirely left/right. Before that point, it doesn't matter which side you pick, as there are pending cards on both sides. E3: this is a bad question because there's not a lot of places where it can go very organically. If the candidate burns through it in half the time what do you do, just smile at them? Maybe someone more clever can think of semi-interesting constraints to add. leper khan fucked around with this message at 22:00 on Apr 16, 2021 |
|
#
?
Apr 16, 2021 21:43
|
|
|
As far as I can see, it is a (simple) sliding window question. Whether that is a "one simple trick" or not depends on whether you would also categorize recursion as one simple trick, but just like with recursion, if you've never dealt with it before, you are gonna have a hard time.
|
|
#
?
Apr 16, 2021 22:05
|
|
|
You don't necessarily need to find the best solution as long as your solution works, is not brute force and is not exponential time. A step a lot of people miss is checking in with the interviewer between proposing a solution and implementing it. Assuming they aren't an rear end in a top hat, they should give clear feedback on whether your proposed solution is acceptable. Good Will Hrunting: That problem would likely be a lot simpler if an interviewer gave a hint or two. It's also hard to understand and conceptualize given that I believe the answer is to remove the window of unpicked cards and calculate and then slide the window over the array and take the max. Sliding windows are either very common or unheard of dependent on your domain. asur fucked around with this message at 22:10 on Apr 16, 2021 |
|
#
?
Apr 16, 2021 22:07
|
|
|
asur posted:You don't necessarily need to find the best solution as long as your solution works, is not brute force and is not exponential time. A step a lot of people miss is checking in with the interviewer between proposing a solution and implementing it. Assuming they aren't an rear end in a top hat, they should give clear feedback on whether your proposed solution is acceptable. I think tracking pulled and tracking remaining cards are both O(k). Probably easier to do unpicked cards since it's one window instead of two.
|
|
#
?
Apr 16, 2021 22:10
|
|
|
asur posted:You don't necessarily need to find the best solution as long as your solution works, is not brute force and is not exponential time. A step a lot of people miss is checking in with the interviewer between proposing a solution and implementing it. Assuming they aren't an rear end in a top hat, they should give clear feedback on whether your proposed solution is acceptable. Removing never possibly picked cards and sliding the window over the remains naively will not give correct results. But if you want to avoid messing around with wraparound window, take last K elements, first K elements, and slide window over their concantenation.
|
|
#
?
Apr 16, 2021 22:21
|
|
|
Not familiar with sliding windows really, and I haven't fully thought this through, but it seems like you could maybe solve this O(k) with a - possibly implicit - k-deep binary tree built from the left and right cards at each step. Brain's a bit fried today, so don't feel like actually proving that out though.
|
|
#
?
Apr 16, 2021 22:25
|
|
|
I messed around with the problematic case k=2 and input [1, 5, 3, 2] (should be 6, but would be 5 if we naively chose only from left and right.)code:xtal fucked around with this message at 02:29 on Apr 17, 2021 |
|
#
?
Apr 16, 2021 22:28
|
|
|
Nah, it's a One Simple Trick problem. Once you realize that the order you pull the cards doesn't matter, you're just going to be pulling X cards from the left and K - X cards from the right, then you just iterate to figure out how many to pull from left and right ends:code:
|
|
#
?
Apr 16, 2021 22:29
|
|
|
Edit: beat lol I've only done 2 or 3 sliding window problems before this, and they were both fairly standard without any wraparound. Handling the wraparound threw me off and I thought I'd need to track indices. Now that I see this pattern and understand how to notice (and check for) the efficient wraparound solution, it's obviously substantially more clear. That being said, my point was more around what others touched on. If you haven't seen these types of problems and the variations, it's pretty difficult to reason about efficiently and to me something like this is pretty one-tricky. Given that there are an insane number of domains that you could get asked questions on, knowing the nuances of things like this seems overwhelming. This was my accepted answer: code:
|
|
#
?
Apr 16, 2021 22:31
|
|
|
I think a lot of the difference in opinion about how deep to know your tools comes from the different flavor of roles that exist for engineers. If you automate business processes and knowing how a trie works is vastly less important than having a deep understanding of the domain. Similarly, knowing your users and their needs in a product development type role is vastly more important than being an expert on how libraries get loaded in your language of choice. There are also roles where if you don't know all the details about how the query engine executes queries you're going to light tens of thousands of dollars on fire. That's not to say that all of those skills aren't useful in most roles, just that the balance of relative importance shifts. A good chunk of being effective at job searching is being clear about what kind of job you're good at and looking for companies who value that sort of thing and a good chunk of being effective at hiring is being clear what kind of skills are important to your particular role and making sure to only screen for the things that are important.
|
|
#
?
Apr 16, 2021 22:41
|
|
|
and a good portion of the completely merited complete lack of trust between employers and candidates is that this information and the nature of the role is very seldom given even close to honestly and even more seldom used to decide to apply to places or not lemons as far as the eye can see. lemon companies, lemon candidates
|
|
#
?
Apr 16, 2021 23:33
|
|
|
bob dobbs is dead posted:and a good portion of the completely merited complete lack of trust between employers and candidates is that this information and the nature of the role is very seldom given even close to honestly and even more seldom used to decide to apply to places or not Part of it is that hardly anyone is out there saying this enough so I think a lot of people don't really understand that it's a thing. It took me well more than a decade into my career (and being a hiring manager) to really understand that software engineer as a title hides a tremendous amount of complexity. The rise of back end/front end/data/fullstack/embedded has been a good start but doesn't go far enough to really help with that differentiation.
|
|
#
?
Apr 16, 2021 23:54
|
|
|
I don't really think that's a One Weird Trick problem but maybe that's because I figured out the one weird trick My thought process was: 1) Brute force it, just do all the iterations of lll, llr, lrl, lrr, etc. There are 2^k permutations, each one will take k to put together so I think this is O(k*2^k)? 2) It's similar to the coin game interview question, so I spent a bit of time thinking about how to do it as DP. This was a bit of a red herring in my thought process although it could probably be done like this too. It might even naturally lead into solution 3? Not sure, I'm rusty on DP and don't want to spend more time thinking about it. 3) Looked at a couple of examples, if lll is the max then the value is a[0]+a[1]+a[2], if llr is the max then the value is a[0]+a[1]+a[k-1], at this point I realized that there is no real difference between llr and rll, you just need to figure out how many to take from each side. The order you take them from each side is irrelevant. So you need k elements, in the k = 3 example you either take all 3 elements on the left, 2 elements on the left 1 on the right, 1 on the left and 2 on the right or all 3 elements on the right. Now you're down to O(k). I don't consider this to be one weird trick because you don't have to know the trick ahead of time to solve the problem, the solution can be found just be logically progressing through the problem. If I was giving this question in an interview I would expect a great candidate to quickly identify the naive solution, fairly quickly identify solution 2 or 3 and implement them cleanly. Solution 3 would give bonus points for being optimal. A borderline to good candidate would identify the naive solution and solution 2 or 3 and make good progress towards implementing them or give a somewhat messy but working implementation. All in all I like the question, it has the one hallmark I look for in good interview questions: I was able to solve it 
|
|
#
?
Apr 17, 2021 00:55
|
|
|
Jose Valasquez posted:I don't consider this to be one weird trick because you don't have to know the trick ahead of time to solve the problem, the solution can be found just be logically progressing through the problem. Of course, this is what everyone who figures out the trick says about every One Weird Trick question.
|
|
#
?
Apr 17, 2021 01:30
|
|
|
How do I career change lol
|
|
#
?
Apr 17, 2021 01:55
|
|
|
raminasi posted:Of course, this is what everyone who figures out the trick says about every One Weird Trick question. I tend to think of one weird trick problems as ones that require you to either know the answer ahead of time or not. Like, I had an interview question where the answer was topological sort. If I hadn't seen that algorithm before when I was studying I would have bombed the question, but I did see it so I aced the question and it was probably the difference in me getting hired or not. A candidate is unlikely to independently discover topological sort in an interview and it's not something I would consider to be in the basic algorithmic toolkit I would expect to be tested in an interview. I don't think the question falls into that category. You could argue the DP solution might, but DP is just something that a bunch of companies agreed is fair game so it should be a part of interview prep.
|
|
#
?
Apr 17, 2021 02:24
|
|
|
This is all just one guy's opinion though. If I was going to use it in real life I'd test it out a few times on colleagues to see how it works in a 45m window on a whiteboard by people I know should be hired, then if that went well I'd use it in a few interviews and make sure my interview notes indicated it was a new problem that I wasn't well calibrated on. If a bunch of candidates don't get past the naive solution then it's probably a bad question, but hopefully it provides some insight into their thought process.
|
|
#
?
Apr 17, 2021 02:31
|
|
|
Good Will Hrunting posted:How do I career change lol Buy a farm, buy a shovel and a bunch of pigs. And then get on to shove pig poo poo. It's bound to be more rewarding.
|
|
#
?
Apr 17, 2021 03:04
|
|
|
Jose Valasquez posted:something that a bunch of companies agreed is fair game At this point what isn't though? Google's packet for "brushing up" is like an algorithms textbook table of contents.
|
|
#
?
Apr 17, 2021 03:20
|
|
|
|
| # ? May 9, 2024 23:05 |
|
|
dantheman650 posted:I understand this to an extent, but I guarantee you use tools every day that you don't understand. You can't possibly have deep knowledge of the internal implementation of every single tool you use. If an interview is doing a FAANG style interview and asks you a question that requires you to have a gotcha of an uncommon algorithm or an advanced application to make any progress that's a bad interview, but on the other hand if the candidate just says "I'd use a library" and when asked "ok how would you write that library if we had to?" still stick with "I'd just find a library >  " its a bad look.The number one advice I give for FAANG interviews is the point is to see how you think through solving problems with computers. Can you take a problem and turn it into the steps to solve it, understand the complexity and tradeoffs and where to focus your efforts. Its not that you've memorized some specific niche algorithm but that you can use the basic blocks of computer science to solve problems. quote:Is acting smug about ignorance really a common issue? I haven't encountered this attitude and I hope I wasn't coming across as smug. wins32767 posted:Part of it is that hardly anyone is out there saying this enough so I think a lot of people don't really understand that it's a thing. It took me well more than a decade into my career (and being a hiring manager) to really understand that software engineer as a title hides a tremendous amount of complexity. The rise of back end/front end/data/fullstack/embedded has been a good start but doesn't go far enough to really help with that differentiation. Also sadly a resume can easily lie. "I was an engineer on X" can mean anything from having done the whole thing to having written a design document and then sat around shitposting all day. Not to mention that the skills associated with a title vary vastly across the industry. Good Will Hrunting posted:I'm curious whether something like this constitutes a one weird trick problem. Looking at it originally, I had a few ideas in mind - the brute force and then one I got stuck around where you could track the first biggest found item index (when you encountered numerical card value ties) from either side, and then backtrack on that to keep accurate indexes for the circular window (subtract from either side index accordingly to make your indexes accurately reflect that biggest found blah blah). But, when I finally saw the actual ideal solution, I realized how dumb my original solution sounded and just had to laugh at myself, and the hour+ of my life I will never get back trying to implement something absurd. The ahha I think is noticing that there is no difference between l l r r and l r l r and any other permutation of that, which leads to the "one side takes x and the other takes k-x, find the best value of x", which then leads to "how do I try each value of x without redoing a bunch of work? well the difference between x=i and x=i+1 is adding the new value on the left and subtracting the removed value from the right" It's not super gotcha-y, but its easier if you have someone to keep you from going down the greedy solution route early (protip, if you get asked an algorithms question and you think the answer is greedy it almost certainly never is) and to nudge you toward those two key points. If I was giving this question I'd make sure to have an example ready where the greedy solution wouldn't work and have some probing questions ready if you got stuck. That's why I don't like leetcode interviews, sometimes we all brain fart or get stuck in a loop and need a nudge. e: I cant spell at the end of the week, 
apseudonym fucked around with this message at 04:45 on Apr 17, 2021 |
|
#
?
Apr 17, 2021 04:00
|
|