vim {filename}
General | |
---|---|
:e {filename} |
edit a file |
:q |
quit |
:q! |
quit without writing |
:wa |
write all changed files (save all changes), and keep working |
# /------------------------------------------\ | |
# | don't forget to download the .tp file | | |
# | and place it in the user's directory :› | | |
# | | | |
# | also install lolcat: | | |
# | https://github.com/busyloop/lolcat | | |
# \------------------------------------------/ | |
alias test-passed='if [ "$?" -eq "0" ]; then lolcat ~/.tp -a -s 40 -d 2; fi;' |
Originally published in June 2008
When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.
To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.
Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.
Picking the right architecture = Picking the right battles + Managing trade-offs