|
Kibbles n Shits posted:I'm working through Hacker Rank challenges and I'm getting a little discouraged. I got through the warmup algorithms fine and a few others were doable but largely it's making me feel absolutely stupid. However, I'm going to a junior college and haven't taken algorithms or data structures yet. Am I being too hard on myself? I feel like I should be able to at least understand some of these problems. The answer to your question is Yes. But what kind of questions are you stumped on?
|
#
?
Jan 10, 2017 22:05
|
|
|
|
| # ? May 18, 2024 02:16 |
|
|
Kibbles n Shits posted:haven't taken algorithms or data structures yet. Am I being too hard on myself? Yes! These algorithm questions are actually much tougher to think about than what most programmers do at work on a daily basis.
|
|
#
?
Jan 11, 2017 00:29
|
|
|
HondaCivet posted:OK, so this is more common than I thought. I wanted to ask, did all of you pick topics that were semi-related to the stack the company was using? Or did you do something off the wall like robot tracking algorithms at a web dev company interview? Both times I've done this it has had zero relavence to the company I was interviewing at as it was based on previous work so in one case I did a presentation on flight controls and the company I was interviewing at made networking products. Both times the presentation was well received and the people thought it was interesting.
|
|
#
?
Jan 11, 2017 01:15
|
|
|
I have a small pet project, not primarily tech related, that I trot out for these presentation-type interviews. It's always nice to connect back to real world objects, or at least objectives, so as to help people relate
|
|
#
?
Jan 11, 2017 01:37
|
|
|
Kibbles n Shits posted:I'm working through Hacker Rank challenges and I'm getting a little discouraged. I got through the warmup algorithms fine and a few others were doable but largely it's making me feel absolutely stupid. However, I'm going to a junior college and haven't taken algorithms or data structures yet. Am I being too hard on myself? I feel like I should be able to at least understand some of these problems. A lot of the "advanced" hackerrank questions are only hard because of their descriptions. If you can get through the basic data structures and algorithms you're doing incredibly well.
|
|
#
?
Jan 11, 2017 02:04
|
|
|
Yea I'm just being stupid. Of course without even so much as a class in algorithms I'm not going to be amazing at this. Disregard me, I should just keep practicing and learning. My inner voice is an rear end in a top hat sometimes.
|
|
#
?
Jan 11, 2017 03:09
|
|
|
HondaCivet posted:OK, so this is more common than I thought. I wanted to ask, did all of you pick topics that were semi-related to the stack the company was using? Or did you do something off the wall like robot tracking algorithms at a web dev company interview? I was given some guiderails, I was supposed to give a presentation about my background and key contributions I made in the past. So I talked about a big project I did, gave metrics on improvements made before and after my work, etc. The position was for laboratory automation at a biotechnology firm, and so I built my presentation around a project I did at my then-current job to take a bunch of tasks a human would do in a lab and make a robot do them instead.
|
|
#
?
Jan 11, 2017 03:56
|
|
|
I've been at my first job for a year now, and will be getting my bachelors in a month or two. I'm officially a DW specialist, but that might be overselling me a bit. I have been heavily involved with designing and implementing our new DW and related data processes however. Would know be a good time to start looking around for a new job? I will at least discuss a pay raise with my current employer, but my position doesn't have a lot of advancement potential. I'd also like to do more work with backends, which isn't really possible at the moment.
|
|
#
?
Jan 11, 2017 13:00
|
|
|
rt4 posted:Yes! These algorithm questions are actually much tougher to think about than what most programmers do at work on a daily basis. Still, I think they are archaic, and I can't help but think that there are some really smug interviewers out there with a PhD in CS that think that being able to reverse a linked link and sort a hashtable in O(n) time or whatever, is the cornerstone of being a good developer. My butt. I would much rather be asked to design the backend for a wiki, or even the semi-archaic "design a coffee machine / elevator / traffic light system" is more useful in daily life.
|
|
#
?
Jan 11, 2017 13:14
|
|
|
Pilsner posted:... and to boot, the algorithm coding is something almost no one uses in their daily work, either. Who codes their own sorting algorithm these days? The questions exist partly out of tradition, and their point is to show that you can think and work your way towards a solution. It also shows a bit about your how outward thinking you are, and how you present yourself. PhD? It's something you lean in basic algorithms and datastructures. Anyway, sorting has its merits as an introduction to algorithms and datastructures. You get around a lot of non-trivial big-O analysis, introduce divide and conquer (one of the three main paradigms), introduce randomized algorithms (in a variation on quicksort) and get around binary heaps and with that binary trees (not binary-search-trees mind you) and how they can be implemented with objects/pointers and array. Also, there are comparison-sorts and non-comparinson-sorts. Some sort are in-place and som are stable. Insertion sort is both. If it is possible to do a non-comparinson-sort like counting sort or bucket sort (bucket sort depends on distribution) you can do it in O(n) time. So even though you don't implement your own sort in real life you might be in a situation where you need to know the differences between different kinds of sorts. It's not always quick sort. Also.. since all since this is the very first thing you learn in a course that any computer scientist should have within the first year I don't think it is unreasonable for an interviewer to ask questions requiring this knowledge.
|
|
#
?
Jan 11, 2017 13:31
|
|
|
It's fine if it interests you and you're good at it, but my point is just that during my 10 years of working as a dev, I have never had the need to actually write any of those algorithms by hand (nor care how the internals of a .NET .Sort() method works), which is why I would completely fail an interview asking me to do so, particularly if the interview was on a high horse about it. I don't see how being able to write a sorting algorithm shows any skill beyond being able to memorize some code. I'm all for understanding basics and fundamental concepts, but being able to write them? It's like requiring a carpenter to be able to build a sawmill (I just made up that brilliant analogy).
|
|
#
?
Jan 11, 2017 13:49
|
|
|
Pilsner posted:It's fine if it interests you and you're good at it, but my point is just that during my 10 years of working as a dev, I have never had the need to actually write any of those algorithms by hand (nor care how the internals of a .NET .Sort() method works), which is why I would completely fail an interview asking me to do so, particularly if the interview was on a high horse about it. I don't see how being able to write a sorting algorithm shows any skill beyond being able to memorize some code. I feel you should know the basics of how hashes, dictionaries, and trees/lists work while also knowing the proper use cases for each one and understanding Big O notation. I've worked with front-end and back end guys that don't realize their nested loops are causing huge performance issues or how much they could be saving in space by using a hashtable to lookup values. Does that mean you should be able to code these by scratch? No, even the simpler structures can be tough to get 'right'. But you should be able to show that you understand how they work.
|
|
#
?
Jan 11, 2017 14:10
|
|
|
Pilsner posted:It's fine if it interests you and you're good at it, but my point is just that during my 10 years of working as a dev, I have never had the need to actually write any of those algorithms by hand (nor care how the internals of a .NET .Sort() method works), which is why I would completely fail an interview asking me to do so, particularly if the interview was on a high horse about it. I don't see how being able to write a sorting algorithm shows any skill beyond being able to memorize some code. One of the points is that maybe you are in a situation where you shouldn't use .NET's .sort(). Tip: For both algorithms and proofs don't remember all the details. Remember the two or three ideas behind it and fill in the rest (hence, you actually need to figure stuff out as you go if you don't have photographic memory). Of course any technical interview where you are asked to write pseudo code for quicksort (or implement it in a real language) and explain how and why it works and nothing more... well, that's a bad interview. However, I think it is fair being asked if you would use quicksort in this situation and then why.. or being asked to verbally explain how quicksort works in broad strokes. I also think it's fair to give a problem that needs something like graph theory, have you realize this, have you realize you need to augment depth-first-search to solve it and then have you write the code on a whiteboard. Jarl fucked around with this message at 14:47 on Jan 11, 2017 |
|
#
?
Jan 11, 2017 14:14
|
|
|
Kibbles n Shits posted:Yea I'm just being stupid. Of course without even so much as a class in algorithms I'm not going to be amazing at this. Disregard me, I should just keep practicing and learning. My inner voice is an rear end in a top hat sometimes. You'll always feel stupid. There will always be something new that comes up and makes you feel like a dumbass. ... gently caress it, keep practicing anyway. You learn code by writing code. Write more code.
|
|
#
?
Jan 12, 2017 00:23
|
|
|
Pilsner posted:It's fine if it interests you and you're good at it, but my point is just that during my 10 years of working as a dev, I have never had the need to actually write any of those algorithms by hand (nor care how the internals of a .NET .Sort() method works), which is why I would completely fail an interview asking me to do so, particularly if the interview was on a high horse about it. I don't see how being able to write a sorting algorithm shows any skill beyond being able to memorize some code. Knowing HOW everything works is by far more important than being able to replicate it, but being able to replicate the basics is the only way to really prove you know how they work. If you don't know what's under the hood, it becomes much harder to choose the right data structure or algorithm. .sort(), whatever it is, is going to work fine 95% of the time, but if you don't know the various sorts, you're not going to recognize that (depending on the algorithm it's using) you could slash your processing time massively because 99% of the time you're just sorting in one element, or it's not keeping things in the right order, you are only popping off the top item and inserting so a heap is easiest, or you just don't actually NEED everything to actually be in order and you could just use a map. All of those things can cause problems depending on the data and application, and if you don't know sorts you will have a rough time being able to diagnose them. It's like trying to diagnose an engine without knowing what is actually going on inside any of the components. You can get a general idea and figure out something right a lot of the time, but when something off the wall comes up, then you're SOL. Edit:  Edit2: Also, possibly more importantly, knowing when you can cheat and do something the lazy way and not cause problems, and when you actually need to do something the right way. Felime fucked around with this message at 14:57 on Jan 13, 2017 |
|
#
?
Jan 13, 2017 14:44
|
|
|
Most interview questions are not about implementing data structures or algorithms, they are about identifying the appropriate data structure or algorithm for the problem. Yeah, you might have to implement a simple algorithm like binary search or in order traversal of a tree but if you can identify that is what you need then honestly the implementation should be pretty trivial. Most problems are just variations on the same ~10 algorithms. All that assumes you're interviewing at a non lovely company with a non lovely interviewer though, if you get stuck with one of the "one weird trick" questions then there's really nothing you can do except try to figure out the trick.
|
|
#
?
Jan 13, 2017 15:17
|
|
|
Jose Valasquez posted:All that assumes you're interviewing at a non lovely company with a non lovely interviewer though, if you get stuck with one of the "one weird trick" questions then there's really nothing you can do except try to figure out the trick. Those are the worst simply because they're a trivia test rather than a coding test. Chances are you won't figure that out on your own in 30 minutes.
|
|
#
?
Jan 13, 2017 18:47
|
|
|
Kibbles n Shits posted:I'm working through Hacker Rank challenges and I'm getting a little discouraged. I got through the warmup algorithms fine and a few others were doable but largely it's making me feel absolutely stupid. However, I'm going to a junior college and haven't taken algorithms or data structures yet. Am I being too hard on myself? I feel like I should be able to at least understand some of these problems. Depending on where you want to work a lot of places are frankly gonna be on the easy side of that stuff.
|
|
#
?
Jan 14, 2017 02:36
|
|
|
Dang. I'm seeing a bunch of Jr Front End roles popping up in Philly now that I'm employed as a goddamn QA person Truly a first world problem
|
|
#
?
Jan 14, 2017 16:55
|
|
|
Apply anyway and omit the qa role from your resume?
|
|
#
?
Jan 14, 2017 17:10
|
|
|
Grump posted:Dang. I'm seeing a bunch of Jr Front End roles popping up in Philly now that I'm employed as a goddamn QA person Apply to them?
|
|
#
?
Jan 14, 2017 17:22
|
|
|
Eh. I would if I wasn't in my first job out of college. I figure I'll start applying in 6 months. I just thought it was funny 
|
|
#
?
Jan 14, 2017 17:42
|
|
|
Grump posted:Eh. I would if I wasn't in my first job out of college. I figure I'll start applying in 6 months. I just thought it was funny If you want to be a web dev instead of QA, why would you wait?? The fact that it's your first job out of college actually makes it easier to answer the "why are you trying to leave so soon" question.
|
|
#
?
Jan 14, 2017 17:47
|
|
|
loving do it, never waste time sitting in a job you don't want!
|
|
#
?
Jan 14, 2017 18:00
|
|
|
Grump posted:Eh. I would if I wasn't in my first job out of college. I figure I'll start applying in 6 months. I just thought it was funny None of the tech companies in Philly are particularly great or super desirable to work for so your competition is going to be pretty low
|
|
#
?
Jan 14, 2017 19:42
|
|
|
Grump posted:Eh. I would if I wasn't in my first job out of college. I figure I'll start applying in 6 months. I just thought it was funny yeah that's what i thought too, then i ended up working in qa for like three years. i also developed a surly attitude and alcoholism.
|
|
#
?
Jan 14, 2017 23:06
|
|
|
Pilsner posted:It's fine if it interests you and you're good at it, but my point is just that during my 10 years of working as a dev, I have never had the need to actually write any of those algorithms by hand (nor care how the internals of a .NET .Sort() method works), which is why I would completely fail an interview asking me to do so, particularly if the interview was on a high horse about it. I don't see how being able to write a sorting algorithm shows any skill beyond being able to memorize some code. My thinking is that if you've gone ten years without having had to use stuff you've learned in an introductory Data Structures & Algorithms class then maybe the problems you're working on are too easy. (That said, I don't interview particularly well, and when I'm the interviewer my standard question is easy as long as the candidate (a) remembers that maps are a thing that exist and (b) knows the basics of for-loops)
|
|
#
?
Jan 15, 2017 00:21
|
|
|
fritz posted:My thinking is that if you've gone ten years without having had to use stuff you've learned in an introductory Data Structures & Algorithms class then maybe the problems you're working on are too easy. (That said, I don't interview particularly well, and when I'm the interviewer my standard question is easy as long as the candidate (a) remembers that maps are a thing that exist and (b) knows the basics of for-loops) Don't get me wrong, I went to Computer Engineering uni and appreciate knowing about the fundamentals, but again, knowing the intimates of sorting algorithms just sounds so theoretical rather than practical, and not something you'll use when actually being a dev at company that cares about solving business problems, not tech. Them's the breaks. To get back to basics, I was mainly poking at those (perhaps theoretical?) interviews where you have to write a quicksort algorithm by hand on a whiteboard, but perhaps I was excaggerating.
|
|
#
?
Jan 15, 2017 00:42
|
|
|
Lots of .NET code uses databases, so you'd better be able to think about performance. There's no shortage of bozos that'll do O(n) round-trips, or queries that require a table scan.
|
|
#
?
Jan 15, 2017 01:06
|
|
|
Sure, but those database interaction issues are about software design, not sorting algorithms
|
|
#
?
Jan 15, 2017 01:50
|
|
|
rt4 posted:Sure, but those database interaction issues are about software design, not sorting algorithms Databases sort stuff. And sorting algorithms is just what you started talking about, the conversation's about more than that. Even if you want to go in-memory, I've had to deal with stuff like hash table implementation details on .NET. sarehu fucked around with this message at 03:06 on Jan 15, 2017 |
|
#
?
Jan 15, 2017 03:00
|
|
|
It amazes me how many people gripe about these questions with the argument that you'll never have to write a sorting algorithm in real work because there are plenty of implementations available to you. Yes, this is generally true, but you're missing the point. The goal is to gauge whether you are capable of thinking about and reasoning through problems *like* sorting, and they're throwing you a loving bone by making it a problem that you should be familiar with. I'm not arguing that it's the foundation of a great interview question, but if you're going to argue that it is a lovely one, then you should at least get right what it is generally trying to achieve, and argue that the actual goal of the question is lovely, or that the question is a lovely way of accomplishing that goal, not against some strawman that nobody will need to write a sorting algorithm on the job. Pretty much nobody asking that question is asking it because they expect you to implement sorting algorithms as part of your job: you know that, they know that. Even if you're working in a pure .NET environment, you still most likely need to be thinking about computational complexity unless you are only building straightforward CRUD apps or something. And the nature of computational complexity is such that even if you have a lot of compute resources, you should still be thinking about it, because if you gently caress up and do something that's quadratic or exponential in complexity without realizing it, those resources might not save you. That's more of an argument against micro-optimizations and choosing a programming language based on constant-factor performance than it is against needing to worry about complexity.
|
|
#
?
Jan 15, 2017 03:58
|
|
|
Those kinds of questions are bad and dumb because most places just do them to ape Google. A better way I have seen is a well crafted coding challenge that is tailored for the common kinds of problems that will be faced in the day to day for that position. A sort could be one of the things required by this and seeing which they choose and how they implement it, not constrained by on the spot interview time or whiteboard, is a much better gauge of a candidate. Then you have a face to face and see if they are a passable human and don't raise any red flags if that is completed to your satisfaction.
|
|
#
?
Jan 15, 2017 06:30
|
|
|
Gildiss posted:Those kinds of questions are bad and dumb because most places just do them to ape Google. That is not a reasonable argument for why they are "bad and dumb"
|
|
#
?
Jan 15, 2017 06:45
|
|
|
Gildiss posted:Those kinds of questions are bad and dumb because most places just do them to ape Google. Coding challenges have the massive problem that you have no idea if the person you're hiring was the one to complete it.
|
|
#
?
Jan 15, 2017 07:49
|
|
|
At my final interview for my current job I had to whiteboard a solution to a problem they had actually just developed a solution to. Turns out my solution was almost identical to theirs  .asur posted:Coding challenges have the massive problem that you have no idea if the person you're hiring was the one to complete it. That's how you catch students that the plagiarism software doesn't catch.
|
|
#
?
Jan 15, 2017 15:05
|
|
|
Steve French posted:That is not a reasonable argument for why they are "bad and dumb" They are typically only pertinent to the original asker of the question and that position, and when that same one is used by other companies that just got them from the CTCI book they only see the quesion and not the situation or purpose it was originally asked for. asur posted:Coding challenges have the massive problem that you have no idea if the person you're hiring was the one to complete it. That can pretty easily be revealed when further questions are asked at the next step of the process. Questions about what or why they wrote what they did.
|
|
#
?
Jan 15, 2017 15:09
|
|
|
Gildiss posted:Those kinds of questions are bad and dumb because most places just do them to ape Google. I read this page on careercup and rethought my resume. (I get a lot of interviews I think, relatively) but I'm always looking to improve. Currently, this is what I have listed (the headers were the names of the games, which I changed, but the point is they were meaningless to everyone but me)  Now, I've reformatted so that the headers describe in brief terms what the project actually was, and the bullet points go into finer detail about the tech stack and components I made.  So, does it seem like an improvement? Or should I scrap it? I'm getting a little restless as I wait for offers and count down days til flights and interviews, so I'm kinda just trying to placate myself with this stuff bomblol fucked around with this message at 20:27 on Jan 15, 2017 |
|
#
?
Jan 15, 2017 20:22
|
|
|
I think naming the game either in the header or description is better.
|
|
#
?
Jan 16, 2017 13:30
|
|
|
|
| # ? May 18, 2024 02:16 |
|
|
edit: nevermind
Subyng fucked around with this message at 22:16 on Jan 16, 2017 |
|
#
?
Jan 16, 2017 21:19
|
|