タグ付けされた質問 「problem-solving」

問題解決には、アルゴリズム、ヒューリスティック、根本原因分析などとして知られるいくつかの手法が含まれます。

15
物事がうまくいかない場合のフラストレーションへの対処[終了]
シンプルなものを実装しようとしますが、何らかの奇妙な理由で機能しません。 そのため、可能な解決策を試してみますが、他の何かが機能しません。さまざまな回避策を試し続けていますが、毎回異なるものが機能していません。 一歩近づくたびに、この問題の解決からさらに1つ(またはそれ以上)のステップが得られ、現在では10時間かかっていたはずの3時間でした。そして、それはまだ解決されていません。 あなたの会社には誰も助けることができず、あなたはあなたの拳をあなたのスクリーンに入れようとしています。 この時点であなたはとてもイライラして、あなたはもはや問題についてはっきりと考えることができません。この時点で何をすべきですか?または、このポイントに到達しないようにするために何ができますか?

12
どのプログラミング言語が最も見つけにくいバグを生成しますか?[閉まっている]
あなたの意見では、平均的なプログラマーが見つけにくいバグを最小限に抑えて機能を出力できる言語は何ですか?これはもちろん非常に広範な質問であり、私は非常に広く一般的な答えと知恵に興味があります。 個人的には、JavaおよびC#プログラムの奇妙なバグを探すのにほとんど時間を費やさず、C ++コードには明確な繰り返しバグのセットがあり、Python / similarにはコンパイラによって検出される一般的で愚かなバグのセットがあります他の言語で。 また、完全に機能的なコードで書かれた大きくて複雑なプログラムを見たことがないので、この点で関数型言語を検討するのは難しいと感じています。ご入力ください。 編集:見つけにくいバグを完全にarbitrary意的に明確化:再現するのに15分以上かかり、原因を見つけて修正するのに1時間以上かかります。 これが重複している場合はご容赦ください。ただし、この特定のトピックについては何も見つかりませんでした。

26
問題解決能力を向上させるにはどうすればよいですか?
誰もが同じことを言います:「本当のプログラマーは本当の問題を処理する方法を知っています。」しかし、彼らはこの能力をどこでどのように学んだかを忘れています。それは学校で教えられていません。 複雑なプログラミングの問題に取り組む能力を向上させるにはどうすればよいですか?どの戦略が効果的ですか?アルゴリズムや設計パターンなど、私が注目すべき特定の領域はありますか?

12
インタビュー中に大声で考えることは本当に最高の戦略ですか?[閉まっている]
ホワイトボードのベストプラクティスについて最近質問した別の質問では、答えを思いついて大声で考えることが最良の戦略であるという一般的なコンセンサスがありました。 確かに、長い沈黙の瞬間は厄介です。 しかし、最近のインタビューの後、大声で考えると間違った解決策や間違った道をたどる場合、さらに検討すると、インタビュアーはすぐに飛び込んで私のアプローチの問題を指摘する傾向があることに気付きました1分間停止します。これは孤立したケースではなく、複数のインタビュアーとの複数のインタビュー中に発生しました。 もう1つは、インタビューの後、私が絶対に爆撃した問題について、座って無言で紙の上に問題をスケッチしたとき、私は解決策をかなり迅速にスケッチできたということです。大声で考えることは、私が言うことをインタビュアーに登録しなければならないことを考えることに頭脳サイクルを費やすことになり、さらに、間違った道を進んだことを認識し、ボードに何かを書いた後にやり直すことを恐れる多くの時間を無駄にします。1つの道を歩み始めて、たくさんのジャンクを書いたことに気付いたら、それを元に戻すことはできませんが、それについて静かに考えた場合、インタビュアーは混乱を見なかったでしょうし、それはより迅速だったでしょうホワイトボードに悪いアイデアを考えると、単に悪いアイデアを考えるよりも多くの時間がかかります。 沈黙の瞬間は欲しくありませんが、同時に話すことはより多くの時間を要し、自己意識につながり、ほんの少しの時間で自分が見つけたかもしれない何かに対するインタビュアーの介入につながる可能性があります。

28
過去数十年間の人類にとって重要なアルゴリズムはどれですか?[閉まっている]
過去数十年で人類に最も貢献した最も重要なアルゴリズムはどれですか? これは、開発者が知るべき一般的な知識だと思いました。 更新: 可能であれば、特定のプログラミングアルゴリズムに対する回答を保管してください。 最も重要なもののリストを取得したいのですが、回答ごとにアルゴリズムが1つだけです。 アルゴリズムが重要かつ重要である理由を述べることを考慮してください...

10
完璧主義のためにどこで線を引きますか?[閉まっている]
プログラミングの場合、完璧主義は良い面と悪い面があります。 問題を解決するとき、いつどこで線を引きますか? ソリューションが過剰すぎる、一般的すぎる、または単に未来的すぎると判断するのはいつですか? 質問が不明な場合はコメントしてください。

9
抽象化:問題の解決と一般的な解決策の間の戦争[終了]
プログラマーとして、私は自分のプログラムをできるだけ抽象的で一般的なものにするジレンマに陥っています。 そうすることで、通常、コードを再利用し、再び発生する可能性のある(または発生しない)問題のより一般的な解決策を得ることができます。 それから私の頭の中のこの声は、問題のダミーを簡単に解決するだけだと言います!なぜあなたが必要以上に多くの時間を費やしますか? 実際、私たちは皆、この疑問に直面してきました。そこでは、抽象化があなたの右肩にあり、Solve-it-愚かな人が左に座っています。 どれを、どのくらいの頻度で聞くべきですか?これに対するあなたの戦略は何ですか?すべてを抽象化する必要がありますか?

13
インタビュー中に「ホワイトボードコーディング」は不適切ですか?[閉まっている]
これはやや主観的な質問ですが、このトピックに関するインタビュアー/インタビュイーからのフィードバック/意見を聞きたいです。 テクニカルインタビューを4つのパートに分けました。ホワイトボード上のコードの記述、コードの読み取りと分析、デザインセッションとコード。 最後の部分について、インタビュー対象者にお願いすることは、ホワイトボードに小さなコードスニペット(4〜5行)を記述し、説明することです。目的を人々を捕まえることではないことをはっきりさせてください。完全な構文を探しているわけではありません。地獄それは擬似コードでさえありえます。しかし、ポイントは彼らに非常に単純な問題を与え、彼らの脳が解決策を私たちに伝えることができるかどうかを確認することです。単純な問題とは、「文字列を逆にする」、「FizzBu​​zz」などを意味します... 最初に明示的な言語を常に要求することに注意してください。私たちは.NET C#の家です。誰かがコードを消している/本当に苦労している「擬似コード」とだけ言いました。 私の質問は、「プログラマがインタビュー中にホワイトボードにコードスニペットを書くことを期待するのは不適切/不合理ですか?」です。

9
チーム内の開発者間の競合を処理する方法は?[閉まっている]
これはすべてのチームで起こっています。 何らかの理由で、チーム内で競合が発生し、全体的な動機と生産性に影響します。 その一般的な問題を解決するために推奨されるアプローチは何ですか? 例: チームの一部は依存性注入の実装を望んでおり、もう一方は時間の無駄だと考えています。 一部の開発者は、チームの残りの部分が開発を遅くしていると考えています(これにより、スケジュールが遅れる理由が説明されます) 1人以上の開発者間の個人的な非互換性 ある開発者が別の開発者と話すことを拒否する(明白な理由なしに)

5
最大でターゲットへの弾丸のパスを計算するためのアルゴリズム。2リコット
悪いタイトルで申し訳ありませんが、私はそれを表現するより良い方法を持っていませんでした... Wiiには任天堂による素晴らしいゲームがあります(そうです!)。9つのミニゲームがあり、私のお気に入りはタンクと呼ばれます!。自分自身を破壊することなく、COM敵の戦車を破壊することです。レベルのスクリーンショットは次のとおりです。 戦車を破壊する1つの方法は、弾丸を発射することです。このライムグリーンの敵の戦車は、2回跳ね返る(壁やブロックに対して)高速弾丸を発射します。プレイヤーの戦車が現在の場所に留まっていると、プレイヤーの戦車が即座に破壊される様子を見ることができます。中央の石灰戦車は、画像に描いた緑の道に沿って弾丸を発射できます。 私はアマチュアプログラマーとして、ライムタンクがプレイヤータンクを撃つためにどの方向に発火すべきかをどのように決定できるのかと思っていました。 私は自分でそれについて考えましたが、可能なアルゴリズムを思いつきませんでした。誰かに刺激を与えた場合の結論を説明します。説明を簡単にするために、壁は弾丸が跳ね返ることのできる表面であると想定しています。したがって、ブロックの孤立した長方形が4つの壁を形成します。 私は、弾丸のリコットが常に平行四辺形の片側にあるか、平行四辺形の反対の頂点になる2つの点を結論付けました。射撃する敵の戦車と、それが狙うプレイヤーの戦車は、必ずしも他の2つの頂点ではありませんが、平行四辺形の4つの側面のいずれかと同一線上にあることは間違いありません。以下は、平行四辺形を形成できる4つの可能な方法の説明です。 HOR-VERは、弾丸が最初に水平の壁に当たり、次に垂直の壁に当たります。 そして、私は立ち往生しています。敵の戦車とプレイヤーの戦車をマップ上で接続するラインを移動して、壁との2回のヒットで平行四辺形を形成するかどうかを考えましたが、敵の戦車とプレイヤーの戦車は平行四辺形の頂点と必然的に一致します。 また、アルゴリズムの一般的な流れがわかりません。アルゴリズムは次の2つの構造のいずれかを使用しますか、それとも両方とも間違っていますか? 考えられるパスを常に把握し、常に1つを最良としてマークし(最短、最も不明瞭、最も避けられない、または複数の基準に基づいた組み合わせおよび重み付けの評価)、残りは忘れます。すべての計算後に残ったものが最適です。 最初に弾丸で到達可能なすべての壁を決定し(これらの各壁に到達するために弾丸が他の壁に跳ね返る必要はありません)、次にこれらの各壁のすべての到達可能な範囲を決定します(遠くの点に到達できない場合があります)別の壁があなたの近くに立っている場合は跳ね返りのない壁)、再び跳ね返りで到達可能なすべての壁、およびこれらの壁に到達可能なすべての範囲を決定します。これらの4つのプロセスは、レイトレーシングと同様の方法で実行できます。各プロセス中に、プレイヤーの戦車が光線に当たった場合、その光線に従って弾丸の経路を見つけます。 私の意見では、このアルゴリズムは次の理由で把握するのが困難です。 弾丸はどの方向にも発射できます。そして 数学のように、線上に無限に多くの点がある壁には、無限に多くの点があります。 しかし、任天堂の人々はとにかくそれを作ったので、...アイデアを持っている人はいますか?

3
圧力がかかっているときにソリューションにジャンプしないようにする方法は?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 特に厳しいプログラミング期限(1時間など)にあるとき、私がまったくパニックに陥った場合、私の傾向は実際の計画なしにコーディングに飛びつき、私が進むにつれてそれを理解することを望みます。十分な時間を与えられれば、これはうまくいく可能性がありますが、インタビューでは、まったく逆効果ではないとしても、かなり失敗しました。時計が時を刻む間、私はそこに座って考えるのがいつも快適ではありません。 チェックリストはありますか、またはコーディングを開始するのに十分なほど問題を理解したときに認識するテクニックはありますか?いくつかの実験をコード化してより多くのことを考えて設計し、後で全体的な設計を理解することが最も生産的ですか? ここに数学試験を受けるためのテクニックと口頭試験を受けるための別のリストがあります。プレッシャーのかかったプログラミング問題を処理するための同様のテクニックのリストはありますか? 回答:これは有効な答えだと思います:解決方法。私はそのリンクが解決策に向かって解決またはアプローチするためのステップへの答えとして見つけました。でいくつかの本当に良いヒントもあった本当にインタビューの最善の戦略中に大声で考えているのは?。TDDの素晴らしく簡潔な議論は、TDDに対する最初の答えです。。

6
特定のケースの解決よりも一般化されたソリューションを好む場合
プログラミングでは、考えられる各ユースケースを個別にカバーするか、一般的な問題を解決するという選択肢に直面することがよくあります。 差し迫った問題を解決する方が速いことは明らかですが、一般化されたソリューションを作成すると、将来の時間を節約できます。 有限のケースのリストをカバーしてカバーするのが最善であるか、またはすべての可能性をカバーする汎用システムを作成するのが最善であるかをどのようにして知ることができますか?

4
Monadsはどのようなプログラミング上の問題を解決しますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 3年前に閉店しました。 私はモナドがどのように、何であるかを説明記事をたくさん読んだunitし、bindそれは目がいくつかのつまり完全に無視して、出血との奇妙なアナロジーに触れます(少なくとも私にとっては)それらのいくつかは、抽象ので圏論にまっすぐ急落仕事を、ブリトー、ボックスなど。 数週間の研究と多くの揚げたニューロンの後、(私は思う)モナドがどのように機能するかを理解しています。しかし、私の理解を逸するものがまだ1つあります。実際に触れている投稿はほとんどありません(IOと状態を除く)。 どうして? モナドが重要なのはなぜですか?なぜそんなに重要なのですか?彼らが解決している問題は何ですか?これらの問題はMonadsでのみ解決できますか、それとも他の方法がありますか?

8
インタビューでは、難しい質問に対するブルートフォースソリューションをコーディングするのがよいのでしょうか、それともインタビューを注意深く質問を調べるのに費やすほうがよいでしょうか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 インタビュアーが意図しているかどうかにかかわらず、インタビューの質問は難しい場合があります。限られたインタビュー時間を使用して、い、非効率的なブルートフォースソリューションをコーディングするか、インタビュアーで問題のあらゆる側面を理解する時間を費やすかを選択できます。 たとえば、Project Eulerの問題91は、可能性のあるすべての三角形を計算し、isRightTriangle()テストを記述し、テストに合格するすべての三角形をセットにポップするというそれほど難しくないブルートフォースソリューションによって解決できます。しかし、X / Y座標の2つのペアにより、高い定数値を持つO(x ^ 4)解が作成されます。友人と私は、はるかにエレガントで効率的なソリューションを思いつきましたが、2人で3時間かけて数十個の図を描き、複数の数式をテストし、複数のアプローチを検討しました。 すべてのインタビューの質問が公正であるとは限りません。また、ある人にとって簡単なことは別の人にとっては難しいかもしれません。誰かが質問に苦労した場合、ブルートフォースのい解決策が効果的であることにもっと感心しますか?または、優れた問題理解とエレガントなソリューションへの道を歩んでいますが、コード化されたソリューションはありませんか?20分後には、何があってもコーディングを始めるべきというようなルールはありますか?

7
圧倒的なコードを管理可能なチャンクに分解する最良の方法は?
特定のレベルの複雑さに達すると、大規模なプロジェクトに絶えず圧倒されます。プロジェクトの特定のポイントに達すると、進行が遅くなり、絶えずステップをたどり、あらゆる種類の混乱を整理します。 私のこの弱さのために、リファクタリングが本当に上手になりました。そして、私は常にオブジェクトをより小さく管理しやすいものに分解しようとしています。この弱点のために、物事を適切に設計することにあまりにも注意を払うことになりました。 問題を小さな問題に分解できれば、スムーズに達成できると思います。頭に浮かぶ戦略の1つは、テスト駆動開発です。他に何ができますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.