6 ms·

I don't disregard them completely and I think CVs can be written in such a way that recruiters (who actually get very excited about such stuff these days) and H

I don't disregard them completely and I think CVs can be written in such a way that recruiters (who actually get very excited about such stuff these days) and HR people will be fine with this sort of thing. What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do. All that said, I deal in corporate style CRUD apps (there is a bit more to it that that but that's the core). That's an area where OSS - the best sort of out of work project as it's team based, real world and so on - isn't that active so it's not a consideration I have to make too often.

talmand 12y ago
What I get out of that first statement is that you do tend to disregard unless the candidate knows exactly how to describe the related subjects on their CV in a way that makes you happy. And you don't see the problem that developers might have with that? Especially when they don't know the secret method of describing things to make recruiters happy? As for the rest, I think it's reasonable to assume that a candidate with commercial experience will favor over hobby experience. I'm sure there are plenty of examples of where that doesn't hold true, but I suppose it's a decent rule.
- DigitalJack 12y ago
  The GP is giving helpful advice here. It takes stages to get to the people who will have some idea if your side project is really something or a bit of fluff. Recruiters don't have the experience to know, so it is your job to help them out with your CV. They are looking at many applicants and can't research them in depth and get through the stack at the same time. I believe this is essentially true for hiring managers as well, although they will probably be able to tell fluff from something interesting, they won't have the time to do it. And it will reflect poorly on you if you aren't willing to work your CV for relevance to the job. When you get through those gates to a peer interview, you can talk up your side projects all you want, and these are the people who might look at it and incorporate it in their decision making.
  - talmand 12y ago
    It is helpful advice, to get a job from that recruiter. But what I'm saying is that this is an example of the games that job seekers have to play with different recruiters that have their own methods and agendas. It's also possibly a difference between Europe and United States hiring methods, which could be a misunderstanding on my part. But you've mentioned part of the problem, "Recruiters don't have the experience to know", therefore there is an issue with some recruiters being the gatekeepers. Especially when they state things that imply if you didn't explain things in the magic way that they want to read it then they'll pass on your resume. That's my issue. It's one thing to say "please phrase your experience in simple terms for a non-technical person might be able to understand and can easily use as a basis for research" as opposed to "write it the way I like it or I may disregard". It's not as bad as the guy who throws out resumes stating he doesn't hire unlucky people, but it is a problem. After all, if someone writes that they have AngularJS experience and the recruiter can't be bothered to think "I don't know what that is, maybe I should look on Google" then there's a problem. I'm not saying that the recruiter in this thread is that person, but does seem to have something close to that mindset. Which, I feel the need to point out, I've personally never had a bad experience with a recruiter nor hiring manager. I'm not sure if that means that this problem that crops up quite frequently in the community is not that big a deal as it seems or I'm just lucky. I've also been on the hiring side of the table. It's just my personal experience and it may or may not mean anything to the discussion.
    - DigitalJack 12y ago
      There is nothing magic about it. It's common sense. You first make it through a basic keyword search, then someone sifts through those results for basic relevancy, then you get an interview. You are the one seeking something here, lost in a pile of other seekers. Why wouldn't you do everything you could to make it easy for the person looking at your CV to pass it on to the next stage of vetting. Why would someone bother googling some obscure reference on your resume when they have dozens or hundreds of others that fit the bill? The key is learning what it takes, in general, to get to the next stage. While there are always horror stories about oddball reasons for not getting selected, they aren't the norm. Understand the job you are going for, understand the expertise and expectations at the different stages, and you'll do fine. It is basically a numbers game at that point.
- Tyrannosaurs 12y ago
  I think it's OTT describing it as a secret. If a job spec lists a skill, highlight where you've used it so I can see your experience. That's not difficult or counter intuitive or unreasonable. Realistically I can't interview everyone and it wouldn't be in anyone's interest to do so. The current stats I have say I will first interview one in four screened CVs. Out of those about one in three will get a second interview and half of those an offer. So I interview maybe half a dozen people per appointment from about 25 CVs). That means right now if you give up an hour of your time for a first interview (plus travel and so on), you've got a one in six chance of getting a job. If I interviewed more people, your chances go down. I may end up with a better recruit but I'm actually externalising a lot of the costs to the other candidates who don't get the role.
  - talmand 12y ago
    I'm not disagreeing with your first point. As for interviewing people after the first selection round based off of resumes; that's a totally different situation and I can't say I disagree with your viewpoint.
vinceguidry 12y ago
I do agree with you RE: hobby code. I did a jQuery Facebook app for fun, but the one-off weather app I built for a major utility company was and should have been way more impressive even though I did the hobby project after the weather app with all the lessons I'd learned about Javascript from the one I got paid for. Ultimately this is why I don't take any of my side projects seriously anymore, and if there's something I want to learn, I'll find a way to get paid for it. That way I can figure out where it fits in the ecosystem of working with other professionals to deliver production code that fits specs and actual business needs. I still have side projects, I just use them to scratch an itch rather than to try to conjure something truly useful to someone out of thin air.
- dasboth 12y ago
  "if there's something I want to learn, I'll find a way to get paid for it" - I'm intrigued, can you give an example?
  - vinceguidry 12y ago
    Say it's something like Angular, I'll just use it on my next front-end project. When I wanted a better provisioning scheme, I built it for my employer. I sold my boss on the benefits of automated provisioning, and created a system for doing it. When I started reading object-oriented design literature, I immediately started implementing it in my next project. I didn't even need buy-in because they don't and can't see anything but the fact that everything is more flexible and modular. When I wanted to learn how to do TDD, I first sold it to my boss, and when he saw how powerful an idea it is, said to go all in with it. I got him to buy a book and the Destroy All Software screencasts. Basically, whatever the business you work for needs, find a way to deliver it in a way that scratches your learning itch. Side projects for me have been relegated to just exploring new domains, with technologies I already know well. When I'm having fun on the weekend, I don't want to get hung up on high-friction, high-buy-in paradigm shifting. I just want to have fun and focus on gathering insight.
- opendais 12y ago
  That doesn't work in the real world for most people. At my Day Job, I use Language X with version Y for everything. I use Library Z and T only. Oh, and I can use ancient language B as well but I cannot use any 3rd party code with B. You will use version control method G. Any attempt to deviate from that is not permitted because it leads to compatibility issues with the rest of the codebase & it reduces the ability of other programmers to work efficiently on it. I suspect many programmers operate under similar restrictions.
crdoconnor 12y ago
>What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do. Yeah, the difference is that hobby code means that you can take the time to do it right and "commercial contexts" (aka coding in a rush) means that you can't so you never learn how to do it properly.
opendais 12y ago
> What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do. 1) If I can write a backend integration for some well known property (say, Amazon) as a hobby in Language X. 2) If I can show I can write backend integrations for some well known standard (say, EDI) in Language Y at my Day Job. The idea I could write a backend integration for some API in Language X at a new job in situations where I don't control the requirements, etc. is quite reasonable. "Commercial experience" is really managing expectations and timelines to make it clear what you can/cannot do. It doesn't magically make the choice of X vs. Y a significant difference if you are experienced enough in both to produce functional projects. Tbh, I'd be more worried about domain knowledge (How well does the programmer understand accounting?) than I would be about whether the programming language is X or Y is the one they use at their day job. The quality of code isn't going to massively change because a different language is used. You aren't going to know the quality of code from their Day Job anyway, for all you know its unsustainable crap and they are trying to bail before their boss realizes it. At least with a hobby project you can check the basic boxes like "Does this person like OOP vs. functional programming?". The most that would change is how often the Dev would need to refer to the documentation and honestly, for anything that matters, that is going to happen alot anyway since no one wants to write something moving 5-6 figures a day worth of product without double checking everything first. If you aren't building something that handles that kind of value, the bar makes even less sense since you aren't worried about them screwing up language specific edge cases that might cost you more than their paycheck if it goes unnoticed for an hour. If anything, it seems to me this is testing for the absolute opposite of what you'd want to test for. Sure, it'll work if the other measures are good...but communication ability + domain knowledge + ability to write code in Language X is what is required. Caring about whether or not Language X is or is not a hobby language...isn't testing for anything relevant to the job if they've had programming jobs before.

talmand 12y ago

What I get out of that first statement is that you do tend to disregard unless the candidate knows exactly how to describe the related subjects on their CV in a way that makes you happy. And you don't see the problem that developers might have with that? Especially when they don't know the secret method of describing things to make recruiters happy? As for the rest, I think it's reasonable to assume that a candidate with commercial experience will favor over hobby experience. I'm sure there are plenty of examples of where that doesn't hold true, but I suppose it's a decent rule.

DigitalJack 12y ago
The GP is giving helpful advice here. It takes stages to get to the people who will have some idea if your side project is really something or a bit of fluff. Recruiters don't have the experience to know, so it is your job to help them out with your CV. They are looking at many applicants and can't research them in depth and get through the stack at the same time. I believe this is essentially true for hiring managers as well, although they will probably be able to tell fluff from something interesting, they won't have the time to do it. And it will reflect poorly on you if you aren't willing to work your CV for relevance to the job. When you get through those gates to a peer interview, you can talk up your side projects all you want, and these are the people who might look at it and incorporate it in their decision making.
- talmand 12y ago
  It is helpful advice, to get a job from that recruiter. But what I'm saying is that this is an example of the games that job seekers have to play with different recruiters that have their own methods and agendas. It's also possibly a difference between Europe and United States hiring methods, which could be a misunderstanding on my part. But you've mentioned part of the problem, "Recruiters don't have the experience to know", therefore there is an issue with some recruiters being the gatekeepers. Especially when they state things that imply if you didn't explain things in the magic way that they want to read it then they'll pass on your resume. That's my issue. It's one thing to say "please phrase your experience in simple terms for a non-technical person might be able to understand and can easily use as a basis for research" as opposed to "write it the way I like it or I may disregard". It's not as bad as the guy who throws out resumes stating he doesn't hire unlucky people, but it is a problem. After all, if someone writes that they have AngularJS experience and the recruiter can't be bothered to think "I don't know what that is, maybe I should look on Google" then there's a problem. I'm not saying that the recruiter in this thread is that person, but does seem to have something close to that mindset. Which, I feel the need to point out, I've personally never had a bad experience with a recruiter nor hiring manager. I'm not sure if that means that this problem that crops up quite frequently in the community is not that big a deal as it seems or I'm just lucky. I've also been on the hiring side of the table. It's just my personal experience and it may or may not mean anything to the discussion.
  - DigitalJack 12y ago
    There is nothing magic about it. It's common sense. You first make it through a basic keyword search, then someone sifts through those results for basic relevancy, then you get an interview. You are the one seeking something here, lost in a pile of other seekers. Why wouldn't you do everything you could to make it easy for the person looking at your CV to pass it on to the next stage of vetting. Why would someone bother googling some obscure reference on your resume when they have dozens or hundreds of others that fit the bill? The key is learning what it takes, in general, to get to the next stage. While there are always horror stories about oddball reasons for not getting selected, they aren't the norm. Understand the job you are going for, understand the expertise and expectations at the different stages, and you'll do fine. It is basically a numbers game at that point.
Tyrannosaurs 12y ago
I think it's OTT describing it as a secret. If a job spec lists a skill, highlight where you've used it so I can see your experience. That's not difficult or counter intuitive or unreasonable. Realistically I can't interview everyone and it wouldn't be in anyone's interest to do so. The current stats I have say I will first interview one in four screened CVs. Out of those about one in three will get a second interview and half of those an offer. So I interview maybe half a dozen people per appointment from about 25 CVs). That means right now if you give up an hour of your time for a first interview (plus travel and so on), you've got a one in six chance of getting a job. If I interviewed more people, your chances go down. I may end up with a better recruit but I'm actually externalising a lot of the costs to the other candidates who don't get the role.
- talmand 12y ago
  I'm not disagreeing with your first point. As for interviewing people after the first selection round based off of resumes; that's a totally different situation and I can't say I disagree with your viewpoint.

vinceguidry 12y ago

I do agree with you RE: hobby code. I did a jQuery Facebook app for fun, but the one-off weather app I built for a major utility company was and should have been way more impressive even though I did the hobby project after the weather app with all the lessons I'd learned about Javascript from the one I got paid for. Ultimately this is why I don't take any of my side projects seriously anymore, and if there's something I want to learn, I'll find a way to get paid for it. That way I can figure out where it fits in the ecosystem of working with other professionals to deliver production code that fits specs and actual business needs. I still have side projects, I just use them to scratch an itch rather than to try to conjure something truly useful to someone out of thin air.

dasboth 12y ago
"if there's something I want to learn, I'll find a way to get paid for it" - I'm intrigued, can you give an example?
- vinceguidry 12y ago
  Say it's something like Angular, I'll just use it on my next front-end project. When I wanted a better provisioning scheme, I built it for my employer. I sold my boss on the benefits of automated provisioning, and created a system for doing it. When I started reading object-oriented design literature, I immediately started implementing it in my next project. I didn't even need buy-in because they don't and can't see anything but the fact that everything is more flexible and modular. When I wanted to learn how to do TDD, I first sold it to my boss, and when he saw how powerful an idea it is, said to go all in with it. I got him to buy a book and the Destroy All Software screencasts. Basically, whatever the business you work for needs, find a way to deliver it in a way that scratches your learning itch. Side projects for me have been relegated to just exploring new domains, with technologies I already know well. When I'm having fun on the weekend, I don't want to get hung up on high-friction, high-buy-in paradigm shifting. I just want to have fun and focus on gathering insight.
opendais 12y ago
That doesn't work in the real world for most people. At my Day Job, I use Language X with version Y for everything. I use Library Z and T only. Oh, and I can use ancient language B as well but I cannot use any 3rd party code with B. You will use version control method G. Any attempt to deviate from that is not permitted because it leads to compatibility issues with the rest of the codebase & it reduces the ability of other programmers to work efficiently on it. I suspect many programmers operate under similar restrictions.

crdoconnor 12y ago

opendais 12y ago

> What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do. 1) If I can write a backend integration for some well known property (say, Amazon) as a hobby in Language X. 2) If I can show I can write backend integrations for some well known standard (say, EDI) in Language Y at my Day Job. The idea I could write a backend integration for some API in Language X at a new job in situations where I don't control the requirements, etc. is quite reasonable. "Commercial experience" is really managing expectations and timelines to make it clear what you can/cannot do. It doesn't magically make the choice of X vs. Y a significant difference if you are experienced enough in both to produce functional projects. Tbh, I'd be more worried about domain knowledge (How well does the programmer understand accounting?) than I would be about whether the programming language is X or Y is the one they use at their day job. The quality of code isn't going to massively change because a different language is used. You aren't going to know the quality of code from their Day Job anyway, for all you know its unsustainable crap and they are trying to bail before their boss realizes it. At least with a hobby project you can check the basic boxes like "Does this person like OOP vs. functional programming?". The most that would change is how often the Dev would need to refer to the documentation and honestly, for anything that matters, that is going to happen alot anyway since no one wants to write something moving 5-6 figures a day worth of product without double checking everything first. If you aren't building something that handles that kind of value, the bar makes even less sense since you aren't worried about them screwing up language specific edge cases that might cost you more than their paycheck if it goes unnoticed for an hour. If anything, it seems to me this is testing for the absolute opposite of what you'd want to test for. Sure, it'll work if the other measures are good...but communication ability + domain knowledge + ability to write code in Language X is what is required. Caring about whether or not Language X is or is not a hobby language...isn't testing for anything relevant to the job if they've had programming jobs before.