Just tinker with Elm at work on your lunchbreak and say you uswd it at work. If you're awesome, no one will know and/or care where you picked up your awesomeness.
Please don't do this. If you're not found out in the interview, you'll be found out on the job eventually due to your obvious lack of experience. Some of my most personally loathed coworkers have been people who have bullshitted their way into positions by claiming skills they don't have or aren't qualified in, making them a nightmare to work with.
Good developers should be able to pick up new technologies on the job though. And you are conducting interviews in such a way as to select for good developers, right? To the extent that that's possible anyway?
I'd rather just hire for good developers in general who are interested in working in Elm than to hire only for Elm experience. As you've pointed out, there are problems in doing the latter.
Yep, I'd rather take the person who says "I've never worked with Elm but I've heard it does X, Y, and Z well because those are things I've always found lacking in [insert JS framework here]" or even "I've never heard of Elm, but based on your description it sounds like it might mitigate X, Y, and Z problems because of [reasons], cool!"; over the person who says they've used Elm before but gives vague answers to follow-up questions (even if they aren't lying and have actually used it).
This can get really messy. Using it on your job, creates a one-off orphan that no one knows how it works. Then I've seen a number of people claim they used it but didn't
I've also found this as a partial negative. Positive you took initiative, and want to learn. Negative you've now written a product that only you can maintain, and doesn't listen well.
I go down the honest path. Of I did a proof of concept, or scratch project in this language. But didn't get the buy in from the rest of the team. Which sometimes leads to why am I not good at sailing new technologies.
Aside, at least my side projects can be pushed to Github. I feel like committing to publishing a repo is the only reason I even finish anything, like writing a solid README, stubbing out a few issues, and then eventually closing them.
I never know if someone has seen my repositories but it's been invaluable to have projects I can confidently link to. Until I got to that point, I remember an anxiety of "gee, I sure hope they take my word for my skills." Talk about imposter syndrome.
But yeah, I agree with what you were trying to say. Whether you are honestly representing your skill level doesn't have much to do with whether your experience was paid or done in free-time.
The aspects in which they differ are numerous and substantial. If a candidate expressed the sentiment that they are the same in an interview, I would not take them seriously since it would indicate that they are either ignorant or naive, and either apathetic about work, or likely to favor personal coding pursuits over the job they're applying for.
And you've managed to try your best to denigrate me without actually stating any of the reasoning. If you would, try again, but hopefully without the ineffective sense of superiority.
* Technical failure in a professional setting can lead to loss of your source of income and therefore, in the worst case scenario: loss of access to food, shelter, comfort and other basic life necessities. Failure at a personal project has no such comparable consequences. Techniques to minimize failure are quite literally a matter of survival in a professional context; they are often an afterthought in a personal project. Fault prevention and tolerance are often the most difficult characteristics to achieve in any sufficiently complex software system, and their prioritization or lack thereof has an enormous impact on virtually every aspect of working on such a system.
* In a professional setting, you often have little choice of who you work with. Therefore the technical choices you make in a professional setting must take into account the possibility that the next person who works on your project may be someone who does not understand, like, or care about the way you do things, and that the way they interact with your work may have significant negative repercussions for both you and the project. This is often a tedious, difficult, and time-consuming task that requires different techniques and approaches than one would use when working on a personal project. Conversely, in a professional setting you will also inherit the work of others which may be done in ways you don't understand, like, or care about, with few or no options to change those ways, and you must develop and adopt technical strategies to deal with this as well.
* Documentation, readability, and testing take much more precedence in a professional setting since they serve as guardrails for the long-term integrity of your work as it gets passed on to others to maintain and expand.
* Working with others also requires agreement, and usually mutual compromise, on basic standards, conventions, and processes that can significantly affect your daily workflow and may greatly differ from how you would work on a personal project.
* The end goal of personal projects is usually personal enjoyment, satisfaction, and learning. The end goal of the vast majority of professional projects is to generate revenue, or otherwise serve some need that your employer deems sufficiently important to fulfill by compensating you. The intersection of techniques that are personally appealing to you and the ones that will generate value for your employer may be very small or nonexistent much of the time.
* Your employer may not care about letting technical debt pile up indefinitely as long as you can keep cranking out new features and meeting deadlines, code quality be damned. Alternatively, your employer may impose onerous processes to ensure code quality and integrity that aren't really necessary or effective, and which may even be counterproductive. In fact, there's a good chance your employer will understand very little about what you do at all and make demands that are incongruent with technical realities, which you must deal with, sometimes by performing pointless tasks solely to appease them.
* Personal projects are usually started from scratch, and often dropped or 'completed' once they reach a certain level of complexity, due to the increased level of difficulty brought on by said complexity. Rarely does one have the luxury of dropping projects on a whim for such reasons in a professional context. In general, working in a professional context often involves dealing with a lot more annoying complexity and thorny problems that simply cannot be ignored. Even successful, enjoyable professional projects may become boring after a while since their success will draw continued investment by the employer, oftentimes in areas that are uninteresting or largely irrelevant to the aspects that were originally exciting.
> Techniques to minimize failure are quite literally a matter of survival in a professional context; they are often an afterthought in a personal project. Fault prevention and tolerance are often the most difficult characteristics to achieve in any sufficiently complex software system, and their prioritization or lack thereof has an enormous impact on virtually every aspect of working on such a system.
See, I almost see this as backwards. My personal projects often depend on only myself to maintain survival, and I didn't put all that time in to see them go by the wayside so easily. This means I build in tools and resources to help put them up and keep them up, because I'm the only one who can. In a professional context, I've often seen team members not consider these issues because once it's out, it's someone else's problem- if it causes downtime, DevOps, if it's a simple bug, whoever takes the ticket.
> Your employer may not care about letting technical debt pile up indefinitely as long as you can keep cranking out new features and meeting deadlines, code quality be damned. Alternatively, your employer may impose onerous processes to ensure code quality and integrity that aren't really necessary or effective, and which may even be counterproductive. In fact, there's a good chance your employer will understand very little about what you do at all and make demands that are incongruent with technical realities, which you must deal with, sometimes by performing pointless tasks solely to appease them.
While certainly true, this is also something I would never expect someone on my team to be proud of. This is a shameful act, and done often enough leads to the departure of good talent. I expect management(including myself) to do it's job: Manage. This means not taking advantage of your employees often enough to make it a norm.
---
However, the thing I keep noticing about a lot of these is a certain level of assumption of what a personal project entails. That you may be producing something with significant technical debt, that you are coding in a way that isn't trying to work best with others, that you're not aiming for revenue or having to work under unrealistic constraints. Personally, I code at home the same way I code at work: With quality and hope that it will continue to have a life long into the future. Sometimes I don't return to projects for months- and I want to be able to pick them up the way I put them down. The other thing I recognize, is the kind of experience that has to do with working with others- something most personal projects certainly don't approach, but I don't look for them to solve it. Team experience still matters, I just also think personal projects mean something for technical experience.
> My personal projects often depend on only myself to maintain survival, and I didn't put all that time in to see them go by the wayside so easily.
That's great, but when push comes to shove, you can and will ignore an intractable issue in a personal project until you feel like working on it again. With a job, consistently ignoring issues can endanger your career and thereby, eventually, your ability to provide for yourself. (And to me, being a parasite who punts issues like you describe is hardly a better existence even if you're able to get away with it.)
> While certainly true, this is also something I would never expect someone on my team to be proud of. This is a shameful act, and done often enough leads to the departure of good talent. I expect management(including myself) to do it's job: Manage. This means not taking advantage of your employees often enough to make it a norm.
Sometimes accumulating technical debt is a more pragmatic option in the bigger picture - what I'm describing isn't necessarily a universally bad thing (although it often is bad); the point is that professional and personal projects have fundamentally different priorities and that they require different skills and approaches to navigate effectively.
> However, the thing I keep noticing about a lot of these is a certain level of assumption of what a personal project entails. That you may be producing something with significant technical debt, that you are coding in a way that isn't trying to work best with others, that you're not aiming for revenue or having to work under unrealistic constraints.
You are validating this assumption with statements like this:
> Sometimes I don't return to projects for months- and I want to be able to pick them up the way I put them down.
When you are in production with real customers, you rarely have the option to do this. It's great to strive to adopt good practices in your personal projects, but when shit hits the fan at 3am, you're not going to get out of bed and fix it unless you have some real skin in the game, and you're not going to be truly motivated to code as if that's a real possibility (That means having: runbooks, paging, escalations, dashboards, metrics, alarms, gradual rollouts, time windowing, calendar blackouts, rollbacks, multi-step deployments, canaries, tech-ops, feature toggling, A/B testing, backup/restore, DNS safeguards, load balancing, SLAs, pentesting, failover, status reporting through 3rd-party channel, etc. etc.). I never said personal projects don't mean anything for technical experience; they certainly do. But that doesn't mean they're representative of professional experience either.
