Berkeley CSUA MOTD:Entry 46755
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2025/07/09 [General] UID:1000 Activity:popular
7/9     

2007/5/25-28 [Industry/Jobs] UID:46755 Activity:moderate
5/25    I'm looking for pointers on how to recruit excellent junior/mid level
        computer scientists or programmers. For those of you who have hired
        people, what is a good way to go about recruiting? Basically we want
        really smart people who know and love CS and programming. Money is
        not a constraint, but we don't want people just in it for the money.
        Google seems to have a good way of doing this, but I don't know if
        there methods apply to much smaller organizations. Thanks.
        \_ Google hires excellent people by hiring a lot of people and letting
           probability take care of the rest.
        \_ I would start getting your employees to refer someone they know to
           come in and talk to you. Or if you have good/trusted friends in the
           IT industry, see if they can refer someone to you as well. Good people
           hire good people. (most of the time).
           IT industry, see if they can refer someone to you as well. Good
           people hire good people. (most of the time).
           \_ Myth.  All people hire people they like.  Not everyone knows or
              likes good people.  If this myth were true then good people would
              be running all these companies and we know that isn't true.
        \_ Google is struggling to hire anyone decent.  There is no reason for
           a non-PhD to go to Google these days and it shows in their
           increasingly desperate hiring behavior.  As far as money goes, 99%
           of people are 'in it for the money' because there are lots of things
           they could be doing they would enjoy more that don't pay as much yet
           there's their resume in front of you.  Ask yourself if you would
           do the same job if you got paid half as much, no options, etc.
           \_ I wouldn't be doing the same job if the compensation were
              halved, but there isn't any other job I would want unless the
              compensation was more than twice what I get now. That's what I
              meant by not in it for the money.
              \_ Fair enough.  Just curious, are you married?  Have kids?
                 Mortgage?
        \_ http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
           My medium-size company has arrangements with some recruiters who are not
           employees to find good candidates based on resumes, referrals, etc.
           employees to find good candidates based on their resumes, or references, etc.
           They will figure out what you are looking for. Then you have to screen
           and interview a ton of people to find the ones worth hiring.
           and interview a ton of people to find the good ones.
           \_ Very good link.  Thanks for posting that.  If only more hiring
              managers would follow his advice.
2025/07/09 [General] UID:1000 Activity:popular
7/9     

You may also be interested in these entries...
2013/4/17-5/18 [Industry/Jobs] UID:54658 Activity:nil
4/17    Questions about recruiting below.  Thanks.
        1. Why are different positions called full-time, contracting, and
        intern, with "full-time" meaning regular permanent positions?
        Contracting and intern positions are usually 40 hours/week which would
        imply they are full-time (i.e. not part-time) also.
        2. What's the difference between temp, contracting, and consulting
	...
2013/1/16-2/17 [Industry/Startup, Finance/Investment] UID:54582 Activity:nil
1/16    Fred Wilson says you should focus on the cash value of your
        options, not the percentages:
        http://www.avc.com/a_vc/2010/11/employee-equity-how-much.html
        \_ Or at least, so says a VC trying increase his profit margin...
        \_ A VC wants to keep as much of the stock for themselves (and give
           as little to employees as possible).  That maximizes their return.
	...
2012/12/21-2013/1/24 [Industry/Startup, Finance/Investment] UID:54568 Activity:nil
12/21   http://techcompanypay.com
        Yahooers in Sunnyvale don't seem to average 170K/year.
        \_ Googlers average $104k/yr? Uh huh.
           \_ what is it suppose to be?
              \_ link:preview.tinyurl.com/a36ejr4
                 Google Sr. Software Engineer in Sunnyvale averages $193k in total pay,
	...
2012/12/8-30 [Industry/Jobs] UID:54551 Activity:nil
12/8    http://s3.amazonaws.com/engine-advocacy/TechReport_LoRes.pdf
        According to this report, 28.8% of the jobs in the
        Sunnyvale-San Jose-Santa Clara area are considered IT. Is this
        bullshit or what? What about all the restaurants, cleaning,
        retail, and a shitload of other non-IT jobs in the area?
        Just walk around Santa Clara, a bunch of people there are
	...
2012/5/23-7/20 [Industry/Startup] UID:54399 Activity:nil
5/23    Does your company have an opening for a data-entry position?  Hurry!
        "Jersey Woman Says She Was Fired For Being Too Busty"
        http://www.csua.org/u/wiy (gma.yahoo.com)
        \_ why would you hire a dumb bimbo who can't do anything?
           \_ Daily eye candy, or more.
        \_ This is the kind of woman the phrase butter face was invented for.
	...
Cache (8192 bytes)
www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
The Guerrilla Guide to Interviewing (version 30) By Joel Spolsky Wednesday, October 25, 2006 A motley gang of anarchists, free-love advocates, and banana-rights agitators have hijacked The Love Boat out of Puerto Vallarta and are threatening to sink it in 7 days with all 616 passengers and 327 crew members unless their demands are met. A million dollars in small unmarked bills, and a GPL implementation of WATFIV, that is, the esteemed Waterloo Fortran IV compiler. One of the benefits of writing this article is that I get to put words into your mouth and you can't do a darn thing about it. If the team doesn't get along, we'll never be able to work together. And I know a few superstar programmers who could crank out a Fortran compiler by themselves in one week, and lots of programmers who couldn't write the code to print the startup banner if they had six months." Everybody gives lip service to the idea that people are the most important part of a software project, but nobody is quite sure what you can do about it. The very first thing you have to do right if you want to have good programmers is to hire the right programmers, and that means you have to be able to figure out who the right programmers are, and this is usually done in the interview process. You know the kind of company that just has some salty old manager interview each candidate, and that decision is the only one that matters? These companies don't have very good people working there. It's too easy to fake out one interview, especially when a non-programmer interviews a programmer. If even two of the six interviewers thinks that a person is not worth hiring, don't hire them. That means you can technically end the "day" of interviews after the first two if the candidate is not going to be hired, which is not a bad idea, but to avoid cruelty you may not want to tell the candidate in advance how many people will be interviewing them. I have heard of companies that allow any interviewer to reject a candidate. I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn't like them. Don't try to interview a bunch of people at the same time. Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard. I can tell you from extensive experience that if you spend less than one hour on an interview you're not going to be able to make a decision. You're going to see three types of people in your interviews. At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by asking two or three quick questions. At the other extreme you've got your brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS. And in the middle, you have a large number of "maybes" who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don't want to hire any of the maybes. At the end of the interview, you must be prepared to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire. This is rude and implies that the candidate is not smart enough to work with you, but maybe he's smart enough for those losers over in that other team. If you find yourself tempted to say "Hire, but not in my team," simply translate that mechanically to "No Hire" and you'll be OK. Even if you have a candidate that would be brilliant at doing your particular task, but wouldn't be very good in another team, that's a No Hire. In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire. You'll solve some short term pain in exchange for a lot of long term pain. Mechanically translate all the waffling to "no" and you'll be all right. It's because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone. And they might be bad programmers but really nice people or maybe they really need this job, so you can't bear to fire them, or you can't fire them without pissing everybody off, or whatever. On the other hand, if you reject a good candidate, I mean, I guess in some existential sense an injustice has been done, but, hey, if they're so smart, don't worry, they'll get lots of good job offers. Don't be afraid that you're going to reject too many people and you won't be able to find anyone to hire. But once you're actually interviewing someone, pretend that you've got 900 more people lined up outside the door. Don't lower your standards no matter how hard it seems to find those great candidates. OK, I didn't tell you the most important part--how do you know whether to hire someone? You're looking for people who are 1 Smart, and 2 Get things done. You don't have enough time to figure out much more in a short interview, so don't waste time trying to figure out whether the candidate might be pleasant to be stuck in an airport with, or whether they really know ATL and COM programming or if they're just faking it. People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say, "Spreadsheets are really just a special case of programming language," and then go off for a week and write a thrilling, brilliant whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. The other way to identify these people is that they have a tendency to show up at your office, coffee mug in hand, and try to start a long conversation about the relative merits of Java introspection vs. COM type libraries, on the day you are trying to ship a beta. People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people's time. They are the kind of people who decide to refactor your core algorithms to use the Visitor Pattern, which they just read about the night before, and completely misunderstood, and instead of simple loops adding up items in an array you've got an AdderVistior class (yes, it's spelled wrong) and a VisitationArrangingOfficer singleton and none of your code works any more. The first good sign is that you don't have to explain things over and over again. Often, the candidate says something that shows real insight, or brains, or mental acuity. So an important part of the interview is creating a situation where someone can show you how smart they are. That's the kind who blabs the whole time and barely leaves the candidate time to say, "yes, that's so true, I couldn't agree with you more." they think that the candidate must be smart because "he thinks so much like me!" The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means "knows a lot of facts." They just ask a bunch of trivia questions about programming and give points for correct answers. Just for fun, here is the worst interview question on Earth: "What's the difference between varchar and varchar2 in Oracle 8i?" There is no possible...