|
Space Whale posted:Technical interview with Amazon later today. The first one. They are most likely going to ask you a few questions on data structures and immediately move into a 45 minute problem solving question dealing with data structures and algorithms. You can find some of the actual questions that they ask candidates here and here. I highly recommend picking up a copy of Cracking the Coding Interview from the OP so you know the type of problems to expect in the future. If you explain your thought process the whole time and talk clearly I'm sure you'll do fine. Good luck! sailormoon fucked around with this message at 15:19 on May 21, 2015 |
# ? May 21, 2015 15:13 |
|
|
# ? Jun 7, 2024 17:48 |
|
So understanding what I'm doing conceptually is more important than having memorized particularities of implementation, right? Note that the first conversation-haver with me knows full and well I've done C# for 3 years so I'm going to have some rust when it comes to Java. I hope that helps.
|
# ? May 21, 2015 16:38 |
|
For most high level discussions, C# and Java can be used interchangeably, and you shouldn't really be getting into discussions on the difference between a HashMap vs Dictionary<T>, unless again it is a high level discussion about generics and boxing & unboxing. Implementing most sort/search algorithms is the same in Java/C#. Hopefully you don't get some interviewer that thinks it important to know minutia of the Java GC and makes hiring decisions about it. Just relax, talk clearly, and don't panic.
|
# ? May 21, 2015 17:23 |
|
I cannot for the life of me get how people memorize poo poo with tree traversal. Are notes ok? Why the gently caress would you memorize it, you'd code it and call it.
|
# ? May 21, 2015 20:42 |
|
Why would you need to memorize how to traverse trees?
|
# ? May 21, 2015 21:25 |
|
sarehu posted:Why would you need to memorize how to traverse trees?
|
# ? May 21, 2015 21:44 |
|
Space Whale posted:I cannot for the life of me get how people memorize poo poo with tree traversal. Are notes ok?
|
# ? May 21, 2015 21:44 |
|
Space Whale posted:I cannot for the life of me get how people memorize poo poo with tree traversal. Are notes ok? Some people just don't get why we have computers in the first place; to automate the things we don't like doing/are terrible at.
|
# ? May 21, 2015 21:51 |
|
"Memorizing how to traverse trees" sounds to me a bit like "memorizing how to loop through an array". It's simple and fundamental enough that it shouldn't really take any effort to recall, and if it does, you should really work on that.
|
# ? May 21, 2015 21:51 |
|
Space Whale posted:I cannot for the life of me get how people memorize poo poo with tree traversal. Are notes ok? Pre-order, in-order, and post-order are fairly easy to remember! The first part of "*-order" is where the root node is accessed. Here's some pseudocode showing an example: pre-order, in-order, and post-order traversal Breadth-first, depth-first, and Dijkstra's are also fairly easy to remember too. They're basically the exact same search, just using different data structures. Breadth-first uses a queue, depth first uses a stack, and Dijkstra uses a PriorityQueue. The following pastie has more pseudocode showing their relationship to each other: generalized breadth first, depth first, and dijkstra You should try programming the pre-order, in-order, and post-order searches iteratively as an exercise! Also I apologize for any poor practices or mistakes in my pseudocode. I whipped it up quickly as an example. sailormoon fucked around with this message at 22:13 on May 21, 2015 |
# ? May 21, 2015 22:02 |
|
JawnV6 posted:[git] So git is like makefiles for you? What's the first thing you do when you want to start a new project? You (probably) clone the git repository. That's how work begins in life. That's how work should begin in class. Or subversion, or whatever. And by SVN I mean git. And Mercurial is git, so use git. Anyone here looking for a programming job not know source control? Learn git. Fun fact: Git is generally much easier to learn from fresh than if you know other systems beforehand. And you can run it locally, so students don't even have to bother with remotes until a later chapter. I think I smell a group project. sarehu posted:Why would you need to memorize how to traverse trees? Having as much stuff as possible memorized is never a bad idea. Employers should grade you based on your process, but we all know there are people who are looking at time, buzzwords, and pass/fail.
|
# ? May 21, 2015 22:18 |
|
revdrkevind posted:Having as much stuff as possible memorized is never a bad idea. Employers should grade you based on your process, but we all know there are people who are looking at time, buzzwords, and pass/fail. I don't think employers should grade you based on your process. But anyway, it's what Cicero said: memorizing how to traverse trees is like memorizing how to loop through an array.
|
# ? May 21, 2015 22:26 |
|
revdrkevind posted:Having as much stuff as possible memorized is never a bad idea. Employers should grade you based on your process, but we all know there are people who are looking at time, buzzwords, and pass/fail. This is a terrible way to go about things. The whole point of the internet is so we can look stuff up when we need it, instead of trying to memorize every single bit of information that is tangentially related to your job. Why bother having computers if we are not going to offload cognitive work to them? I'd rather not work at a place that thinks I should be a human hard-drive.
|
# ? May 21, 2015 22:52 |
|
I never play with trees at the low level since I'm either hitting a database or an ICollection/IEnumerable/IWhatever with LINQ. This is probably to my detriment. I also haven't had time to code to practice, just read up on what I had forgotten since school. Anyway the interview ended with "You were literally one line away from implementation." I was tasked with validating a BST. I was thinking "traverse tree, build a list, check if the list is in the right order." I literally brain farted at this: code:
Obviously I know how to traverse a list in order and make sure the prior value is less than the current value, so that wasn't a point of contention. FGSFDS this is frustrating.
|
# ? May 21, 2015 23:02 |
|
sailormoon posted:Pre-order, in-order, and post-order are fairly easy to remember! When put that way it's blindingly simple. Cicero posted:"Memorizing how to traverse trees" sounds to me a bit like "memorizing how to loop through an array". It's simple and fundamental enough that it shouldn't really take any effort to recall, and if it does, you should really work on that. I should. I literally never actually move through a tree to do poo poo, I just query something wrapped around one, or a database. My brain was torn between setting a variable to the actual node, or using recursion to go down the tree, so it (in the mind of the interviewer) tried to do BOTH, which is what made me hang at the end. He got a laugh out of it. Webdev makes you dependent on abstractions - which is not so bad! But you have to make sure you don't freak out in interviews or just plain forget how to traverse a tree. Edit: Took a stab at in-place traversin' checkin': code:
Space Whale fucked around with this message at 01:18 on May 22, 2015 |
# ? May 21, 2015 23:14 |
|
There are some variations of traversal algorithms that are non trivial to come up on the spot or just recall without having recently studied/used/implemented them (particularly the minutiae). I can understand someone who's going for a Google interview feeling like they have to memorize that stuff.
|
# ? May 21, 2015 23:57 |
|
I found Cracking the Coding Interview's questions to be almost useless due to how easy they were. Elements of Programming Interviews had harder questions, so I did those instead, which was fine because of the sixteen different questions I was asked in my Facebook and Amazon interviews, all but four were exactly from EPI. Of the remaining three two were quite different from but seemed to be inspired by questions from CtCI's OOP chapter, another one was a design question I didn't recognize from any book, and one is widely available online and said to be asked by all the huge tech companies. That last one was asked of me by both Facebook and Amazon. I also feel like my practice with EPI left me with a much stronger understanding of CS fundamentals, but the early, non-question parts of CtCI were nice. That was the first place I had heard of Amazon's "bar raiser" interviewers. shodanjr_gr posted:I can understand someone who's going for a Google interview feeling like they have to memorize that stuff. In my experience, Google was the only company where memorization wouldn't have helped. Not a single one of my Google questions was from one of those books. Safe and Secure! fucked around with this message at 03:00 on May 22, 2015 |
# ? May 22, 2015 02:57 |
|
This thread's reminding me of pre-meds trying to memorize their way through o-chem.
|
# ? May 22, 2015 03:03 |
|
I'm just rusty from 3 years of literally never doing anything with a tree that wasn't wrapped up in LINQ or behind a database
|
# ? May 22, 2015 03:20 |
|
Safe and Secure! posted:In my experience, Google was the only company where memorization wouldn't have helped. Not a single one of my Google questions was from one of those books. Google actually has a shared database of interview questions; questions are often put on a "banned" list if a detailed answer to the question shows up online or in a print book. (That said, there's a few questions where incorrect answers have shown up online. We're allowed to keep asking those. ) I'd say to remember that coding questions aren't always a "you must produce neat and tidy working code" thing. There's plenty of smart candidates out there that are worth hiring, but don't code well under pressure, especially on whiteboard. An interviewer is there to attempt to figure out how you think, how you decompose problems, and whether or not you're an active programmer; it's not a binary "they answered the question correctly" thing. Do they automatically do things like closing braces without thinking, or are they a middle manager who hasn't touched an IDE in five years? Do they stop to actually consider their algorithm's correctness, or are they a TopCoder type who blitzes to get spaghetti on the wall ASAP without thinking about degenerate inputs? Do they show some familiarity with some sort of standard library, or are they reinventing the wheel every time they need to manipulate a string? (Of course, if you can demonstrate adeptness AND finish the problem, even better.)
|
# ? May 22, 2015 03:23 |
|
Don't worry about trying to game the situation where you can't solve a problem. Don't worry about making mistakes -- double-check for them, and if you miss them, that's not what'll ruin the interview, it's being unable to solve the problem that'll ruin it.ullerm posted:Do they automatically do things like closing braces without thinking, or are they a middle manager who hasn't touched an IDE in five years? Do they stop to actually consider their algorithm's correctness, or are they a TopCoder type who blitzes to get spaghetti on the wall ASAP without thinking about degenerate inputs? Do they show some familiarity with some sort of standard library, or are they reinventing the wheel every time they need to manipulate a string? Nobody cares. Just solve the loving problem and don't be painfully stupid.
|
# ? May 22, 2015 03:47 |
|
Space Whale posted:Edit: Took a stab at in-place traversin' checkin': code:
You obviously could compact this down to one line but at that point I'd say it becomes less clear and the optimiser should be able to trivially remove those booleans so there's no real world impact to adding them. This may depend on your language choice though. I would say that it's more important that you can verbally explain what you are doing than it is to be able to neatly comment every line. Nobody comments like that in the real world because everyone knows that any other developers can figure out what a less-than comparison does. Tunga fucked around with this message at 10:25 on May 22, 2015 |
# ? May 22, 2015 10:21 |
|
Tunga posted:It looks like it would work fine but to me this is horribly verbose. I know that it's better to over explain in an interview rather than the other way but "if (condition) return false" is kind of a horrible construct that I have to parse out in my brain to figure out what we're actually working out. In the real world I'd be using a thoroughly tested library that was combed over by an army of spergs on monster, mountain dew and purestrain white cheddar cheetos, which is exactly why getting back into inside-the-method-call-recursion was so weird for a while. It's frustrating that in the course of my job I almost never actually make an algorithm or implement much of anything, just call libraries and write POCOs and move them around and configure things. How the hell do you actually do this day to day on a job besides working for amazon?
|
# ? May 22, 2015 14:54 |
|
Space Whale posted:In the real world I'd be using a thoroughly tested library Also someone will probably now reply and tell you that I'm wrong and that you should comment every line in an interview. There isn't really a right answer to this stuff and it depends on what the interview happens to like. Which is, rather unhelpfully, a thing you cannot determine until after the interview. I am poo poo at technical interviews so probably just ignore me anyway.
|
# ? May 22, 2015 17:02 |
|
As a forewarning to anyone that memorized the above, their answer is wrong. The left child could have a right node that's bigger than the the lefts parent. You could fix it by checking that the largest element in the left is smaller than the parent (similar for the right child), or you could take the equivalent property of "an in order traversal is sorted" and run with that. FamDav fucked around with this message at 17:14 on May 22, 2015 |
# ? May 22, 2015 17:09 |
|
God damnit, I was even hovering over the "or equal to" comparison thinking "this feels like it is going to gently caress something up but I can't quite figure out what it is". Well at least there's now proof that I'm bad.
|
# ? May 22, 2015 17:19 |
|
FamDav posted:As a forewarning to anyone that memorized the above, their answer is wrong. Was my ultrawordy stab valid? I get brain worms when I don't solve something
|
# ? May 22, 2015 18:43 |
|
Just memorize this solution:code:
sarehu fucked around with this message at 19:14 on May 22, 2015 |
# ? May 22, 2015 19:12 |
|
So the point of a technical interview is to help assess whether a candidate can perform the duties of the job timely, without excessive hand-holding, without making egregious mistakes, and by producing a result that can be understood and maintained by others in the future. For most positions, the details of BST traversal aren't particularly important. There's probably two reasons why folks like them though. The first is that BSTs are one of the first moderately-complicated topics discussed in every CS curriculum, so they serve as a litmus for "do you have background in CS?" and "do you actually remember anything from your schooling?" The second is that, even if an interviewee can't remember the details things like BST traversals off the top of his/her head, they're a simple enough concept that most folks can reason about them on the spot, providing a good way for interviewers to prod thought processes and problem solving skills. Actually, because BSTs are so pervasive I don't think they're great interview topics. Everyone knows about them, or at least knows they should know about them. I think it's generally better to ask questions people won't have an answer for right away, as they give a more fair and honest invitation to walking through the thought process of a new problem.
|
# ? May 22, 2015 20:08 |
|
ExcessBLarg! posted:So the point of a technical interview is to help assess whether a candidate can perform the duties of the job timely, without excessive hand-holding, without making egregious mistakes, and by producing a result that can be understood and maintained by others in the future. If you don't think recursively in your niche of the programming world, or worse, just do import library; collection.SomeBuiltInFunction().Linq(x=>x.whee); as your workflow, you're going to stumble for a little while going back to what you did in school. Skills atrophy over time. A lot of people quite literally never use a lot of what they learned after graduation. Do you remember all the identities from trig and calc for integration, or how to do a force diagram? I sure don't off the top of my head.
|
# ? May 22, 2015 20:12 |
|
Space Whale posted:If you don't think recursively in your niche of the programming world, or worse, just do import library; collection.SomeBuiltInFunction().Linq(x=>x.whee); as your workflow, you're going to stumble for a little while going back to what you did in school. Also, you don't have to get every question right in an interview, you just have to recognize mistakes and get through the process. Sometimes you'll get a savant in an interview who remember all minutiae, but can't think critically beyond that. Sometimes you'll get folks with terrible memory but fantastic engineering insight. Sometimes you might have positions available where both kinds of people are great fits for their respective jobs. Space Whale posted:Skills atrophy over time. A lot of people quite literally never use a lot of what they learned after graduation. Space Whale posted:Do you remember all the identities from trig and calc for integration, or how to do a force diagram? I sure don't off the top of my head.
|
# ? May 22, 2015 20:29 |
|
The DOM is a tree, directory structures are trees, config files are trees, JSON is a tree, management hierarchies are a tree (or gosh, maybe a DAG), dependency graphs are a DAG (or, in npm, a tree? Heh!) -- since when do web devs not traverse trees? I traversed trees as a web dev.quote:Do you remember all the identities from trig and calc for integration, or how to do a force diagram? For what it's worth, yes.
|
# ? May 22, 2015 20:30 |
|
Everyone knows skills atrophy over time, but interviewers would rather know by how much catching up someone has to do. Between two people, they may like the one that can do the BST problem over the person who has the same fundamentals, but struggles a bit because they're used to using LINQ. Sometimes it's a choice between two or more good candidates, for one position. Don't take it so hard, they should be looking at many more aspects than just one problem you didn't do perfectly, like how well you handled not getting it. It's far more important that you can persevere through a difficult problem than start whining and bitching at the first sign of difficulty.
|
# ? May 22, 2015 20:30 |
|
sarehu posted:The DOM is a tree, directory structures are trees, config files are trees, JSON is a tree, management hierarchies are a tree (or gosh, maybe a DAG), dependency graphs are a DAG (or, in npm, a tree? Heh!) -- since when do web devs not traverse trees? I traversed trees as a web dev. I didn't implement the actual method(s) that go up or down the tree, or search the tree, I called them. Same for if I was searching a dictionary or list or tree or map or whatever. I mean sure the concept of what a tree is and what to do and how it's sorted is something you'd have to grasp, but that's not what I got stuck on. sarehu posted:For what it's worth, yes. ExcessBLarg! posted:If a particular skill is commonly regarded as being taught as part of your standard CS curriculum (apologies for the butchered meaning of "CS" in this context), and that skill is relevant to the job, then yes, I do expect that interviewees maintain their skills. It might be the case that you haven't touched that topic in the past ten years in previous positions, but if necessary for this job, then I'm going to hire the guy who clearly demonstrates them. Skandranon posted:Everyone knows skills atrophy over time, but interviewers would rather know by how much catching up someone has to do. Between two people, they may like the one that can do the BST problem over the person who has the same fundamentals, but struggles a bit because they're used to using LINQ. Sometimes it's a choice between two or more good candidates, for one position. Don't take it so hard, they should be looking at many more aspects than just one problem you didn't do perfectly, like how well you handled not getting it. It's far more important that you can persevere through a difficult problem than start whining and bitching at the first sign of difficulty.
|
# ? May 22, 2015 20:54 |
|
Space Whale posted:I didn't implement the actual method(s) that go up or down the tree, or search the tree, I called them. The point is you can't just call some APIs and hope everything just works. Knowledge of the underlying structure may influence even the high-level approach depending on the engineering goals. You probably know that, but there's folks out there that, while they can code their way around some libraries, are otherwise very naive and aren't aware that graphs are a thing. Those are the kinds of folks you want to ferret out in an interview.
|
# ? May 22, 2015 21:23 |
|
Space Whale posted:Dammit, I wish I had that kind of memory. Joke's on you, I taught that stuff for a couple of semesters. Edit: For what it's worth, making a function that computes if some binary tree's a BST is something $former_employer asked everybody, and all but 1 or 2 people I phone screened did the "local" mistake first. Then it's a question of whether they realize it themselves (do they not prove their code's correct? Lol what's wrong with them?) or need a nudge. That's OK. And even then, some people still don't get it, and can't fix it, and their code explodes into an ever-expanding disaster. (Like, the people that when given a counterexample decide to check just the four grandchildren.) sarehu fucked around with this message at 22:04 on May 22, 2015 |
# ? May 22, 2015 21:53 |
|
I majored in math and can't remember any of that. Except the power rule. And the definition of a group.
|
# ? May 22, 2015 21:58 |
|
sarehu posted:Joke's on you, I taught that stuff for a couple of semesters. I tutored this poo poo for two years and most of what I remember about integration is "DO NOT FORGET THE +C"
|
# ? May 22, 2015 22:03 |
|
sarehu posted:The DOM is a tree, directory structures are trees, config files are trees, JSON is a tree, management hierarchies are a tree (or gosh, maybe a DAG), dependency graphs are a DAG (or, in npm, a tree? Heh!) -- since when do web devs not traverse trees? I traversed trees as a web dev. Also abstract syntax trees... source code is parsed into these trees.
|
# ? May 22, 2015 23:20 |
|
|
# ? Jun 7, 2024 17:48 |
|
Is it going to be impossible to find a fully remote job as a largely self taught guy with only 6 months, so far, as a software engineer? I just really want to get out of the continental US as fast as I can again. I've been checking weworkremotely and other places, but remote seems to be either non existent, 3+ years min, or just a bunch of Ruby jobs.
|
# ? May 25, 2015 16:38 |