3 ms·

> If your company wants to see side projects but dislikes the idea of you actually working on them after starting, you are doing something wrong. My impression

> If your company wants to see side projects but dislikes the idea of you actually working on them after starting, you are doing something wrong. My impression was they generally want to see side projects for newbies/recent graduates, i.e. stuff the applicant would have been working on during college or something. Not stuff the applicant was doing on the "side" during his/her previous years of employment. Am I totally wrong here?

dvcrn 10y ago
> Not stuff the applicant was doing on the "side" during his/her previous years of employment. Am I totally wrong here? Hmm, the way I see it is that side projects usually demonstrate that you have a passion for code outside of your work as well. From a company perspective I would probably also hire someone who is using his free time to advance his knowledge since some of that stuff he is using/learning could also become useful for the company at some point. I personally don't mean any harm with my projects. I just really like coding, creating things and learning more (my way of learning also being to experiment/build something with technology X). The field is so broad and there are so many interesting things to learn about with new ones getting released almost weekly.
- TAForObvReasons 10y ago
  > side projects usually demonstrate that you have a passion for code outside of your work In other industries, these are called "portfolios" or "writing samples". It's not just about showing a passion; it's your chance to make a piece of work that represents your best abilities and judgments. When I interview candidates I find it easier and more constructive to ask design questions about the side projects than to contrive some hypothetical scenario. IMHO the alternative, where you ask people to write code under the pressure of an interview setting, is far less informative.
  - dasil003 10y ago
    I know what you mean, but it's also easier to fake. I've definitely run into the situation where someone's projects look good, but then they are terrible on the job. I'm left to conclude they were pairing with someone more knowledgeable or cloning some idea or maybe has spent years preparing to tackle that one problem and are not good in general problem solving. Not saying you won't get a lot of false negatives with high-pressure on-site coding or whiteboarding, but if done correctly I think it's probably the most signal you can get for the least time. Granted it requires good judgement from the interviewer, and a lot of candidates to calibrate. It's also unfair to candidates who are easily rattled, and biased towards candidates who have time to do a lot of preparation. In the past I have preferred contract-to-hire as the gold standard if that works for a candidate, but that only works if the pipeline is small.
    - dj-wonk 10y ago
      I also think that contract-to-hire is a good option to consider. Vetting a small, unknown company requires time and effort.
____nope 10y ago
It probably depends on the company but I think this is right. If I interview someone with little working experience it definitely helps that they have some work on Github. But it would be strange to reject a senior candidate with a great resume who did very well in the technical interview just because they didn't have anything on Github.
dasil003 10y ago
Anecdata: I'm currently in the middle of interviewing with a wide slate of mid-size SV companies, and not one has asked for code samples. It's all a mix of whiteboarding, on-site coding, phone-screen coding, or take-home coding. So at least for 15-year veterans it does not really seem to be much of a thing. Although I do secretly wish they would discover my 4-digit GitHub user id, that's gotta be worth some kinda programmer-cred right?

dvcrn 10y ago

> Not stuff the applicant was doing on the "side" during his/her previous years of employment. Am I totally wrong here? Hmm, the way I see it is that side projects usually demonstrate that you have a passion for code outside of your work as well. From a company perspective I would probably also hire someone who is using his free time to advance his knowledge since some of that stuff he is using/learning could also become useful for the company at some point. I personally don't mean any harm with my projects. I just really like coding, creating things and learning more (my way of learning also being to experiment/build something with technology X). The field is so broad and there are so many interesting things to learn about with new ones getting released almost weekly.

TAForObvReasons 10y ago
> side projects usually demonstrate that you have a passion for code outside of your work In other industries, these are called "portfolios" or "writing samples". It's not just about showing a passion; it's your chance to make a piece of work that represents your best abilities and judgments. When I interview candidates I find it easier and more constructive to ask design questions about the side projects than to contrive some hypothetical scenario. IMHO the alternative, where you ask people to write code under the pressure of an interview setting, is far less informative.
- dasil003 10y ago
  I know what you mean, but it's also easier to fake. I've definitely run into the situation where someone's projects look good, but then they are terrible on the job. I'm left to conclude they were pairing with someone more knowledgeable or cloning some idea or maybe has spent years preparing to tackle that one problem and are not good in general problem solving. Not saying you won't get a lot of false negatives with high-pressure on-site coding or whiteboarding, but if done correctly I think it's probably the most signal you can get for the least time. Granted it requires good judgement from the interviewer, and a lot of candidates to calibrate. It's also unfair to candidates who are easily rattled, and biased towards candidates who have time to do a lot of preparation. In the past I have preferred contract-to-hire as the gold standard if that works for a candidate, but that only works if the pipeline is small.
  - dj-wonk 10y ago
    I also think that contract-to-hire is a good option to consider. Vetting a small, unknown company requires time and effort.

____nope 10y ago

It probably depends on the company but I think this is right. If I interview someone with little working experience it definitely helps that they have some work on Github. But it would be strange to reject a senior candidate with a great resume who did very well in the technical interview just because they didn't have anything on Github.

dasil003 10y ago

Anecdata: I'm currently in the middle of interviewing with a wide slate of mid-size SV companies, and not one has asked for code samples. It's all a mix of whiteboarding, on-site coding, phone-screen coding, or take-home coding. So at least for 15-year veterans it does not really seem to be much of a thing. Although I do secretly wish they would discover my 4-digit GitHub user id, that's gotta be worth some kinda programmer-cred right?