Some of this list is excerpted from Ryan Biggs' Post on Stack Overflow
[ x ] Have a pet project
[ x ] Learn all the time
[ 0 ] Test, Test, Test (Rspec and MiniTest)
[ x ] Attend the local user groups
[ x ] Share all the cool shiny things you come across
[ x ] Contribute back to open source
[ x ] Be active, helpful and constantly visible in the community
[ x ] Keep a blog
[ o ] Practice your Ruby, be able to explain it and do it on a white board
[ o ] Practice some algorithms, be able to explain them and do it on a white board
[ o ] Have a portfolio of your work to show
[ o ] Have your story down about how you got into coding
[ o ] Have your other interests clarified in your head and ready to talk about, whether it's biking or reading, pick something and be ready to talk about it, briefly!
[ o ] Be ready to talk about how you have gone about learning to code
[ o ] Be ready to show my Rails project to someone through the code.
[ o ] Be ready to talk about how Rails works and answer question about Active Record, the database and the structure of Rails
[ o ] Have all your websites preloaded on your computer before you get there in case you can't connect to the internet.
[ x ] Figure out what you want in a job and what your concessions could be
[ x ] Research the company you are interviewing with
[ x ] Research the people you are interviewing with
** Open Source Opportunities:**
https://openhatch.org/
I have now interviewed for three Rails jobs which I have not gotten and a fourth for which I still have my fingers crossed. As difficult as these technical interviews have been I have learned a lot.
My first interview was a while back at Cal Tech. That position was probably over my head a bit at the time. It would have creating and updating Rails apps for departments at Cal Tech. I got through the first interview which was actually not particularly technical. The people who were interviewing me and who I would be directly working with were not that technical so it was pretty easy to make my half information sound impressive and correct even though it might not have been. I acted confident and it worked.
I was called in for a second interview with 3 different people. One of them was the head of that department, another was a math professor and another was an administrator for the department. The administartor already liked me from the last interview so that went well then I headed over to the math professor which I was really nervous about, I was at Cal Tech! He ended up being quite nice and we talked about programming a bit and then we talked about music. I thought for sure I would tank that part but I got through it fine.
Then I met with the head of the department and it also went really well. I told her about my background in film and media. She said that the people who do really well there often come from a diverse background and have many interests. She had come from a dance background and ended up where she was after several strange turns and side jobs that turned into a career. I really thought I was going to get that job. I was so close. I was told that I was at the top of the list but they decided to hire internally.
After this interview which was probably premature due to my skills at the time someone asked me if I had gotten the job. I replied no and that I was bummed out. They asked what I wanted out of a job. I had not thought about this before. This question made me really think. I had just assumed I should take whatever because I am so new I can't be picky. Then I realized some of the things I didn't want. One of the reasons this job would have been over my head was that I would have been in charge and have been the main technical person. I would have had one person to help whose job was not realated to the one I would hold. There was no real plan for how much they could help me. I would mainly be on my own. Having dbeen in this position before I realized that I want to work with a group of other technical people. I do not want to be in charge right now. I want to be able to learn from more experienced developers.
My second interview was with a company called Epoch. I got an at home challenege which was really hard. I used the power of the Gist to record my progress and to create a document which I then used durin my interview to guide me and the interviewees through my process. They had a few Rails and datbase questions for me which I had some pretty lame answers for but not particularly impressive answers that really made me sound like I knew what I was doing. The rest of the interview went really well though and I left feeling confident. They wanted me to finish the coding challenge and send it to them. I tried and tried and really couldn't figure out how to do it. Sadly I didn't get that job either.
My third interview was with a company where many of my friends in the community work. They have a small but impressive team that I was excited to join.
My fourth interview was at Fullscreen. Because I have been going to Meetup for years and am involved in the community, I knew 3 of the 5 people interviewing me.
I got started with Ruby on Rails in September of 2006. My first project was not a blogging system like was cool at the time, but a forum system. I remember one of my first questions in the #rubyonrails channel was asking why I was getting an undefined method find on Thread, not knowing Thread was already a class.
In June 2007, I was hired at my first Rails job. I didn't know much then, perhaps a smidgeon more now. So as you can see, the process wasn't instant. Very few processes are.
What happened during this interval though was (aside from PHP contracting, being a checkout bitch and studying) that I continued asking questions in the #rubyonrails channel and refining the forum system until I got something I was happy with. In April 2007 the first official user group meeting of my home town begun and I attended that, mentioned I was doing PHP work whilst toying around with Ruby and was offered three business cards on the spot. I basically did cards.rand and picked a job that landed me an 8-month contract which I enjoyed.
I learned a huge amount during this job, as you should with any job. I applied what I learned to my forums, refining it using the techniques I was learning on the job. I've been refining it further and further since then and in its current incarnation it's probably my Open Source Magnum Opus.
After I left that job I was quickly picked up at another company where, again, I learned new things and applied what I had learned to my open source work. One of the greatest things to learn was automated testing. If you're not writing tests, you're at a huge disadvantage to those who are. I know of many prospective employers who are looking for people who can write good tests for their code.
Now that Github's about, I have a nice central location to share all my work where prospective employers can look. The only feature I crave from Github would be a list of all the projects I've ever contributed to, since this is what lures most employers. So far the "Big Three" in my mind would be: RSpec (better Hash diffing + other changes), Cucumber (That list of failing scenarios when Things Go Wrong(tm)) and Rails (documentation such as the Querying Guide and the in-progress Initialization Guide as well as bug fixes).
It also doesn't hurt to keep a blog of the technical (and not so technical) things you come across. If you provide useful information, you'll get noticed for that too. I got noticed enough that I was recruited to write a book.
I also attended the second Railscamp event in November 2007 where I met one of my future bosses and made a lot of "connections" with people in the Ruby community. I then went on to run a Railscamp in Adelaide (#4), and assisted with the ones following that in varying degrees.
I'm also very active in the community, helping out on of course here and the IRC channels on Freenode. Helping out is definitely one of the ways I've learned how to be a better Rails coder. You can witness other people making mistakes and suggest fixes, and also watch other people suggest fixes that you may not have thought of.
Currently, I'm teaching people Ruby on Rails and when there's nobody to teach I do development work. That's my day job. The night job is writing the book. I would advise you to only have one job, because over-work can lead to burn outs. That's what weekends are for, or so I'm told.
shareimprove this answer answered May 25 '10 at 22:56
Ryan Bigg