そもそも前提が全く違う。
課題は『答えが合っていないとダメ』ではないです。
むしろ、『考えること、調べること』が大事なのです。
もちろん、正解するのがベターかもしれませんが、出題者はそこまで望んでいないはずです。
課題丸投げして正解するよりも、間違ってでもいいので自力でやっている方がかなり評価が高いです。
(私が出題者および単位を与える側ならそうする)
課題丸投げは言い換えると、『自分は努力せず、他人に労力を強いること』です。
さらに、プログラミングは『こう書けばいい』……ではないです。
自分で設計し、自分でコーディングし、自分でデバッグし、自分でテストまでする。
これは当たり前のレベルです。
また、一括処理程度ですら1~2日ぐらいは当たり前のように使います。
それで、他の方々も『丸投げは非推奨』と言っているのです。
……と言い過ぎましたね。(;^ω^)
次からは実際の回答です。
[回答編]
Step1. 仕様を確認せよ
まず、問題を解く前に、『仕様を確認せよ』です。
実務なら仕様書、今回のように課題や競技プログラミング等であれば問題文です。
Step2. 現実世界でならどうするかを考える
プログラミングは『こう書けばいい』ではなく、
、『プログラムは魔法でもなんでもなく、人間が現実世界でやっていることを逐一指示されながら処理しているだけの代物である』です。
よって、『現実世界でならどうするか』を考える。
たとえば今回の場合、
[言い換え]
とある学生4人が5科目のテストを受けた。
それぞれ、A, B, C... と本人達がそれぞれの点数を言うため、
あなたは各教科の平均点、および各人の平均点をノートに記述せよ。
という感じでしょうか。
(ヒント等は省いています)
で、今回は省略しますが、この部分はご自分で考えてください。
Step3. 規則性を見付けたり、言い換えたりする
今回の本来の問題文を読んでください。
国語 数学 英語 理科 社会
A 80 75 60 95 76
B 44 59 56 46 28
C 88 67 98 77 75
D 48 86 79 87 76
この書式を見て、何か思いつきませんか?
そう、Excelの方眼用紙(?)です。
arr[行][列] とし、1から始まるとしたら、
arr[1][1] は "A" ですね。
Step4. 必要なものを調べる
今回のもので使いそうなもので、必要そうなものを考えます。
たとえば、ヒントとして『ダブルforループ』とあるので、これは必須。
実際の呼び名は違うと思いますが、簡単に言えば入れ子です。
forは『範囲が分かっている時』です。回数も範囲で考えることが出来るので。
配列を使えということなので配列も必須。
それ以外にも入門書等にあるもの、後は関数等も調べる。
Step5. 実装
今まで出てきたものを実装します。
Step6. デバッグする
エラーが出てきたらエラーメッセージを読んで対処し、結果が合わないならデバッガ等を使ってデバッグをする。
後、エラーメッセージは読みましょう。
エラーメッセージは怒声でも暴言でも罵倒でもハラスメントでもなく、
『コンパイラ等からのメッセージ』です。
「エラーが出た(泣」とやっている人はプログラミングなんてできません。
だって、コンパイラ等からのメッセージですよ?
言い換えると、『相手の話を聞かずに、逆ギレしている人』です。
そういう人はコミュニケーションなんて取れませんよね。
なのでメッセージぐらいは読みましょう。
Step7. テスト(検証)する
たとえば正常系と呼ばれる、問題のない動き。
ちゃんとしたデータを入れたときとかのやつですね。
後は異常系。たとえば「不正な値が入力された」時とかです。
実際にありうるものだと、「『半角英数字10文字以内』と書かれているのに、全角文字を入れようとした」とかのです。
C言語の場合、そういう場合はバッファオーバーフローが起きやすい(やり方によっては回避できるが)ので。
競技プログラミングや課題程度ならそこまで意識しなくてもいいですが、慣れておくといいですよ。
[追記0]
ヒントのダブルforは、外側のforで行の制御、内側のforで列の制御をすることが多いです。
(あえて逆でやったり、仕様に因っては違うが)