数週間前まで12ヶ月の契約を結んでいたのですが(私が住んでいる国は、新人開発者にとっては普通ではありません)、会社の経営陣から正社員になるオファーと昇給がありました。私は履歴書を常に最新の状態に保ちたいので(特にCOVIDのことを考えると)、履歴書への記載についてググりまくりました。
そこで、履歴書への記載についてググってみたところ、一般的には、採用のきっかけとなった業績を記載すべきだというアドバイスを見つけました。なるほど。
問題なのは、その実績は常にクライアントの厳しい納期に間に合わせることであり、率直に言って、対象となるケースではエンジニアリングはそれほど優秀ではない可能性がある(経営陣もそれに同意していた)と判断することによって、私はそれを成し遂げたということだ。
私は6人の開発者からなるチームの中では比較的若手の開発者です。しかし、私は経営陣から最も信頼される開発者の一人となり、私が納品すると言ったときに納品し、納品に至るまでの相対的なトレードオフについて経営陣に報告するようになりました。ここでの短い勤務期間ではあったが、私はいつも、私が出荷できると言ったときに何かを出荷することができた。
このようなケースは何度かありましたが、これは正社員のオファーを受ける直前にやったものです。私たちの製品の1つは、1人のクライアントから1日1回呼び出されるバッチAPIです。失敗したエントリーのCSVをメールで送る以外は、何も返す必要はありません。彼らは新しい機能の追加を望んでおり、営業担当者は契約上、今月末までにその機能を追加することに同意していた。様々な理由で、その機能要求は最終週の月曜日まで私たちに届かなかった。
シニア開発者はマネージャーに対し、開発は適切に行えないので、クライアントにその旨を伝えるように言った。私はスプリントの計画会議で先輩開発者に反論することはありませんが、先輩の意見に反対したのは明らかだったのかもしれません。反対ではなく、あるトレードオフのオプションが存在する、というような。他の開発者もかなり消極的なので、誰も彼に反論しなかった。 約束しても納品しないことで、クライアントはすでに私たちに腹を立てている。マネージャーはミーティングの後、私をオフィスに呼び、代替案はないかと尋ねた。私は、何かうまくいく方法はあるが、私にはSQLの専門的なスキルがないので、おそらくAPIの処理時間が2倍になる(4分追加される)だろうと言った。マネージャーは同意してくれたが、クライアントはそれに気づかなかったようだ。
期限に間に合わなかった場合、どのような結果になるかはわからないが、1000人規模の会社のCEOが私にお礼のメールを送ってくれたほど、その結果は険しいものだった。
別のケースはそれほど注目されませんでしたが、データベース上で実行する必要があるプロセスがありました。正しいやり方は、私たちが使っている巨大なJavaシステムで適切なバッチプロセスを書き、通常のQAプロセスをすべて経て、2週間後に完成させることでした。私はマネージャーにPythonスクリプトを提案した。このスクリプトは手動で実行する必要があり、恐ろしく効率が悪い(一晩中実行しなければならない)。これは生産上の問題だったので、彼は応急処置としてそれに同意した。これは基本的に、ある種の誤ったデータについて行をチェックし、それを再フォーマットする安価なforループに過ぎなかった。
このようなことを履歴書に書いても、先輩開発者を貶めるハッカー・プログラマーと思われない方法はありますか?私の解決策が技術的に健全でないことは認めますが、その時のビジネスニーズには健全でしたし、非効率のトレードオフはほとんどの場合ほとんど関係ありませんでした。
あなたは、過剰にエンジニアリングすることなく問題を解決する効果的な(効率的ではない)方法をいくつか見つけた;
そうでなければ、最適化する価値のないものの最適化に多くの時間を費やすことになるからです。 そうでなければ、最適化する価値のないものを最適化するために多くの時間を費やすことになるからだ。XKCD-コミック]1に、何かにどれくらいの時間を投資すべきかを示す表がある。
解決策は、それが使用される(または使用できる)場合にのみ価値があるので、ハックを使用すると、顧客が解決策を得るまで作業を続けることができます。
上司と意見が合わなかったことを誰かに言う必要はない。時間的なプレッシャーの中で効果的な解決策を生み出すことができる。
私の解決策が技術的に適切でないことは認めます。 その時のビジネスニーズには合っていた。 ほとんどの場合、非効率的な取引はほとんど関係ありませんでした。
あなたには一つの仕事があった:仕事を解決する時間制限内で実行されるソリューションを見つけること。そして、それこそがあなたがしたことなのです。
不当な締め切りを守ることは賞賛に過ぎなかったので、ここでは経営陣だけが答えを出していると感じています。
ここには別の視点があります。 経営陣が手抜きをし、上級開発者の意見を無視するときに、開発チーム内で発火する社会的混乱を過小評価しないでください。 大まかにこのように言うことわざがあります:
絶えず火を消している人がいる限り、経営陣は試合をするのをやめません。
ハッキーな道を1回/ 2回下る場合は、そうすることを余儀なくされているが、それが標準に達している場合は完全に異なるものです。 そして、あなたの説明から、経営陣はあなたを使って手抜きをする習慣に非常に慣れているように思えます。 健全な職場環境を維持するために、この問題を経営陣や上級管理職に提起することを真剣に検討する必要があります。 企業は開発と管理の間のバランスであり、単なるトップダウン構造ではありません。 「いいえ」という言葉が存在するのには理由があり、それを使用して練習する必要があります。
しかし、これはあなたよりも管理の問題です。 したがって、履歴書でこれを何らかの形で言及する理由はありません。 だから私は一緒に行きます:
締め切りに間に合わせることができます。
完璧は善の敵」ということわざがあるように、ビジネスのニーズを満たすために技術的な妥協をすることは、ごく当たり前のことだ。優秀な開発者/プログラマー/エンジニアは、許容できるトレードオフを見極めることができる人だ。
あなたのAPIの例では、顧客は明らかに、機能し納期通りに納品されるもののために、4分の処理の遅れを受け入れることを望んでいた。
理想的には、このような妥協をする際に技術的負債を最小限に抑えることを考えるべきだ。
|にできるようにあなたがそれをすることができます本当に出くわすことあなたは、実際には私たち約束、誰でも素早くはちょうど無視これらの一見正確にどのように{}人のことを忘れることができます。
実際の実装の詳細がなくても、単に、時間に制約のあるプロジェクトで納期に間に合わせた良い実績があると言って、その例を挙げればいいのです。
あなたがしていることはハッキングではなく、解決策を見つけることだ。
私は20年前から開発者やコンサルタントとして働いていますが、雇用主が求めているのはこのスキルです:履歴書から省くのではなく、そのことを強調してください:履歴書から省くのではなく、まさにそのことを強調してください:たとえそれが「普通でない」道を行くことを意味するとしても、あなたは解決策を見つけようとします。
先輩開発者に隠れてそうしていると書くのではなく、たとえ経験豊富な開発者が反対したり、不可能だと言ったりしても、解決策を求められるたびにそうしていると書くこと。
アルバート・アインシュタインの名言がありますが、まさにあなたの状況を言い表しています:
誰もが不可能だと知っていたが、知らない愚か者がやってきてそれをやってしまった。
私は多くの開発者と一緒に仕事をしてきたので、あらゆる面を知っています:
stackoverflowのJavaScriptエキスパートでトップ1%に入る開発者と一緒に仕事をした。彼は天才で、彼が書くコードの一行一行を本当に尊敬している。しかし、彼はしばしば自分のプロジェクトを完成させませんでした:コードの美しさに満足できないなら、何かを完成させないほうがましだ。
彼はコードの美しさに満足できないくらいなら、むしろ何かを完成させないことを選ぶのです。また、私は非常に効率的な開発者たちと仕事をしましたが、そのため、ソリューションをほとんど保守不可能にするようなショートカットをたくさん使っていました(ハードコードされたパス、マジックナンバーなど)。
そして、私は常に「美しい」よりも「完成された」ものを好みました:そして、私の顧客もまたそうでした。彼らは、何もないけど、もう少し時間が経てば美しくなるだろうというものよりも、締め切りが迫っているときに、何か完成しているものの方が欲しいのです;
回避策/ショートカット/ハックは、理解しやすく、文書化され、保守可能でなければなりません。
私には通常の技術借金のように聞こえます。 シニアはおそらく年上で疲れ果てており、すでに過負荷になっているプロジェクトにこれ以上の借金を追加したくありませんでした(実際、私がこれを押し戻すのは私と同じです)。 あるいは、彼らはチームを保護しようとしていたのかもしれません。 質問を直接見てみましょう。
私の履歴書にこれらのタイプのものをリストしない方法はありますか? 私を上級開発者を傷つけるハックプログラマーのように見せてください?
たぶん私はここで世間知らずですが、履歴書にこれらのタイプのものをリストするべきではありません。 全体的な成果だけなので、これがこの会社の標準である場合、それはあなたと引用することです。;タイトなタイムスケールの下で作業し、クライアントとクォートにソリューションを提供しました。; クライアントで機能するものを作るために、保存した手順を数日で1〜2回ジャッキアップした方法の詳細ではありません。 タイトなタイムスケールで配信するという履歴書を読んだら、要点はわかります。
それでも、履歴書に本当に追加する必要があるのはそれだけです。SQLやその他の技術を扱う開発者としてBlah Incで働いていたので、それを緩やかに保ちます。 なぜこれが履歴書にある必要があるのですか?.
あなたは技術的な負債を説明していますが、技術的な負債は常に悪いわけではありません。 借金の類推は、企業が金融債務を引き受ける正当な理由がたくさんあることにまで及びます。 重要なのは、それが意図的であり、それを完済する現実的な計画があることです。 マーティンファウラーはこれについて広範囲に書いており、特に彼が技術的負債象限と呼んでいるものについては特に書いています。
。。
技術的な借金に関して慎重な決定を下したようですね。 技術的負債がどこにあるかを認識し、それを管理する方法を知ることは非常に貴重なスキルです。
私はあなたを雇いたくないと言わなければなりません、そしてそれはあなたがトレードオフをしたからではありません。 それは仕事の重要な部分であり、習得するのが難しいスキルです。 これは、チームの他のメンバーの経験の恩恵なしにブラインドトレードオフを行ったためです。
潜在的なデザインを探求することは、上級開発者に「矛盾」するものではありません。 会話は次のようになっているはずです。
あなた:Xを実行した場合はどうなりますか? 。 上級開発:それはおそらく処理時間を2倍にするでしょう。 私はしません。 顧客はそれに満足していると思います。 。 PM:実際、私は彼らがまったく遅くするよりも遅くしたいと思います。 確認するためにフォローアップします。 。 他のジュニア:ボブはSQLについてよく知っています。彼に助けてもらえるなら、私。 彼はその時間の多くをカットすることができたに違いない。 。 シニア開発:しかし、私はまだコーナーケースYについて心配しています。 それを適切にテストする時間です。 もしそれが本当に恥ずかしいでしょう。 私たちはそれを間違えました。 。 PM:同意する。 テストに取り組み、OPがBobと協力して行った場合。 彼が言ったようにAPIを変更してください? 。 シニア開発:締め切りはそう思うと思いますが、戻って行きたいです。 次のリリースのためにクリーンアップします。 それ以外の場合は、顧客がこれを行うたびにYメンテナンスの頭痛の危険があります。 。 PM:わかりました。
また、これらのことはインタビューで行う。 インタビュアーは、「厳しい締め切りで価値を提供するためにトレードオフを行うことで認められた」のようなものを見て、例を求め、次に、上級開発者が持つであろうほぼ同じ質問をすることでフォローアップします。
「あなたの履歴書はこの話にふさわしい場所ですか??"片側に。 おそらく、履歴書にはそのような詳細のためのスペースがありませんが、それがインタビューで出てくるかもしれない種類のものであり、あなたはそれを最高の光の中で提示する方法について考えているとしましょう。 いずれにせよ、誰もそれについて再度話さなくても、あなた自身の専門能力開発への影響を通して考える価値があります。 さて、ここに私が提案したい1つの観察は、他の誰も言及していない適切なものです:
あなたはまだ仕事をしています。。
ストーリーを提示するのに最適な方法を検討していますが、ストーリーを変更できるという特権もあります。
それで、あなたは判断を下し、リスクを冒しました。 そのため、完全に観察可能な機能で期限を守り、クライアントを満足させ、マネージャーに印象づけることができました。 そのため、必要以上の実行コストでソリューションを提供し、コードベースの設計を危険にさらす可能性があり、チームリーダーを困惑させました。 それは合理的な判断の呼びかけです。 他の人はすでにそれを提示する方法を説明しました:チーム内の対立を完全にストーリーから外し、認識したソリューションの技術的な問題をビジネスの現実の認識とともに明示的に述べ、あなたが電話。
しかし、もっと良い話をすることができれば、この借金をとって清算することが含まれます。 これには、期限が迫っていない今、少しレビュー時間を取ることを含みます。おそらく、コードをより適切にカプセル化し、いくつかの主要なユニットテストを追加するためです。 これは、追加の4分のうち2分を削り取り、おそらくローカルのSQLエキスパートに相談することを意味します。 これには、他のチームとクレジットを優雅に共有する方法を探すことが含まれます。
速く動いて物事を壊す男としての評判を望まない場合は、あなたの決定(タフだが非常に合理的な決定を含む)が行う技術的、ビジネス的、対人関係の混乱を評価し、それらを片付ける責任があります。
あなたはまだ仕事をしています。。
問題は、その成果は常にタイトなクライアントに貢献していたことです。 締め切りと率直に言って、私はエンジニアリングができると決定することによってそれをしました。 ターゲットを絞ったケース(経営陣が同意した)では、恒星よりも少なくなります。 。 締め切りを逃した場合の結果がどうなるかはわかりません。 ありましたが、彼らは私たちの1000人のCEOほど急でした。 会社は、それを配信してくれたありがとうメールを私に送りました。 。 私の履歴書にこれらのタイプのものをリストしない方法はありますか? 私を上級開発者を傷つけるハックプログラマーのように見せてください?
再開すると、達成度が強調されます。.. 厳しいクライアントの締め切りで配信され、CEOからお礼状が届きました。」.
面接の設定でどのように到達したかはわかりますが、履歴書には含まれていません。
場合によっては、ビジネスの決定に迅速性が必要です。 個人的な経験から、マネージャーは重要なことを成し遂げる方法を見つけることができる人々を大切にしていることがわかります。
実行に4分かかるソフトウェアを作成しました(コードがあまり良くなかったため)。 手で作業を行うのに12時間かかる場合、ソフトウェアで11時間56分節約できます。 1秒で実行されるより良いコードを書いた場合、11時間、59分、59秒節約できます。 1週間後により良いコードが配信され、手動で5回作業を行わなければならなかった場合、追加の3分59秒は、失った時間を補うことはありません。
またはそれをより極端にします。 ソフトウェアは24時間で実行する必要があります。 コードが悪いので、24時間で実行するには$ 5,000のコンピューターが必要です。 より良いコードがあれば、2,000ドルのコンピューターが24時間で実行できます。 3,000ドルの節約。 コードを高速化するのに2週間かかる場合、それは全体的な損失です。
必要なときに配達できることは、非常に良いことです。 さらに、非常に優れた開発者は、後で簡単に改善できるように、悪いコードを記述できます。 悪い開発者は、リファクターを良い形にするのは苦痛である悪いコードを書き、時間のプレッシャーの下で良い開発者は簡単に改善できる悪いコードを書きます。
「それは何ですか、あなたは言います?"。
<ストライク>問題は< /ストライク> < b> < i> achievement(。!)< / i> was< / b>常に厳しいクライアントの締め切りと< strike> frankly< / strike> < b>私はそれをしました< / b>ターゲットを絞ったケースでは、エンジニアリングが恒星よりも少ない可能性があると判断することにより< b>(経営陣が同意した)。< / b>。
そして。 ...(。!)。
< i>< b> "おい。...!!!「< / b> < b>< i> youを雇いたい。!!!< / i>< / b>。締め切りを逃した結果がどうなるかはわかりませんが、1000人の会社のCEO< / i> < b>< i>のCEOに十分急 ⁇ 配でした。ありがとうメール< i>を私に送った(。!)< / i>< / b>それを配信するため。
最初に経営コンサルタントにならない限り。.. --。
非常に単純に、あなたはする必要があります。 ... まず最初に。 ... あなたは例外的に "になったことを自分の手の努力によって認識し、そしてあなたはそれについて非常に適切に認識されていることを認識してください。 履歴書では、元の投稿で概説したまさにその資質を強調する必要があります。
しかしまた:「あなたの現在の状況を見落とさないでください。「あなたが今前進できる唯一の方法はそれらを離れることであると自動的に仮定しないでください。 ... 「ディレクター」「チーフ・テクノロジー・オフィサー」「エグゼクティブ・バイスプレジデント」などのタイトルが由来します。
アインシュタインを言い換える。
ソフトウェアの品質はできるだけ低く保つ必要がありますが、低くする必要はありません。
彼らが書いたコードに誇りを持ち、これに強く反対する多くの開発者がいることを知っています。 しかし、ビジネスの観点から見ると、ソフトウェアの品質目標に到達するとすぐに、品質をさらに向上させることは、求められていない、または支払われていないことに費やされた追加の作業に相当します。 絶対的な品質は単に到達不可能です。ソフトウェアがどれほど優れていても、常に改善の余地があります。
明らかに、ドロップコード品質で賞賛されていませんでした。 **許容可能なコード品質を維持しながら、期限を守ったことで賞賛されました。 それがあなたの履歴書でそれを表現する方法です。
私はこれのためにあなたの履歴書に何を入れるべきかについて特に意見はありませんが、私はそのようなことは履歴書に実際には適合しないと言う答えに同意する傾向があります。
しかし、私があなたにインタビューしていて、あなたが質問でしたようにあなたが状況を説明した場合、どうなるかを指摘したいと思います。
私の最初の考えは、「良い、彼が行っているトレードオフを認識しながら、短期的に必要なことをできる人が好きです。「しかし、あなたの会社のソフトウェアプロジェクトの管理には、かなり明確に識別可能な問題もあります。
私が聞きたい答えは、テクニカルチームにいない誰かが、いつ配達できるかについてテクニカルチームから手元にある見積もりなしで、特定の期限までに顧客に何かを約束したということです。 それを行うことは、長期的な災害のレシピです。 あなたがそのような問題を特定できなかった場合、私はあなたを私のチームに入れることに非常に警戒するでしょう。
さらに、問題が特定されたら、誰かが長期的な修正を実装して、問題が徐々に軽減され、理想的には最終的に排除されるようにする必要があります。 これを実現するために、新しい管理職で何をしたかをお ⁇ いします。 あなたがそれに対する良い答えを思い付くことができなかったならば、再び私はあなたを雇うことにかなり警戒するでしょう。 費用のかかる短期的な修正に責任を持つことは素晴らしいことです。, しかし、あなたと#39の場合。;これらの費用のかかる短期的な修正の必要性を取り除く長期的な修正については責任を負わない。, 会社の時間とお金を全体的に節約します。, I'。;dそれを学ぶまで、あなたはジュニアロールにのみ合うと考えてください。