About the new poll

[t***@public.gmane.org]

I apologize for something slightly off topic, but I just ran across another "the world is going to end because we are not graduating enough CS people" article. When I read statistics like CS student make up ~2% of all STEM students and yet 60% of all STEM jobs are in computing, I wonder two things: How many of us in "computing" have CS degrees? How many "computing" jobs require a CS degree? And good luck finding the answer. Most of the doomsayers imply it takes a CS degree to do anything computer related. So that's the purpose of my poll. I realize this group is skewed much more toward the high end of "computing" jobs.

[Scott Shipp]

I don't know about "jobs in computing" but let me address the idea of software developers not having a CS degree. It seems like everyone is anti-degree now. There's always some story about a developer interview where some sorry applicant came in and admitted that despite their degree they don't know how to code. And those things do happen. But for every single person like that, there's dozens of others who got their degree and there's high competition for these people.

Every now and then I see some forum post or blog where the author decries the fact that job postings say something like "Requirements: " and the first thing listed is a CS degree. Amazon is posting dev jobs now where they say if you don't have a CS degree, you better have three years of experience for every one year you would have spent in a degree. So that's 12 years experience to equal four years in university. Apparently that's how they (or certain departments there at least) are calculating equivalence now. Well, I think that's a good thing. It's at least a reality. There's new work that needs to be done in the industry and there's a need for people who have a full background in mathematics, the sciences, and computing.

But at the same time there's a split going on right now. A good chunk of the people out there writing code for a living say they got into it through other channels than graduating with a CS degree. Probably more got a traditional CS degree, but the former is at least a voice in the conversation. They say you don't need a degree. It's a waste of time and money. And with the cost of college hitting something like $120,000 and up now, it sounds like a reasonable argument. For much less, you can theoretically learn the same stuff and not waste time in boring humanities and "rocks for jocks" classes. (That's what we called geology at PLU when I went there.)

But the other side of the coin is that those of us with a CS degree have seen how valuable that background is once we get on the job. It's certainly no substitute for experience, but it gives you something else, which I think of as "leverage" or a "multiplying factor." If you had a good school with strong professors and you absorbed all that information about data structures, algorithms, operating systems, computer networks, databases, etc. then you get a context that other people don't have, and you look at each new problem and each new piece of code with lenses that show you more possibilities. You have a much higher chance of progressing beyond the average developer. You may even become 10X. And then you add experience on top of all that, and that's a good recipe for a good developer!

In short, a CS degree is actually valuable. You can pick up the same knowledge elsewhere, but you almost cannot get the same experience in the same amount of time. I would be willing to go out on a limb and tell you that unless you are someone who would already excel in a degree program, you are not going to do well without one. To me, the anti-CS degree people developing software just need to consider the other side of the coin. Yes you can possibly get into the industry and even do well without the degree. But you might be doing a disservice to young people by telling them this, because how many are going to try it and fail? Or worse, how many are going to go and become bad developers who the rest of us have to clean up after?

"Uncle Bob" says it better than me: http://blog.8thlight.com/uncle-bob/2013/11/19/HoardsOfNovices.html

Scott

To: seajug-***@public.gmane.org
From: tresschwartzs-/***@public.gmane.org
Date: Tue, 25 Mar 2014 07:58:23 -0700
Subject: [seajug] About the new poll


























I apologize for something slightly off topic, but I just ran across another "the world is going to end because we are not graduating enough CS people" article. When I read statistics like CS student make up ~2% of all STEM students and yet 60% of all STEM jobs are in computing, I wonder two things:
How many of us in "computing" have CS degrees?How many "computing" jobs require a CS degree?And good luck finding the answer. Most of the doomsayers imply it takes a CS degree to do anything computer related. So that's the purpose of my poll. I realize this group is skewed much more toward the high end of "computing" jobs.

[t***@public.gmane.org]

You won't get any disagreement from me about the value of a CS degree. I got mine back when it was a pretty new field and there was debate where to put the department--math or engineering or ??? I am surprised how many people complain that green CS graduates are often not prepared to immediately be productive as developers. If I'm not mistaken, few industries expect to give recent grads much responsibility as they have learned the danger in doing so.

I also wonder whether anyone who bemoans the lack of CS grads knows anything about macro economics. If there is a consistent 25% shortfall in any area, cost goes up appropriately. Not necessarily 25%, but certainly more than the measly salary increases I've seen. I think these are the same people who predict the end of all small business if the $15/hour minimum wage goes through. Show me data!


doug

[Eric Jain]

Post by Scott Shipp
There's new work that
needs to be done in the industry and there's a need for people who have a
full background in mathematics, the sciences, and computing.

No doubt, but I suspect that most of these hires end up spending their
days wrestling with build configuration files.

You need to know the basic data structures and algorithms, but an
academic CS program seems like overkill for that, and in any case this
isn't what makes software development difficult, in my experience.

Perhaps the real problem is that large companies need more people who
can't quit to start or join a startup, in which case a H1B or large
student loan is a plus :-)
--
Eric Jain
Got data? Get answers at zenobase.com.


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Dan Paik]

Hmm, where to begin.

TLDR; get a degree, it's better.

For full disclosure, I have a CS degree. It's a good CS degree from a good
school. Not all CS degrees are created equal.

A good CS degree will focus on building fundamentals. These are subjects
such as algorithms, architecture, design, databases, operating systems,
compilers, etc.

Notice that I didn't put programming on that list. Programming is
important but is such a basic part of a CS degree that there is really no
class called "programming (e.g. Programming in Java)." You learn to write
code while exploring and learning the subjects mentioned above. That's how
you build a solid core of fundamentals that can then be built upon at a
later date (at your job) using any language.

Ask any Computer Scientist and he (usually it's a he but she is fine too)
will tell you that he can write code in any language given some time to
ramp up on the specifics of the language. When I was in school, our first
class used SCHEME as a language. Nobody uses SCHEME in "real life" except
for some AI folks. But the stuff I learned using SCHEME as a language was
a good foundation for programming in C++, C, Java, Python, PHP, Ruby, etc.
I have never written a line of code in go or scalar but I'm pretty sure
that given a few hours, I can write code as well as anyone in those
languages.

Now let's take the folks who don't have a CS degree. Instead they learned
how to code by tinkering around on their own as a hobby or taking a class
as a trade school (DeVry, etc.). They know enough to get the job done but
they have a much harder time adapting to new technologies. I find that
people without a CS degree tend to be great systems administrators, front
end HTML/js developers, graphic designers, etc. where experience is much
more important than fundamental skills. When I have an engineer that works
for me without fundamentals but can do that job, I always recommend that
they go out and get Java certified...it will help build those fundamentals
that they don't get from work and that they didn't get from a school.

As for jobs, large companies such as Amazon are all about bringing in smart
college graduates who have a strong core. They will then train them on
Amazon's technologies, the build system, the deployment system, etc. OTOH,
take a startup that needs to get some features out the door before the next
round of funding...these guys need developers who can build their new
features the fastest so they want RoR developers who have done something
like that before.

And finally, for many of the large tech companies, a CS degree is a
requirement even for non developer jobs. These are engineering managers,
product managers, and even sales and marketing folks. The reason for this
is that these companies sell technology and need people up and down the
stack that are technical. I do not work as a hands on developer anymore
but my job pretty much has a CS degree as a requirement (at least for most
of those who are successful here).

In closing, if anyone ever asks me the question of "should I get a CS
degree and spend $X on college or just go out and take a "programming in
Java" class to get a job" I always tell them to get the degree from the
best school they can get into.

Dan.

Post by Eric Jain

Post by Scott Shipp
There's new work that
needs to be done in the industry and there's a need for people who have a
full background in mathematics, the sciences, and computing.

No doubt, but I suspect that most of these hires end up spending their
days wrestling with build configuration files.
You need to know the basic data structures and algorithms, but an
academic CS program seems like overkill for that, and in any case this
isn't what makes software development difficult, in my experience.
Perhaps the real problem is that large companies need more people who
can't quit to start or join a startup, in which case a H1B or large
student loan is a plus :-)
--
Eric Jain
Got data? Get answers at zenobase.com.

[Ross Bleakney]

Post by Scott Shipp

Post by Dan Paik
Ask any Computer Scientist and he (usually it's a he but she is

fine too) will tell you that he can write code in any language given
some time to ramp up on the specifics of the language.

Post by Scott Shipp

Post by Dan Paik
Now let's take the folks who don't have a CS degree.

Instead they learned how to code by tinkering around on their own as a
hobby or taking a class as a trade school (DeVry, etc.). They know
enough to get the job done but they have a much harder time adapting to
new technologies.

Sorry, but I think that is an unfair stereotype. I've known guys that wrote terrible code and they had CS degrees. I've also known plenty of people without degrees who know plenty about the fundamentals of programming. They understand computers from the ground up and had no trouble understanding all of the key concepts. How? They read the same books as the guys and gals that went to school and got the Computer Science degrees.

Was everything you learned in college applicable? I doubt it. Just to get into the CS program at my school I had to finish the first year of calculus. I haven't used it since. Meanwhile I didn't learn much about TCP/IP, because, well, it wasn't that important a protocol back then.

A lot of it is about professionalism. I'm sure there are folks who graduate with a CS degree with a solid foundation and a strong sense of professionalism. Maybe a good professor inspired him or her to keep learning, to keep involved. But there are plenty who graduate and say "great, I've mastered that; now it's off to make some money". These are the folks that tinker, and say "good enough". These are the people who "just get it working" without wondering if maybe there was a better way to write that code. They don't join groups like these, or spend any time reading programming books or journals, or join in study groups. If you think you are the best programmer in the room you are probably wrong, and you are hurting your company because of that attitude. It means you likely aren't improving. My guess is the programmer who believes he has nothing to learn from his (or her) fellow programmer is just as likely to be a CS graduate as not.

I think the focus on the CS degree is a misguided attempt by the industry to deal with a problem they have had for a long time: companies are stupid when it comes to hiring people. I'm not talking about a company that hires the best folks from good universities. That is a good strategy, and it will probably pay off. Not because the schools necessarily taught them everything they need to know, but if you succeeded in school, you probably will succeed in work. I'm not talking about that -- I'm talking about how a typical company hires a typical employee. Such a company isn't likely to hire the best students right out of school and spend the time grooming them (only a handful of companies can afford to do that). They are going to try and find the regular folks - the folks that have been working hard for many years. If they do it right, the new employee will fit in quickly and start being productive way faster than the new graduate. This employee will do just as well in the long run, too, because of the head start. But do it wrong, and they are stuck with a bozo who writes really, really bad code. So, how does a company try and figure out who is good and who is not? Stupid interview questions. Really. I've been asked everything from design questions for Mapquest (which was interesting) to solving atoi (which was not). Seriously?!! atoi? You have to be kidding me. Do you want me to write it in assembly? While you are at it, ask me some calculus questions. (By the way, I nailed the atoi question, but only because I refreshed my knowledge by looking at typical interview questions. Even though I nailed the question (and got an offer) my big regret is that I didn't start the response by writing unit test code on the white board.)

Anyway, I can see why companies ask such questions. They are trying to weed out the "tinkerers" from the "real programmers". The problem is, they don't have a great success rate with it. The same is true of "certification". Does it guarantee that you will write good code? Hardly. So how does a company determine whether a programmer is good? Or better yet, a good fit for the company?

I've asked people in much more professional fields like law and medicine and they all give the same answer: You ask people. I've been asked the most asinine questions in job interviews but I've never been asked about my references.* Idiotic, really. I can give you the names of people I've worked closely with, who have critiqued my code, maintained my code, and (I'll admit) fixed my code. I can give you the names of managers who have had to deal with my code as well as my knowledge of the product and my ability to convey the nuts and bolts of it. I can give you the names of testers who have had to deal with my code, as well as my analysis of code written by others. But now you you want to decide whether to hire me based on how I can code atoi, or whether I have a degree from thirty years ago? Insane. Those bozos I mentioned -- they can't come up with the references I mentioned because, well, they are bozos. The guys or gals they worked with won't give them references. Or when the call is made, they will damn them with faint praise.

Like I said, other professions follow this model when it comes to hiring their higher priced employees. Assume they are good and know what they are doing. See if they are a good fit. If everything looks good, then ask the references. Ask about the references, too (e. g. "Who is this person; how closely did you work with her; how would you describe her skills", etc.). For whatever reason, this industry doesn't do that. I can come up with a bunch of theories as to why, but it drags down the industry. It keeps people from doing what they should do to improve -- learn from the people around them.

Thanks,
Ross

* To be fair, at a couple of my jobs, they already had "references" in that I was recommended for the position by someone who worked there. I was asked questions that would determine whether I would be a good fit or not. Since I didn't have to write atoi (in the job or the interview) I was a good fit.

Post by Scott Shipp
There's new work that
needs to be done in the industry and there's a need for people who have a
full background in mathematics, the sciences, and computing.

No doubt, but I suspect that most of these hires end up spending their

days wrestling with build configuration files.



You need to know the basic data structures and algorithms, but an

academic CS program seems like overkill for that, and in any case this

isn't what makes software development difficult, in my experience.



Perhaps the real problem is that large companies need more people who

can't quit to start or join a startup, in which case a H1B or large

student loan is a plus :-)

[Jason Osgood]

Hi Ross (Everyone)


This is a worthy discussion, even if no one says anything new. Maybe especially if its a rehash.

Hacker News (news.ycombinator.com) is obsessed with hiring practices. What little I’ve gleaned (best available science) is the only worthwhile interview question (filter) is to ask people about their prior work(s), in detail. Programming questions have no predictive power. Though I personally think programming assignments are useful.

Post by Ross Bleakney
companies are stupid when it comes to hiring people.

Interviewing is like dating. Why would organizations be any better (more successful) at forming relationships than individuals?

I can report two things that worked, universally. Self selecting teams. (Not motivated to identify Agile Guru who coined this, sorry.) And Luke Hohmann’s Roman Evaluation; where anything less than a Yes by all is a No.

YMMV

Post by Ross Bleakney
I've asked people ... and they all give the same answer: You ask people.

I like your point about (not) checking references. I would only add that its one of a handful of social validation strategies. Work on open source projects is another.

A not so subtle side motivation to user groups and study groups is for us to network for jobs.

Back when I was hosting the Wing Ding, part of the job screening process was punishing any one who showed up early (aka “on time”) with KP duty. You learn so much about people that way. Who are the do’ers, the kibitzers, the lurkers, etc. My friends Bill Pierce and Adam Levin-Delson were always standouts; they always, always jumped right into food prep. Which completely mirrored their professional selves; these two just got things done.

These non work interactions also helped remove people from the candidate list. People who otherwise looked pretty good on paper.

One Wing Ding we had burritos. So a dude walks in. I hand him a bowl, the block of cheddar, and a grater and tell him to first wash his hands. So he gets to work. The dude cannot figure out how to convert big cheese into little cheese. I let him struggle, just to see how it’d play out.

Think about that. Imagine you’ve never worked in a kitchen. How would you solve this new problem?

The grater has four possible orientations. Wouldn’t you try them all?

But dude doesn’t. Instead, he decides to brute force the problem. Dude is actually pushing the cheese through the grater, like a Play-Doh machine.

I’m actually okay with dude not being able to figure out how to grate cheese. Sure, it’s a disappointment, but some people just don’t get hardware.

What’s not cool is the dude didn’t ask for help. Whether its embarrassment, failure to recognize his own failure, or whatever, I don’t care. What I learned about dude is that he’d silently fail in a corner for as long you ignored him.

I mention this story 1/2 for humor, 1/2 to give an example of the kind of personality trait that is hard to uncover during an interview process.


Cheers, Jason

[Dan Paik]

I think many companies do try to seek out internal referrals pretty
heavily. I've hired people without even conducting an actual interview
when a person that I respect refers someone. I simply meet with the person
to answer any questions that he/she has and let them make the decision.

But most of us don't know many engineers who are looking for work. Sure,
there are many engineers that aren't totally happy at their current jobs
but many aren't willing to move. I would guess that as a company gets
bigger, it simply cannot rely completely on firsthand accounts do their
hiring.

Hence, the interview.

I will agree that most hiring practices suck. At my last company we tried
to do a "pair programming" exercise as our interview to see how the person
works. It was decent.

Asking a bunch of questions about what they did in their job is useful but
only one aspect. Another useful aspect to measure is how well the person
can think on his/her feet when presented with a new problem. For this, you
need to come up with some random questions.

On a related note, I was asked atoi at an interview a few years ago. I
stumbled a bit on the question. The next question was to architect a
solution to combine 2 huge email lists and I nailed that one using
map/reduce, etc. I got the job and worked there for a few years.

And I will admit that my post was very broad. Of course there are many
exceptions. But I still stand by my opinions. Just because Bill Gates
dropped out of Harvard doesn't change my opinion that Harvard students
should stay in school and graduate.

Dan.

Post by Jason Osgood
Hi Ross (Everyone)
This is a worthy discussion, even if no one says anything new. Maybe
especially if its a rehash.
Hacker News (news.ycombinator.com) is obsessed with hiring practices.
What little I've gleaned (best available science) is the only worthwhile
interview question (filter) is to ask people about their prior work(s), in
detail. Programming questions have no predictive power. Though I personally
think programming assignments are useful.
companies are stupid when it comes to hiring people.
Interviewing is like dating. Why would organizations be any better (more
successful) at forming relationships than individuals?
I can report two things that worked, universally. Self selecting teams.
(Not motivated to identify Agile Guru who coined this, sorry.) And Luke
Hohmann's Roman Evaluation; where anything less than a Yes by all is a No.
YMMV
I've asked people ... and they all give the same answer: You ask people.
I like your point about (not) checking references. I would only add that
its one of a handful of social validation strategies. Work on open source
projects is another.
A not so subtle side motivation to user groups and study groups is for us
to network for jobs.
Back when I was hosting the Wing Ding, part of the job screening process
was punishing any one who showed up early (aka "on time") with KP duty. You
learn so much about people that way. Who are the do'ers, the kibitzers, the
lurkers, etc. My friends Bill Pierce and Adam Levin-Delson were always
standouts; they always, always jumped right into food prep. Which
completely mirrored their professional selves; these two just got things
done.
These non work interactions also helped remove people from the candidate
list. People who otherwise looked pretty good on paper.
One Wing Ding we had burritos. So a dude walks in. I hand him a bowl, the
block of cheddar, and a grater and tell him to first wash his hands. So he
gets to work. The dude cannot figure out how to convert big cheese into
little cheese. I let him struggle, just to see how it'd play out.
Think about that. Imagine you've never worked in a kitchen. How would you
solve this new problem?
The grater has four possible orientations. Wouldn't you try them all?
But dude doesn't. Instead, he decides to brute force the problem. Dude is
actually pushing the cheese through the grater, like a Play-Doh machine.
I'm actually okay with dude not being able to figure out how to grate
cheese. Sure, it's a disappointment, but some people just don't get
hardware.
What's not cool is the dude didn't ask for help. Whether its
embarrassment, failure to recognize his own failure, or whatever, I don't
care. What I learned about dude is that he'd silently fail in a corner for
as long you ignored him.
I mention this story 1/2 for humor, 1/2 to give an example of the kind of
personality trait that is hard to uncover during an interview process.
Cheers, Jason

[Douglas Pearson]

Post by Jason Osgood

Post by Jason Osgood
I mention this story 1/2 for humor, 1/2 to give an example of the kind

of personality trait that is hard to uncover during an interview process.

Would comment more on this thread, but I've got to rush out to buy a big
block of cheese and a grater before our next interview candidate gets
here...

Doug

Post by Jason Osgood
Hi Ross (Everyone)
This is a worthy discussion, even if no one says anything new. Maybe
especially if its a rehash.
Hacker News (news.ycombinator.com) is obsessed with hiring practices.
What little I've gleaned (best available science) is the only worthwhile
interview question (filter) is to ask people about their prior work(s), in
detail. Programming questions have no predictive power. Though I personally
think programming assignments are useful.
companies are stupid when it comes to hiring people.
Interviewing is like dating. Why would organizations be any better (more
successful) at forming relationships than individuals?
I can report two things that worked, universally. Self selecting teams.
(Not motivated to identify Agile Guru who coined this, sorry.) And Luke
Hohmann's Roman Evaluation; where anything less than a Yes by all is a No.
YMMV
I've asked people ... and they all give the same answer: You ask people.
I like your point about (not) checking references. I would only add that
its one of a handful of social validation strategies. Work on open source
projects is another.
A not so subtle side motivation to user groups and study groups is for us
to network for jobs.
Back when I was hosting the Wing Ding, part of the job screening process
was punishing any one who showed up early (aka "on time") with KP duty. You
learn so much about people that way. Who are the do'ers, the kibitzers, the
lurkers, etc. My friends Bill Pierce and Adam Levin-Delson were always
standouts; they always, always jumped right into food prep. Which
completely mirrored their professional selves; these two just got things
done.
These non work interactions also helped remove people from the candidate
list. People who otherwise looked pretty good on paper.
One Wing Ding we had burritos. So a dude walks in. I hand him a bowl, the
block of cheddar, and a grater and tell him to first wash his hands. So he
gets to work. The dude cannot figure out how to convert big cheese into
little cheese. I let him struggle, just to see how it'd play out.
Think about that. Imagine you've never worked in a kitchen. How would you
solve this new problem?
The grater has four possible orientations. Wouldn't you try them all?
But dude doesn't. Instead, he decides to brute force the problem. Dude is
actually pushing the cheese through the grater, like a Play-Doh machine.
I'm actually okay with dude not being able to figure out how to grate
cheese. Sure, it's a disappointment, but some people just don't get
hardware.
What's not cool is the dude didn't ask for help. Whether its
embarrassment, failure to recognize his own failure, or whatever, I don't
care. What I learned about dude is that he'd silently fail in a corner for
as long you ignored him.
I mention this story 1/2 for humor, 1/2 to give an example of the kind of
personality trait that is hard to uncover during an interview process.
Cheers, Jason

[George Smith]

I have a CS degree, but I must say that it did not teach me to "program",
but how to "code". IMO they are not the same thing!

Lance Young, commented (repeated?) to me that a year of XP (full time Pair
Programming) felt like a 4-year CS degree from the perspective of CS
learning! Pairing with someone who "knows" an area / technique / language
allows for an incredible amount of learning from a one-on-one teacher! I
think that the Software industry would do well for itself if it promoted an
apprenticeship model based around Pair Programming!

I have done XP, 3 times in my career (for a total of about 6 years), and
can attest that it was incredibly valuable when joining a new team, or
learning a new technology. But far less valuable "to me" when I am the
Senior / Experienced developer. However, when you look from the
perspective of the team, (e.g. as a Manager &/ Lead Developer), I
completely endorse XP!

I have been a FTE (for a short while before leaving for Google) for
Amazon/AWS, and am now on my 4th contract there, and while the interns and
new graduates they bring in are pretty good, there is little or no support
/ training, except for some on-line study guides / tutorials around the
"custom" Amazon tools. So, IMO, the bigger companies in the industry are
not doing any batter creating good developers!

Finally on the subject of "consensus" (Jason):

While a team of just Senior Developers "can" hire based solely on team fit
with consensus, teams with Junior Developers, whether XP of not, however
should never select members based on consensus. This leads to LCD
thinking, and the last thing you want when hiring a Senior Developer is to
hire a Least Common Denominator with a Junior Dev! I will go further and
state that a Senior Developer candidate should never be interviewed by
Junior Developer(s) alone (mixed "can be" ok) - this is where the asinine
questions like write "atoi" come in!

George







On Thu, Mar 27, 2014 at 2:05 PM, Douglas Pearson

Post by Jason Osgood

Post by Jason Osgood

Post by Jason Osgood
I mention this story 1/2 for humor, 1/2 to give an example of the kind

of personality trait that is hard to uncover during an interview process.
Would comment more on this thread, but I've got to rush out to buy a big
block of cheese and a grater before our next interview candidate gets
here...
Doug

Post by Jason Osgood
Hi Ross (Everyone)
This is a worthy discussion, even if no one says anything new. Maybe
especially if its a rehash.
Hacker News (news.ycombinator.com) is obsessed with hiring practices.
What little I've gleaned (best available science) is the only worthwhile
interview question (filter) is to ask people about their prior work(s), in
detail. Programming questions have no predictive power. Though I personally
think programming assignments are useful.
companies are stupid when it comes to hiring people.
Interviewing is like dating. Why would organizations be any better (more
successful) at forming relationships than individuals?
I can report two things that worked, universally. Self selecting teams.
(Not motivated to identify Agile Guru who coined this, sorry.) And Luke
Hohmann's Roman Evaluation; where anything less than a Yes by all is a No.
YMMV
I've asked people ... and they all give the same answer: You ask people.
I like your point about (not) checking references. I would only add that
its one of a handful of social validation strategies. Work on open source
projects is another.
A not so subtle side motivation to user groups and study groups is for us
to network for jobs.
Back when I was hosting the Wing Ding, part of the job screening process
was punishing any one who showed up early (aka "on time") with KP duty. You
learn so much about people that way. Who are the do'ers, the kibitzers, the
lurkers, etc. My friends Bill Pierce and Adam Levin-Delson were always
standouts; they always, always jumped right into food prep. Which
completely mirrored their professional selves; these two just got things
done.
These non work interactions also helped remove people from the candidate
list. People who otherwise looked pretty good on paper.
One Wing Ding we had burritos. So a dude walks in. I hand him a bowl, the
block of cheddar, and a grater and tell him to first wash his hands. So he
gets to work. The dude cannot figure out how to convert big cheese into
little cheese. I let him struggle, just to see how it'd play out.
Think about that. Imagine you've never worked in a kitchen. How would you
solve this new problem?
The grater has four possible orientations. Wouldn't you try them all?
But dude doesn't. Instead, he decides to brute force the problem. Dude is
actually pushing the cheese through the grater, like a Play-Doh machine.
I'm actually okay with dude not being able to figure out how to grate
cheese. Sure, it's a disappointment, but some people just don't get
hardware.
What's not cool is the dude didn't ask for help. Whether its
embarrassment, failure to recognize his own failure, or whatever, I don't
care. What I learned about dude is that he'd silently fail in a corner for
as long you ignored him.
I mention this story 1/2 for humor, 1/2 to give an example of the kind of
personality trait that is hard to uncover during an interview process.
Cheers, Jason

[Jason Osgood]

Hi George.

Post by George Smith
apprenticeship model based around Pair Programming!

You’ve stated many times that Pair Programming leads to LCD work.

Post by George Smith
should never select members based on consensus. This leads to LCD thinking

Umm.

Either way, I apologize for being unclear. Self-selecting team plus Roman Eval. The WHOLE team. Everyone.

Example: I had a great dev lined up. QA manager said no. I didn’t even argue. Instead, I did some horse trading with another manager. Dev did very well on another team. My team got other things we needed. Win-win.

Per Coach Wooden, team dynamics are more important than individual ability, except when you have a super star.

Post by George Smith
there is little or no support / training, except for some on-line study guides / tutorials around the "custom" Amazon tools.

Ambiguous rules ruthlessly enforced. Where do I sign up?


If true, I am very impressed by the stories of Facebook Bootcamp.

Bootcamp! How Facebook indoctrinates every new engineer it hires
http://venturebeat.com/2013/03/02/facebook-bootcamp/



Cheers, Jason

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[George Smith]

I have never stated that Pair Programming leads to LCD!

I have stated that Pair Programming "can" lead to LCD.

The issue is the teams approach, and IMO there ends up being two outcomes:

1. Develop DOWN to the LCD, or
2. Develop UP to the Majority favored best solution (this requires that
there NOT be more Junior than Senior Devs).

The first usually results from a "consensus" approach to the team, and the
junior team members become a "power block of ignorance and/or fear" leading
to the "tyranny of the minority" and sub-par decisions.

And the second leads to mentoring, better code/solutions, but appears to
the junior devs as the "tyranny of the majority".

There is no free lunch, each team / management needs to decide which path /
pros & cons to deal with. I can say that on my last XP team, that followed
#1 above, they could not hold on to Senior Devs! There was just nothing
interesting going on...

George

Post by Jason Osgood
Hi George.

Post by George Smith
apprenticeship model based around Pair Programming!

You've stated many times that Pair Programming leads to LCD work.

Post by George Smith
should never select members based on consensus. This leads to LCD

thinking
Umm.
Either way, I apologize for being unclear. Self-selecting team plus Roman
Eval. The WHOLE team. Everyone.
Example: I had a great dev lined up. QA manager said no. I didn't even
argue. Instead, I did some horse trading with another manager. Dev did very
well on another team. My team got other things we needed. Win-win.
Per Coach Wooden, team dynamics are more important than individual
ability, except when you have a super star.

Post by George Smith
there is little or no support / training, except for some on-line study

guides / tutorials around the "custom" Amazon tools.
Ambiguous rules ruthlessly enforced. Where do I sign up?
If true, I am very impressed by the stories of Facebook Bootcamp.
Bootcamp! How Facebook indoctrinates every new engineer it hires
http://venturebeat.com/2013/03/02/facebook-bootcamp/
Cheers, Jason
------------------------------------
Yahoo Groups Links

[Stewart Buskirk]

I am one of those self-taught folks who started in the days when CS as an academic discipline was essentially still mathematics. Anyone else remember using PEEK and POKE on an Apple II? The only formal CS course I have taken was "Fortran for Biology Majors", and the final exam was writing a program on graph paper, longhand.

I have picked up and worked through several algorithms/data structures books, taken online courses in Scala, algorithms, etc. I do feel I am better for it. That knowledge has a lot of value. I am also aware I have blind spots (compiler theory, for example). Don't ask me to whip out a quicksort algorithm on a whiteboard, but I do understand O(n), know what a DAG is, know what a tree data structure is and when it's useful, and can do a decent job of algorithmic analysis if I squint. I'm sure I could study effectively for an interview, but it feels so arbitrary except for specific roles ("You will create a novel algorithm for predicting consumer behavior based on large datasets").

OTOH, it's difficult to keep that knowledge front of mind when the daily work consists of XML parsing, database reporting, system integration, etc. I appreciate the intent of "CS 101" interview questions as far as they try to ensure that teams have a common language, but I would argue that there are many, many other skills that are not part of a normal CS curriculum that are absolutely required to be present in a successful group. When I think of a development team, I try to think not just in terms of skills, but of roles within the group - teams need people who can write and communicate, people who can lead others through problem solving, people who are effective at training others on domain knowledge, people who can focus on specific problems and people who are more big picture oriented. I feel that's perfectly valid to bring in someone who benefits the group "flow" even if they aren't as great as others at solving puzzles with code. Most of the code I am responsible for just isn't that complicated to produce, and my personal experience with new CS grads is that they can have a tendency to be overly dogmatic about the "right" way to accomplish something - and disagree with each other. Nothing makes me more frustrated than religious arguments about the One True Way, or where the brackets should go.

I do wish I had a CS degree and will likely apply to the Udacity online MS program to pursue that (cheap!), but it does feel like jumping through hoops to get my fish. I think there's a middle ground that serves a lot of contexts where the ability to be flexible, respectful, reliable, experienced in the domain and socially non-abrasive is more important than an instant familiarity with recursive tree traversal algorithms, assuming a base level of intelligence and skills appropriate to the role. There's room for both the CS and non-CS types on the same software development team in most cases, IMO.

I have a CS degree, but I must say that it did not teach me to "program", but how to "code". IMO they are not the same thing!
Lance Young, commented (repeated?) to me that a year of XP (full time Pair Programming) felt like a 4-year CS degree from the perspective of CS learning! Pairing with someone who "knows" an area / technique / language allows for an incredible amount of learning from a one-on-one teacher! I think that the Software industry would do well for itself if it promoted an apprenticeship model based around Pair Programming!
I have done XP, 3 times in my career (for a total of about 6 years), and can attest that it was incredibly valuable when joining a new team, or learning a new technology. But far less valuable "to me" when I am the Senior / Experienced developer. However, when you look from the perspective of the team, (e.g. as a Manager &/ Lead Developer), I completely endorse XP!
I have been a FTE (for a short while before leaving for Google) for Amazon/AWS, and am now on my 4th contract there, and while the interns and new graduates they bring in are pretty good, there is little or no support / training, except for some on-line study guides / tutorials around the "custom" Amazon tools. So, IMO, the bigger companies in the industry are not doing any batter creating good developers!
While a team of just Senior Developers "can" hire based solely on team fit with consensus, teams with Junior Developers, whether XP of not, however should never select members based on consensus. This leads to LCD thinking, and the last thing you want when hiring a Senior Developer is to hire a Least Common Denominator with a Junior Dev! I will go further and state that a Senior Developer candidate should never be interviewed by Junior Developer(s) alone (mixed "can be" ok) - this is where the asinine questions like write "atoi" come in!
George

Post by Ross Bleakney

Post by Jason Osgood
I mention this story 1/2 for humor, 1/2 to give an example of the kind of personality trait that is hard to uncover during an interview process.

Would comment more on this thread, but I've got to rush out to buy a big block of cheese and a grater before our next interview candidate gets here...
Doug
Hi Ross (Everyone)
This is a worthy discussion, even if no one says anything new. Maybe especially if its a rehash.
Hacker News (news.ycombinator.com) is obsessed with hiring practices. What little I’ve gleaned (best available science) is the only worthwhile interview question (filter) is to ask people about their prior work(s), in detail. Programming questions have no predictive power. Though I personally think programming assignments are useful.

Post by Ross Bleakney
companies are stupid when it comes to hiring people.

Interviewing is like dating. Why would organizations be any better (more successful) at forming relationships than individuals?
I can report two things that worked, universally. Self selecting teams. (Not motivated to identify Agile Guru who coined this, sorry.) And Luke Hohmann’s Roman Evaluation; where anything less than a Yes by all is a No.
YMMV

Post by Ross Bleakney
I've asked people ... and they all give the same answer: You ask people.

I like your point about (not) checking references. I would only add that its one of a handful of social validation strategies. Work on open source projects is another.
A not so subtle side motivation to user groups and study groups is for us to network for jobs.
Back when I was hosting the Wing Ding, part of the job screening process was punishing any one who showed up early (aka “on time”) with KP duty. You learn so much about people that way. Who are the do’ers, the kibitzers, the lurkers, etc. My friends Bill Pierce and Adam Levin-Delson were always standouts; they always, always jumped right into food prep. Which completely mirrored their professional selves; these two just got things done.
These non work interactions also helped remove people from the candidate list. People who otherwise looked pretty good on paper.
One Wing Ding we had burritos. So a dude walks in. I hand him a bowl, the block of cheddar, and a grater and tell him to first wash his hands. So he gets to work. The dude cannot figure out how to convert big cheese into little cheese. I let him struggle, just to see how it’d play out.
Think about that. Imagine you’ve never worked in a kitchen. How would you solve this new problem?
The grater has four possible orientations. Wouldn’t you try them all?
But dude doesn’t. Instead, he decides to brute force the problem. Dude is actually pushing the cheese through the grater, like a Play-Doh machine.
I’m actually okay with dude not being able to figure out how to grate cheese. Sure, it’s a disappointment, but some people just don’t get hardware.
What’s not cool is the dude didn’t ask for help. Whether its embarrassment, failure to recognize his own failure, or whatever, I don’t care. What I learned about dude is that he’d silently fail in a corner for as long you ignored him.
I mention this story 1/2 for humor, 1/2 to give an example of the kind of personality trait that is hard to uncover during an interview process.
Cheers, Jason
--
"And the users exclaimed with a laugh and a taunt: It's just what we asked for but not what we want." -- Unknown

[George Smith]

Very well said Stewart!

George

Post by Stewart Buskirk
I am one of those self-taught folks who started in the days when CS as an
academic discipline was essentially still mathematics. Anyone else remember
using PEEK and POKE on an Apple II? The only formal CS course I have taken
was "Fortran for Biology Majors", and the final exam was writing a program
on graph paper, longhand.
I have picked up and worked through several algorithms/data structures
books, taken online courses in Scala, algorithms, etc. I do feel I am
better for it. That knowledge has a lot of value. I am also aware I have
blind spots (compiler theory, for example). Don't ask me to whip out a
quicksort algorithm on a whiteboard, but I do understand O(n), know what a
DAG is, know what a tree data structure is and when it's useful, and can do
a decent job of algorithmic analysis if I squint. I'm sure I could study
effectively for an interview, but it feels so arbitrary except for specific
roles ("You will create a novel algorithm for predicting consumer behavior
based on large datasets").
OTOH, it's difficult to keep that knowledge front of mind when the daily
work consists of XML parsing, database reporting, system integration, etc.
I appreciate the intent of "CS 101" interview questions as far as they try
to ensure that teams have a common language, but I would argue that there
are many, many other skills that are not part of a normal CS curriculum
that are absolutely required to be present in a successful group. When I
think of a development team, I try to think not just in terms of skills,
but of roles within the group - teams need people who can write and
communicate, people who can lead others through problem solving, people who
are effective at training others on domain knowledge, people who can focus
on specific problems and people who are more big picture oriented. I feel
that's perfectly valid to bring in someone who benefits the group "flow"
even if they aren't as great as others at solving puzzles with code. Most
of the code I am responsible for just isn't that complicated to produce,
and my personal experience with new CS grads is that they can have a
tendency to be overly dogmatic about the "right" way to accomplish
something - and disagree with each other. Nothing makes me more frustrated
than religious arguments about the One True Way, or where the brackets
should go.
I do wish I had a CS degree and will likely apply to the Udacity online MS
program to pursue that (cheap!), but it does feel like jumping through
hoops to get my fish. I think there's a middle ground that serves a lot of
contexts where the ability to be flexible, respectful, reliable,
experienced in the domain and socially non-abrasive is more important than
an instant familiarity with recursive tree traversal algorithms, assuming a
base level of intelligence and skills appropriate to the role. There's room
for both the CS and non-CS types on the same software development team in
most cases, IMO.
I have a CS degree, but I must say that it did not teach me to "program",
but how to "code". IMO they are not the same thing!
Lance Young, commented (repeated?) to me that a year of XP (full time Pair
Programming) felt like a 4-year CS degree from the perspective of CS
learning! Pairing with someone who "knows" an area / technique / language
allows for an incredible amount of learning from a one-on-one teacher! I
think that the Software industry would do well for itself if it promoted an
apprenticeship model based around Pair Programming!
I have done XP, 3 times in my career (for a total of about 6 years), and
can attest that it was incredibly valuable when joining a new team, or
learning a new technology. But far less valuable "to me" when I am the
Senior / Experienced developer. However, when you look from the
perspective of the team, (e.g. as a Manager &/ Lead Developer), I
completely endorse XP!
I have been a FTE (for a short while before leaving for Google) for
Amazon/AWS, and am now on my 4th contract there, and while the interns and
new graduates they bring in are pretty good, there is little or no support
/ training, except for some on-line study guides / tutorials around the
"custom" Amazon tools. So, IMO, the bigger companies in the industry are
not doing any batter creating good developers!
While a team of just Senior Developers "can" hire based solely on team fit
with consensus, teams with Junior Developers, whether XP of not, however
should never select members based on consensus. This leads to LCD
thinking, and the last thing you want when hiring a Senior Developer is to
hire a Least Common Denominator with a Junior Dev! I will go further and
state that a Senior Developer candidate should never be interviewed by
Junior Developer(s) alone (mixed "can be" ok) - this is where the asinine
questions like write "atoi" come in!
George

Post by Jason Osgood

Post by Jason Osgood

Post by Jason Osgood
I mention this story 1/2 for humor, 1/2 to give an example of the

kind of personality trait that is hard to uncover during an interview
process.
Would comment more on this thread, but I've got to rush out to buy a big
block of cheese and a grater before our next interview candidate gets
here...
Doug

Post by Jason Osgood
Hi Ross (Everyone)
This is a worthy discussion, even if no one says anything new. Maybe
especially if its a rehash.
Hacker News (news.ycombinator.com) is obsessed with hiring practices.
What little I've gleaned (best available science) is the only worthwhile
interview question (filter) is to ask people about their prior work(s), in
detail. Programming questions have no predictive power. Though I personally
think programming assignments are useful.
companies are stupid when it comes to hiring people.
Interviewing is like dating. Why would organizations be any better (more
successful) at forming relationships than individuals?
I can report two things that worked, universally. Self selecting teams.
(Not motivated to identify Agile Guru who coined this, sorry.) And Luke
Hohmann's Roman Evaluation; where anything less than a Yes by all is a No.
YMMV
I've asked people ... and they all give the same answer: You ask people.
I like your point about (not) checking references. I would only add that
its one of a handful of social validation strategies. Work on open source
projects is another.
A not so subtle side motivation to user groups and study groups is for
us to network for jobs.
Back when I was hosting the Wing Ding, part of the job screening process
was punishing any one who showed up early (aka "on time") with KP duty. You
learn so much about people that way. Who are the do'ers, the kibitzers, the
lurkers, etc. My friends Bill Pierce and Adam Levin-Delson were always
standouts; they always, always jumped right into food prep. Which
completely mirrored their professional selves; these two just got things
done.
These non work interactions also helped remove people from the candidate
list. People who otherwise looked pretty good on paper.
One Wing Ding we had burritos. So a dude walks in. I hand him a bowl,
the block of cheddar, and a grater and tell him to first wash his hands. So
he gets to work. The dude cannot figure out how to convert big cheese into
little cheese. I let him struggle, just to see how it'd play out.
Think about that. Imagine you've never worked in a kitchen. How would
you solve this new problem?
The grater has four possible orientations. Wouldn't you try them all?
But dude doesn't. Instead, he decides to brute force the problem. Dude
is actually pushing the cheese through the grater, like a Play-Doh machine.
I'm actually okay with dude not being able to figure out how to grate
cheese. Sure, it's a disappointment, but some people just don't get
hardware.
What's not cool is the dude didn't ask for help. Whether its
embarrassment, failure to recognize his own failure, or whatever, I don't
care. What I learned about dude is that he'd silently fail in a corner for
as long you ignored him.
I mention this story 1/2 for humor, 1/2 to give an example of the kind
of personality trait that is hard to uncover during an interview process.
Cheers, Jason

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

[Jason Osgood]

Hi Stewart.

I am one of those self-taught folks who started in the days when CS as an academic discipline was essentially still mathematics. … I appreciate the intent of "CS 101" interview questions ... but I would argue that there are many, many other skills that are not part of a normal CS curriculum that are absolutely required to be present in a successful group.

CS degrees both raised the floor of the talent pool and made the working knowledge base (conventional wisdom) more homogenous.

Happens as every discipline matures.

The ability to reliably signal achievement and proficiency is not a solved problem.


Cheers, Jason

[Stewart Buskirk]

I agree, but would add that the ability to successfully *define* what achievements and proficiencies are needed is also unsolved (and perhaps at the heart of the inability to find a reliable signal).

This leads to settling for the more easily measured signals rather than, perhaps, the actually appropriate ones.

Post by Jason Osgood
The ability to reliably signal achievement and proficiency is not a solved problem.

[Dan Paik]

I am probably taking this thread a bit off topic but what are some good
interview questions? I agree that "atoi" isn't a good one but interview
questions generally have to fall within these constraints (yes, maybe
there's a problem with these constraints):

1) Must not violate NDA or trade secrets. e.g., you can't ask them to
write code on what your team is currently working on and you can't tell
them what your team is currently working on.

2) Probably should not use interviews as an opportunity to get free
consulting work (e.g., spend 6 hours designing and building an API for our
system to ... (and then to the next interview you say "now extend the API
that this other guy wrote to also do ..")) - relates to #1

3) Should be solvable in about 30 minutes or so (since the typical
interview is about an hour you want to leave time for questions + time for
slower developers)

4) Want to test the ability to write code

So in general, we're left with engineers who ask questions like:

1) pub/sub model

2) overall OO - explain the difference between an abstract class and an
interface.

3) code "atoi", code a binary search, code a quicksort, code a graph, etc.

Dan.

Post by Jason Osgood
Hi Stewart.
I am one of those self-taught folks who started in the days when CS as an
academic discipline was essentially still mathematics. ... I appreciate the
intent of "CS 101" interview questions ... but I would argue that there are
many, many other skills that are not part of a normal CS curriculum that
are absolutely required to be present in a successful group.
CS degrees both raised the floor of the talent pool and made the working
knowledge base (conventional wisdom) more homogenous.
Happens as every discipline matures.
The ability to reliably signal achievement and proficiency is not a solved problem.
Cheers, Jason

[Richard Rodseth]

The topic of interviews in our industry is a pet peeve of mine, but in an
effort to be positive, I'll say that one I thought was rather good (and I
didn't get that particular job) involved the interviewer writing a method
on the board and saying "step through this as though you are a debugger and
tell me what it does".

Post by Dan Paik
I am probably taking this thread a bit off topic but what are some good
interview questions? I agree that "atoi" isn't a good one but interview
questions generally have to fall within these constraints (yes, maybe

[Stewart Buskirk]

I like that!

Especially if the job entails any significant amount of working with legacy code rather than building from scratch. And you can extend it into so many areas - can they find a bug in it, can they describe what the overall method accomplishes and how it might be used, can they improve it, might they refactor it, how would they respond to it in a code review, etc. - the activities that for many actually make up the bulk of their day, especially in a team or coaching situation.

The topic of interviews in our industry is a pet peeve of mine, but in an effort to be positive, I'll say that one I thought was rather good (and I didn't get that particular job) involved the interviewer writing a method on the board and saying "step through this as though you are a debugger and tell me what it does".

[Laird Nelson]

Post by Dan Paik
I am probably taking this thread a bit off topic but what are some good
interview questions?

"Hello, and thank you for interviewing with Yoyodyne. I am sure your time
is valuable and I thank you for spending some of it with us today. I see
here on your resume that you've been programming for a few years, so I
don't plan to insult you asking you questions fundamental to the
discipline. Instead, I like to have a conversation with candidates. It's
been my experience that deep conversations about your past work will tell
me everything that I need to know about what kind of a fit you'd find here.
To that end, then, let's start with the project a couple years back. So
tell me: can you describe...."

Then dive deeply into the details of the project. Then have another
conversation about a real problem that you're having at work, and ask
questions about how this person might go about solving it.

You find out REALLY quickly whether the person can communicate, could
program, is slinging b. s., is easy to get along with, is responsible, etc.
Never made a bad hire using this technique over around ten years. Made a
couple when trying to suss people out using scored programming tests.

Best,
Laird

[Dan Paik]

I think that is very useful for one aspect of the candidate's ability which
is how well the candidate can communicate previously encountered design and
coding ability. The only problem is that it may have taken this candidate
much longer than the amount of time that you expect him to take to come up
with this solution (he will tell you that it took him "a week" when it took
him a few months) and the design may have been a design that this candidate
had only a marginal influence in making yet is representing as his own. bs
meter might go off but there are some slick talking engineers out there...

In addition to talking about historical problems, I do like to talk about
real problems at work but if it's too detailed, it's not appropriate for an
interview. If it's made really generic, it can become insulting. Hence,
questions such as "merge 2 really big lists, design a shopping cart, etc."
The difficult stuff that we deal with at work tend not to be the easiest
thing to talk about in a 45 minute interview setting.

I've probably made around 300 hires over the past 10 years and it's been a
pretty mixed bag...I have definitely made my share of mistakes. If
anything, I've grown to be ok with the way that big companies hire
engineers primarily trying to minimize the mistake of bad hires by
admittedly not letting in many qualified hires and focusing on fundamental
skills.

Dan.

Post by Laird Nelson

Post by Dan Paik
I am probably taking this thread a bit off topic but what are some good
interview questions?

"Hello, and thank you for interviewing with Yoyodyne. I am sure your time
is valuable and I thank you for spending some of it with us today. I see
here on your resume that you've been programming for a few years, so I
don't plan to insult you asking you questions fundamental to the
discipline. Instead, I like to have a conversation with candidates. It's
been my experience that deep conversations about your past work will tell
me everything that I need to know about what kind of a fit you'd find here.
To that end, then, let's start with the project a couple years back. So
tell me: can you describe...."
Then dive deeply into the details of the project. Then have another
conversation about a real problem that you're having at work, and ask
questions about how this person might go about solving it.
You find out REALLY quickly whether the person can communicate, could
program, is slinging b. s., is easy to get along with, is responsible, etc.
Never made a bad hire using this technique over around ten years. Made a
couple when trying to suss people out using scored programming tests.
Best,
Laird
--
http://about.me/lairdnelson

[Ross Bleakney]

There are some great comments on this thread.

As far as hiring goes, I take an approach similar to Laird. I also try and figure out if we are a good fit. Even if the developer is smart, they might not be a good fit for the company. For example:

"So, Jason, we like to program using a very large framework that is probably a bit too complex for our needs, but maybe someday we will take advantage of it (and fully understand it). It is XML based. Does that sound good to you? ... Wait, you still have your key card, slow down ..."

And, as I already mentioned, I would ask to see references. Even before I called the people I could learn a lot. For example, how closely did the person work with each reference. Explain why they think this person is good at what they do. In other words, if they list a programmer, explain why they think the programmer is good.

I think biggest weakness in our industry has already been mentioned, and we keep dancing around it: We don't communicate well enough. I really like the pair programming as mentoring idea. That is great. Some of it is installing a proper attitude in the company. The story about the cheese grater is absolutely outstanding. But guess how software companies would respond: Make sure everyone gets proper training in how to use the cheese grater (sign up for "cheese grater boot camp"). Or make sure to ask cheese grating questions (no rookie cheese graters here). Or make sure that every candidate graduated from a school that taught cheese grating.

This misses the whole point. The problem isn't that this guy didn't know how to use a cheese grater (although that is really weird) but that he didn't have the guts to ask. Now imagine it isn't cheese grating, but threading in Java. In some environments, that guy is going to go off in the corner, read a little bit about threading, get it working and call it a day. At some point (probably under heavier load) someone is going to have to fix the code and the will say "Wait, what the heck is this!". But if the company takes a Jack Welch style approach towards the employees, can you blame a guy if he tries to push the cheese through the grater? The better response is to say, "I really don't know that much about the Java threading model, but if you are patient, I'll see if I can write something. But someone should review my work. While we are talking about this, does anyone know of a good book or other resource so I can really dig deep into this. I probably don't need it for this project, but eventually I figure it will be handy". Being able to say "I think that other guy can do a better job at that" is really, really valuable for a company. I do that all the time, even though I know I could do the same work (just not as well or it would take me longer). Figuring out why that other person is better at it is also really valuable. Just asking about books, or other resources can go a long way towards getting better as a developer. It can also speed up the learning process.

Thanks,
Ross


To: seajug-***@public.gmane.org
From: danpaik-***@public.gmane.org
Date: Fri, 28 Mar 2014 16:09:42 -0700
Subject: Re: [seajug] About the new poll


























I think that is very useful for one aspect of the candidate's ability which is how well the candidate can communicate previously encountered design and coding ability. The only problem is that it may have taken this candidate much longer than the amount of time that you expect him to take to come up with this solution (he will tell you that it took him "a week" when it took him a few months) and the design may have been a design that this candidate had only a marginal influence in making yet is representing as his own. bs meter might go off but there are some slick talking engineers out there...


In addition to talking about historical problems, I do like to talk about real problems at work but if it's too detailed, it's not appropriate for an interview. If it's made really generic, it can become insulting. Hence, questions such as "merge 2 really big lists, design a shopping cart, etc." The difficult stuff that we deal with at work tend not to be the easiest thing to talk about in a 45 minute interview setting.



I've probably made around 300 hires over the past 10 years and it's been a pretty mixed bag...I have definitely made my share of mistakes. If anything, I've grown to be ok with the way that big companies hire engineers primarily trying to minimize the mistake of bad hires by admittedly not letting in many qualified hires and focusing on fundamental skills.


Dan.

On Fri, Mar 28, 2014 at 2:41 PM, Laird Nelson <ljnelson-***@public.gmane.org> wrote:




























On Fri, Mar 28, 2014 at 10:53 AM, Dan Paik <danpaik-***@public.gmane.org> wrote:

















I am probably taking this thread a bit off topic but what are some good interview questions?
"Hello, and thank you for interviewing with Yoyodyne. I am sure your time is valuable and I thank you for spending some of it with us today. I see here on your resume that you've been programming for a few years, so I don't plan to insult you asking you questions fundamental to the discipline. Instead, I like to have a conversation with candidates. It's been my experience that deep conversations about your past work will tell me everything that I need to know about what kind of a fit you'd find here. To that end, then, let's start with the project a couple years back. So tell me: can you describe...."



Then dive deeply into the details of the project. Then have another conversation about a real problem that you're having at work, and ask questions about how this person might go about solving it.



You find out REALLY quickly whether the person can communicate, could program, is slinging b. s., is easy to get along with, is responsible, etc. Never made a bad hire using this technique over around ten years. Made a couple when trying to suss people out using scored programming tests.



Best,Laird

[Daniel Kirkdorffer]

Another approach is to ask about a particularly tough problem they've faced
in the past and how they dealt with.

There's book/school learning and there's having been in the trenches
fighting the battles trying to get things to actually work.

On another front, I wonder what people think about group interviews. I
prefer one on ones, but there is value in having another interviewer present
to perhaps observe or note something you may have missed. However, I also
feel that a candidate can become intimidated or feel more under a spotlight
if too many people are present.

Thoughts?

Dan

-----Original Message-----
From: seajug-***@public.gmane.org [mailto:seajug-***@public.gmane.org] On Behalf Of
Ross Bleakney
Sent: Friday, March 28, 2014 6:47 PM
To: seajug-***@public.gmane.org
Subject: RE: [seajug] About the new poll






There are some great comments on this thread.

As far as hiring goes, I take an approach similar to Laird. I also try and
figure out if we are a good fit. Even if the developer is smart, they might
not be a good fit for the company. For example:

"So, Jason, we like to program using a very large framework that is probably
a bit too complex for our needs, but maybe someday we will take advantage of
it (and fully understand it). It is XML based. Does that sound good to you?
... Wait, you still have your key card, slow down ..."

And, as I already mentioned, I would ask to see references. Even before I
called the people I could learn a lot. For example, how closely did the
person work with each reference. Explain why they think this person is good
at what they do. In other words, if they list a programmer, explain why they
think the programmer is good.

I think biggest weakness in our industry has already been mentioned, and we
keep dancing around it: We don't communicate well enough. I really like the
pair programming as mentoring idea. That is great. Some of it is installing
a proper attitude in the company. The story about the cheese grater is
absolutely outstanding. But guess how software companies would respond: Make
sure everyone gets proper training in how to use the cheese grater (sign up
for "cheese grater boot camp"). Or make sure to ask cheese grating questions
(no rookie cheese graters here). Or make sure that every candidate graduated
from a school that taught cheese grating.

This misses the whole point. The problem isn't that this guy didn't know how
to use a cheese grater (although that is really weird) but that he didn't
have the guts to ask. Now imagine it isn't cheese grating, but threading in
Java. In some environments, that guy is going to go off in the corner, read
a little bit about threading, get it working and call it a day. At some
point (probably under heavier load) someone is going to have to fix the code
and the will say "Wait, what the heck is this!". But if the company takes a
Jack Welch style approach towards the employees, can you blame a guy if he
tries to push the cheese through the grater? The better response is to say,
"I really don't know that much about the Java threading model, but if you
are patient, I'll see if I can write something. But someone should review my
work. While we are talking about this, does anyone know of a good book or
other resource so I can really dig deep into this. I probably don't need it
for this project, but eventually I figure it will be handy". Being able to
say "I think that other guy can do a better job at that" is really, really
valuable for a company. I do that all the time, even though I know I could
do the same work (just not as well or it would take me longer). Figuring out
why that other person is better at it is also really valuable. Just asking
about books, or other resources can go a long way towards getting better as
a developer. It can also speed up the learning process.

Thanks,
Ross

[Joe Bowbeer]

I like group interviews if the team typically works as a group. One of the
creative teams at Adobe was doing this a few years ago. It threw me off at
first, because there we not single point of focus. But I think it makes a
lot of sense.

The one-on-one is fake in many ways. Asking questions that are already
solved... When does this happen in the real world?

The rigid one-on-one is easier to regulate, though. If a company is
(ostensibly) hiring for at-large positions that will be determined after
the interviewee is hired (e.g., Facebook) then a suite of rigorous
one-sided interviews is easier to assess than more free-flowing and/or
group-oriented interviews.

However, if a team generally works together as a group (if not then why
not?!), then the group dynamics are a big contributor to productivity, and
I think it can be very effective to assess this before hiring.


On Sat, Mar 29, 2014 at 12:33 PM, Daniel Kirkdorffer

Post by Daniel Kirkdorffer
Another approach is to ask about a particularly tough problem they've
faced in the past and how they dealt with.
There's book/school learning and there's having been in the trenches
fighting the battles trying to get things to actually work.
On another front, I wonder what people think about group interviews. I
prefer one on ones, but there is value in having another interviewer
present to perhaps observe or note something you may have missed. However,
I also feel that a candidate can become intimidated or feel more under a
spotlight if too many people are present.
Thoughts?
Dan
-----Original Message-----
Of *Ross Bleakney
*Sent:* Friday, March 28, 2014 6:47 PM
*Subject:* RE: [seajug] About the new poll
There are some great comments on this thread.
As far as hiring goes, I take an approach similar to Laird. I also try and
figure out if we are a good fit. Even if the developer is smart, they might
"So, Jason, we like to program using a very large framework that is
probably a bit too complex for our needs, but maybe someday we will take
advantage of it (and fully understand it). It is XML based. Does that sound
good to you? ... Wait, you still have your key card, slow down ..."
And, as I already mentioned, I would ask to see references. Even before I
called the people I could learn a lot. For example, how closely did the
person work with each reference. Explain why they think this person is good
at what they do. In other words, if they list a programmer, explain why
they think the programmer is good.
I think biggest weakness in our industry has already been mentioned, and
we keep dancing around it: We don't communicate well enough. I really like
the pair programming as mentoring idea. That is great. Some of it is
installing a proper attitude in the company. The story about the cheese
grater is absolutely outstanding. But guess how software companies would
respond: Make sure everyone gets proper training in how to use the cheese
grater (sign up for "cheese grater boot camp"). Or make sure to ask cheese
grating questions (no rookie cheese graters here). Or make sure that every
candidate graduated from a school that taught cheese grating.
This misses the whole point. The problem isn't that this guy didn't know
how to use a cheese grater (although that is really weird) but that he
didn't have the guts to ask. Now imagine it isn't cheese grating, but
threading in Java. In some environments, that guy is going to go off in the
corner, read a little bit about threading, get it working and call it a
day. At some point (probably under heavier load) someone is going to have
to fix the code and the will say "Wait, what the heck is this!". But if the
company takes a Jack Welch style approach towards the employees, can you
blame a guy if he tries to push the cheese through the grater? The better
response is to say, "I really don't know that much about the Java threading
model, but if you are patient, I'll see if I can write something. But
someone should review my work. While we are talking about this, does anyone
know of a good book or other resource so I can really dig deep into this. I
probably don't need it for this project, but eventually I figure it will be
handy". Being able to say "I think that other guy can do a better job at
that" is really, really valuable for a company. I do that all the time,
even though I know I could do the same work (just not as well or it would
take me longer). Figuring out why that other person is better at it is also
really valuable. Just asking about books, or other resources can go a long
way towards getting better as a developer. It can also speed up the
learning process.
Thanks,
Ross

[Scott Shipp]

That cheese grater story bothers me. I don't think it proves anything about the candidate. For all we know this person is founding the next billion dollar startup as we speak (or even already has). Using a cheese grater has nothing to do with coding skills. Furthermore, the expectation that someone would know how to use a cheese grater is a cultural bias since shredded cheese and cheese graters are not universal. There are entire major portions of the world that do not use cheese in their food at all. See China.

Yes, I know the point is seeing if the person would ask for help. But is that really what it showed? Here is someone coming in to interview for a job they really want. Put yourself in that place. They want to impress you. They spent the last few weeks nervously preparing. Maybe they obsessed over what coding question they might be asked. Perhaps they spent a few hours learning about your company and thinking about (with limited information) what it might be like to work there and how they can contribute. The night before they perhaps didn't sleep well. That very morning, they tried to cram for the interview one last time. They are coming in to meet a stranger. They don't know you from Adam. You probably spoke in a phone screen, and they are trying to envision what you look like. They are analyzing every word that was said to see if they can figure out what will impress you. Everything hinges on the first impression anyway. They know that. The pressure is pretty high.

Then you throw a random task at them out of left field. Hi nice to meet you. Here's a cheese grater and some cheese. See you in a few minutes. Whoa. Back up. Isn't this a coding interview? What's going on here?

If you didn't completely flummox them, then you at least got their gears going, and going in the wrong direction. They are thinking: "What's the catch here? Where's the secret test? Is this about how much cheese I will grate? Is it about whether I'll choose the little holes or the big holes on this grater? Are they trying to see if my choice reveals some hidden aspect of my personality? Maybe they want me to refuse to grate cheese at all, and say I'm a 'developer not a kitchen worker.' And since I don't know how to use a cheese grater, if I ask for help, I'll look like really foolish. Probably they don't want me to ask for help anyway. What will that show? It will show that I can't get things done. I'm sure they want me to try and figure it out the best I can, because that will show independent thought and resolve."

This is a bad interview question in my mind because it has only ONE HOLY ANSWER: get help. But when the candidate doesn't do this, we jump to the conclusion that they are a person who will never get help. And who knows whether that's true or not. We're talking about cheese-grating here. We're not even in the context of coding, and it's well-known that people behave differently in different contexts anyway. This might be a really humble team player when it comes to coding. Maybe they never worked in a team situation in the kitchen though. They probably live alone. Actually the fact that they don't know how to use a cheese grater may indicate they don't use the kitchen (aside from the microwave) anyway. So your context is completely lost.

And besides that, in most cases it would be a waste of time to ask someone to shred cheese as part of an interview because most people already know how and they'll just shred the cheese and you won't see them struggling in the first place. So there won't be any opportunity for them to have to ask for help. So you gained net zero toward understanding this candidate.

IMO good interview questions are completely open-ended and there is no preconceived or expected answer whatsoever. You ask the question and see how they react. Then, later on, once you've had some distance and are back in your own office, giving the candidate the benefit of the doubt since this was a nerve-wracking interview, you think about how they approached the problem, what they said, how they think, what assumptions they might be operating under (such as "they want me to do this on my own and not ask for help, because they are testing me right now"). Then you think about how that type of approach will complement your team or not. And the whole time you remember that maybe you didn't see this person at their best, but in an awkward social situation with a lot of other things going on.
Scott

To: seajug-***@public.gmane.org
From: joe.bowbeer-***@public.gmane.org
Date: Sat, 29 Mar 2014 12:48:18 -0700
Subject: Re: [seajug] About the new poll



























I like group interviews if the team typically works as a group. One of the creative teams at Adobe was doing this a few years ago. It threw me off at first, because there we not single point of focus. But I think it makes a lot of sense.

The one-on-one is fake in many ways. Asking questions that are already solved... When does this happen in the real world?
The rigid one-on-one is easier to regulate, though. If a company is (ostensibly) hiring for at-large positions that will be determined after the interviewee is hired (e.g., Facebook) then a suite of rigorous one-sided interviews is easier to assess than more free-flowing and/or group-oriented interviews.

However, if a team generally works together as a group (if not then why not?!), then the group dynamics are a big contributor to productivity, and I think it can be very effective to assess this before hiring.


On Sat, Mar 29, 2014 at 12:33 PM, Daniel Kirkdorffer <dankirkd-***@public.gmane.org> wrote:




























Another approach is to ask about a particularly
tough problem they've faced in the past and how they dealt
with.

There's book/school learning and there's having
been in the trenches fighting the battles trying to get things to actually
work.

On
another front, I wonder what people think about group interviews. I prefer
one on ones, but there is value in having another interviewer present to perhaps
observe or note something you may have missed. However, I also feel that a
candidate can become intimidated or feel more under a spotlight if too many
people are present.

Thoughts?

Dan


-----Original Message-----
From:
seajug-***@public.gmane.org [mailto:seajug-***@public.gmane.org] On Behalf Of
Ross Bleakney
Sent: Friday, March 28, 2014 6:47 PM
To:
***@yahoogroups.com
Subject: RE: [seajug] About the new
poll





There are some great comments on this thread.

As far as
hiring goes, I take an approach similar to Laird. I also try and figure out if
we are a good fit. Even if the developer is smart, they might not be a good
fit for the company. For example:

"So, Jason, we like to program using
a very large framework that is probably a bit too complex for our needs, but
maybe someday we will take advantage of it (and fully understand it). It is
XML based. Does that sound good to you? ... Wait, you still have your
key card, slow down ..."

And, as I already mentioned, I would ask to
see references. Even before I called the people I could learn a lot. For
example, how closely did the person work with each reference. Explain why they
think this person is good at what they do. In other words, if they list a
programmer, explain why they think the programmer is good.

I think
biggest weakness in our industry has already been mentioned, and we keep
dancing around it: We don't communicate well enough. I really like the pair
programming as mentoring idea. That is great. Some of it is installing a
proper attitude in the company. The story about the cheese grater is
absolutely outstanding. But guess how software companies would respond: Make
sure everyone gets proper training in how to use the cheese grater (sign up
for "cheese grater boot camp"). Or make sure to ask cheese grating questions
(no rookie cheese graters here). Or make sure that every candidate graduated
from a school that taught cheese grating.

This misses the whole point.
The problem isn't that this guy didn't know how to use a cheese grater
(although that is really weird) but that he didn't have the guts to ask. Now
imagine it isn't cheese grating, but threading in Java. In some environments,
that guy is going to go off in the corner, read a little bit about threading,
get it working and call it a day. At some point (probably under heavier load)
someone is going to have to fix the code and the will say "Wait, what the heck
is this!". But if the company takes a Jack Welch style approach towards the
employees, can you blame a guy if he tries to push the cheese through the
grater? The better response is to say, "I really don't know that much about
the Java threading model, but if you are patient, I'll see if I can write
something. But someone should review my work. While we are talking about this,
does anyone know of a good book or other resource so I can really dig deep
into this. I probably don't need it for this project, but eventually I figure
it will be handy". Being able to say "I think that other guy can do a better
job at that" is really, really valuable for a company. I do that all the time,
even though I know I could do the same work (just not as well or it would take
me longer). Figuring out why that other person is better at it is also really
valuable. Just asking about books, or other resources can go a long way
towards getting better as a developer. It can also speed up the learning
process.

Thanks,
Ross

[Dan Paik]

one of the things we discussed a lot at one of my previous companies was
the whole notion of whether the candidate was "just nervous" (so give them
the benefit of doubt) or disregard and evaluate everyone on the same
playing field. In general, we evaluated everyone on the same playing field
and if a candidate was nervous, seemed smart but just can't interview well,
etc. it was simply tough luck. I'm not sure that i always agreed with it
but other folks always said "i can only work with the data points that they
give me..."

i do find it interesting that there are largely 3 ways that companies
interview:

1) the team interviews candidates and picks the best one...this is usually
one where there are multiple rounds and cuts and eventually the list
narrows down and the team picks who they feel was the best amongst all of
the candidate for their budget, location, etc. this is prevalent in most
small and mid-sized companies where there is usually 1 open req and once
it's filled, it's over.

2) the team interviews candidates and as long as the candidate exceeds a
hiring bar, they discuss feedback and hire. this is common in large
companies where there are always many open reqs and the limiting reagent is
qualified people.

3) random people in the same job family interview and write up notes and a
central committee makes all hiring decisions. this helps to ensure
consistency in hires across the company so this is common in large
companies.

the cheese grater interview would fly in #1 but likely would not fly in #2
and definitely would not fly in #3.

but more importantly, i think it's critical for interviewers to detach
their personal idiosyncrasies from the interview process. i have had
co-workers say things like "i will never hire a candidate if the resume is
longer than 2 pages" or "i will never hire a candidate who doesn't wear a
suit" or "i will never hire a candidate who wears a suit" or "i will never
hire a candidate who shows up to an interview in flip flops" or "i will
never hire this candidate because he answered his phone during my interview
- shows bad judgement" or "i will never hire a candidate who is late to the
interview" or "i will never hire a candidate who doesn't use the
whiteboard", etc. this is where i believe that candidates need the benefit
of the doubt because interviewers can be a weird bunch of folks too...

Post by Scott Shipp
That cheese grater story bothers me. I don't think it proves anything
about the candidate. For all we know this person is founding the next
billion dollar startup as we speak (or even already has). Using a cheese
grater has nothing to do with coding skills. Furthermore, the expectation
that someone would know how to use a cheese grater is a cultural bias since
shredded cheese and cheese graters are not universal. There are entire
major portions of the world that do not use cheese in their food at all.
See China.
Yes, I know the point is seeing if the person would ask for help. But is
that really what it showed? Here is someone coming in to interview for a
job they really want. Put yourself in that place. They want to impress you.
They spent the last few weeks nervously preparing. Maybe they obsessed over
what coding question they might be asked. Perhaps they spent a few hours
learning about your company and thinking about (with limited information)
what it might be like to work there and how they can contribute. The night
before they perhaps didn't sleep well. That very morning, they tried to
cram for the interview one last time. They are coming in to meet a
stranger. They don't know you from Adam. You probably spoke in a phone
screen, and they are trying to envision what you look like. They are
analyzing every word that was said to see if they can figure out what will
impress you. Everything hinges on the first impression anyway. They know
that. The pressure is pretty high.
Then you throw a random task at them out of left field. Hi nice to meet
you. Here's a cheese grater and some cheese. See you in a few minutes.
Whoa. Back up. Isn't this a coding interview? What's going on here?
If you didn't completely flummox them, then you at least got their gears
going, and going in the wrong direction. They are thinking: "What's the
catch here? Where's the secret test? Is this about how much cheese I will
grate? Is it about whether I'll choose the little holes or the big holes on
this grater? Are they trying to see if my choice reveals some hidden aspect
of my personality? Maybe they want me to refuse to grate cheese at all, and
say I'm a 'developer not a kitchen worker.' And since I don't know how to
use a cheese grater, if I ask for help, I'll look like really foolish.
Probably they don't want me to ask for help anyway. What will that show? It
will show that I can't get things done. I'm sure they want me to try and
figure it out the best I can, because that will show independent thought
and resolve."
This is a bad interview question in my mind because it has only ONE HOLY
ANSWER: get help. But when the candidate doesn't do this, we jump to the
conclusion that they are a person who will never get help. And who knows
whether that's true or not. We're talking about cheese-grating here. We're
not even in the context of coding, and it's well-known that people behave
differently in different contexts anyway. This might be a really humble
team player when it comes to coding. Maybe they never worked in a team
situation in the kitchen though. They probably live alone. Actually the
fact that they don't know how to use a cheese grater may indicate they
don't use the kitchen (aside from the microwave) anyway. So your context is
completely lost.
And besides that, in most cases it would be a waste of time to ask someone
to shred cheese as part of an interview because most people already know
how and they'll just shred the cheese and you won't see them struggling in
the first place. So there won't be any opportunity for them to have to ask
for help. So you gained net zero toward understanding this candidate.
IMO good interview questions are completely open-ended and there is no
preconceived or expected answer whatsoever. You ask the question and see
how they react. Then, later on, once you've had some distance and are back
in your own office, giving the candidate the benefit of the doubt since
this was a nerve-wracking interview, you think about how they approached
the problem, what they said, how they think, what assumptions they might be
operating under (such as "they want me to do this on my own and not ask for
help, because they are testing me right now"). Then you think about how
that type of approach will complement your team or not. And the whole time
you remember that maybe you didn't see this person at their best, but in an
awkward social situation with a lot of other things going on.
Scott
------------------------------
Date: Sat, 29 Mar 2014 12:48:18 -0700
Subject: Re: [seajug] About the new poll
I like group interviews if the team typically works as a group. One of
the creative teams at Adobe was doing this a few years ago. It threw me
off at first, because there we not single point of focus. But I think it
makes a lot of sense.
The one-on-one is fake in many ways. Asking questions that are already
solved... When does this happen in the real world?
The rigid one-on-one is easier to regulate, though. If a company is
(ostensibly) hiring for at-large positions that will be determined after
the interviewee is hired (e.g., Facebook) then a suite of rigorous
one-sided interviews is easier to assess than more free-flowing and/or
group-oriented interviews.
However, if a team generally works together as a group (if not then why
not?!), then the group dynamics are a big contributor to productivity, and
I think it can be very effective to assess this before hiring.
Another approach is to ask about a particularly tough problem they've
faced in the past and how they dealt with.
There's book/school learning and there's having been in the trenches
fighting the battles trying to get things to actually work.
On another front, I wonder what people think about group interviews. I
prefer one on ones, but there is value in having another interviewer
present to perhaps observe or note something you may have missed. However,
I also feel that a candidate can become intimidated or feel more under a
spotlight if too many people are present.
Thoughts?
Dan
-----Original Message-----
Of *Ross Bleakney
*Sent:* Friday, March 28, 2014 6:47 PM
*Subject:* RE: [seajug] About the new poll
There are some great comments on this thread.
As far as hiring goes, I take an approach similar to Laird. I also try and
figure out if we are a good fit. Even if the developer is smart, they might
"So, Jason, we like to program using a very large framework that is
probably a bit too complex for our needs, but maybe someday we will take
advantage of it (and fully understand it). It is XML based. Does that sound
good to you? ... Wait, you still have your key card, slow down ..."
And, as I already mentioned, I would ask to see references. Even before I
called the people I could learn a lot. For example, how closely did the
person work with each reference. Explain why they think this person is good
at what they do. In other words, if they list a programmer, explain why
they think the programmer is good.
I think biggest weakness in our industry has already been mentioned, and
we keep dancing around it: We don't communicate well enough. I really like
the pair programming as mentoring idea. That is great. Some of it is
installing a proper attitude in the company. The story about the cheese
grater is absolutely outstanding. But guess how software companies would
respond: Make sure everyone gets proper training in how to use the cheese
grater (sign up for "cheese grater boot camp"). Or make sure to ask cheese
grating questions (no rookie cheese graters here). Or make sure that every
candidate graduated from a school that taught cheese grating.
This misses the whole point. The problem isn't that this guy didn't know
how to use a cheese grater (although that is really weird) but that he
didn't have the guts to ask. Now imagine it isn't cheese grating, but
threading in Java. In some environments, that guy is going to go off in the
corner, read a little bit about threading, get it working and call it a
day. At some point (probably under heavier load) someone is going to have
to fix the code and the will say "Wait, what the heck is this!". But if the
company takes a Jack Welch style approach towards the employees, can you
blame a guy if he tries to push the cheese through the grater? The better
response is to say, "I really don't know that much about the Java threading
model, but if you are patient, I'll see if I can write something. But
someone should review my work. While we are talking about this, does anyone
know of a good book or other resource so I can really dig deep into this. I
probably don't need it for this project, but eventually I figure it will be
handy". Being able to say "I think that other guy can do a better job at
that" is really, really valuable for a company. I do that all the time,
even though I know I could do the same work (just not as well or it would
take me longer). Figuring out why that other person is better at it is also
really valuable. Just asking about books, or other resources can go a long
way towards getting better as a developer. It can also speed up the
learning process.
Thanks,
Ross

[Jason Osgood]

Hi Scott.


Great, thoughtful reply. Thanks.

Post by Scott Shipp
I don't think it proves anything about the candidate.

No. But it does prove that I could never respect a North American middle aged white dude who can’t work a cheese grater.

Respectfully, at the risk of making another gross over generalization: I’m more worried about false positives (hiring a stinker) than false negatives (missing a diamond in the rough).


Cheers, Jason

[Dan Paik]

i agree. type I errors (rejecting the null hypothesis when it's true) is
bad.

most companies actively make this tradeoff knowing that they are going to
reject some (or many) good hires to minimize the risk of making a bad hire.

Post by Jason Osgood
Hi Scott.
Great, thoughtful reply. Thanks.
I don't think it proves anything about the candidate.
No. But it does prove that I could never respect a North American middle
aged white dude who can't work a cheese grater.
Respectfully, at the risk of making another gross over generalization: I'm
more worried about false positives (hiring a stinker) than false negatives
(missing a diamond in the rough).
Cheers, Jason

[c***@public.gmane.org]

If your company has code reviews and a probationary period, then I don't see how the potential for false positives causes more concern than false negatives. With code reviews, you can determine whether someone's work is good or not before they can cause a problem in production. With the probationary period, you can fire these workers early in their time with the company if their code is consistently bad.

The larger problem it seems is the lack of will in companies to realistically address issues such as bad developers. That's certainly not limited to the interviewing process.


Chris


---In ***@yahoogroups.com, <***@...> wrote :

Hi Scott.



Great, thoughtful reply. Thanks.


I don't think it proves anything about the candidate.







No. But it does prove that I could never respect a North American middle aged white dude who can’t work a cheese grater.


Respectfully, at the risk of making another gross over generalization: I’m more worried about false positives (hiring a stinker) than false negatives (missing a diamond in the rough).




Cheers, Jason

[Ross Bleakney]

I don't think Jason believes that it is a good idea to use a cheese grater (whether literally or metaphorically) in an interview. Quite the opposite. His point was that in a non-interview situation (AKA they were making burritos before a casual meeting) the guy never asked how to use a cheese grater. Maybe he asks questions all the time at work, but I doubt it. The point of his story is that this is really bad behavior. It is common in this industry. As I said below, I don't blame a guy for acting this way -- in many environments you are forced to (which is why I referenced Jack Welch). There are really two things here: fostering the right environment, and hiring the right people.

The cheese grater is a very important analogy to foster the right environment. It is funny, and sticks in people's mind. That is why it would be a great discussion point to tell all the new hires. Basically, you tell them that they will never be punished for asking how to use a cheese grater. Not all companies take this approach, so it is very important that you encourage this. A lot of people will laugh, then take a big sigh, and think to themselves "I think I'll like it here". If the group really sticks to that principle, then the company will be successful.

The cheese grater question is the type of question that is asked all the time in interviews. Again, not literally, but in many forms (whether atoi or the shape of an M & M). These types of questions, as people have said (and studies have backed up) are pretty much pointless. Ask what they've done, what they like they to do, what they would be expected to do, and if you are worried if they can do it, ask for (and about) the references.

Ross

From: ***@outlook.com
To: seajug-***@public.gmane.org
Date: Mon, 31 Mar 2014 08:57:53 -0700
Subject: RE: [seajug] About the new poll



























That cheese grater story bothers me. I don't think it proves anything about the candidate. For all we know this person is founding the next billion dollar startup as we speak (or even already has). Using a cheese grater has nothing to do with coding skills. Furthermore, the expectation that someone would know how to use a cheese grater is a cultural bias since shredded cheese and cheese graters are not universal. There are entire major portions of the world that do not use cheese in their food at all. See China.

Yes, I know the point is seeing if the person would ask for help. But is that really what it showed? Here is someone coming in to interview for a job they really want. Put yourself in that place. They want to impress you. They spent the last few weeks nervously preparing. Maybe they obsessed over what coding question they might be asked. Perhaps they spent a few hours learning about your company and thinking about (with limited information) what it might be like to work there and how they can contribute. The night before they perhaps didn't sleep well. That very morning, they tried to cram for the interview one last time. They are coming in to meet a stranger. They don't know you from Adam. You probably spoke in a phone screen, and they are trying to envision what you look like. They are analyzing every word that was said to see if they can figure out what will impress you. Everything hinges on the first impression anyway. They know that. The pressure is pretty high.

Then you throw a random task at them out of left field. Hi nice to meet you. Here's a cheese grater and some cheese. See you in a few minutes. Whoa. Back up. Isn't this a coding interview? What's going on here?

If you didn't completely flummox them, then you at least got their gears going, and going in the wrong direction. They are thinking: "What's the catch here? Where's the secret test? Is this about how much cheese I will grate? Is it about whether I'll choose the little holes or the big holes on this grater? Are they trying to see if my choice reveals some hidden aspect of my personality? Maybe they want me to refuse to grate cheese at all, and say I'm a 'developer not a kitchen worker.' And since I don't know how to use a cheese grater, if I ask for help, I'll look like really foolish. Probably they don't want me to ask for help anyway. What will that show? It will show that I can't get things done. I'm sure they want me to try and figure it out the best I can, because that will show independent thought and resolve."

This is a bad interview question in my mind because it has only ONE HOLY ANSWER: get help. But when the candidate doesn't do this, we jump to the conclusion that they are a person who will never get help. And who knows whether that's true or not. We're talking about cheese-grating here. We're not even in the context of coding, and it's well-known that people behave differently in different contexts anyway. This might be a really humble team player when it comes to coding. Maybe they never worked in a team situation in the kitchen though. They probably live alone. Actually the fact that they don't know how to use a cheese grater may indicate they don't use the kitchen (aside from the microwave) anyway. So your context is completely lost.

And besides that, in most cases it would be a waste of time to ask someone to shred cheese as part of an interview because most people already know how and they'll just shred the cheese and you won't see them struggling in the first place. So there won't be any opportunity for them to have to ask for help. So you gained net zero toward understanding this candidate.

IMO good interview questions are completely open-ended and there is no preconceived or expected answer whatsoever. You ask the question and see how they react. Then, later on, once you've had some distance and are back in your own office, giving the candidate the benefit of the doubt since this was a nerve-wracking interview, you think about how they approached the problem, what they said, how they think, what assumptions they might be operating under (such as "they want me to do this on my own and not ask for help, because they are testing me right now"). Then you think about how that type of approach will complement your team or not. And the whole time you remember that maybe you didn't see this person at their best, but in an awkward social situation with a lot of other things going on.
Scott

To: seajug-***@public.gmane.org
From: joe.bowbeer-***@public.gmane.org
Date: Sat, 29 Mar 2014 12:48:18 -0700
Subject: Re: [seajug] About the new poll



























I like group interviews if the team typically works as a group. One of the creative teams at Adobe was doing this a few years ago. It threw me off at first, because there we not single point of focus. But I think it makes a lot of sense.

The one-on-one is fake in many ways. Asking questions that are already solved... When does this happen in the real world?
The rigid one-on-one is easier to regulate, though. If a company is (ostensibly) hiring for at-large positions that will be determined after the interviewee is hired (e.g., Facebook) then a suite of rigorous one-sided interviews is easier to assess than more free-flowing and/or group-oriented interviews.

However, if a team generally works together as a group (if not then why not?!), then the group dynamics are a big contributor to productivity, and I think it can be very effective to assess this before hiring.


On Sat, Mar 29, 2014 at 12:33 PM, Daniel Kirkdorffer <dankirkd-***@public.gmane.org> wrote:




























Another approach is to ask about a particularly
tough problem they've faced in the past and how they dealt
with.

There's book/school learning and there's having
been in the trenches fighting the battles trying to get things to actually
work.

On
another front, I wonder what people think about group interviews. I prefer
one on ones, but there is value in having another interviewer present to perhaps
observe or note something you may have missed. However, I also feel that a
candidate can become intimidated or feel more under a spotlight if too many
people are present.

Thoughts?

Dan


-----Original Message-----
From:
seajug-***@public.gmane.org [mailto:seajug-***@public.gmane.org] On Behalf Of
Ross Bleakney
Sent: Friday, March 28, 2014 6:47 PM
To:
***@yahoogroups.com
Subject: RE: [seajug] About the new
poll





There are some great comments on this thread.

As far as
hiring goes, I take an approach similar to Laird. I also try and figure out if
we are a good fit. Even if the developer is smart, they might not be a good
fit for the company. For example:

"So, Jason, we like to program using
a very large framework that is probably a bit too complex for our needs, but
maybe someday we will take advantage of it (and fully understand it). It is
XML based. Does that sound good to you? ... Wait, you still have your
key card, slow down ..."

And, as I already mentioned, I would ask to
see references. Even before I called the people I could learn a lot. For
example, how closely did the person work with each reference. Explain why they
think this person is good at what they do. In other words, if they list a
programmer, explain why they think the programmer is good.

I think
biggest weakness in our industry has already been mentioned, and we keep
dancing around it: We don't communicate well enough. I really like the pair
programming as mentoring idea. That is great. Some of it is installing a
proper attitude in the company. The story about the cheese grater is
absolutely outstanding. But guess how software companies would respond: Make
sure everyone gets proper training in how to use the cheese grater (sign up
for "cheese grater boot camp"). Or make sure to ask cheese grating questions
(no rookie cheese graters here). Or make sure that every candidate graduated
from a school that taught cheese grating.

This misses the whole point.
The problem isn't that this guy didn't know how to use a cheese grater
(although that is really weird) but that he didn't have the guts to ask. Now
imagine it isn't cheese grating, but threading in Java. In some environments,
that guy is going to go off in the corner, read a little bit about threading,
get it working and call it a day. At some point (probably under heavier load)
someone is going to have to fix the code and the will say "Wait, what the heck
is this!". But if the company takes a Jack Welch style approach towards the
employees, can you blame a guy if he tries to push the cheese through the
grater? The better response is to say, "I really don't know that much about
the Java threading model, but if you are patient, I'll see if I can write
something. But someone should review my work. While we are talking about this,
does anyone know of a good book or other resource so I can really dig deep
into this. I probably don't need it for this project, but eventually I figure
it will be handy". Being able to say "I think that other guy can do a better
job at that" is really, really valuable for a company. I do that all the time,
even though I know I could do the same work (just not as well or it would take
me longer). Figuring out why that other person is better at it is also really
valuable. Just asking about books, or other resources can go a long way
towards getting better as a developer. It can also speed up the learning
process.

Thanks,
Ross

[Daniel Kirkdorffer]

Post by Laird Nelson
You find out REALLY quickly whether the person can communicate, could

program,

Post by Laird Nelson
is slinging b. s., is easy to get along with, is responsible, etc. Never

made a bad hire

Post by Laird Nelson
using this technique over around ten years. Made a couple when trying to

suss people

Post by Laird Nelson
out using scored programming tests.

Not to mention those you may have rejected based on the tests that may have
turned out to be good hires.

Dan

[Eric Jain]

So, IMO, the bigger companies in the industry are not doing any batter creating good developers!

True; companies should be doing their own batter instead of expecting
an unlimited supply of oven-ready developers.
--
Eric Jain
Got data? Get answers at zenobase.com.


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[k***@u.washington.edu]

Hello,

You've got a lot of responses already, and I haven't read them yet, but
would like to add to the statements regarding percentages of people
w.r.t. skill sets. You have to remember that there are extreme selection
effects a the K-12 level, not with respect to what kids are interested in,
but with what they have as options to learn. The few cases I knew of
before the last few years were that there were usually not options for
K-12 to learn programming through their schools, though there were
"computer classes" that taught them how to use spreadsheet software.
(Some of us luckily had schools that did offer such classes.)


The AWIS once attempted to gather stats about K-12, university, post-undergrad,
and professional levels with respect to all sciences and demographics, gender,
race, and the final careers. Very interesting articles that basically state
objective accurate statistics are difficult if not impossible with small numbers.
Selection affects are what all "surveys" must account for as best they can.


"the world is going to end because we are not graduating enough CS people" article. When I read statistics like CS student make up ~2% of all STEM students and yet 60% of all STEM jobs are in computing, I wonder two things:

[Scott Shipp]

How to provide opportunities for kids to learn and gain an interest in programming before going to college is the most valuable aspect of the discussion to focus on, IMO. I had programming classes in grades 6, 7, and 10 (this was in rural schools in the early and mid '90s to boot). Pretty lucky! When I tell people this they are very surprised because in todays underfunded education world, it's rarely the case that any primary or secondary schools will have any resources to teach programming. They can hardly teach basic primary skills like math correctly (see http://seattlemathcoalition.org/).

Initiatives like "Hour of Code" (http://code.org/) and Saturday Morning Coder Dojo (http://www.meetup.com/Seattle-Coder-Dojo/) appeal very strongly to me. I hope that a lot of things like these start happening more regularly. I fully intend to volunteer at such events and take my kids to them once they are old enough (my kids are toddler and infant respectively).

On another topic, Ross said, "I've also known plenty of people without degrees who know plenty about
the fundamentals of programming. They understand computers from the
ground up and had no trouble understanding all of the key concepts. How?
They read the same books as the guys and gals that went to school and
got the Computer Science degrees."

Really? That's pretty good and I applaud this. It seems like in my experience what's more likely to happen is that someone wrote some VB or Python because they needed to get something done and this eventually led into reading a "Learn [insert trendy recent language] in 28 days" book for them. After which they go off writing a bunch of code that exhibits no understanding of any best practices or design principles. Have you ever loaded up the "newest" questions tab on Stack Overflow? It's full of people like this. The pain of gritting my teeth while reading these questions is nearly too much to bear! Not because they are "stupid questions" but because it just hurts to see people trying to bite off way more than they can chew.

If you know people who take the time to go through books that provide the core of a traditional CS degree program (like http://algs4.cs.princeton.edu/home/ which is available online for free and you can also take a Coursera MOOC on for free) then I'd say they are the exception that proves the rule. CS is hard. Not many people want the inconvenience of learning it without the reward of a guaranteed degree or job.

I really like most of what you said, though. The interviewing approach in this industry is a cluster-you-know-what.

Scott

[Konstantin Ignatyev]

Post by Scott Shipp
How to provide opportunities for kids to learn and gain an interest in
programming before going to college is the most valuable aspect of the
discussion to focus on, IMO. I had programming classes in grades 6, 7, and
10 (this was in rural schools in the early and mid '90s to boot). Pretty
lucky! When I tell people this they are very surprised because in todays
underfunded education world, it's rarely the case that any primary or
secondary schools will have any resources to teach programming.

Oh please do not repeat that 'education is underfunded' nonsense. To get
good education in math and science all is needed a good teacher and a chalk
board. Plus a collection of decent equipment to experiment and tinker with.

Problem is motivation and whole society attitude which praises sales,
celebrities, and athletes.

But do not take my word for it, there is a well respected Daniel Quinn
talking
http://ishmael.org/Education/Writings/unschooling.shtml

[Scott Shipp]

Maybe so...that's hardly a primary point I was trying to make nor an argument I care to push one way or the other. :-)

[t***@public.gmane.org]

More important than what interviewing techniques you use is do you analyze whether the techniques work? Are you hiring the right people? Does every hire work out as expected? If not, why not? Do you feed this information back into the interview process? And for the really tough question: how do you know whether you are filtering out better candidates than the ones you hire?

I started this thread because I felt the whole debate about the lack of suitable candidates for "computing" jobs is a red herring. I've seen zero evidence the assertion has any validity. What's missing is the perfect candidate at the given price point. It's like saying I want a Mercedes but only want to pay for a Toyota.


doug