p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Star War Sex Parrot posted:

what region are you in now

london

# ? Jul 9, 2014 00:04

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 02:40

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Star War Sex Parrot posted:

all i know is that you post good poo poo in the math thread in SAL

gotta get some use out of that math degree

2day i spent 8 hours fighting tfs build system engineers

# ? Jul 9, 2014 00:05

Star War Sex Parrot: Oct 2, 2003

i see

someday i would like to work there. got a buddy who just graduated with the same degree i'm getting and got a sweet gig for a visual FX shop in London doing automated tools testing or something

# ? Jul 9, 2014 00:06

Symbolic Butt: Mar 22, 2009; (_!_); Buglord

Malcolm XML posted:

gotta get some use out of that math degree

2day i spent 8 hours fighting tfs build system engineers

I wish I was one of you people with a math degree who are actually smart

# ? Jul 9, 2014 00:14

Soricidus: Oct 21, 2010; freedom-hating statist shill

i wish my coworkers with math degrees would go back into their ivory towers and stop writing bad code where i have to see it

no offense to any math majors who write good code but i've never met you

# ? Jul 9, 2014 00:18

Star War Sex Parrot: Oct 2, 2003

i was disqualified by the school of physical sciences when i first attended uni, and now that i'm readmitted by engineering i can never scoop up a math double-major

# ? Jul 9, 2014 00:18

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

quote:

The basic problem facing the computer industry today is the software crisis; software cost as a fraction of total system cost has dramatically increased over the last two decades. It is an odd kind of crisis, because it is in a sense a crisis caused by good fortune: decreasing hardware costs have made possible more and more ambitious projects. Unfortunately, our ambitions greatly exceed our current programming abilities. There are four fundamental problems: the size of modern programs, the demands for security, the use of concurrency, and the need for expandable systems.

From Intel's "Introduction to the iAPX 432 Architecture", published in 1981.

# ? Jul 9, 2014 00:45

MrMoo: Sep 14, 2000

Mr Dog posted:

Perl has an API for SQL databases that doesn't suck

that's more than I can say for Python

ODBC is fast to integrate in Python, brought up some hideous custom Firebird DB in a few minutes.

# ? Jul 9, 2014 01:38

Sapozhnik: Jan 2, 2005; Nap Ghost

MrMoo posted:

ODBC is fast to integrate in Python, brought up some hideous custom Firebird DB in a few minutes.

"now you have two problems"

is it interviewchat? oh good i wanna do interviewchat

ask them about the latest project they worked on, have them explain the project itself and what they contributed to it

ask them to solve some open-ended design problem and pay attention to what questions they ask. maybe ask them to combine some standard algorithms and data structures in order to accomplish some real-world task. maybe also ask them to explain one of those standard algorithms or data structures; it doesn't have to be perfectly correct but you can usually tell when somebody actually understands wtf they're talking about or whether they're just bullshitting.

whiteboarding through some simple string or linked list processing algorithm is probably the least worst way of telling whether somebody can actually write a code or just bullshit about software design in the abstract. the problem is that code written by bad programmers tends to mostly work, it's just horribly designed with massive intertwined functions and modules and is difficult to actually understand and verify. i don't know how to easily tell if somebody is going to poo poo out something really god drat boring that actually gets the job done. i guess maybe try to bait them into coming up with an elaborate solution to a problem that you'd rather they solve simply?

and problems that clearly have nothing to do with programming whatsoever can gently caress right off. i'm not hiring somebody to stand in a circle of people forbidden to speak who need to not get killed by correctly raising their hand based on the colour of hat they deduce they must be wearing, there isn't much money in it and i'm pretty sure there are several laws against that. if somebody can communicate clearly and write a reasonable code but have no "lateral thinking" skills whatsoever then let me enumerate all the fucks i give:

# ? Jul 9, 2014 02:15

tef: May 30, 2004; -> some l-system crap ->

Subjunctive posted:

yeah, that sounds like a lovely experience. sorry. :-(

yep. my first facebook interview experience was being dicked around for a recruiter who took a couple of weeks to realise that I was a) not a US citizen, and b) not a graduate eligible for an h1b, and subsequently told me "go and get a degree"

the second was marred by a recruiter who didn't know which time zone they were in, or thought to schedule the interview and the hotel booking for the same period. finding out at 11pm that i have to traipse across london to find somewhere to sleep was not conducive to "hey i want to work here". oh, and also taking 2+ months to go from internal recommendation to interview stage was kinda laughable too.

i think if the recruiter was capable of understanding what day of the week my interview was, i may have been less confrontational. what i encountered was a bunch of programmers who didn't deal with criticism, as they were used to an interview being entirely one way, to wit "why *wouldn't* you want to work here? this is the future of brand engagement and we have a lot of cool machines and toys to make it happen!"

quote:

implement-this-thing isn't generally motivated by the need to have you do that in the field. it's really a shibboleth for facility with CS principles.

this has been thoroughly debunked elsewhere. it isn't computer science principles, it's rote memorization of brain teasers.

quote:

there are definitely false negatives from it, as with anything as crude as interview questions. the "can you do good engineering" interview is a different one ("pirate"!), but again it's a heuristic.

it's a proxy, a proxy for "do you have a computer science degree" somewhat, well more often "have you read that interview practice book doing the rounds"

i've had interviews where I said "i got this puzzle when i interviewed at X, you do Y", and the interviewer was kinda embarrassed. although in that same interview for that company, i got asked a rambling interview questions where someone remembered the trick but couldn't phrase the question to
force my answer to be incorrect. he forgot the question halfway through and then abandoned it.

you will have no data for false negatives here, but you may have some for false positives. i encountered some of them when i visited facebook hq.

quote:

when I interviewed for a director position, I had to rotate an image buffer -- not because I was likely to have to do that as part of my job, but because it was a way to measure a certain kind of technical depth.

well, yes and no. your problem sounds far less goal-post moving than "reverse a linked list in place", but it itself does not justify "reversing a linked list in place"

my "reverse a linked list in place" interview dance wasn't good enough until i wrote it in java. the interviewer didn't like my smart rear end answer of "it's already in place, this uses a free list and ref counting" kinda exemplifies that. it's not digging for cs principles, but cs trivia � every algorithmic puzzler has a trick, and the interview is "do you know this trick"

quote:

it's really not all about the quality of the result but about how people reason their way through it, react to feedback or changes, ask questions and state assumptions, can explain why they made the choices they did.

i guess this may be your intent, but my experience was the exact opposite. i spent a good 10 minutes talking about queues and dispatch as the interviewer pushed me until i went "oh, you want me to say pub-sub?" and he went "yes, that is what i am looking for"

the problem is that if you know the magic answer to the algorithmic brainteaser, you can fake all of those critiera. in many ways you've set up a turing test for programming which can only be passed by the chinese room. good job!

quote:

you can do pretty badly on the result of a "ninja" and still get an offer, if the other signals are good. (that said, I did write threaded C code in bootcamp, so I guess I ended up using similar skills in the field.)

i don't really know how well or badly i did as i accepted an offer to work on writing educational materials for children instead.

quote:

"solve an actually complex problem" isn't really a tenable thing in 45-min engineering interviews, because it requires a really good match between domain experience and the problem (for both candidate and interviewer) and complex problems take a while to nail down in terms of assumptions and such. I'm interested in a longer-form systems interview model for experienced candidates, but it takes a long time to get that right and calibrate interviewers and so forth.

i'm not suggesting you "solve a complex problem" instead of "solving a trick question", and it is foolish to suggest these are the only two options available to you.

quote:

(I think the silly names are as good a shorthand as anything else. it helps with people coming in from other environments and thinking "I know how to do a ds&a interview" before learning about how we do them and why they're that way)

aside: every interviewer gave me a different answer to what those meant, and one didn't tell me as they thought it was secret.

quote:

I doubt many of our interviewers are prepared for a candidate to be adversarial. Mostly people want to get along, and if they can't bring up "why do this?" in a pleasant way then that's honestly a pretty relevant signal for whether or not you'd want to work with that person.

my challenge wasn't exactly in their face "is this coding test representative of what you do in production?" "no" "ok, just wondering *scrawls up solution*"

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.

(also i wrote a working binary search first time on the whiteboard. it wasn't from rote memorization either. i am a magical beast)

# ? Jul 9, 2014 02:41

tef: May 30, 2004; -> some l-system crap ->

the weird thing about programming interviews is that they demonstrate the inadequacy of programming education. i've met prize winning graduates, and professors who struggled with fizzbuzz level questions, because it turns out lots of people with degrees can't program for poo poo.

and then to cap it all off: after acknowledging that computer science degrees are not a good proxy for ability, we fill the interview with algorithmic brainteasers from uni-level education, filtering out people without degrees, or people who haven't encountered the interview question before.

# ? Jul 9, 2014 02:46

Mr. Glass: May 1, 2009

yeah, computer science ability does not imply programming ability, nor vice versa. any competent technical interview process should test both

Mr. Glass fucked around with this message at 02:51 on Jul 9, 2014

# ? Jul 9, 2014 02:48

tef: May 30, 2004; -> some l-system crap ->

Malcolm XML posted:

i interviewed at fb

first few interviews had some algo problems, totally uselss but the idea was that it revealed ur problem solving process

then the rest were all job related with maybe a "do it in python on the board"

my "out" for a bunch of coding cases is "do u mind if I reuse X from stdlib/basic poo poo?" if they refuse its usually a sign they are bad

prob the nicest interview experience i ever did tbh, i liked everything about the place and people

by comparison, twitter: got recommended, called back within a week for a recruiter screen. passed on to extended phone interview with two engineers within a few days

first interview was average interview fodder, but i don't recall much trickery. second interview was "give me a associative array, where foo.set(dict(a=1,b=2), "foo"), foo.get(dict(a=1,b=2)) works, but foo.get(dict(a=1,b=2,c=3)) works too, and returns the same". i hacked up a crap but working implementation and asked if he wanted me to optimize it and he went "no". i wrote the code in a shared notepad, and they commented on bits as we went. we then went over stylistic choices and refactored some elements. it was all in all a good interview.

# ? Jul 9, 2014 02:51

tef: May 30, 2004; -> some l-system crap ->

Malcolm XML posted:

london

poor sod. are you in n|s|e|w london?

# ? Jul 9, 2014 02:52

syntaxrigger: Jul 7, 2011; Actually you owe me 6! But who's countin?

tef posted:

yep. my first facebook interview experience was being dicked around for a recruiter who took a couple of weeks to realise that I was a) not a US citizen, and b) not a graduate eligible for an h1b, and subsequently told me "go and get a degree"

the second was marred by a recruiter who didn't know which time zone they were in, or thought to schedule the interview and the hotel booking for the same period. finding out at 11pm that i have to traipse across london to find somewhere to sleep was not conducive to "hey i want to work here". oh, and also taking 2+ months to go from internal recommendation to interview stage was kinda laughable too.

i think if the recruiter was capable of understanding what day of the week my interview was, i may have been less confrontational. what i encountered was a bunch of programmers who didn't deal with criticism, as they were used to an interview being entirely one way, to wit "why *wouldn't* you want to work here? this is the future of brand engagement and we have a lot of cool machines and toys to make it happen!"

this has been thoroughly debunked elsewhere. it isn't computer science principles, it's rote memorization of brain teasers.

it's a proxy, a proxy for "do you have a computer science degree" somewhat, well more often "have you read that interview practice book doing the rounds"

i've had interviews where I said "i got this puzzle when i interviewed at X, you do Y", and the interviewer was kinda embarrassed. although in that same interview for that company, i got asked a rambling interview questions where someone remembered the trick but couldn't phrase the question to
force my answer to be incorrect. he forgot the question halfway through and then abandoned it.

you will have no data for false negatives here, but you may have some for false positives. i encountered some of them when i visited facebook hq.

well, yes and no. your problem sounds far less goal-post moving than "reverse a linked list in place", but it itself does not justify "reversing a linked list in place"

my "reverse a linked list in place" interview dance wasn't good enough until i wrote it in java. the interviewer didn't like my smart rear end answer of "it's already in place, this uses a free list and ref counting" kinda exemplifies that. it's not digging for cs principles, but cs trivia � every algorithmic puzzler has a trick, and the interview is "do you know this trick"

i guess this may be your intent, but my experience was the exact opposite. i spent a good 10 minutes talking about queues and dispatch as the interviewer pushed me until i went "oh, you want me to say pub-sub?" and he went "yes, that is what i am looking for"

the problem is that if you know the magic answer to the algorithmic brainteaser, you can fake all of those critiera. in many ways you've set up a turing test for programming which can only be passed by the chinese room. good job!

i don't really know how well or badly i did as i accepted an offer to work on writing educational materials for children instead.

i'm not suggesting you "solve a complex problem" instead of "solving a trick question", and it is foolish to suggest these are the only two options available to you.

aside: every interviewer gave me a different answer to what those meant, and one didn't tell me as they thought it was secret.

my challenge wasn't exactly in their face "is this coding test representative of what you do in production?" "no" "ok, just wondering *scrawls up solution*"

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.

(also i wrote a working binary search first time on the whiteboard. it wasn't from rote memorization either. i am a magical beast)

tef posted:

the weird thing about programming interviews is that they demonstrate the inadequacy of programming education. i've met prize winning graduates, and professors who struggled with fizzbuzz level questions, because it turns out lots of people with degrees can't program for poo poo.

and then to cap it all off: after acknowledging that computer science degrees are not a good proxy for ability, we fill the interview with algorithmic brainteasers from uni-level education, filtering out people without degrees, or people who haven't encountered the interview question before.

you are my hero

# ? Jul 9, 2014 02:56

Notorious b.s.d.: Jan 25, 2003; by Reene

Suspicious Dish posted:

From Intel's "Introduction to the iAPX 432 Architecture", published in 1981.

the iapx 432 was ridiculously cool. 128-way smp, multiple memory controllers, and mainframe-like intelligent I/O. in 1982.

unfortunately it cost a fortune, ran no off the shelf software, and delivered 1/10th of the performance of an 80286. oops.

# ? Jul 9, 2014 02:56

Notorious b.s.d.: Jan 25, 2003; by Reene

i've got a fair bit of i432 documentation around the house and i've always wanted to write an emulator

sadly, it seems impossible to find any binaries or object code. writing an emulator is no fun with no actual code to run.

# ? Jul 9, 2014 02:59

shrughes: Oct 11, 2008; (call/cc call/cc)

tef posted:

my "reverse a linked list in place" interview dance wasn't good enough until i wrote it in java. the interviewer didn't like my smart rear end answer of "it's already in place, this uses a free list and ref counting" kinda exemplifies that. it's not digging for cs principles, but cs trivia � every algorithmic puzzler has a trick, and the interview is "do you know this trick"

No, it's "can you figure out the trick". And if it's not a bad problem, figuring out the trick is something you can do through basic reasoning, not some grand NP-hard search of a strategy space. Reversing a linked list in place is one such problem -- people that can't figure it out suck. It's a bad problem solely because it's too well known and a lot of bad people will pass.

# ? Jul 9, 2014 03:10

MononcQc: May 29, 2007

shrughes posted:

No, it's "can you figure out the trick". And if it's not a bad problem, figuring out the trick is something you can do through basic reasoning, not some grand NP-hard search of a strategy space. Reversing a linked list in place is one such problem -- people that can't figure it out suck. It's a bad problem solely because it's too well known and a lot of bad people will pass.

In what way does tef's solution not solve the problem perfectly right, other than not being the solution the interviewer expected? poo poo, by all standards it's even better, because it doesn't require adding any special code that you later need to maintain or explain.

# ? Jul 9, 2014 03:17

shrughes: Oct 11, 2008; (call/cc call/cc)

MononcQc posted:

In what way does tef's solution not solve the problem perfectly right, other than not being the solution the interviewer expected? poo poo, by all standards it's even better, because it doesn't require adding any special code that you later need to maintain or explain.

He didn't show his solution, but if somebody answers a question one way (in some environment where memory is managed with a free list?) it's perfectly reasonable to ask a followup question that adds more restrictions or nuance to the question. The example tef gave shows one where the followup makes the question more rigorous and lets his performance be compared with other people that answered the question.

Your response is not relevant to what my reply was about, which is that it's not about knowing the trick.

# ? Jul 9, 2014 03:24

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

there's an assumption here that "did they get the answer?" is the high-order bit in discussion of the interview feedback. it's not. the specific problem is a calibrated topic of conversation, not a pass-fail test. if you get it instantly, it usually means "didn't get signal", not "omg brilliant". I've been in offer review for >200 candidates since I got here, and I've never seen someone lose because they didn't know "the trick", or acclaimed because they got the answers on the first try.

for any given candidate there are questions you can ask that would give you a better signal about them. it's too bad you can't know what those are ahead of time, and bespoke stuff frankly doesn't scale to thousands of candidates a year. if we know something about a candidate going in that indicates that we'd be better-served by a different interview approach, we sometimes do that, but it's ~1% of the time I expect.

I'm sure we have false positives. I've never worked anywhere that didn't; interviews are too crude a tool to avoid it. the issue is what happens with them, and how it affects the team around them. I think we do pretty well on those scores, though we're certainly imperfect.

I like the Twitter question.

(edit: as far as being representative of work, how you solve problems you know the answer to is one of the most useless things we could probe)

Subjunctive fucked around with this message at 03:38 on Jul 9, 2014

# ? Jul 9, 2014 03:28

Mr. Glass: May 1, 2009

Subjunctive posted:

the specific problem is a calibrated topic of conversation, not a pass-fail test. if you get it instantly, it usually means "didn't get signal", not "omg brilliant".

# ? Jul 9, 2014 03:31

MononcQc: May 29, 2007

shrughes posted:

He didn't show his solution, but if somebody answers a question one way (in some environment where memory is managed with a free list?) it's perfectly reasonable to ask a followup question that adds more restrictions or nuance to the question. The example tef gave shows one where the followup makes the question more rigorous and lets his performance be compared with other people that answered the question.

Your response is not relevant to what my reply was about, which is that it's not about knowing the trick.

If the answer you want is 'know the trick the interviewer expects' rather than using whatever answer you get to evaluate how the candidate thinks, you may as well just ask them what number you're thinking of and only keep those who get the right one, because how they got to the answer clearly has no value to you.

"yes, 17 is a number, but what if the number I'm thinking of is lower than 10?"

# ? Jul 9, 2014 03:39

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

MononcQc posted:

If the answer you want is 'know the trick the interviewer expects'

then

# ? Jul 9, 2014 03:42

tef: May 30, 2004; -> some l-system crap ->

shrughes posted:

No, it's "can you figure out the trick". And if it's not a bad problem, figuring out the trick is something you can do through basic reasoning, not some grand NP-hard search of a strategy space.

not all interview problems tef, not all of them. i mean it only took, what less than a decade for quicksort.

the linked list question was more about "you are looking for a specific answer, not asking me to demonstrate my knowledge". writing the second version was approximately the same, line for line. except I did foo.a = a, foo.b = b, intstead of foo = foo(a,b)

the second problem "find the common tail in two linked lists" is the one i fumbled on, i forgot the trick.

# ? Jul 9, 2014 03:42

tef: May 30, 2004; -> some l-system crap ->

Subjunctive posted:

I've been in offer review for >200 candidates since I got here, and I've never seen someone lose because they didn't know "the trick", or acclaimed because they got the answers on the first try.

so what you're saying is "knowing the answer in advance makes no little to no difference to how we score the question"?

quote:

for any given candidate there are questions you can ask that would give you a better signal about them. it's too bad you can't know what those are ahead of time, and bespoke stuff frankly doesn't scale to thousands of candidates a year. if we know something about a candidate going in that indicates that we'd be better-served by a different interview approach, we sometimes do that, but it's ~1% of the time I expect.

there must be some programming problems that allow people to reason and explain their choices and approach, without being based around knowing a specific trick in advance. these tricks aren't performance tricks, they're big O notation tricks.

quote:

I'm sure we have false positives. I've never worked anywhere that didn't; interviews are too crude a tool to avoid it. the issue is what happens with them, and how it affects the team around them. I think we do pretty well on those scores, though we're certainly imperfect.

I like the Twitter question.

(edit: as far as being representative of work, how you solve problems you know the answer to is one of the most useless things we could probe)

on the other hand, how you solve algorithmic puzzlers is possibly just as useless :3:

# ? Jul 9, 2014 03:47

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

As long as our interview questions keep how!! out, I don't have any other opinion on them. My interview question was a round of Mario Kart :mrgw:

# ? Jul 9, 2014 03:50

Damiya: Jul 3, 2012

Suspicious Dish posted:

As long as our interview questions keep how!! out, I don't have any other opinion on them. My interview question was a round of Mario Kart

uhm if the accepted answer for a given interview question isn't "rewrite the entire codebase from the ground up" i don't wanna work there. :colbert:

# ? Jul 9, 2014 03:53

shrughes: Oct 11, 2008; (call/cc call/cc)

tef posted:

the linked list question was more about "you are looking for a specific answer, not asking me to demonstrate my knowledge".

No, it's not asking for knowledge. It's to see if you can figure out how to do it.

tef posted:

the second problem "find the common tail in two linked lists" is the one i fumbled on, i forgot the trick.

You couldn't figure out the trick.

If you're thinking these questions are about remembering a solution, well, the questions must be correctly filtering you out.

# ? Jul 9, 2014 04:01

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

shrughes posted:

No, it's not asking for knowledge. It's to see if you can figure out how to do it.

Reversing a linked list in-place? The magical thing about this is that it's identical to building a new list from nothing. This is the traditional solution:

C code:

Node * reverse (Node *head) {
    Node *prev = NULL;
    while (head) {
        // Save onto the old next node before we trash it.
        Node *elem = head->next;

        // Point it to the previous one.
        head->next = prev;

        // Go forward.
        prev = head;
        head = next;
    }

    // prev is now the head of the list.
    return prev;
}

Now let's do it "not in place" by building a new list:

C code:


Node * reverse (Node *old_head) {
    Node *new_head = NULL;
    while (old_head) {
        // Pop the node
        Node *elem = old_head;
        old_head = old_head->next;

        // Push it to to the new list
        elem->next = new_head;
        new_head = elem;
    }
    return new_head;
}

The two are exactly identical. Well, we rearranged some of the statements, but the algorithm is exactly the same. They compile to the same code.

in-place means "use the same variable names that I did when I wrote this function" and nothing more.

# ? Jul 9, 2014 04:12

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

tef posted:

so what you're saying is "knowing the answer in advance makes no little to no difference to how we score the question"?

the system is designed so that it shouldn't. if you get the answer right away, the interviewer asks another one. we want to see people do work, because that's where the signal is.

quote:

there must be some programming problems that allow people to reason and explain their choices and approach, without being based around knowing a specific trick in advance. these tricks aren't performance tricks, they're big O notation tricks.

there are lots; we have a couple dozen that we have found to provoke the signal we want, most of the time. few such problems are domain-neutral, but ability to develop an algorithm is close to the core computer science capability. (plus watching how the code manifests, which weeds out a lot of people who just aren't fluent enough in their best language. our phone screens are intentionally quite permissive, because the model is low-signal even by tech interview standards.)

big-O analysis is one of the common follow-up question areas (example: "make it constant space"), but they too are often decried as being "do they remember that CS class?".

our interview process is by no means perfect, but I don't think the most important areas to fix are what you're concerned about here. everyone knows that doing bar trivia tells you very little based on the answer itself. you are not presenting some novel analysis here. I'm sorry you had a bad time, though.

(I didn't get to the optimization phase of image-rotate at all, because I had a bunch of rust to shake off and stupidly chose C as my language. I don't know the specific feedback on it, but I did get the job.)

I've asked interview questions I don't know the specific answer to. works fine, because I don't care about the answer.

# ? Jul 9, 2014 04:15

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Don't Ask Discrete Math Puzzles That Aren't Explicitly Programming

dump the counterfeit coins, smash the light bulbs, slaughter the fox and the goose. there are competent programmers who weren't suckled on martin gardener columns

# ? Jul 9, 2014 04:22

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

I don't have to hire every competent programmer. catching them all is not a goal of the process.

we care a fair bit about combinatorics, as one must when an intern can (correctly) push something that generates billions of ops/day against whatever internal service, but I don't think we have questions around them.

We do like dynamic programming questions though. maybe more than we should.

# ? Jul 9, 2014 04:29

shrughes: Oct 11, 2008; (call/cc call/cc)

I don't think dynamic programming questions are a great idea. It's one of those things where the question often tells whether the person has seen dynamic programming, and it's not a particularly valuable signal. At least for the sort of dynamic programming questions that involve 2D arrays.

I think our problem right now is that we have two questions that involve putting metadata on tree nodes that count how many elements there are in a subtree.

Subjunctive posted:

I don't have to hire every competent programmer. catching them all is not a goal of the process.

Given the state of the job market, and how much we want to hire, I am rather concerned with avoiding false negatives. Right now, I think the main goal of designing an interview process, for us, is to minimize false negatives. The important part of the interview process is the earliest part, because you want to minimize false negatives but you also don't want to waste the team's time (and you also want to keep them interested). Once the person's coming into the office, I think we'll figure out whether they're good or bad.

# ? Jul 9, 2014 05:02

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

I'm trying to remember which are the dynamic programming questions in play right now. I didn't actually know the term until I started looking at them in candidate review, but I'd learned the techniques over the years. I'll look it up tomorrow, I'm curious now.

our phone screen is oriented around avoiding false negatives; it's a fog-a-mirror test, and if the interviewer thinks there's a >25% chance the person will pass a loop, we bring them in. the on-site interviews are more oriented around avoiding false positives, especially "will they be happy and effective in our environment?"

# ? Jul 9, 2014 05:10

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

tef posted:

see, if you were on a cray, this is an instruction

the llvm teams here ask this question a lot, and pointing out that some ISAs provide it natively is considered an excellent response (but then they make you work through it anyway)

# ? Jul 9, 2014 05:42

shrughes: Oct 11, 2008; (call/cc call/cc)

Subjunctive posted:

our phone screen is oriented around avoiding false negatives; it's a fog-a-mirror test, and if the interviewer thinks there's a >25% chance the person will pass a loop, we bring them in. the on-site interviews are more oriented around avoiding false positives, especially "will they be happy and effective in our environment?"

After the first phone screen we've started having a take-home coding assignment of the form "make a program that meets such and such spec" that is a mildly interesting toy problem of nonzero difficulty where you're not allowed to take more than 2 hours. Nobody has refused to do it. It's let us efficiently reject some 25%ers or maybe some 12%ers. It's the sort of problem some people have done before (and the sort of thing tef has posted links to books about before), but even then, bad programmers who've done it before will fail the test, and good programmers who haven't will pass (since the problem's simple enough).

# ? Jul 9, 2014 08:15

JewKiller 3000: Nov 28, 2006; by Lowtax

don't limit their time to write the program, aside from the limit for the evaluation period. send them the problem and give them a week or whatever to do their thing

also the best way is to start everyone as a contractor with some trial period and then move to full time once everyone involved agrees

# ? Jul 9, 2014 09:17

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

rjmccall posted:

the llvm teams here ask this question a lot, and pointing out that some ISAs provide it natively is considered an excellent response (but then they make you work through it anyway)

it's been an instruction on late model intel CPUs so the correct answer is "look it up in hackers delight"

# ? Jul 9, 2014 09:28

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 02:40

shrughes: Oct 11, 2008; (call/cc call/cc)

JewKiller 3000 posted:

don't limit their time to write the program, aside from the limit for the evaluation period. send them the problem and give them a week or whatever to do their thing

But we don't want to waste time interviewing retards.

JewKiller 3000 posted:

also the best way is to start everyone as a contractor with some trial period and then move to full time once everyone involved agrees

Oh wait you trolled me.

# ? Jul 9, 2014 09:56

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »