Melbourne RORO Feb is this Thursday, the 23rd.

[Ben Hoskings]

Hi one and all, come along this Thursday the 23rd of Feb for RORO at Inspire9.

http://d.pr/qZ15 at 6pm for a drink before the 6.30pm start. @ben_h / 0438240583 if you're after directions.

If you're visiting Melbourne or haven't been before, welcome! RORO is open to one and all. If you'd like to give a lightning (or longer) talk, even better.

We welcome talks on any and all aspects of web tech, not just ruby. If you'd talk (or argue) about it over a drink, then it's prime RORO fodder. Trolling talks are encouraged in moderation.

Aaaaaaaaaaaaand go.

- Ben

[Pat Allan]

I'm happy to give a talk about using Grape to build APIs. Maybe 15 minutes or so.

--
Pat

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
>

[Jason Crane]

Would love to see this one recorded (and processed and uploaded), for those of us geographically challenged.

Does this still happen in Melbourne?

J

On Monday, 20 February, 2012 at 10:01 AM, Pat Allan wrote:

>
> I'm happy to give a talk about using Grape to build APIs. Maybe 15 minutes or so.
>
> --
> Pat
>
> On 20/02/2012, at 12:23 PM, Ben Hoskings wrote:
>
> > Hi one and all, come along this Thursday the 23rd of Feb for RORO at Inspire9.
> >
> > http://d.pr/qZ15 at 6pm for a drink before the 6.30pm start. @ben_h / 0438240583 if you're after directions.
> >
> > If you're visiting Melbourne or haven't been before, welcome! RORO is open to one and all. If you'd like to give a lightning (or longer) talk, even better.
> >
> > We welcome talks on any and all aspects of web tech, not just ruby. If you'd talk (or argue) about it over a drink, then it's prime RORO fodder. Trolling talks are encouraged in moderation.
> >
> > Aaaaaaaaaaaaand go.
> >
> > - Ben
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

> > To post to this group, send email to rails-...@googlegroups.com (mailto:rails-...@googlegroups.com).
> > To unsubscribe from this group, send email to rails-oceani...@googlegroups.com (mailto:rails-oceani...@googlegroups.com).

> > For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
>
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

> To post to this group, send email to rails-...@googlegroups.com (mailto:rails-...@googlegroups.com).
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com (mailto:rails-oceani...@googlegroups.com).

[Ben Hoskings]

Oh, nice. I'd like to hear about grape.

Keep 'em coming, folks :)

[Ivan Vanderbyl]

I'll do a lightning talk on rabl, and possibly using rabl with grape.

— Ivan

[Andy Croll]

I'll be there, trying to make friends and plugging the Singapore Ruby
scene (and http://reddotrubyconf.com) before heading back there on
Friday.

This was good timing.

On Feb 20, 4:04 pm, Ivan Vanderbyl <ivanvander...@gmail.com> wrote:
> I'll do a lightning talk on rabl, and possibly using rabl with grape.
>
> — Ivan
>
> On 20/02/2012, at 1:19 PM, Ben Hoskings wrote:
>
>
>
>
>
>
>
> > Oh, nice. I'd like to hear about grape.
>
> > Keep 'em coming, folks :)
>
> > On 20/02/2012, at 1:01 PM, Pat Allan wrote:
>
> >> I'm happy to give a talk about using Grape to build APIs. Maybe 15 minutes or so.
>
> >> --
> >> Pat
>
> >> On 20/02/2012, at 12:23 PM, Ben Hoskings wrote:
>
> >>> Hi one and all, come along this Thursday the 23rd of Feb for RORO at Inspire9.
>

> >>>http://d.pr/qZ15at 6pm for a drink before the 6.30pm start. @ben_h / 0438240583 if you're after directions.

>
> >>> If you're visiting Melbourne or haven't been before, welcome! RORO is open to one and all. If you'd like to give a lightning (or longer) talk, even better.
>
> >>> We welcome talks on any and all aspects of web tech, not just ruby. If you'd talk (or argue) about it over a drink, then it's prime RORO fodder. Trolling talks are encouraged in moderation.
>
> >>> Aaaaaaaaaaaaand go.
>
> >>> - Ben
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> >>> To post to this group, send email to rails-...@googlegroups.com.
> >>> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.

> >>> For more options, visit this group athttp://groups.google.com/group/rails-oceania?hl=en.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> >> To post to this group, send email to rails-...@googlegroups.com.
> >> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/rails-oceania?hl=en.

[Naveed]

(Guess this seems a good time to make an introduction!)

Hi everyone. I'm Naveed, another ruby enthusiast flying in from
Singapore on the 23rd.
Looking forward to this meetup.

Naveed

On Feb 21, 8:59 pm, Andy Croll <andycr...@deepcalm.com> wrote:
> I'll be there, trying to make friends and plugging the Singapore Ruby

> scene (andhttp://reddotrubyconf.com) before heading back there on

> Friday.
>
> This was good timing.
>
> On Feb 20, 4:04 pm, Ivan Vanderbyl <ivanvander...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I'll do a lightning talk on rabl, and possibly using rabl with grape.
>
> > — Ivan
>
> > On 20/02/2012, at 1:19 PM, Ben Hoskings wrote:
>
> > > Oh, nice. I'd like to hear about grape.
>
> > > Keep 'em coming, folks :)
>
> > > On 20/02/2012, at 1:01 PM, Pat Allan wrote:
>
> > >> I'm happy to give a talk about using Grape to build APIs. Maybe 15 minutes or so.
>
> > >> --
> > >> Pat
>
> > >> On 20/02/2012, at 12:23 PM, Ben Hoskings wrote:
>
> > >>> Hi one and all, come along this Thursday the 23rd of Feb for RORO at Inspire9.
>

> > >>>http://d.pr/qZ15at6pm for a drink before the 6.30pm start. @ben_h / 0438240583 if you're after directions.

[Robert Postill]

If there's not enough trolling then I'd like to submit a little effort
:) It's called how to pass a code test. As I've just spent some time
looking at code tests recently I now have a reasonable idea of the
things that are impressive in a code test submission.

Rob

[Gareth Townsend]

And I'm going to talk a little bit about fire drills, which has almost nothing to do with rubies, but everything to do with running a web app.

Cheers,
Gareth Townsend
http://www.garethtownsend.info

[Fred Wu]

Some snapshots of tonight's RORO: http://www.flickr.com/photos/76172385@N07/sets/72157629436433815/

Love,
Some creepy dude in the dark

[Ben Hoskings]

Good stuff :) Cheers Fred.

Here's the analogue blogue from last night: https://gist.github.com/1896373

Thanks to Pat, Ivan, Rob & Gareth for their talks last night, I really enjoyed all of them.

And another grateful tip of the hat to Heroku for generously sponsoring our drinks last night -- I think pretty much everyone had a cleansing ale or two on the Heroku tab.

Cheers!
Ben

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/EkMCqWozfHQJ.

[Robert Postill]

Thanks to you too for hosting Ben :)

My slides are on slideshare at
http://www.slideshare.net/robertpostill/how-to-pass-a-ruby-code-test.

Rob

[Korny Sietsma]

You forgot to put in "don't fall asleep".

(sorry to have missed the chance to heckle)

- Korny

--
Kornelis Sietsma  korny at my surname dot com http://korny.info
I was dreaming when I wrote this, forgive me if it goes astray.

[Gareth Townsend]

Here's the blog post about the fire drill on the TC dev site.

http://dev.theconversation.edu.au/post/18174447251

[Adam Boas]

Hi Rob,

I listened with interest to your talk last night and had a think back over the many interactions I have had with the recruitment process both as a candidate and as a hirer. Litening to your critique of candidates made me a little uncomfortable but I couldn't put my finger on exactly what the problem was at the time. Apon reflection I think the source of my discomfort was this:

Many companies these days, often for good reason, are making the hiring process considerably more ownerous to candidates (and incidentally to themselves). Multiple interviews, a requirement to be a good culture fit (whatever that is), and code tests are becoming more and more common. Expecting candidates to do all this is fine and well but companies do seem to be becoming somewhat arogant about what is a fair burden to put on a candidate (who after all, is not being paid for their time and often will not get the job).

I'm not suggesting that companies shouldn't put in place processes to increase the likelihood of making a good hiring choice, but I do suggest that such companies should think about what they in turn owe the candidates. What, after all, does a candidate who has been to 2 interviews and spent around 1 week on a coding test (I think that was the time frame you metntioned in your talk) get out of the experience should they fail to get the job? I think that companies that want to put in place such hiring practices need to be prepared to repay unsuccessful candidates for their time with well considered feedback and advice.

I want to stress, I have never interviewed at C3 and this is not actually directed at you or C3 in particular. It is more that I started thinking about how little I myself have given back to condidates who have been unsuccessful at various companies where I have been a tech lead or dev manager and how useful it might have been for some of those failed candidates to get back a really detailed synopsis of problems I saw in their code test or interview and pair that with some suggested reading or other resources where they might improve the areas where they had problems. There is a real power differential that happens when someone applies as a candidate for a job and it would be awesome if companies who use that differential to leverage candidates to do a fair deal of work to be considered, also took their commensurate reponsiblity just as seriously.

Cheers,

Adam Boas

m:+61 (0)457 741 117

e:adam...@gmail.com

[Nigel Sheridan-Smith]

Hi all,

I'm the guy who announced I was doing the Facebook app (for those who were at RORO in Melbourne last night).

I was also uncomfortable and thinking something similar myself - I have done 2x24 hours tests before (1 in information security for ethical hacking, and 1 in coding) and I found the process tedious... not only because what I thought would take 6 hours ended up taking 23 hours (20 hours, followed by 3 hours sleep, followed by another 3 hours)!

I was actually going to push back on the next coding test, unless there was a significant chance of getting the job, because my time is quite limited with the things I am working on in my own time. It's a significant commitment and an easy way to ruin a whole weekend.

I think the best balance, is probably a 4-6 hr initial test, with potentially a longer test later once they have gotten past a few other hurdles. That way, you can argue that if they are serious about switching jobs then they can be incentivised to continue. The second test would only be given to the top 1 or 2 candidates as final confirmation.

Interview Street (http://www.interviewstreet.com) I have used before as a candidate... it works pretty well and should be able to test Ruby as well. This suits people who want to give problems with different degrees of complexity and not have to come up with a relevant problem.

Its the same situation with a 1 or 2 week trial period for a new employee... why would someone quit an existing full-time contract to do a limited trial period where there is no guarantee of an ongoing position at the end? However, if you are paid to take a day off and spend some time doing something directly with the team before you commit, then the business gets a feel of you as a potential candidate... and can then commit to a longer (3-6 month) probation period.

Cheers,

Nigel

[Robert Postill]

Adam,

There's a lot there so I'm going to try and snip some out and
hopefully not break the intent of your discussion:

"spent around 1 week on a coding test"

I don't think I made myself clear there, the test itself isn't an
entire week's worth of coding. It should take a few hours. It's more
I get nervous (an therefore more critical) if the code test hasn't
returned to me after a week.

"Listening to your critique of candidates made me a little uncomfortable"
I'm not surprised, it's an uncomfortable subject and I might suggest
that one reason it is uncomfortable is because I focussed on some of
the things that shouldn't appear. But I believe someone needs to talk
these things. We can't improve if we don't know what needs to
improve.

"but companies do seem to be becoming somewhat arogant about what is a
fair burden to put on a candidate (who after all, is not being paid
for their time and often will not get the job)"

I stopped believing in my own ability to judge a candidate merely via
interview some time ago. I know a number of companies that are more
extensive in their recruitment process and I think it's a trend that
wil continue for some time yet. Over time I've drifted further and
further towards a higher barrier rather than a lower barrier to entry
because when it doesn't work out no one gains anything.

From a fiscal POV if you hire on top of the salary I may also pay a
placement fee of as high 25% of the annual salary (if I use a
recruiter). Worse though is the effect if the candidate doesn't work
out. Disrupting the team on an emotional level as well as inflicting
a stressful experience on the unsuccessful candidate. Then on top of
that I get to spend the time and effort of recruiting again which I've
found to be normally measured in months. Meanwhile adding stress to
the team and opportunity costs for the business too through a lack of
help with the workload. Between those concerns I want to hire once
and correctly. My role as a manager is to clear the way for the team
to do their thing, making sure they are joined by only those who are
going to positively add the team. There's a measure of arrogance
there so I guess I'm guilty as charged.

"I think that companies that want to put in place such hiring
practices need to be prepared to repay unsuccessful candidates for
their time with well considered feedback and advice."

Personally I've followed up every unsuccessful code test with at
personalised feedback on why they failed. Last night's presentation
was a cumulative collection of antipatterns I've seen. As I said last
night I genuinely don't want anyone to ever fail a code test and if I
could I'd rather recruit without doing a code test at all.

Regards
Rob

[Robert Postill]

Nigel,

"I have done 2x24 hours tests before"

Yipes. That is full on :( But to reiterate I'm looking at a few
hours, I'll give you a week or so to do it so you can fit it around
other things.

"I was actually going to push back on the next coding test, unless
there was a significant chance of getting the job"

I'm deadly serious about hiring you if I give you a code test. I
suppose you could ask how many others are in train but I've always
halted handing out the test after a successful code test until I know
one way or the other. I have had two candidates working on a code
test simultaneously but I've never had two successful code tests at
the same time. If you pass the code test you're talking to someone
who's going to lay down an offer. I want to say yes as quickly as
possible but I need to know you can do the job.

Best of luck with the startup.

Rob

[Korny Sietsma]

>Disrupting the team on an emotional level 

Big +1 - I've had the fun experience in the past of having to give someone the boot (contractor not permanent, so just didn't renew the contract), and then having to explain to all the folks that liked the guy that he was actually rubbish.  He certainly would never have gotten through a coding exercise.

- Korny

[Ryan Bigg]

On Friday, 24 February 2012 at 12:34 AM, Adam Boas wrote:

 It is more that I started thinking about how little I myself have given back to condidates who have been unsuccessful at various companies where I have been a tech lead or dev manager and how useful it might have been for some of those failed candidates to get back a really detailed synopsis of problems I saw in their code test or interview and pair that with some suggested reading or other resources where they might improve the areas where they had problems. 

I think this idea is marvellous. Giving people feedback on precisely why they didn't get the job is exactly what they need to improve. It sets a goal for them to strive for and get to that point where perhaps the next place they interview for *will* accept them.

Just flat-out rejecting someone without giving any kind of feedback is, imo, a dick move.

[Mark Ryall]

Recruitment is just incredibly difficult.  It is very easy to hire someone appearing to be smart and personable that turns out to be impossible to work with and equally easy to reject someone who interviews poorly but turns out to be fantastic asset to any team.

Even though you can always scan someone's linkedin profile (rarely very effective at determining if you'd like to work with someone) or github repos (quite informative but some people are awesome developers who's circumstances do not allow them to make much contribution to open source projects) perhaps with some facebook and twitter stalking thrown in for good measure (wow this is a really long sentence) ... a coding test seems a necessary part of getting a developer role.

Having to write code in person seems too stressful.  Being given a few days to complete a coding task that is expected to take 3-4 hours seems reasonable to me.

Having 3 interviews with an organisation seems a better option for you to decide whether that organisation suits you.

I agree with the content of Rob's slides - my favourite things to look for are: a git/hg repository (so I can replay and see how the code evolved), sensible testing (some end to end testing as well as comprehensive unit testing), some brief discussion around the approach and simple code with teeny tiny classes (although many of my github repos completely violate most of these criteria).

It is reasonable for you to insist on detailed feedback on successful/unsuccessful application for a job - it'd be pathetic for code reviewers' feedback to go unchallenged.

[Robert Postill]

Ryan,
A couple of thoughts spliced into your comments:

On 25 February 2012 10:20, Ryan Bigg <radarl...@gmail.com> wrote:
> I think this idea is marvellous. Giving people feedback on precisely why they didn't get the job is exactly what they need to improve.

It is good to give feedback but there's two things that go with that.
On the one hand there's an issue of leaving a candidate some dignity.
When a code test has a few problems how many do you pick out? I
generally go up to three. After that I think I'm just beating up a
candidate. Secondarily, if the feedback goes through a third party
(HR person, recruiter, etc.) that person may give a modified version
of your feedback. So for both those reasons I started collecting my
thoughts.

> It sets a goal for them to strive for and get to that point where perhaps the next place they interview for *will* accept them.

Speaking personally (yet again :) I think a no can be a temporal
thing. Some people will never fit your organisational culture and
some will never write in the "house style" but there are many cases
where a candidate isn't suitable because of where the team is at that
time. I try to be a never say never guy.

> Just flat-out rejecting someone without giving any kind of feedback is, imo, a dick move.

Agreed.

[Daniel May]

Plus also a reminder for interview candidates themselves to always follow up with interviewers to ask why they weren't successful.

This reflects well on the interview candidates and also opens up the conversation. There've been candidates that were really groovy and full of potential, but we couldn't take them just yet. We might ask them to please keep in touch and keep a look-out for possibilities. It's a small world.

And then again … they just might not be a great fit for the organisation at the time. And it can be good to be straight about that as well.