Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

«‹›728 »

sailormoon: Jun 28, 2014; fighting evil by moonlight
winning love by daylight

Space Whale posted:

Technical interview with Amazon later today. The first one.

What should I expect? I've been a developer for three years, so I tend to think more about "oh this is figured out, I'll check my sources if I forgot this data structure is good for this or that based on bla bla foo foo foo" than stuff like "stack vs queue for breadth and depth traversal!" Is this going to bite me in the rear end or is that to be expected?

Also should I be ready for "hash your integers for 2sum" type poo poo or stuff more like "linear probing with a hash means worst case is gonna be O(constant for the hash + n for the list built off of that single bucket since the hash is literally awful) or on average just more like O(c)" ?

STILL waiting on the SF joint to say yes or no. I'd take it if it was offered. Generally an amazon interview scheduled means an offer too good to refuse comes up right before the actual interview, so let's see if that happens again this time!

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! :3:

sailormoon fucked around with this message at 15:19 on May 21, 2015

# ? May 21, 2015 15:13

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 19:08

Space Whale: Nov 6, 2014

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

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

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

Space Whale: Nov 6, 2014

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

sarehu: Apr 20, 2007; (call/cc call/cc)

Why would you need to memorize how to traverse trees?

# ? May 21, 2015 21:25

America Inc.: Nov 22, 2013; I plan to live forever, of course, but barring that I'd settle for a couple thousand years. Even 500 would be pretty nice.

sarehu posted:

Why would you need to memorize how to traverse trees?

Maybe if you want your interviewer to think you're Rain Man.

# ? May 21, 2015 21:44

ExcessBLarg!: Sep 1, 2001

Space Whale posted:

I cannot for the life of me get how people memorize poo poo with tree traversal. Are notes ok?

You mean like preorder vs. inorder vs. postorder?

# ? May 21, 2015 21:44

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Space Whale posted:

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.

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

Cicero: Dec 17, 2003; Jumpjet, melta, jumpjet. Repeat for ten minutes or until victory is assured.

"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

sailormoon: Jun 28, 2014; fighting evil by moonlight
winning love by daylight

Space Whale posted:

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.

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

revdrkevind: Dec 15, 2013; ASK ME ABOUT MY TINY DICK

also my opinion on

JawnV6 posted:

[git]

Reminds me of the CS program that started off CS101 with an in-depth look at Makefiles. Before "hello world" there was a quiz on what happens to .o files during linking. A fantastic way to suck all the potential joy about getting to control a machine and going off into the weeds on minutia that can easily be provided until more fundamentals are in place. But hey, Programmers Should Know Makefiles so lovely pedagogy is ok.

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

sarehu: Apr 20, 2007; (call/cc call/cc)

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

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

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

Space Whale: Nov 6, 2014

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." :what:

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:

public void getNode(Node _leaf, List<Node> collection)
{
    if (_leaf.left)
    {
        getNode(_leaf.left, collection);
    }
    
    //collection.Add(_leaf); // <---- I was too panickey to figure out where to put it between my if statements
    
    if (_leaf.right)
    {
        getNode(_leaf.right, collection);
    }

}

The duder put it in for me in collabedit and said nerves happen. I'm definitely not ready for an in person panel, but my god, nerves will make your brain stop working. When he said "Hey, email me the solution" and shot the poo poo with me my brain started working again immediately.

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

Space Whale: Nov 6, 2014

sailormoon posted:

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.

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:

public bool isBST(Node root) {

    if(root.left) //if it exists, keep going, if not, skip
    {    
        if(root.left.value > root.value) //if the left leaf is greater than the current value, it is not a BST
            {return false;}  //go ahead and return false 
        if(!isBST(root.left)) //otherwise, go on down
        {return false;} 
    }
    
    if(root.right) //if it exists, keep going, if not, skip
    {
        if(root.right.value < root.value) //if the right leaf is less than the current value, it is not a BST
            {return false;}    //go ahead and return false 
        if(!isBST(root.right)) //otherwise, go on down   
        {return false;}
    }  
    
    return true; // If you got here, things are fine, so go ahead and return true. 
                        
}

Would THAT work?

Space Whale fucked around with this message at 01:18 on May 22, 2015

# ? May 21, 2015 23:14

shodanjr_gr: Nov 20, 2007

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

Safe and Secure!: Jun 14, 2008; OFFICIAL SA THREAD RUINER
SPRING 2013

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

sarehu: Apr 20, 2007; (call/cc call/cc)

This thread's reminding me of pre-meds trying to memorize their way through o-chem.

# ? May 22, 2015 03:03

Space Whale: Nov 6, 2014

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 :v:

# ? May 22, 2015 03:20

ullerrm: Dec 31, 2012; Oh, the network slogan is true -- "watch FOX and be damned for all eternity!"

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. :getin:

)

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

sarehu: Apr 20, 2007; (call/cc call/cc)

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

Tunga: May 7, 2004; Grimey Drawer

Space Whale posted:

Edit: Took a stab at in-place traversin' checkin':

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.

code:

public bool isBST(Node root) {
    boolean leftGood = (root.left == null || (root.left.value <= root.value && isBST(root.left)); // If the left node exists, check that it's good
    boolean rightGood = (root.right == null || (root.right.value >= root.value && isBST(root.right)); // If the right node exists, check that it's good
    return leftGood && rightGood;
}

I think this is logically identical to yours?

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

Space Whale: Nov 6, 2014

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.
code:
public bool isBST(Node root) {
    boolean leftGood = (root.left == null || (root.left.value <= root.value && isBST(root.left)); // If the left node exists, check that it's good
    boolean rightGood = (root.right == null || (root.right.value >= root.value && isBST(root.right)); // If the right node exists, check that it's good
    return leftGood && rightGood;
}
I think this is logically identical to yours?

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.

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

Tunga: May 7, 2004; Grimey Drawer

Space Whale posted:

In the real world I'd be using a thoroughly tested library

Well, yes, of course. I wasn't really talking about that specific code but the general idea of how verbose it was applies to anything.

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

FamDav: Mar 29, 2008

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

Tunga: May 7, 2004; Grimey Drawer

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

Space Whale: Nov 6, 2014

FamDav posted:

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.

Was my ultrawordy stab valid?

I get brain worms when I don't solve something

# ? May 22, 2015 18:43

sarehu: Apr 20, 2007; (call/cc call/cc)

Just memorize this solution:

code:

a=INT_MIN;isBST(node*n){return!n||isBST(n->left)&&a<=n->value&&(a=n->value,isBST(n->right));}

sarehu fucked around with this message at 19:14 on May 22, 2015

# ? May 22, 2015 19:12

ExcessBLarg!: Sep 1, 2001

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

Space Whale: Nov 6, 2014

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.

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.

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

ExcessBLarg!: Sep 1, 2001

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.

It's not wrong if someone writes "collection.SomeBuiltInFunction().Linq(x=>x.whee);" in a technical interview in response to a question. In fact, it may well be one of the better answers in terms of "makes use of common libraries and is concise". But I'd also expect to be able to ask questions around "how might 'collection'" be implemented internally, with what kind of data structures? What are the trade-offs of using a tree vs. a hash table? Those kinds of things.

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.

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.

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.

I remember the core principals of a force diagram. If I were applying for a job in mechanics, I sure as hell would brush up on them.

# ? May 22, 2015 20:29

sarehu: Apr 20, 2007; (call/cc call/cc)

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

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

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

Space Whale: Nov 6, 2014

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 might say parentof/childof in some CSS, same for directory structures with ../foo/bar/butts. Woo hoo?

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.

Dammit, I wish I had that kind of memory.

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.

Honestly, I'm just frustrated as hell I remembered what the structures are, what they did, hash collision poo poo, bla bla bla, and then had a moment of panic with "do I add to my queue/stack before, between, or after I check the leaves???? :ohdear:

" before the interviewer said "dude just put it there you got it already."

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.

Personally, I obsess until I fully understand it and try to burn it into my brain so I never gently caress it up again.

# ? May 22, 2015 20:54

ExcessBLarg!: Sep 1, 2001

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 underlying graph structure of directories (or at least the class of graphs they're capable of representing) is important if you ever have to do a search over them. For example, FAT-based file systems are purely hierarchical and can be represented as a tree. LFN weirdness aside, you know that there's a unique path for each file. Unix (local) file systems are DAGs because each leaf node (inode) can be linked to from different paths, and non-leaf nodes (directories) can't be linked to each other except in a purely hierarchical fashion. So when doing a local search, you're guaranteed not to have cycles, but you may come across the same leaf nodes multiple times. If you follow symlinks, the structure can have cycles, so you either have to do cycle detection or not follow them (or run forever). Remote file-systems and bind mounts add further weirdness to the mix.

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

sarehu: Apr 20, 2007; (call/cc call/cc)

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

Safe and Secure!: Jun 14, 2008; OFFICIAL SA THREAD RUINER
SPRING 2013

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

Space Whale: Nov 6, 2014

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

Evil_Greven: Feb 20, 2007; Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

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

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 19:08

Gildiss: Aug 24, 2010; Grimey Drawer

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

«‹›728 »