From: Tia Marie Date: 21:06 on 12 Jun 2007 Subject: I hate you UI Designer at Prove It! I'm currently on the horrible road to job hunting. One company in particular is having me take "aptitude" tests from this site proveit.com in order to "prove" I am as proficient on certain softwares as I have claimed to be. That is totally fine with me. However, the "Virtual software" Java applet sucks. The user interface for the tests for the Microsoft office programs is by far the worst and most hateful shit I have ever touched. You can only launch it from IE or Netscape. Also when testing it will ONLY except standard answers. Like clicking the [B] icon for bold to change the font instead of the shortcut key. When I do try an alternative method (or the method that isn't considered right by the test's standards) it interrupts me with a pop up saying "Are you finished with this question?" and gives me the option to say "repeat question" which starts me brand new (if I were in a menu or something a few options in I'd be back at start and have to retrace a multistep process) or I can say yup I'm done. I hate you UI Designer. You may seem to think that making these tests more frustrating to us unemployed non-programmer types is funny, but I find it sadistic and I hate you and your entire company and your shitty UI. --Tia
From: Yossi Kreinin Date: 07:45 on 13 Jun 2007 Subject: Re: I hate you UI Designer at Prove It! Tia Marie wrote: > I hate you UI Designer. You may seem to think that making these tests > more frustrating to us unemployed non-programmer types is funny, but I > find it sadistic and I hate you and your entire company and your shitty > UI. > One of my current coworkers actually failed a test where she was supposed to *build an aircraft from paper* with a bunch of other candidates. She wasn't found "cooperative" enough or something. The company didn't want that kind of programmer. She claims to have previously passed the same idiotic set of tests for some other purpose. According to my crude estimations, at least about 75% of the people getting payed for crafting tests used for various selection processes in modern society should be taken out and shot. As to the morons paying them for the tests rejecting random people and accepting other random people (or, worse, accepting the worst possible candidates) - those morons don't require any special attention. Uncle Darwin will collect their bodies himself.
From: Andrew Black - lists Date: 08:00 on 13 Jun 2007 Subject: Re: I hate you UI Designer at Prove It! Yossi Kreinin wrote: > According to my crude estimations, at least about 75% of the people > getting payed for crafting tests used for various selection processes in > modern society should be taken out and shot. But what tests do you use to select the lucky 25% that remain. And who arranges this test, without the danger of themselves being shot.
From: Yossi Kreinin Date: 09:20 on 13 Jun 2007 Subject: Re: I hate you UI Designer at Prove It! Andrew Black - lists wrote: > > But what tests do you use to select the lucky 25% that remain. And who > arranges this test, without the danger of themselves being shot. > > You have a point. That's what happens when one gets too humane. You start with a harmlessly looking amendement (I only said "at least 75%", could be 100% for all I know), and the next thing you see is a self-referential bullet shot through your face. Forget it. Just shoot the whole lot. Seriously, even IQ-like tests, which are a couple orders of magnitude less moronic than your typical special-purpose aptitude test, are effectively microbenchmarks for the brain. I wouldn't insult a computer by estimating it's abilities using the total execution time of hundreds of tiny jobs. Want to hire a programmer? Ask the candidates to write a fucking *program*, and see what happens. Sounds better than having them make a paper plane to me.
From: A. Pagaltzis Date: 11:33 on 13 Jun 2007 Subject: OT: hiring programmers (was: I hate you UI Designer at Prove It!) * Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> [2007-06-13 10:25]: > Want to hire a programmer? Ask the candidates to write a > fucking *program*, and see what happens. Sounds better than > having them make a paper plane to me. Or better yet, ask them to bring along some limited-size chunk of code they wrote; not too trivial, not too substantial. Tell them you expect them to discuss any aspect of their choice about this piece of code. Yeah, it's not a cookie cutter interview and you need someone who really understands the subject matter rather than sitting people down in front of a screen or an HR drone. But you'll actually learn something about how that programmer ticks. (It gets especially interesting when you start to ask meta questions: what other pieces of code did the candidate consider? Why did they pick the one they picked?) Asking people to perform any sort of test during the interview, even if it's writing code and not a moronic test, tends to filter for people who do well in testing situations rather than for people who are actually apt. Asking them to bring something along is more likely to provide clues as to how they reason in a realworld situation. It also weeds out the incompetents and the liars as easily as a any basic aptitude test, since a bumbler or cheater is unlikely to a) have written a substatial piece of code, b) understand in detail how it works, and c) be able to talk intelligently about it. Regards,
From: Yossi Kreinin Date: 11:45 on 13 Jun 2007 Subject: Re: OT: hiring programmers A. Pagaltzis wrote: > > Or better yet, ask them to bring along some limited-size chunk of > code they wrote; not too trivial, not too substantial. Tell them > you expect them to discuss any aspect of their choice about this > piece of code. > It's a great test, but many people only write code when they get payed for it, and in those situations they can't legitimately keep a private copy of it and discuss it with potential employers. Which means that their previous projects have to be discussed without actual code listings. Which is still more useful than only having people write code without talking about solving real problems.
From: Robert Rothenberg Date: 11:54 on 13 Jun 2007 Subject: Re: OT: hiring programmers On 13/06/07 11:45 Yossi Kreinin wrote: > It's a great test, but many people only write code when they get payed > for it, and in those situations they can't legitimately keep a private > copy of it and discuss it with potential employers.... Surely the better candidates have written some code for their own personal use or even to share with the wider world.
From: Yossi Kreinin Date: 15:22 on 13 Jun 2007 Subject: Re: OT: hiring programmers Robert Rothenberg wrote: > > Surely the better candidates have written some code for their own personal > use or even to share with the wider world. > 4 out of the best 5 programmers I know haven't. Personally, I started programming projects in the background a couple of times but it didn't really get very far, and the last time I did it was a long time ago. Here are some reasons for a strong programmer not to program outside of the office: * If you have a good job, you're likely to get to do whatever kind of work you want to do as part of that job anyway. * You might be interested in and/or be good at other things which can occupy your spare time. * For a project to succeed (as in have any side effects in addition to having the code take bytes on your hard drive), you may need more than just good code (ranging from equipment to time/skills needed to communicate with other people). You may prefer some organization to deal with it and concentrate on programming. * You hate software. You only want to write good code when you work with other people on something, and you want the software not to exceed a hatefulness threshold so that people dealing with it are not too miserable. There are other reasons. Sometimes all these reasons cause people not to code at their spare time at all; sometimes they cause them to work on code which is hard to discuss at interviews (like brainfuck interpreters or ioccc entries or code for doing things inside their obscure window manager connected to their fridge via bluetooth or whatever). And then there's the horrific category of people who love software and can talk for all day long about it and know everything they've ever used inside out but somehow manage not to get anything done properly and/or annoy everyone around themselves and/or they have very strong religious beliefs about technology causing them to make costly wrong decisions. These people are not unlikely to write code at their spare time. So it's not that simple, although the false negative cases are probably much more frequent than the false positive cases.
From: Abigail Date: 15:54 on 13 Jun 2007 Subject: Re: OT: hiring programmers --mR8QP4gmHujQHb1c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2007 at 05:22:30PM +0300, Yossi Kreinin wrote: > Robert Rothenberg wrote: > > > >Surely the better candidates have written some code for their own person= al > >use or even to share with the wider world. > > >=20 > 4 out of the best 5 programmers I know haven't. Personally, I started=20 > programming projects in the background a couple of times but it didn't=20 > really get very far, and the last time I did it was a long time ago. >=20 > Here are some reasons for a strong programmer not to program outside of t= he=20 > office: >=20 > * If you have a good job, you're likely to get to do whatever kind of wor= k=20 > you want to do as part of that job anyway. > * You might be interested in and/or be good at other things which can=20 > occupy your spare time. > * For a project to succeed (as in have any side effects in addition to=20 > having the code take bytes on your hard drive), you may need more than ju= st=20 > good code (ranging from equipment to time/skills needed to communicate wi= th=20 > other people). You may prefer some organization to deal with it and=20 > concentrate on programming. > * You hate software. You only want to write good code when you work with= =20 > other people on something, and you want the software not to exceed a=20 > hatefulness threshold so that people dealing with it are not too miserabl= e. * You have more interests than coding, and spend your time away from the office on the other things you like. Abigail --mR8QP4gmHujQHb1c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFGcAUTBOh7Ggo6rasRAjQiAJ4z8yGZZSDrEyTyP1pHkl0K/5GzFgCgmJER tpHNB4SjzU2u0fMq4AYL0Po= =DwXm -----END PGP SIGNATURE----- --mR8QP4gmHujQHb1c--
From: Denny Date: 16:02 on 13 Jun 2007 Subject: Re: OT: hiring programmers On Wed, 2007-06-13 at 16:54 +0200, Abigail wrote: > On Wed, Jun 13, 2007 at 05:22:30PM +0300, Yossi Kreinin wrote: > > > > * You might be interested in and/or be good at other things which > > can occupy your spare time. > > * You have more interests than coding, and spend your time away from > the office on the other things you like. * Your time-consuming voluntary work at the Department of Redundancy Department is very time-consuming. ;)
From: David Cantrell Date: 16:09 on 13 Jun 2007 Subject: Re: OT: hiring programmers On Wed, Jun 13, 2007 at 05:22:30PM +0300, Yossi Kreinin wrote: > Robert Rothenberg wrote: > >Surely the better candidates have written some code for their own personal > >use or even to share with the wider world. > 4 out of the best 5 programmers I know haven't. What, not even to automate away some of the incredibly tedious things you have to do sometimes on your home machine? Nothing to work around some other bastard's Hatefulness? I'd be quite happy to review shell or C code, even code for Windows, if interviewing someone for a perl on Unix job. > Here are some reasons for a strong programmer not to program outside of the > office: > > * If you have a good job, you're likely to get to do whatever kind of work > you want to do as part of that job anyway. It's possible, but unlikely. And if the job is that good why are you looking for a new one? > * You might be interested in and/or be good at other things which can > occupy your spare time. True, but I keep finding that all of the other things I'm interested in can be helped out with a few lines of code, whether it be driving model trains or going for a walk on the Downs. > * For a project to succeed (as in have any side effects in addition to > having the code take bytes on your hard drive), you may need ... For a project to succeed all it has to do is solve the problem that prompted you to write it in the first place. > * You hate software. I even hate my own a little bit, but I hate not having software even more. > So it's not that simple, although the false negative cases are probably > much more frequent than the false positive cases. And there is the heart of the issue. I suppose it's like automagically rejecting people who don't have a piece of paper from a university. But I bet that rejecting people who don't do any coding at all on their own time is *far* more accurate.
From: Yossi Kreinin
Date: 16:47 on 13 Jun 2007
Subject: Re: OT: hiring programmers
David Cantrell wrote:
>
> What, not even to automate away some of the incredibly tedious things
> you have to do sometimes on your home machine? Nothing to work around
> some other bastard's Hatefulness?
>
I guess that extending the scope to tiny piece of code would make it 3 out of 5
in my case. Doesn't make it worth to start an argument whether such kind of code
is any good when you want to judge someone's skills relevant for a practical job.
>
> It's possible, but unlikely. And if the job is that good why are you
> looking for a new one?
>
At this point we probably both realize that it can go on and on. I'll try to
compensate my urge to proceed despite that fact by lame attempts to make my
reply entertaining, but I don't guarantee anything.
So. You could leave that good job since
* You moved to another country
* A critical mass of bastards formed in that place, slaughtering the good
projects and rendering the place a graveyard
* The organization ran out of money (can happen to strong ones, especially when
they are huge and a critical mass of bastards paralizes too much of them, even
though some parts remain productive)
* You get to do great stuff at that place, but they think it means they don't
have to pay competitively, and you're in the mood for buying real estate
* You're done. Everything runs smoothely, no big interesting things are left,
the company is going to do nothing but ship copies of the feature-complete
product and answer tech support calls.
* The company ships a big hit and starts growing rapidly, but stupidly. Soon it
gets clogged up by people you'd rather not work with.
>
>
> True, but I keep finding that all of the other things I'm interested in
> can be helped out with a few lines of code, whether it be driving model
> trains or going for a walk on the Downs.
>
The physical world has a lot to offer, and many of the interesting devices lack
digital components. Enumerating them would take copying the larger part of a
dictionary, so I'll pass.
>
> For a project to succeed all it has to do is solve the problem that
> prompted you to write it in the first place.
>
There are many programming languages solving the same problem of programming,
many operating systems solving the problem of operating a system, many web
browsers solving the problem of browsing the web, and many idiotic programs
solving the problem of wishing to look at an idiotic program for amusement
(dc.sed, etc.). Some of them succeeded, some didn't. Few people would agree that
the ones that largely failed did so because they largely failed to solve the
problem.
>
> I even hate my own a little bit, but I hate not having software even more.
>
The thing is that some people have much more extrinsic motivation ("people need
this program", "I get payed for it") than intrinsic motivation ("this program is
so interesting", "nobody did this before"). This doesn't make them weak
professionals, since their extrinsic motivation can cause their intrinsic
motivation to ultimately reach a high level. But this won't happen if there's no
extrinsic motivation to start with.
>
> And there is the heart of the issue. I suppose it's like automagically
> rejecting people who don't have a piece of paper from a university. But
> I bet that rejecting people who don't do any coding at all on their own
> time is *far* more accurate.
>
I won't argue with that, even though personally I went straight for the piece of
paper but didn't complete any programming project outside of work. Your claim is
somewhat analogous to my assumption that the problem is mostly in false negative
cases, not the false positive. That is, you'll surely reject good candidates,
but accepting poor candidates is less likely.
I still dislike both methods of rejection, and I think they're ultimately based
on the same principle - people reject the ones who are less like them. If
someone studied in a university but never coded without getting payed, they'll
look for their kind, and vice versa.
From: A. Pagaltzis Date: 19:43 on 13 Jun 2007 Subject: Re: OT: hiring programmers * Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> [2007-06-13 17:55]: > There are many programming languages solving the same problem > of programming, many operating systems solving the problem of > operating a system, many web browsers solving the problem of > browsing the web, and many idiotic programs solving the problem > of wishing to look at an idiotic program for amusement (dc.sed, > etc.). Some of them succeeded, some didn't. Few people would > agree that the ones that largely failed did so because they > largely failed to solve the problem. Yeah, but that sort of success criterion is irrelevant to a discussion in an interview; if someone brought along a copy of some part of the BeOS kernel, say, or a short excerpt from a REXX interpreter, I certainly wouldn’t mind talking about it. > I still dislike both methods of rejection, and I think they're > ultimately based on the same principle - people reject the ones > who are less like them. If someone studied in a university but > never coded without getting payed, they'll look for their kind, > and vice versa. Can't argue with that. Unfortunately you can't devise *any* form of interview that will tell you everything you need to know about the candidate prior to actually working with them. And a big problem is the fact that it's really, really, REALLY costly to deal with false positives, so keeping those as close to zero as possible is vital, even if it means you'll be forced to accept an unfortunate amount of false negatives. C'est la vie. :-( Regards,
From: Yossi Kreinin Date: 08:47 on 14 Jun 2007 Subject: Re: OT: hiring programmers A. Pagaltzis wrote: > * Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> [2007-06-13 17:55]: >=20 >>There are many programming languages solving the same problem >>of programming, many operating systems solving the problem of >>operating a system, many web browsers solving the problem of >>browsing the web, and many idiotic programs solving the problem >>of wishing to look at an idiotic program for amusement (dc.sed, >>etc.). Some of them succeeded, some didn't. Few people would >>agree that the ones that largely failed did so because they >>largely failed to solve the problem. >=20 >=20 > Yeah, but that sort of success criterion is irrelevant to a > discussion in an interview; if someone brought along a copy of > some part of the BeOS kernel, say, or a short excerpt from a > REXX interpreter, I certainly wouldn=E2=80=99t mind talking about it. >=20 >=20 Sure. I didn't argue with a suggestion to reject programmers who worked o= n=20 projects that failed for non-technical reasons or the like, since natural= ly=20 nobody proposed that. What I wanted to say was that some people don't lik= e=20 working on "the next big thing", and would rather work on "the current bi= g=20 thing". At least 3 great programmers I know are like that. And one of the= m=20 actually works for fun, since he's made enough money on a previous job to= not=20 have to work anymore. But he *works for a company* for fun, not writing o= pen=20 source stuff. It took me some time to even realize that category of people exists, and = I'm not=20 sure I fully understand their perspective today, which may be the reason = I=20 didn't really make myself clear. I think that for this kind of people, so= mething=20 doesn't even exist until they actually see people using it or asking for = it, for=20 some of them that must be physical people around them. For these people, = working=20 on problems someone finds important enough to pay for makes sense, and wo= rking=20 on something which theoritically can become interesting to people or it m= ay not=20 doesn't make sense. Usually, people who like the current big thing are into implementing stuf= f, and=20 people who like the next big thing are into defining stuff. Apparently th= e first=20 category is larger, and I don't think that it's unique to programming. Fo= r=20 example, 4 out of 5 strongest hardware hackers I know are into implementa= tions,=20 not architecture definitions. As to your other message, about writing code before the interview - sure,= every=20 good candidate should be able to do it. I'm only saying I don't like the = idea of=20 making writing code outside of one's job a precondition for an interview.=
From: A. Pagaltzis Date: 10:53 on 14 Jun 2007 Subject: Re: OT: hiring programmers * Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> [2007-06-14 09:55]: > As to your other message, about writing code before the > interview - sure, every good candidate should be able to do it. > I'm only saying I don't like the idea of making writing code > outside of one's job a precondition for an interview. Nowhere did I say that writing code outside of the job should be a precondition. What I said is merely that candidates should bring some non-trivial piece of code along to discuss. It doesn't matter whether they've written the code specifically for the interview or for their own use or for an open source project or even for a past employer (as long as they have permission to show it, natch). A surprising number of applicants can't actually program, so you want to weed them out early by asking for direct proof that they can do so. However, you also want to avoid the testing situation bias, so I wouldn't to sit them down with a moronic coding test (like that "FizzBuzz" silliness) during the interview, either. The point of asking to see code is to weed out the incompetents; the point of asking them to talk about is to weed out any liars who may have brought code they pulled up with Google. In short: show me you can program. At all. That is all. (I actually lost this point a bit myself during the discussion.) That this sort of question gives you plenty of opportunities to pick the candidate's brain is a nice fringe benefit, but not its main purpose. Note that (obviously, I had hoped) whether they can write code at all wouldn't be the sole criterion for an offer -- in fact it's nothing more than a litmus test. So the nasty false positives you mentioned don't really come up. Regards,
From: Zach White Date: 13:56 on 14 Jun 2007 Subject: Re: OT: hiring programmers On Thu, Jun 14, 2007 at 11:53:39AM +0200, A. Pagaltzis wrote: > A surprising number of applicants can't actually program, so you > want to weed them out early by asking for direct proof that they > can do so. However, you also want to avoid the testing situation > bias, so I wouldn't to sit them down with a moronic coding test > (like that "FizzBuzz" silliness) during the interview, either. I find that people who speak poorly of FizzBuzz style tests don't understand the problem they solve, or think they somehow test for competency. FizzBuzz doesn't tell you how good a programmer is. It doesn't tell you what their work ethic is like. It doesn't tell you how well they work with others. It simply tells you that they can solve a tiny programming problem, which an amazingly large number of "programmers" simply can't do. It's not a general tool, it's only used to weed out those people who come from untrustworthy sources, like a recruiter, or craigslist. If a candidate is coming to me through one of those sources it tells me that they don't have the ability to get a job through the normal means (old coworkers, college buddies, etc) and therefore deserve more scrutiny. FizzBuzz is a cheap and easy way to filter those candidates at phone interview time. -Zach
From: A. Pagaltzis Date: 00:01 on 15 Jun 2007 Subject: Re: OT: hiring programmers * Zach White <zwhite-hates-software@xxxxxxxx.xxxx.xxx> [2007-06-14 15:05]: > On Thu, Jun 14, 2007 at 11:53:39AM +0200, A. Pagaltzis wrote: > > A surprising number of applicants can't actually program, so > > you want to weed them out early by asking for direct proof > > that they can do so. However, you also want to avoid the > > testing situation bias, so I wouldn't to sit them down with a > > moronic coding test (like that "FizzBuzz" silliness) during > > the interview, either. > > I find that people who speak poorly of FizzBuzz style tests > don't understand the problem they solve, or think they somehow > test for competency. I can't speak for everyone who criticises FizzBuzz, but I didn't think (or claim) that that's the point of such a test. > FizzBuzz doesn't tell you how good a programmer is. It doesn't > tell you what their work ethic is like. It doesn't tell you how > well they work with others. It simply tells you that they can > solve a tiny programming problem, which an amazingly large > number of "programmers" simply can't do. Yes, and that is exactly what asking them to bring along code and then talk about it is also meant to accomplish -- no more than that. > It's not a general tool, it's only used to weed out those > people who come from untrustworthy sources, like a recruiter, > or craigslist. If a candidate is coming to me through one of > those sources it tells me that they don't have the ability to > get a job through the normal means (old coworkers, college > buddies, etc) and therefore deserve more scrutiny. FizzBuzz is > a cheap and easy way to filter those candidates at phone > interview time. Exactly; the point of asking for a snippet of code and some discussion of it is merely and solely to weed out the same categories of duds that FizzBuzz is also meant to solve. But having them provide proof by solving a cookie-cutter problem during the interview puts the candidate in a stressful closed-ended situation; whereas seeing some code they previously wrote and hearing them talk about it accomplishes exactly the same thing, while letting the candidate pick familiar and comfortable ground, making it a casual open-ended situation. Of course, a fringe benefit is that in contrdistinction to Fizz- Buzz, you get extra opportunities to figure out the candidate. But that's just a nice bonus and not the point. Perceptions are hugely important in the hiring game, so you want avoid anything that might introduce large random inputs or systemic biases. Therefore it is important to minimise the stressfulness and maximise the neutrality of the situation: neither the candidate's behaviour nor the interviewer's opinion should be inordinately affected by irrelevant minutiæ. I agree with the premises and the goal that lead to FizzBuzz- style tests. I simply disagree that FizzBuzz tests are the best way to achieve that goal. Regards,
From: Peter da Silva Date: 18:12 on 13 Jun 2007 Subject: Re: OT: hiring programmers On Jun 13, 2007, at 9:22 AM, Yossi Kreinin wrote: > And then there's the horrific category of people who love software and > can talk for all day long about it and know everything they've ever > used inside out but somehow manage not to get anything done properly > and/or annoy everyone around themselves and/or they have very strong > religious beliefs about technology causing them to make costly wrong > decisions. These people are not unlikely to write code at their spare > time. That's why you interview them instead of just having them send in a code sample, no?
From: Yossi Kreinin Date: 07:53 on 14 Jun 2007 Subject: Re: OT: hiring programmers Peter da Silva wrote: > On Jun 13, 2007, at 9:22 AM, Yossi Kreinin wrote: > >> And then there's the horrific category of people who love software and >> can talk for all day long about it and know everything they've ever >> used inside out but somehow manage not to get anything done properly >> and/or annoy everyone around themselves and/or they have very strong >> religious beliefs about technology causing them to make costly wrong >> decisions. These people are not unlikely to write code at their spare >> time. > > > That's why you interview them instead of just having them send in a code > sample, no? > Yeah, I just mentioned them because they are the worst false positives. I assumed that if someone thinks writing code on one's spare time is good, that someone will kind of like the (not extremely large set of) candidates that actually do so and can thus proceed to the next stage of testing. The smart software-loving psychopath candidate can then strengthen the good impression in an interview since many people will like the "passion" or whatever. Of course it doesn't have to happen, and the high likelyhood of it didn't directly and inevitably follow from any of the claims I was answering. I just mentioned it because these are rare, but pretty nasty false positives.
From: David Cantrell Date: 14:29 on 13 Jun 2007 Subject: Re: OT: hiring programmers On Wed, Jun 13, 2007 at 01:45:07PM +0300, Yossi Kreinin wrote: > It's a great test, but many people only write code when they get payed for > it, and in those situations they can't legitimately keep a private copy of > it and discuss it with potential employers. Which means that their previous > projects have to be discussed without actual code listings. Which means no interview. I would no more hire someone as a programmer who doesn't write stuff for himself than I would hire someone as a brewer who didn't drink alcohol.
From: Steff Davies Date: 15:01 on 13 Jun 2007 Subject: Re: OT: hiring programmers David Cantrell wrote: > > Which means no interview. I would no more hire someone as a programmer > who doesn't write stuff for himself than I would hire someone as a > brewer who didn't drink alcohol. I'm not totally sure about that, myself. There are people doing excellent work at $formeremployer (the interview for which involves a live programming exercise which sems to screen out bluffers very effectively) who don't even own a home computer, much less trip lightly off after work to write the Next Great Text Editor or whatever. S Obligatory software hate: Totem, the little media player that couldn't, but which Gnome assigns as the default for so many file types that months after installing this machine, it still pops up at intervals when I expected vlc or mplayer.
From: Yossi Kreinin Date: 15:30 on 13 Jun 2007 Subject: Re: OT: hiring programmers David Cantrell wrote: > > > Which means no interview. I would no more hire someone as a programmer > who doesn't write stuff for himself than I would hire someone as a > brewer who didn't drink alcohol. > Analogies rule, although there are many others giving different perspectives (proctologists that don't mess with their own rear ends, soldiers who don't shoot themselves, prostitutes that don't masturbate - looks like my brain is all about sex and violence, so I'll stop there). And I'd guess that brewers who regularly get drunk at nights and are not fully functional in the morning are no picnic, either. Anyway, I get the idea. I'd appreciate if you sent over the CVs of those rejected people.
From: Peter da Silva Date: 17:58 on 13 Jun 2007 Subject: Re: OT: hiring programmers Actually... I think the analogy "not hiring a brewer who doesn't drink" doesn't even go far enough. Even if you don't like programming, or don't currently program in your spare time, I can't imagine someone who's a programmer who has *never* written any software that they can't bring in as an example. Even if it's something horrid from college that they think sucks, at least they could bring it in and explain why it sucks and what they'd do differently now. The point isn't to see the code, it's to have the code there for them to explain, discuss, critique, apologize for, and so on.
From: Yossi Kreinin Date: 07:44 on 14 Jun 2007 Subject: Re: OT: hiring programmers Peter da Silva wrote: > Actually... > > I think the analogy "not hiring a brewer who doesn't drink" doesn't even > go far enough. > > Even if you don't like programming, or don't currently program in your > spare time, I can't imagine someone who's a programmer who has *never* > written any software that they can't bring in as an example. Even if > it's something horrid from college that they think sucks, at least they > could bring it in and explain why it sucks and what they'd do > differently now. The point isn't to see the code, it's to have the code > there for them to explain, discuss, critique, apologize for, and so on. > > > If you count stuff they did back when they learnt how to program, then, yes, almost everyone should have done something like that. Although I don't know where's the CD with all that stuff of mine. I was only referring to claims about writing code for yourself or the humanity outside of your job.
From: Jonathan Stowe Date: 08:46 on 14 Jun 2007 Subject: Re: OT: hiring programmers On Thu, 2007-06-14 at 09:44 +0300, Yossi Kreinin wrote: > Peter da Silva wrote: > > Actually... > > > > I think the analogy "not hiring a brewer who doesn't drink" doesn't even > > go far enough. > > > > Even if you don't like programming, or don't currently program in your > > spare time, I can't imagine someone who's a programmer who has *never* > > written any software that they can't bring in as an example. Even if > > it's something horrid from college that they think sucks, at least they > > could bring it in and explain why it sucks and what they'd do > > differently now. The point isn't to see the code, it's to have the code > > there for them to explain, discuss, critique, apologize for, and so on. > > > > > > > > If you count stuff they did back when they learnt how to program, then, yes, > almost everyone should have done something like that. Although I don't know > where's the CD with all that stuff of mine. I was only referring to claims about > writing code for yourself or the humanity outside of your job. > This counts as a hardware hate I guess but I don't have the paper tape reader/cassette reader/qic-50 drive/8" diskette drive to retrieve most of the stuff I have from "the time before the web" .... /J\
From: Abigail Date: 10:11 on 14 Jun 2007 Subject: Re: OT: hiring programmers --KJY2Ze80yH5MUxol Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2007 at 09:44:27AM +0300, Yossi Kreinin wrote: > Peter da Silva wrote: > >Actually... > > > >I think the analogy "not hiring a brewer who doesn't drink" doesn't even= =20 > >go far enough. > > > >Even if you don't like programming, or don't currently program in your= =20 > >spare time, I can't imagine someone who's a programmer who has *never*= =20 > >written any software that they can't bring in as an example. Even if=20 > >it's something horrid from college that they think sucks, at least they= =20 > >could bring it in and explain why it sucks and what they'd do=20 > >differently now. The point isn't to see the code, it's to have the code= =20 > >there for them to explain, discuss, critique, apologize for, and so on. > > > > > > >=20 > If you count stuff they did back when they learnt how to program, then,= =20 > yes, almost everyone should have done something like that. Although I don= 't=20 > know where's the CD with all that stuff of mine. I was only referring to= =20 > claims about writing code for yourself or the humanity outside of your jo= b. Except for some vi mappings, I don't have any 'coding' left from my days at the university. (All code was done on accounts that would be wiped out at the end of the semester, and the only way to take anything home would have been paper prints. Which I no longer have). A few times, I was asked to bring in my thesis work - and then I dutifully brought copies of the published articles that resulted from my thesis. Not that those have been very useful, most people would have been lost even before finishing the abstract. Abigail --KJY2Ze80yH5MUxol Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFGcQZKBOh7Ggo6rasRAjI3AJ4hn/AJAaW/DLStRCUYg52p2c+UHACeJJkn nEjphBOE/uu1Y+Q+l7Pkq20= =E+ti -----END PGP SIGNATURE----- --KJY2Ze80yH5MUxol--
From: Abigail Date: 15:51 on 13 Jun 2007 Subject: Re: OT: hiring programmers --Xm/fll+QQv+hsKip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2007 at 02:29:16PM +0100, David Cantrell wrote: > On Wed, Jun 13, 2007 at 01:45:07PM +0300, Yossi Kreinin wrote: >=20 > > It's a great test, but many people only write code when they get payed = for=20 > > it, and in those situations they can't legitimately keep a private copy= of=20 > > it and discuss it with potential employers. Which means that their prev= ious=20 > > projects have to be discussed without actual code listings. >=20 > Which means no interview. I would no more hire someone as a programmer > who doesn't write stuff for himself than I would hire someone as a > brewer who didn't drink alcohol. I think the analogy is more "not hiring brewers that don't brew at home". When I hire (granted, it has been a while that I interviewed people, and I don't miss it), I don't really care what people do at home. In fact, I don't really care about hiring people that think they qualify for a Unix sysadmin job because they run a Linux box at home. Abigail --Xm/fll+QQv+hsKip Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFGcASABOh7Ggo6rasRAuIpAJ4vfvGtznfC6bdSgkoHsxC6Q6qvpwCeMAeG /8/h1nMD9wmhd28e3fibWs4= =RMbu -----END PGP SIGNATURE----- --Xm/fll+QQv+hsKip--
From: A. Pagaltzis Date: 20:04 on 13 Jun 2007 Subject: Re: OT: hiring programmers * Abigail <abigail@xxxxxxx.xx> [2007-06-13 17:00]: > When I hire (granted, it has been a while that I interviewed > people, and I don't miss it), I don't really care what people > do at home. In fact, I don't really care about hiring people > that think they qualify for a Unix sysadmin job because they > run a Linux box at home. But note that hiring any sort of administrator is very different from hiring a programmer. The skillsets are largely disjoint and partially antithetical. Many programmers think they'd be at least decent sysadmins (I thought so, too), and sysadmins vice versa; the truth is that most of them blow chunks at the respective other role. Regards,
From: Peter da Silva Date: 15:13 on 13 Jun 2007 Subject: Re: OT: hiring programmers On Jun 13, 2007, at 5:45 AM, Yossi Kreinin wrote: > It's a great test, but many people only write code when they get payed > for it, and in those Why would you want to hire someone like that?
From: Peter da Silva Date: 16:34 on 13 Jun 2007 Subject: Re: OT: hiring programmers On Jun 13, 2007, at 5:45 AM, Yossi Kreinin wrote: > It's a great test, but many people only write code when they get payed > for it, and in those Why would you want to hire someone like that?
From: Peter da Silva Date: 19:22 on 13 Jun 2007 Subject: Re: OT: hiring programmers On Jun 13, 2007, at 11:28 AM, Yossi Kreinin wrote: > Peter da Silva wrote: >>> It's a great test, but many people only write code when they get >>> payed for it, and in those >> Why would you want to hire someone like that? > Cuz that's the profile I'd be looking for. The scenario is: (1) we > hire the person, (2) the person writes code, (3) we pay the person > money, (4) the person goes to step 2 for several more times. > Conclusion: look for people who write good code when payed. How did they learn to write good code? OK, I suppose there's going to be a few false positives from people who learned to program on the job, so they never wrote any code in college, and who can't think of a program to write for a job interview given reasonable notice that they're going to be expected to bring some code in.
From: A. Pagaltzis Date: 19:48 on 13 Jun 2007 Subject: Re: OT: hiring programmers * Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> [2007-06-13 12:50]: > A. Pagaltzis wrote: >> Or better yet, ask them to bring along some limited-size chunk >> of code they wrote; not too trivial, not too substantial. Tell >> them you expect them to discuss any aspect of their choice >> about this piece of code. > > It's a great test, but many people only write code when they > get payed for it, and in those situations they can't > legitimately keep a private copy of it and discuss it with > potential employers. Which means that their previous projects > have to be discussed without actual code listings. Which is > still more useful than only having people write code without > talking about solving real problems. You mean they can't write 100 lines of code in preparation for a job interview that's scheduled in a few weeks? Regards,
From: Matt McLeod Date: 14:01 on 13 Jun 2007 Subject: Re: OT: hiring programmers A. Pagaltzis wrote: > Or better yet, ask them to bring along some limited-size chunk of > code they wrote; not too trivial, not too substantial. Tell them > you expect them to discuss any aspect of their choice about this > piece of code. The traditional approach at my workplace is to send out a test to everyone who makes it to the interview shortlist about a week prior to the interviews. Five questions at most, all asking to have a specific (and hopefully relevant to the position) problem solved along with a few thoughts on the approach taken. This means there's code to look at for all the reasons you cite, but it's always answering the same problems so there's a relatively level playing field for all applicants. The last few rounds have involved one question asking to implement a simple HTTP server in C (redirect any request to slashdot.org), some perl to do some sort of text processing, and some SQL related to a footy tipping service. Smartarse answers are acceptable, the point is to have something technical to discuss in the interview. I believe management is moving away from this now as it is seen as helping to perpetuate a technical culture they don't like. Matt
From: David Cantrell Date: 14:03 on 13 Jun 2007 Subject: Re: I hate you UI Designer at Prove It! On Wed, Jun 13, 2007 at 08:00:40AM +0100, Andrew Black - lists wrote: > Yossi Kreinin wrote: > >According to my crude estimations, at least about 75% of the people > >getting payed for crafting tests used for various selection processes in > >modern society should be taken out and shot. > But what tests do you use to select the lucky 25% that remain. And who > arranges this test, without the danger of themselves being shot. Shoot 75% of them at random. It might not be perfect, but it will be very satisfying.
From: Leon Brocard Date: 10:52 on 13 Jun 2007 Subject: Re: I hate you UI Designer at Prove It! On 12/06/07, Tia Marie <tia-marie@xxxxxxxxx.xxx> wrote: > I'm currently on the horrible road to job hunting. One company in > particular is having me take "aptitude" tests from this site > proveit.com in order to "prove" I am as proficient on certain > softwares as I have claimed to be. That is totally fine with me. I have seen these. They are truly hateful. They don't test what they are testing and instead frustrate job seekers and frustrate employers who hire people who pass these sucky tests. And I've seen a friend have to complete the "Excel" test multiple times for multiple agencies. Oh the pain! When I was hiring a while ago, an agency with a cutting-edge Perl aptitude test kept on sending us abysmal candidates. We asked for the test. We laughed at the multiple choice answers, such as when 4/5 could actually have been correct (but not their "correct" answer) depending on how you took the question. We never used them again. Leon
Generated at 10:26 on 16 Apr 2008 by mariachi