以前、エンジニアの中途採用をしていた際に意識していたことを書き残しておきます*1。
当時はうまく整理ができなかった（自分が面接をした/された人がいつか見るかもしれない、など考えると）のですが、今ならできそうと思ったので残しておきます。あくまで個人の主観であり、ノウハウというよりポエムであることをご理解いただければと思います。
*1:厳密にはエンジニア、PjM, PdM, EMの採用に関与していました。また、今は携わっておりません
医療ITの企業でエンジニアをやっているにも関わらず、所属する医療や医薬品業界のことをよくわかっていないと思い、いくつかの本を読んだり、Podcastを聞いたりしていたのでメモ。…と言っても実は読んでいたのは2ヶ月前でもうかなり忘れているので本当にメモ程度*1。
*1:まぁ「雑に書く」ってブログ名なので
ずっともやもやとした課題感がある。
業務システム内で発行されるクエリであれば、だいたいは発行されるクエリまで考えてテーブル設計をするのでそこまで苦労しない（ポリモーフィズムやenumが多用されてると結構きついこともあるけど）。一方でビジネスKPIや分析用のSQLになると難しいなと思っている。500行とかあると脳みそを使い果たして他の仕事ができなくなるくらいに疲れる。
だから、SQLのレビューがあまり好きではなく、後回しにしてしまう。
自分で書いたクエリは、日が空いても自分は読めるのだけど、やはり他の人にとっては読みにくそうなのがずっと不思議に思っていて、どうすれば他の人の書いたSQLを楽に読めるのか、少し向き合ってみる。
例えば1 ~ 100の任意の整数値を取る型を作りたい
// イメージ type Range100 = Range<1, 100> const test: Range100 = 100; // ok const test1: Range100 = 1; // ok const test2: Range100 = 101; // ng続きを読む
