I think what someone hiring looks for is what they value. You have no idea what that is until you're in the interview. So, don't put it all on your shoulders and what you do. Some critical things are beyond your control, and aren't any personal shortcoming per se.
I have enough experience that the interview is really about them. They want to hire someone who fits their culture, their expectations, their team. If you don't match those, it really doesn't matter what you code, or what you have on GitHub. I suggest that those things simply reveal the culture bias of the company. Think about it. Those who publish a lot on their GitHub have deep feelings about a candidate who does the same thing. Same for CocoaPods. Same for certain frameworks. These things have absolutely nothing to do with comprehensive skill. Let me explain. I've worked with guys who were code jam maniacs. But I've also seen those same guys living in a never-ending world of dozens of critical bugs inside the tanker-sized cargo hold of a code maze they've created. They ship unstable products. They are constantly talking to support. They have many fire drill fix sessions for big customers. But these same guys look like geniuses in live-coding exercises. I'm not saying *ALL* live-coding guys are like that. I'm just saying live-coding does not adequately tell you what kind of products you will be getting from that developer. Skills like planning, scaling, architecture, simplicity, usability, all have as much real world value, if not more. I've got a problem with GitHub as a major hiring indicator. Github tells you how involved a developer is with the community, not what their abilities are. I find myself using the word "pretentious" a lot, when I see bad Github examples. Others I see are quite brilliant. I've seen GitHub projects that are wildly popular, but the whole premises of the project is complete garbage. You should consider that someone's best work may be under a company copyright or patent, and literally can't post on GitHub. I think Justin is right. I'd take a look at those things, but I'm looking for red flags more than green ones. I really liked what Sean said about the interview. If someone did the actual work, they will have no trouble telling you the details of what they did. I also don't like giving people technical gotcha questions. "Basic knowledge" questions are a baseline. They can't possibly know everything. Some of the best people I've ever hired had curiosity of what they didn't know. They could learn anything. Their eventual project code worked! To the interviewer/owner, I'd say your hiring a business solution first, a developer second. If your products suck, and you need change, why hire more of the same kinds of developers? Why have your failing team picking someone just like them? You likely have to shake things up. To the interviewee, I'd say, be totally honest, and consider if you are going to be happy, and grow with the company you are talking to. Trust your gut, too. If you are miserable, you would have been better off somewhere else. Often times, you are interviewing for a position that someone else has left. Maybe it was a dead end, or the projects were a coding mess, the company treats people poorly, and they moved on. Just because you aren't picked, doesn't mean you are not a good developer. You may have just avoided a career nightmare. That's a good thing. -- Cole Joplin Quoting Justin Carmony <[email protected]>: > If a person lists a github account, blog, project, etc I will always > take a look at it. > > Justin > > -- > Justin Carmony > Sent with Airmail > > On May 20, 2014 at 12:28:07 PM, Ken Snyder ([email protected]) wrote: > > Always. Online portfolios and GitHub accounts are a great resource for > judging programming skills before a phone screening. > > In the interview(s) you do have to drill down to tease out exactly what > they did in that project. > > The real test of skills, though, ultimately comes down to how you answer > the knowledge questions and perform on the live-coding exercises in the > interview. I've conducted about 30 interviews in the last 5 years and it is > really surprising how many people have impressive stories of stuff they've > worked on but do poorly at basic knowledge questions or simple coding > exercises. > > But yes, visiting links is one of the three things I do as part of > reviewing each resume: > > 1. Look through your GitHub account > 2. Visit any links you provide > 3. Review your LinkedIn profile > > > - Ken > > > > On Tue, May 20, 2014 at 11:45 AM, Kevin Jensen <[email protected]> wrote: > >> Question for those of you that hire—when you are looking through resumes, >> CVs and portfolios, how often do you *actually* look up a web link? >> >> By that I mean, if I list a url on my resume to my portfolio or landing >> page, would you take the time to look it up? >> >> Thanks in advance! >> >> _______________________________________________ >> >> UPHPU mailing list >> [email protected] >> http://uphpu.org/mailman/listinfo/uphpu >> IRC: #uphpu on irc.freenode.net > > _______________________________________________ > > UPHPU mailing list > [email protected] > http://uphpu.org/mailman/listinfo/uphpu > IRC: #uphpu on irc.freenode.net > > _______________________________________________ > > UPHPU mailing list > [email protected] > http://uphpu.org/mailman/listinfo/uphpu > IRC: #uphpu on irc.freenode.net _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
