Because it's optional, it fell apart but it's super important for mod 1's and 2's. Allow people to opt out on weekly basis or module basis so they don't bail on their group. Perhaps allow people to specify cost of lunch and bringing lunch. Leader - Vido
First, take about 30+ minutes and do a retro about your group experience. What's a retro? Think about our friday whole module retro - positives, negatives, and so-sos and actionable things you can improve to better the situation for next time. Here is a short read that may help define retros if you need a little more context. It may be helpful to revisit your DTR conversation too.
"By not giving me feedback, you're preventing me from growing." -Anonymous Student
Group Member Names:
When are group members available to work together? What hours can each group member work individually? Are there any personal time commitments that need to be discussed?
How will group members communicate? How often will communication happen, and how will open lines of communication be maintained?
Which feature(s) does each group member want to work on? Which feature(s) does each group member not want to work on?
Handy resource for keywords: http://ruby-doc.org/docs/keywords/1.9/
This doc: http://bit.ly/1EqHNPH
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.