面接だけで、有能かどうか見抜けるか？
採用市場が活況を呈しているが、「うまく採用できず悩んでいる」とこぼす経営者、幹部は少なくない。 その悩みは大きく２つ。 「応募がない」と「入社させてみたら、思っていたほどパフォーマンスの高い人物ではなかった」 というものだ。 そして、後者は前者に比べて、より深刻である。 あるwebサービス業の幹部は 「面接では素晴らしい人物に見えた。しかし、半年たって今思うと、「騙された」というのが正直な感想だ」 と言った。 「試用期間にやんわりと辞めてもらった。頭もよく、コミュニケーション能力は素晴らしかったが、手を動かせない人物は要らない。」 「クビにした人からは、苦情などは来ていないのですか？」 「給料3ヶ月分を渡して辞めさせた。カネを受け取っているし、退職願も出させたから、訴訟にはならないと思う。」 「そうですか。お互い不幸ですね。」 「面接で、事前に見抜く方があれば良いんだけどね。イマイチな人を
スタートアップの採用に役立つ「パフォーマンス・ベース・インタビュー」の質問の一部翻訳
Work Rules を書いた Google のラズロ・ボックは「非構造的面接の決定係数が 14% しかない」という論文を挙げています。つまり、多くの人が面接でやってしまっている、行き当たりばったりの極めて主観的な面接のやり方（「あなたの長所はなんですか」といった質問や、面接官が個別ばらばらに行う質問等）は、入社後のパフォーマンスの予測にはあまり役に立ちません。 代わりに有効なのは、ワークサンプルテスト (29%)、一般認識能力テスト (26%)、構造的面接 (26%) です。それぞれ非構造的面接の約 2 倍程度、採用後のパフォーマンスの予測能力が高いとされています。そのため Google では基本的にはこれらを組み合わせながら、構造的面接を用いているそうです。そして構造的面接のための行動質問や状況質問を、特定のポジション向けに自動的につくる qDroid というツールを作っています（※
スタートアップの失敗を90%減らす１０のポイント
スタートアップの失敗を90%減らす１０のポイント1. スタートアップの 失敗の90%を潰す １０のポイント 2. 田所 雅之 Masa Tadokoro 【シリアルアントレプレナー】 これまで日本4社と、米国シリコンバレーで１社、 合計5社を起業してきた（Exit経験あり） 【ベンチャーキャピタリスト】 シリコンバレーのベンチャーキャピタルFenox VC の日本・東南アジア地域 Venture Partnerを務める。 国内外のスタートアップの数百社のデューデリジェンス と投資の担当（1年間で２０億円の投資担当） 【講演経験】 成功するスタートアップの作り方 ベンチャーファイナンス講座 起業のアイディア講座 オープンイノベーションの実装講座 など年間数十件の講演 【その他】 スタートアップ10社アドバイザー/ボードメンバーを務める Pioneers Asiaにてスタートアップ統括責任者
migration の中で model を触ったら必ず reset_column_information する - onk.ninja
migration の中で model を触ったら必ず reset_column_information する 治安の悪い Rails アプリケーションでは、migrate 中に model の不整合で怒られることがあります。 class AddAgeToUsers < ActiveRecord::Migration[5.1] def up p User.first # 1 add_column :users, :age, :integer # 2 User.create(name: "Taro", age: 16) # 3 end end 1 で User model を触ってしまっているので add_column 前の DB の状態がキャッシュされて 2 で追加した add_column は別にキャッシュをリセットしないので 3 で ActiveModel::UnknownAttrib
VMに手を加えずRubyを高速化するJITコンパイラ「YARV-MJIT」の話 - k0kubun's blog
先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Mimic Method - Learn a Foreign Language "By Ear"
ReportsKit | Add reporting to your Rails app in minutes, not months