|
why would you ever actually need to know the number of set bits in an int, anyway
|
#
?
Jul 9, 2014 10:06
|
|
|
|
| # ? Jun 6, 2024 15:11 |
|
|
qntm posted:why would you ever actually need to know the number of set bits in an int, anyway
|
|
#
?
Jul 9, 2014 10:18
|
|
|
qntm posted:why would you ever actually need to know the number of set bits in an int, anyway bitsets; = Hamming weight Malcolm XML fucked around with this message at 10:28 on Jul 9, 2014 |
|
#
?
Jul 9, 2014 10:25
|
|
|
when my boss asked us what questions to ask to candidates, I suggested "make them read code". explain what this function does, find the bug in this function and fix it, etc. I know as a programmer I'm supposed to do cool intellectual stuff, design algorithms, elegant data structures and bit twiddling hacks, but the reality of my job is reading code written by someone else or supposedly by me (in some dead-end alternate timeline where I huff glue and eat paint chips maybe?). reading a ton of code, sometimes from inside a debugger, sometimes the debugger can even match the current execution address to the right line (!). invariably bad code, either crap through and through, overambitious code abandoned a third of the way through or some kind of elegantly designed dynamic indirection hell even when I start a new project from scratch, I'm usually editing some kind of template. in fact, another good test is: start a project from scratch. it has to do this incredibly complicated thing that you have to use an external library for, show me how you integrate external dependencies in your project, how you know which implementation to pick from the vast offering of crap, etc. algorithms and data structures are way overrated
|
|
#
?
Jul 9, 2014 11:28
|
|
|
tef posted:poor sod. are you in n|s|e|w london? north ish
|
|
#
?
Jul 9, 2014 12:44
|
|
|
malcolm ur not sounding v. happy with yr job. you trapped by visa reqs or something?
|
|
#
?
Jul 9, 2014 12:55
|
|
|
coffeetable posted:malcolm ur not sounding v. happy with yr job. you trapped by visa reqs or something? nah i like my job + coworkers its just that london weather sux
|
|
#
?
Jul 9, 2014 12:57
|
|
|
hackbunny posted:when my boss asked us what questions to ask to candidates, I suggested "make them read code". explain what this function does, find the bug in this function and fix it, etc. I like the idea, but I've never made it work well. what would you have them read? I couldn't find stuff that was domain neutral, interesting in terms of signal, and was small enough to fit in an interview. maybe as a take-home where they can take the usual 20 mins to understand the lifecycle properties of a library it depends on and then move to pulling on the next string, but not in an on-site slot. we also don't require candidates to know any specific language, so we'd need a half-dozen of them and every interviewer would need to be fluent in all of them.
|
|
#
?
Jul 9, 2014 13:23
|
|
|
What about asking them what clever code they've read recently? What bugs have they fixed and what code have they been really pleased with in their experience, either ones they wrote or ones they read?
|
|
#
?
Jul 9, 2014 13:25
|
|
|
Suspicious Dish posted:What about asking them what clever code they've read recently? What bugs have they fixed and what code have they been really pleased with in their experience, either ones they wrote or ones they read? sure, that's all good stuff to ask, or things like it. do you find that you can get to interesting levels of detail when asking about code when the code isn't in front of both of you? I find it gets pretty hard to follow more than cursory description of clever code, and hard to generate follow-up questions from the answers -- especially if it's from a domain or language I don't know well. do you think that's a substitute for asking more pointed questions about actual code that's in the room, or having the candidate write some? I don't think anyone is advocating for only doing ds&a exercises. I also like "what was the hardest part of your project to test?" and "if you could change one design decision in your project for free, what would it be?", but those are evaluating a different set of things.
|
|
#
?
Jul 9, 2014 13:40
|
|
|
I've never given an interview. I have no idea about these things. I just was just giving a suggestion. It was bad.
|
|
#
?
Jul 9, 2014 13:41
|
|
|
Subjunctive posted:I like the idea, but I've never made it work well. what would you have them read? I didn't participate in the interviews, but I think we used stuff from our own codebase. probably made candidates work on actual bugs we've fixed recently, or asked them to explain what some function does we're a small company and we make a single product so it works for us... I guess? the two viable candidates just vanished and in the end we hired a QA guy instead. not sure what the moral is
|
|
#
?
Jul 9, 2014 15:19
|
|
|
the "read code" sample a former coworker used was an implementation of some sort (can't remember if it was quick sort or simpler) that had a few style issues, a bug or two, and some issues w/ using the function in a threaded program. seemed to work p well i guess
|
|
#
?
Jul 9, 2014 16:24
|
|
|
i hate sitting on the other side of a desk in an interview. false negatives are terrifying. finding and interviewing candidates is expensive and unpleasant, i really don't want to 'pass' on the wrong person performance on algorithm problems correlate strongly with how recently you graduated from college and how recently you dicked around with an algorithms book. i don't see it as a great way to get to grips with a stranger's thought process
|
|
#
?
Jul 9, 2014 16:28
|
|
|
Letting someone read or fix code from your company is also a good way to let them know what your good or bad stuff looks like, which may be valuable if you want them to know what they're getting into in advance.
|
|
#
?
Jul 9, 2014 16:29
|
|
|
Notorious b.s.d. posted:performance on algorithm problems correlate strongly with how recently you graduated from college and how recently you dicked around with an algorithms book. i don't see it as a great way to get to grips with a stranger's thought process wow i could not disagree more w/ this i don't care if you graduated yesterday or have been in the industry for 25 years if you can't apply algorithm concepts i don't want to work with you note that i also don't like trick questions for the reason you state
|
|
#
?
Jul 9, 2014 16:40
|
|
|
there is a difference between the ostensibly-dsa question "detect whether a singly linked list is cyclic using constant space" and the actually-dsa question "find the most recent common ancestor of two nodes in a binary tree"
|
|
#
?
Jul 9, 2014 16:46
|
|
|
agreed. a good algorithms question has multiple solutions of varying complexities. trick questions provide no signal.
|
|
#
?
Jul 9, 2014 17:10
|
|
|
was it in this thread where somebody said that some standard interview question was an unsolved problem in computer science for half a decade?
|
|
#
?
Jul 9, 2014 17:32
|
|
|
when i interviewed the goonlord yesterday i asked the detect-balanced-parenthesis question and he said he'd just use a regex
|
|
#
?
Jul 9, 2014 17:33
|
|
|
Tiny Bug Child posted:when i interviewed the goonlord yesterday i asked the detect-balanced-parenthesis question and he said he'd just use a regex Perl code:
|
|
#
?
Jul 9, 2014 17:38
|
|
|
Tiny Bug Child posted:when i interviewed the goonlord yesterday i asked the detect-balanced-parenthesis question and he said he'd just use a regex no hire, eject from premises immediately
|
|
#
?
Jul 9, 2014 17:40
|
|
|
FamDav posted:was it in this thread where somebody said that some standard interview question was an unsolved problem in computer science for half a decade? quote:Anyway, I think this question perfectly represents everything that can go wrong with an interview question, so I'd like to discuss it here to explain why it's almost hilariously awful as an interview question:
|
|
#
?
Jul 9, 2014 17:40
|
|
|
ya i asked him about the pumping lemma and stuff but he just kinda smiled and nodded
|
|
#
?
Jul 9, 2014 17:41
|
|
|
Tiny Bug Child posted:ya i asked him about the pumping lemma and stuff but he just kinda smiled and nodded remember you work in porn
|
|
#
?
Jul 9, 2014 17:44
|
|
|
Tiny Bug Child posted:when i interviewed the goonlord yesterday i asked the detect-balanced-parenthesis question and he said he'd just use a regex Tiny Bug Co-worker
|
|
#
?
Jul 9, 2014 17:52
|
|
|
MononcQc posted:http://www.nomachetejuggling.com/2014/06/24/the-worst-programming-interview-question/ hahaha, what the gently caress? how is code:
|
|
#
?
Jul 9, 2014 17:53
|
|
|
Suspicious Dish posted:hahaha, what the gently caress? how is your solution doesn't work, it would loop infinitely if it didn't loop back to the head of the list, no? Sweeper fucked around with this message at 17:56 on Jul 9, 2014 |
|
#
?
Jul 9, 2014 17:54
|
|
|
pythagoras came up groundbreaking new theorem but i would expect most people to know it by now
|
|
#
?
Jul 9, 2014 17:55
|
|
|
I think it's just too obvious an algorithm and a solution to have a name.
|
|
#
?
Jul 9, 2014 17:56
|
|
|
Suspicious Dish posted:I think it's just too obvious an algorithm and a solution to have a name. a -> b -> c -> b
|
|
#
?
Jul 9, 2014 17:57
|
|
|
Suspicious Dish posted:hahaha, what the gently caress? how is This looks like you're looking for actual circular lists, not just cycles, which may happen from any point in the list. Unless I read your code wrong, this one would actually run forever on: code:
|
|
#
?
Jul 9, 2014 17:57
|
|
|
MononcQc posted:This looks like you're looking for actual circular lists, not just cycles, which may happen from any point in the list. Yes, it would. I thought cyclic lists meant the same thing as circular lists. My bad.
|
|
#
?
Jul 9, 2014 18:02
|
|
|
tef posted:meanwhile "is this for recommending things to users or recommending adverts to users" is an honest question which has a substantial effect on the answer. the "it's complicated" wasn't really helpful. "is this for users or advertisers" is a good question, but "it's complicated" is a great answer and a wonderful conversation starter. "it's complicated" should have your ears instantly perked and bring a sparkle in your eyes  "how is it complicated? in what sort of ways?" ~they don't give any real answer~ "alright, i'm going to go with a strictly 100% user-focused solution to start with. we can changes things depending on what you think as we go along" and so on... shrughes posted:You couldn't figure out the trick. yeah... the trick isn't remembering that you need to traverse the lists twice, first time to get the size. that's rather a hint if working on a whiteboard, the trick is that instead of drawing the lists like this: pre:|a| -> |a| -> |a| -> |a| -> |1| -> |2| -> |3| -> | | |B| -> |B| -> |B| -> |B| -> |B| -> |B| -> |B| -> |B| -> |1| -> |2| -> |3| -> | | pre: |B|
|B|
|B|
|a| |B|
|a| |B|
|a| |B|
|a| |B|
|1| |1|
|2| |2|
|3| |3|
| | | |
Suspicious Dish posted:hahaha, what the gently caress? how is what if the cycle starts from or really stops at the node next to the head? spoiler
|
|
#
?
Jul 9, 2014 18:03
|
|
|
MononcQc posted:This looks like you're looking for actual circular lists, not just cycles, which may happen from any point in the list. octopus man, you work on distributed systems right? in your interviews do you ask about leader election strategies, quorums, other distributed systems concepts or assume that someone can learn that stuff? I feel like I'm going to have to be interviewing soon and idk if it is that important for them to get the low level stuff or just the general can you do things at massive scale with little to no state
|
|
#
?
Jul 9, 2014 18:04
|
|
|
as for reversing the list, i'd say the trick here is (again working on a whiteboard) to draw the list in the starting state like this:pre:
| |-> | |-> | |-> | |-> | |-> | |-> | |-> | |-> | |-> | |-> nil
| | | | | | | | | |
v v v v v v v v v v
(H) (e) (l) (l) (o) (.) (j) (p) (e) (g)
pre:
| |-> | |-> | |-> | |-> | |-> | |-> | |-> | |-> | |-> | |-> nil
v v v v v v v v v v
(H) (e) (l) (l) (o) (.) (j) (p) (e) (g)
^ ^ ^ ^ ^ ^ ^ ^ ^ ^
nil <-| | <-| | <-| | <-| | <-| | <-| | <-| | <-| | <-| | <-| |
|
|
#
?
Jul 9, 2014 18:23
|
|
|
Which is the exact same thing as popping from the head of the first list and building a new linked list starting with that. I still haven't ever been told what the "in-place" requirement means.
|
|
#
?
Jul 9, 2014 18:28
|
|
|
Sweeper posted:octopus man, you work on distributed systems right? in your interviews do you ask about leader election strategies, quorums, other distributed systems concepts or assume that someone can learn that stuff? I feel like I'm going to have to be interviewing soon and idk if it is that important for them to get the low level stuff or just the general can you do things at massive scale with little to no state It depends if we're looking to fill a junior or senior position, and what we have available on the team or not. We currently seem to be focusing on getting good people we think would work well with us. We have something like a general interview with the manager, then one or more interviews with individual team members if we feel we need more to judge from, then we may have you come on site or work remotely on a small project with us. The interviews I did were as one of the additional team members. So what we aim to do is size up who the person is. We want to pick projects for them that will fit their experience, and know what roles they could fill on the team. Would they be additional hands on the regular development? Real good at testing? Better at architecturing stuff, or maybe operational burden? What will we need to teach them? Distributed systems? The languages and libraries we use? The external dependencies we have? How to work remotely? What can they teach us (this one is harder if you don't know your weaknesses properly)? What they like, what's their experience, what they know, and what they don't know, basically. We sometimes hire people who know poo poo good enough in general areas we really need but some big hurdles (i.e. you don't know the programming language we use, but you're willing to learn and you know a lot about other stuff). So for distributed systems, I try to ask them if they have any experience or interest that way. If they don't have experience but are interested, I can try to gauge what they know for now. If they don't have interest, there isn't much we can do. For gauging, I usually flat out ask if they know about specific things, or ask them how they approached them in projects they mention having worked on that were in any way distributed: - end-to-end principle - idempotence - CAP theorem > PACELC - Latencies vs. netsplits - protocols they used before (HTTP, TCP, UDP, etc.?) - Do they know of things like CRDTs, how Quorum or two-phase commits work (and fail), etc. - leader election - What's a consistent cut - How they would do state replication or whatever - Experience in parallelism/concurrency (they are kind of similar at times) - distributed databases they may have used before - Etc. There are no bad answers to these, it's really to try and figure out where they stand, what they know or don't know. For the cases where they don't know the term, I can try to describe a situation about it to see if they know the principle, but not the terminology (this is especially frequent with self-taught people). So if it's about two-phase commits, I can ask for things like the usual "how would you go about coordinating a bunch of nodes to make sure they all make the right decision in this situation" and see what questions they ask to clarify the concept, to see if they're asking stuff relevant to the case (latencies? can it be inconsistent at all? do you need it to never freeze up? do you need it to be centralized or not?, etc.) Having them ask the right questions is often good enough to let us know that they know how to spot problem cases and could probably ask for help if they just don't know the solution, which is pretty good. Once we have a general idea where they stand on that front (and on plenty of others -- Erlang, ops work, testing, system design, etc.), we'll try to set up a project that matches the strength we perceived them to have, with durations that are flexible (from half a day to three days, remote or local). We've had people come in and design a replication protocol we have plans for and wanted to see what they'd come up with. We've had people whose project was planning sharding of some specific data feed. My own was implementing a binary serialization format decoder from almost legacy software over the course of a few (all expenses paid) days on-site to know how I'd mesh in with the other team members. After that, the candidate must present (small document, short presentation) to people who are interested (our team and some from other teams) what they did for their project. Just 15 minutes or so. That lets us know how well you'll communicate and document things, especially on a distributed team. Once that's all done, the manager consults team members one on one for their impressions and feedback, and can decide that the candidate is accepted or rejected from that feedback. It's a heavy process and possibly cuts us away from really great people who just don't have the time or will to go through the entire process, but tends to give us fairly good hirees we're happy with. I'm not sure if other teams here proceed in the same way. MononcQc fucked around with this message at 18:33 on Jul 9, 2014 |
|
#
?
Jul 9, 2014 18:29
|
|
|
Suspicious Dish posted:I still haven't ever been told what the "in-place" requirement means. "don't explicitly allocate any memory", usually
|
|
#
?
Jul 9, 2014 18:34
|
|
|
|
| # ? Jun 6, 2024 15:11 |
|
|
Mr. Glass posted:"don't explicitly allocate any memory", usually this also "stack is an explicit data structure rather than a free endless resource", mayhaps
|
|
#
?
Jul 9, 2014 18:48
|
|