It doesn’t appear there’s an active group concerning how to land your first Rails job, so I thought I’d create this thread to garner some discussion around how to prepare as a junior Rails developer.
Obviously this topic has been covered a lot elsewhere and you can find lots of tips if you do a Google search (e.g. thanks @benorenstein - http://codeulate.com/2013/08/a-short-guide-to-landing-your-first-rails-job/), but it could be useful to share progress or code samples?
I’m about to start applying for Ruby jobs and I’m at the stage where I’ve built a couple of apps. The thing that often worries me is a requirement I often see in job applications asking the prospective developer to show code “they are proud of”. I consider myself at the stage where I can get stuff working but I’m not particularly proud of the code behind it.
What types of code samples have you shown or would you look to see as a potential employer?
I’m considering creating a gem… or some kind of public project since most of my apps are in private repos.
@Noah_Clark to answer your question from the other group since it’s now closed.
@ralphwintle I disagree with @benorenstein only to the extent it prevents you from starting to apply for jobs. To give you a sense of what I used to get my first rails job:
GitHub - noahc/teacherjoy and GitHub - noahc/verteo-pharma. In particular look at verteo-pharma/static_pages_controller.rb at master · noahc/verteo-pharma · GitHub. It’s not pretty. I don’t think I have a single model that doesn’t inherent from active record for example.
Where are you located? This might make some difference too. As well as the type of jobs your applying for. It seems like in the midwest there is less of a focus on rock stars and ninjas and a bit more of a willingness to mentor folks who might not be excellent craftsmen yet. Also, if you’re looking at more enterprise types of jobs, I think you’ll be surprised how little they care about “code you’re proud of”. Can you produce code that works? is a more important question for many.
This isn’t to say you shouldn’t be trying to get better, but nothing makes you better like having to deal with real issues and the trade offs associated with them. Don’t wait until you’re good enough to apply.
In the absence of “code you are proud of”, being able to talk through the code and demonstrating knowledge of how it could be improved goes a long way.
@cpytel so I guess in a situation where I have to send some code over (perhaps prior to an interview), I’d just attached a message explaining what I did, how I did it, what I’m not happy about and how I’d improve it?
@ralphwintle check this podcast by @cpytel and @benorenstein: Giant Robots Smashing Into Other Giant Robots: 63: Knowledge Bomb!
@ralphwintle Yes, that is what I recommend. Good content for a cover letter or accompanying your code.
I get what you’re saying. What I meant in my post was mostly that you should have made the code that you submit as a sample as good as you know how right now.
If there are things that you know are bad and know how to fix, that just seems lazy to me.
If there are things that you know are bad but don’t know how to fix, then explaining why you think they’re bad is sufficient.
Great advice. Thanks everyone! About to listen to the podcast now.