4 ms·

Sadly, some recruiters are looking for a cog to fill a specific hole, and they do not want someone more experienced or better than what they're looking for (ie.

Sadly, some recruiters are looking for a cog to fill a specific hole, and they do not want someone more experienced or better than what they're looking for (ie. they dont want the Einstein, they just want a math teacher). The salary would also reflect that they are specifically looking for a cog. It's best that you didn't get that position.

sangnoir 5y ago
I disagree - they didn't ask GP because they wanted to gauge their interest in programing - they asked that question because they wanted to figure out what kind of colleague they would be, and if their experiences would mark them as more suitable for role compared to other candidates. GP's answer was probably from the left field (for them) - put yourself in their shoes: how would you gain insight into gauging their suitability for "cog" work based on completely unrelated hobbies? Always keep this in mind at the back of your mind when interviewing - your answers have to relate to the job you're interviewing for in some shape or form, hopefully in a good way. I'm guessing the interview wasn't at a kernel, embedded devices or compiler companies - those would have dug into GP's projects in detail, with enthusiasm. GP would still be cog there, obviously.
- TeMPOraL 5y ago
  > put yourself in their shoes: how would you gain insight into gauging their suitability for "cog" work based on completely unrelated hobbies? This is the core disagreement though: to 'ajxs, me, and many other commenters here, these aren't unrelated hobbies. Software engineering can't be neatly demarked along the lines of programming languages or frameworks. These are just the tip of an iceberg (and most of them are just flavors of the same thing, solving the same underlying problems). You don't just write a OS kernel and become experienced in kernel development. These kinds of projects, done on the side, with no deadline pressure forcing you to do a half-assed, minimum-effort job, allow you to gain more generalized, holistic understanding, that's very much transferable into just about any kind of programming job you could do. > your answers have to relate to the job you're interviewing for in some shape or form, hopefully in a good way That's a very good point. Myself, when talking about my seemingly unrelated side projects, I consider it my responsibility to show how they connect to their domain and skills they look for.
- ajxs 5y ago
  There's a lot of truth in this comment. Being able to gauge the interest of the people you're presenting to, and adjusting accordingly, is obviously going to benefit you in any situation too. It's a good idea to focus on keeping things relevant. In my defense, in this case the instructions were very open ended. They wanted projects I was particularly proud of, and left the scope very wide. Regarding gauging my suitability for "cog" work: Without wanting to sound arrogant, I don't think it's really that remarkable a feat to memorise the semantics of modern enterprise tools (maybe only a great feat of patience). I can't imagine why anyone would want to hear about all the ORMs I've used, or what Java/Python/Node/<insert tech here> libraries I've used over the years. That stuff is already in my resume. I think it's probably a better wager to risk boring the person looking to hear all about which new Java features you've used, rather than to risk boring the interviewer looking for genuinely interesting passion projects.
  - sangnoir 5y ago
    > Regarding gauging my suitability for "cog" work: Without wanting to sound arrogant, I don't think it's really that remarkable a feat to memorise the semantics of modern enterprise tools That is not arrogant at all. However, I think there is room for pride in enterprise projects beyond memorizing specific libs. You can be proud of turning out a solution under pressure, or solving a seemingly-intractable problem creatively, or even a technically simple solution that improved your/user's lives. One of the most high-impact things I've done in my career was to implement a CSV export feature in an afternoon, without being prompted, saving my colleagues many hours of work per week - they were delighted and I'm yet to tip that. Interviewers are not always looking to be dazzled by technical brilliance (which is a plus), but you can show many other attributes: grit, patience, creativity, curiosity. I think your side-projects exhibit all 4 attributes, but interviewers are fallible, and it's your role to figure out which attributes are desirable for the role and weave them into your answers.

sangnoir 5y ago

I disagree - they didn't ask GP because they wanted to gauge their interest in programing - they asked that question because they wanted to figure out what kind of colleague they would be, and if their experiences would mark them as more suitable for role compared to other candidates. GP's answer was probably from the left field (for them) - put yourself in their shoes: how would you gain insight into gauging their suitability for "cog" work based on completely unrelated hobbies? Always keep this in mind at the back of your mind when interviewing - your answers have to relate to the job you're interviewing for in some shape or form, hopefully in a good way. I'm guessing the interview wasn't at a kernel, embedded devices or compiler companies - those would have dug into GP's projects in detail, with enthusiasm. GP would still be cog there, obviously.

TeMPOraL 5y ago
> put yourself in their shoes: how would you gain insight into gauging their suitability for "cog" work based on completely unrelated hobbies? This is the core disagreement though: to 'ajxs, me, and many other commenters here, these aren't unrelated hobbies. Software engineering can't be neatly demarked along the lines of programming languages or frameworks. These are just the tip of an iceberg (and most of them are just flavors of the same thing, solving the same underlying problems). You don't just write a OS kernel and become experienced in kernel development. These kinds of projects, done on the side, with no deadline pressure forcing you to do a half-assed, minimum-effort job, allow you to gain more generalized, holistic understanding, that's very much transferable into just about any kind of programming job you could do. > your answers have to relate to the job you're interviewing for in some shape or form, hopefully in a good way That's a very good point. Myself, when talking about my seemingly unrelated side projects, I consider it my responsibility to show how they connect to their domain and skills they look for.
ajxs 5y ago
There's a lot of truth in this comment. Being able to gauge the interest of the people you're presenting to, and adjusting accordingly, is obviously going to benefit you in any situation too. It's a good idea to focus on keeping things relevant. In my defense, in this case the instructions were very open ended. They wanted projects I was particularly proud of, and left the scope very wide. Regarding gauging my suitability for "cog" work: Without wanting to sound arrogant, I don't think it's really that remarkable a feat to memorise the semantics of modern enterprise tools (maybe only a great feat of patience). I can't imagine why anyone would want to hear about all the ORMs I've used, or what Java/Python/Node/<insert tech here> libraries I've used over the years. That stuff is already in my resume. I think it's probably a better wager to risk boring the person looking to hear all about which new Java features you've used, rather than to risk boring the interviewer looking for genuinely interesting passion projects.
- sangnoir 5y ago
  > Regarding gauging my suitability for "cog" work: Without wanting to sound arrogant, I don't think it's really that remarkable a feat to memorise the semantics of modern enterprise tools That is not arrogant at all. However, I think there is room for pride in enterprise projects beyond memorizing specific libs. You can be proud of turning out a solution under pressure, or solving a seemingly-intractable problem creatively, or even a technically simple solution that improved your/user's lives. One of the most high-impact things I've done in my career was to implement a CSV export feature in an afternoon, without being prompted, saving my colleagues many hours of work per week - they were delighted and I'm yet to tip that. Interviewers are not always looking to be dazzled by technical brilliance (which is a plus), but you can show many other attributes: grit, patience, creativity, curiosity. I think your side-projects exhibit all 4 attributes, but interviewers are fallible, and it's your role to figure out which attributes are desirable for the role and weave them into your answers.