[Remote] Beyond the Brain Teaser: Technical Interviewing with RESPECT
"How would you move Mount Fuji?"
Great question, but does an engineer need to know the answer in order to write great code? No? I don't think so either.
The technical interview is one of the most controversial, challenging, and stressful parts of an engineer's career. The more senior the engineering position, the less relevant the brain teasers, algorithm quizzes, and puzzles that make up these interviews are to the evaluation of a potential candidate. And although this interview style first became famous at large tech corporations like Microsoft and Google, it has propagated across the industry to the point that courses are springing up in college campuses and bootcamps showing candidates exactly how to "crack" these interviews.
In the past, I’ve worked at a number of companies as a lead developer and in that role I spent a lot of time interviewing folks for technical positions. We weren’t allowed to choose our own process and had to follow the company’s rules. In that time I learned a lot about what works, and what doesn't work, for judging technical aptitude in an interview setting.
In this presentation I will talk about the difficulties of technical interviewing from both the interviewee and interviewer's point of view, and provide several helpful tools using the acronym RESPECT to improve the interviewing experience across the board.
** 日本語版もあります。
Outline/Structure of the Talk
- Introduction
- A Sample Problem
- My First Technical Interview and Other Stories
- Benefits and Drawbacks of Technical Interviewing
- The RESPECT Process and How To Apply It Without "Lowering The Bar"
- (R)eal Solutions
- (E)xperience
- (S)afety
- (P)otential
- (E)arned Trust
- (C)onversation
- (T)ime
Learning Outcome
After attending this talk, attendees will have a grasp on a new way of approaching evaluation of technical candidates and be able to apply the principles discussed during their own candidate interview cycles.
Target Audience
Engineers, Managers, HR Professionals
Prerequisites for Attendees
No Prerequisites
Links
Blog on this topic which inspired this proposal: https://medium.com/swlh/trial-by-fire-fox-injecting-respect-into-your-technical-interviews-f1fe567e074c
Personal website: http://www.angstygaijin.com
schedule Submitted 2 years ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Michael Migliacio - [Remote] Leading Engineers To Water: The Art, Science, and Culture of Technical Coaching
45 Mins
Talk
Beginner
Software engineering may be difficult, but fostering a working environment that enables skilled engineers to perform their best can sometimes seem downright impossible. Every day, many engineering teams are battling a messy whirlwind of forces like unmovable deadlines, imposter syndrome, psychological safety issues, personnel/leadership conflicts, fierce technological preferences, and more. With teams more distributed all over the world than ever before, cultural differences can exacerbate many of these difficulties.
In this presentation, I’ll discuss tips, tricks, and techniques that technical leaders and managers alike can utilize to better coach engineering teams, including concepts like the definition of empathy (and, more importantly, what doesn’t count), the trust-influence relationship model, introducing new technologies in a meaningful and consumable way, and a 5-step process to provide teams confidence to own their new solutions moving forward.
** 日本語版もあります。
-
keyboard_arrow_down
Woohyeok Aaron Kim - Roll your Product with Kaizen Culture(Let's 'Tech' the initiative (Renewed for 2021))
45 Mins
Talk
Advanced
Jeff Sutherland氏、Martin Fowler氏、Taichi Ohno氏。世界の業務プロセスに変革を導いた彼らは共通的に「カイゼン」について強調しました。
彼らの本を読みエンジニアとしての道を歩んできた私たちにとって、「カイゼン」は第一の価値として認識されていると思います。
皆さんは、今日より良い明日のために何に力を入れてますか?毎日が忙しすぎて、何かを改善するどころかストレスだけ溜まってたりはしてないでしょうか。
楽天のランキングサービスグループは開発と運用、いわばDevOpsを実践していますが、そのプロセスに対しいくつか問題を抱えていました。開発の段階で発生するボトルネック、効率的だとは言えない運用環境。
何よりも問題だったのは、こういったボトルネックにおいて改善の文化が定着しにくいということでした。せっかく良いアイデアを思いついても、そのボトルネックから発生するコストの問題で後回しにするしかなく、そうなればなるほどチームの改善力はどんどん下がっていきました。
私たちランキングチームは2つの解決策を決め、それを同時に進め相乗効果を発生させることでこの状況を乗り越えようとしました。
ランキングチームが挑戦したトライアルそしてテクニカルな変更によるチームカルチャーの変化。またその後1年間の運用ストーリーまで!
より安全で良いサービスの提供のために、日々工夫を重ねているあなたのために、私たちのお話を特別に公開します。
-
keyboard_arrow_down
Yasunobu Kawaguchi - [スポンサーセッション] DevOpsの時代 ~ 変化を体現する"統合"の先駆者たちから学ぶ
45 Mins
Talk
Advanced
※本セッションはアギレルゴコンサルティング株式会社のスポンサーセッションとして提案しています。
皆さんにとってDevOpsってなんですか?デプロイの自動化ですか?インフラストラクチャー・アズ・コード(IaC)ですか?運用部門と開発部門が共通言語をもって協力し合うことですか?SlackでChatOpsですか?テスト自動化ですか?全社でフィードバックを短期化することですか?
DevOpsは、写真共有サイトのFlickr社の人たちが発表したスライドが一つの源流です。
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickrこれにインスパイアされた Patric Debois さんたちが、DevOpsDaysを始めたそうです。もともと考えていたアイデアはシステム管理者のためのカンファレンスだったとか。(詳しくは基調講演で)
これに影響を及ぼしているのが、当時ThoughtWorks(当時)の Jez Humble さんの「Continuous Delivery 継続的デリバリー」です。
また、概念を会社全体のビジネスに広げ、いまでいうDXをうたっているのが Gene Kim さんの「Phoenix Project」でした。
Microsoft(当時) の Sam Guckenheimer さんはAgile 2014 の基調講演で、「Microsoft's Journey to Cloud Cadence 」で、同社が行ったシステム開発全体の近代化の中で、多くのDevOps/技術プラクティスを取り上げ、アジャイルに取り組む企業が進む先としての一つの像を整理し、現在の「Azure DevOps」や「Github Actions」プロファクトにつながっています。
こうしてDevOpsは、インフラの自動化、コーディングプラクティスの普及、フィードバックサイクルの短縮化、それらにともなうビジネスや組織体制の変革、を取り込みながら広がってきました。
本セッションでは、そうしたDevOpsの背景と広がりを整理します。
さらに、任天堂「ゼルダの伝説 Breath of the Wild」、東宝「シン・ゴジラ」、ポリゴンピクチュアズのアニメ制作過程など、コンテンツ業界での制作過程の変化なども織り交ぜながら、私たちにできそうなことはなにか、探っていきたいと考えています。
主催者として、どうして、アジャイルテスティング研修、アジャイルリーダーシップ研修、情熱プロダクトリーダーシップ研修を企画しているかについても紹介できればと考えています。