4 ms·

In my experience it was never a thing in the first place. I have quite a few non trivial and complete OSS projects on my GH, and in my 10+ year career as a SDE

In my experience it was never a thing in the first place. I have quite a few non trivial and complete OSS projects on my GH, and in my 10+ year career as a SDE no one has ever really looked at any of it. But they do frequently ask me to take their code challenge to prove I can program.

ChrisMarshallNY 4y ago
Yup. I have a huge GH portfolio[0]. Dozens of complete, soup-to-nuts, documented, tested, and in-use projects. I have complete source for shipping apps, backend frameworks, APIs, SDKs, communication libraries, UI widgets, teaching material (complete course modules), etc. I also have many personal blog entries, and online documentation for stuff; not to mention years of tags and commit history. No one ever looked at them. In fact, when I asked one interviewer, why they didn't bother looking at them, I was told "You probably faked it." Needless to say, that interview did not proceed any farther. [0] https://github.com/ChrisMarshallNY#browse-away https://github.com/ChrisMarshallNY#browse-away (NOTE: I just archived and retired a bunch of stuff, because I maintain what I publish; even if I am the only consumer. I dogfood most of my work).
- mike_hearn 4y ago
  Sadly they said that because it does happen. I hired someone on the back of their GitHub repo once. He talked me into it by saying he struggled to control nerves during coding interviews etc. Regretted it immediately - the code he wrote once he joined inexplicably bore no resemblance to what was in his repo. He also turned out to have a major attitude problem with the language we were actually working in, suggesting at one point that maybe he should be able to write his code in Common Lisp and then we should hire cheap Indians to rewrite it into our actual language. This sort of thing seems hard to detect unless you actually watch someone code. The stuff on his repo could have come from anywhere or anyone, really.
  - ChrisMarshallNY 4y ago
    > This sort of thing seems hard to detect This was not my experience. I never gave coding tests, and would have killed for a GH repo. I was a manager for 25 years, and we did pretty hairy C++ programming. What a code repo gives me, is a fulcrum for a discussion. I would never hire, based on a code repo, or a test. What I did hire on, was fairly long, casual conversations, where I drew the applicant out, and got them to talk about their work, problems they solved, and design decisions they made. A GH repo would give me an "in" for that. "I see that you wrote the firmware for an AI-powered cheese straightener. Tell me about how it came to be. ... Really? How did you solve that problem?" etc. A lot of the folks that I interviewed were not "people persons." I found that once we got into one of these conversations, they opened right up. Also, and this actually doesn't have much to do with my tech experience, I'm a pretty hard person to BS. One reason, is that I come across as a naive, credulous, person, and bulshitters can't seem to help themselves. They just have to try yanking my chain. It's kind of fun, actually.
    - mike_hearn 4y ago
      That's certainly a valid way to do things and in some contexts it can work. I've done it too for roles that weren't coding. It's hard to scale. People are very easily BSd in interviews without training. If you need to define a repeatable process that's fair (for a fast growing team), it's easier for people to objectively evaluate coding skills they've watched than to handle an open ended conversation. If you don't need that framework, super, that's a rare and useful skill. At the same company where I made aforementioned interviewing mistake, when I first joined they were in the process of interviewing a guy who billed himself as a high-flying consultant type. They were impressed and intended to offer. They asked me to meet him and ask some questions too, just as a last minute double check. He turned out to not actually have some of the most impressive sounding skills on his CV, in particular, he claimed to be an expert on the internals of HotSpot but when probed couldn't answer even basic questions of the sort you'd learn by reading the user manual. Several other claimed hard skills fell apart under direct questioning too. I got the sense that he had previously been talking about work and projects done whilst he was around, but not by himself. After that I put in place standardized coding tests. My managers continued to do the open ended interviews they'd been doing before. After six months or so we noticed that whilst the coding tests were selective i.e. we sometimes said no, the open ended interviews had never yielded a reject. They were pointless for both us and the candidate because the answer was always yes. When I sat down with the second stage interviewers, we went through some of the questions being asked and I posed a meta-question: what answers to this question would cause you to reject the candidate? They couldn't come up with any.
- akie 4y ago
  For what it's worth I always look at GitHub profiles if they are provided in the CV. I will disregard everything in your CV and won't even look at your cover letter if you provide a GitHub profile. The proof of the pudding is in the eating.
ska 4y ago
This isn’t universal. I’m happy to see candidates with nontrivial projects online. Or even better, contributions to larger projects. It’s a great source of questions about design decisions, technical details, etc. where you are letting the, start from something concrete they should be comfortable with.
nudpiedo 4y ago
That’s my experience too, even with long experience in the CV or referrals, they got a process to go through. It’s the interview illusion.

ChrisMarshallNY 4y ago

Yup. I have a huge GH portfolio[0]. Dozens of complete, soup-to-nuts, documented, tested, and in-use projects. I have complete source for shipping apps, backend frameworks, APIs, SDKs, communication libraries, UI widgets, teaching material (complete course modules), etc. I also have many personal blog entries, and online documentation for stuff; not to mention years of tags and commit history. No one ever looked at them. In fact, when I asked one interviewer, why they didn't bother looking at them, I was told "You probably faked it." Needless to say, that interview did not proceed any farther. [0] https://github.com/ChrisMarshallNY#browse-away https://github.com/ChrisMarshallNY#browse-away (NOTE: I just archived and retired a bunch of stuff, because I maintain what I publish; even if I am the only consumer. I dogfood most of my work).

mike_hearn 4y ago
Sadly they said that because it does happen. I hired someone on the back of their GitHub repo once. He talked me into it by saying he struggled to control nerves during coding interviews etc. Regretted it immediately - the code he wrote once he joined inexplicably bore no resemblance to what was in his repo. He also turned out to have a major attitude problem with the language we were actually working in, suggesting at one point that maybe he should be able to write his code in Common Lisp and then we should hire cheap Indians to rewrite it into our actual language. This sort of thing seems hard to detect unless you actually watch someone code. The stuff on his repo could have come from anywhere or anyone, really.
- ChrisMarshallNY 4y ago
  > This sort of thing seems hard to detect This was not my experience. I never gave coding tests, and would have killed for a GH repo. I was a manager for 25 years, and we did pretty hairy C++ programming. What a code repo gives me, is a fulcrum for a discussion. I would never hire, based on a code repo, or a test. What I did hire on, was fairly long, casual conversations, where I drew the applicant out, and got them to talk about their work, problems they solved, and design decisions they made. A GH repo would give me an "in" for that. "I see that you wrote the firmware for an AI-powered cheese straightener. Tell me about how it came to be. ... Really? How did you solve that problem?" etc. A lot of the folks that I interviewed were not "people persons." I found that once we got into one of these conversations, they opened right up. Also, and this actually doesn't have much to do with my tech experience, I'm a pretty hard person to BS. One reason, is that I come across as a naive, credulous, person, and bulshitters can't seem to help themselves. They just have to try yanking my chain. It's kind of fun, actually.
  - mike_hearn 4y ago
    That's certainly a valid way to do things and in some contexts it can work. I've done it too for roles that weren't coding. It's hard to scale. People are very easily BSd in interviews without training. If you need to define a repeatable process that's fair (for a fast growing team), it's easier for people to objectively evaluate coding skills they've watched than to handle an open ended conversation. If you don't need that framework, super, that's a rare and useful skill. At the same company where I made aforementioned interviewing mistake, when I first joined they were in the process of interviewing a guy who billed himself as a high-flying consultant type. They were impressed and intended to offer. They asked me to meet him and ask some questions too, just as a last minute double check. He turned out to not actually have some of the most impressive sounding skills on his CV, in particular, he claimed to be an expert on the internals of HotSpot but when probed couldn't answer even basic questions of the sort you'd learn by reading the user manual. Several other claimed hard skills fell apart under direct questioning too. I got the sense that he had previously been talking about work and projects done whilst he was around, but not by himself. After that I put in place standardized coding tests. My managers continued to do the open ended interviews they'd been doing before. After six months or so we noticed that whilst the coding tests were selective i.e. we sometimes said no, the open ended interviews had never yielded a reject. They were pointless for both us and the candidate because the answer was always yes. When I sat down with the second stage interviewers, we went through some of the questions being asked and I posed a meta-question: what answers to this question would cause you to reject the candidate? They couldn't come up with any.
akie 4y ago
For what it's worth I always look at GitHub profiles if they are provided in the CV. I will disregard everything in your CV and won't even look at your cover letter if you provide a GitHub profile. The proof of the pudding is in the eating.

ska 4y ago

This isn’t universal. I’m happy to see candidates with nontrivial projects online. Or even better, contributions to larger projects. It’s a great source of questions about design decisions, technical details, etc. where you are letting the, start from something concrete they should be comfortable with.

nudpiedo 4y ago

That’s my experience too, even with long experience in the CV or referrals, they got a process to go through. It’s the interview illusion.