世の中にはプログラマ採用にソースコードの提出を求めたり、GitHubのアカウントを求める企業があります。
彼らはソースコードを見ると何がわかるのでしょうか？
プログラマを学んでいる学生の方はよくわからないかもしれないので、私の体験をご紹介します。
この記事が就活に役立つと良いですね。

プログラムのソースコードは『プログラマーの日記』である

日記は書いたことあるでしょうか？
日記にはその日その日の自身に起こった出来事や心情が綴ってあることでしょう。
それと同じことがソースコードにも反映されます。

でも、日本語で心情を綴っているわけでもない。コンピュータに命令を送っているだけなのに、どこで心情がわかるのか？

プログラムのソースコードには、その人の癖がモロに出る

はい、モロに癖が出ます。
それはどういう所か？

パッと上げただけでもこれだけ出ます。
こういった所から「このコードを書いた人はこういう人だな」ということが推測できますし、直近に編集されたファイルがゴチャゴチャしてると「だんだん設計が曖昧になってきて、手に負えなくなってきているな」とか、メモが減ってくると「突貫工事で作り始めた。プロジェクトに嫌気がさしてきているんだろうか」など、その時点での心情も読み取れます。

もし、応募先企業がソースコードの提出を求めてきたら

プログラマって口下手な人が多いですが、ソースコードは口ほどに物を言います。
もし、あなたの応募先企業が「ソースコード見せて」と言ってきたら、提出前に以下のことを確認しましょう。

• インデント、改行のルールは統一されているか
  • if文の条件が複数になった時に改行するorしない
  • 関数・メソッド間の改行は何行開けるか
  • インデントは空白2つ分なのか4つ分なのか
  • 1行で書けるif文を1行で済ますのか改行するのか
  • 等など
• コメントが少なくなっているファイルはないか
  • コンパイル型言語においてはコンパイルした時点でコメントは取り除かれるため、コメントは多いほど良いとされています。
  • インタープリタ型言語ではコメントが多すぎるとファイルサイズが大きくなり、読み込み速度や処理速度に影響するため、必要な所に必要なだけ書きましょう。（それでも多い方が良いです。）
  • そして、コメントの書き洩らしがないことを確認しましょう。
    コメントが急に薄くなると意欲の低下を感じます。
• 変数や関数の命名規則は統一しましょう。
  • キャメルケース、スネークケース、パスカルケース、ケバブケースなどありますが、最低限１つのプロジェクト内でのルールは統一しましょう。
  • そして、言語ごとに命名規則があるので、なるべく従うようにしましょう。

気づいたでしょうか？
私たちプログラマが他人のソースコードを読んでいて一番気になるのは、書き方がコロコロ変わる人なんです。
書き方がコロコロ変わる人っていうのは、気分屋な人か、他人のソースコードをコピペしているだけの人である可能性が高いです。

他人のソースコードを利用できることは現在のプログラミングでは非常に重要です。
しかし、残念ながら、それがたまたまハマっているだけなのか、意味を理解して利用しているのかまでは読み切れないのです。
なので、プログラミングルールが安定していない人と働くのは、ちょっと不安なんです。

自分の意見を発さず、他人の意見に便乗するだけの人って何考えてるかわからなくて、ちょっと関わりにくいじゃないですか。
それと同じ感情になるんです。