tag:blogger.com,1999:blog-6054545261088815023.post84109475355143308..comments2023-05-28T10:00:08.019-04:00Comments on Daydreams in Ruby: Technical Interviews - A Revised ProcessAllison McMillanhttp://www.blogger.com/profile/04821645194471774106noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-6054545261088815023.post-69050514463907369312016-07-27T03:49:53.302-04:002016-07-27T03:49:53.302-04:00Hello Allison, very good post and very smart ideas...Hello Allison, very good post and very smart ideas, thank you for sharing them. I use 1 (Breaking apart a problem) and 4 (Refactoring) in my interviews. Also a variation of 5 (Tell me what this file is doing), where we provide a piece of code and ask the candidate what could go wrong here (there is a subtle bug).<br /><br />"Breaking apart a problem" is my favourite, because it can lead to great discussions. Steve Yegge provides some useful questions like "Design an elevator bank in a skyscraper": https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions<br /><br />Category 3 (Provide an explanation) is hugely important, in my opinion. If somebody cannot explain something complicated in simple terms, then either they have not fully understood it, or they have bad communication skills. So far, I haven't used concrete code examples for that (instead I had the candidate explain some abstract concept, like dependency injection), but this is definitely worth a try.<br /><br />About the career opportunity: I work at trivago, and I would love to get in touch, but a) we're based in Düsseldorf, Germany, and b) we are not using Ruby at the moment. If you are interested nonetheless, contact me :-)<br /><br />Tom Bartel (http://tombartel.de)Tom Bartelhttps://www.blogger.com/profile/05186055609678417194noreply@blogger.com