私はティーネイジャーの時に一回アメリカ留学して（文系）、さらに社会人としてパートタイムでアメリカの大学を出ました（理系）。一回目は本当に勉強せずに遊んで過ごして勉学的にはなーにもしてなくて、２回目の時は心を入れ替えてほぼオールA（A+も多く）で卒業しました。なので、「失敗例」と「成功例」？両方経験済みです。（ちなみに留学前から英語は大丈夫だったから、１回目からELSなしで授業受け始めた。）
なので、もし今後留学（特にコンピュータサイエンス）で留学したいという若い子がいたら、参考になるかと思い。
ちなみに、遠い昔に日本の学校でやった、文系／理系の適正検査みたいなやつ、あれ私は文系と理系真っ二つで、「どっちでもいける」と出たぜ。今思うと暗示的だな。
まず前提として、特に留学後何らかの形でアメリカに残りたい場合は、成績重要。オールAを目指しなさい。
そもそも大学院に進みたい場合は、単純に成績がないと話にならないしね。
就職するにも、今後ビザをスポンサーしてもらう外国人としては、オールA（まあせめて専攻科目くらい？）を取れるくらいスキルがあると証明されたし。それに、新卒で履歴書には学歴欄に「〇〇大学XX年卒業見込み、GPA 4.0」と書ける。他に大したキャリアがない場合、これくらいは書けないと。
（ちなみに私は決して学歴至上主義でもないつもりだったけど、前の会社で社長の知り合いの娘みたいな子が大学１、２年の時にインターンの面接に来て、上司に私の下につけたいからと面接を頼まれたことがあった。良いCSの学校の生徒だったけど、あまり開発経験がなく、話しててもあまりコーディングに強い印象がしなかったので、思わず「今までどんなCSクラスを取りましたか？（成績的に）どうでしたか？」って聞いちゃった。Bくらいって言われて、「う〜ん、彼女仕事できるかなあ」って悩んじゃった。まあ正直者で良い子だったんだけどさ。）
さて、私の１回目の学校生活と２回目の違いは、まずは気合いだよ。Aは、狙わないと取れない。１回目は、私はぶっちゃけCでも単位取れればオッケーだった！
あと、ぶっちゃけ私は学生の頃、勉強の仕方を知らなかった！！！宿題をやるとか勉強するというコンセプトがそもそもなかったんだわ、若い頃は。なんかなんもしなくても、まあなんとかなってたから。私が本当の意味での勉強方法を学んだのは、多分数学のベクトル積分のクラスかな。。あの先生は難しかった。。。
なので、まあ２回目はちゃんと勉強してたよ、ということだ。
まあどの先生もクラスの初日にシラバスを配ってクラス内容の説明をするんだけど、多分そこで成績のつけ方みたいなのも話されるはず。テストがいくつあって、その点数が成績の何割を占めるか、宿題やプロジェクトなどの提出物が何割か、などなど。先生によっては、カーブで成績をつけたり（うちの州立の学校はそうだった：Aがクラスの何割、Fが何割って決まってる。だいたいB,Cあたりが多くなる。そういう場合は、テストが難しくて平均点が４０点とかに設定されてたりする）、単純にテストの点数で成績つけたり（９０点以上がAとか）する。
まあA狙うには全部制覇だから、「じゃあこれを落としても大丈夫」みたいなのはないんだがな。でもまあ今後の指針としては今後どんな宿題が出てくるかとか、どういう労力の配分が必要かだとか、チェックしておかないとね。
まあ例えば英語のクラスで作文とかレポート提出とか、そういうのは単純に言われたことをやって提出するんだな。クオリティを上げる必要があるので、学校のチュートリアル・センターみたいなとこに駆け込んだり、頭のいい彼氏／彼女が入ればちょっとチェックしてもらったり、まあ使えるものはなんでも使え。
ちなみにうまい文章を書くには、topic sentence(s) ってのを意識するといいよ。全ての英語の先生が教えてくれるかわからないから、ここに書いとく。これが何かは、まあ検索しておくれ。（英語的に）「うまい文章」ってのは、ああいう構造的な小手先の技が必要なのさ。ロジカルなパラグラフの分け方とか、繋ぎ方とか。
私は昔ダメ生徒をやってたせいで、同じ英語のクラスを別の先生で複数回とったことがあるけど！、全ての英語の先生がああやってロジカルに文章の組み立て方を教えてくれるわけじゃなさそうだよ？（もしくは私が聞いてなかったか。）
ちなみに君らは理系だ。美しい言い回しや表現を使おうとは思わないことだな。主張したいことを論理的にシンプルな表現でまとめればいいんだよ。（たとえそれが英語クラスのエッセイであってもね。）
数学と物理の宿題はねえ、得意な場合はいいけど。
私の場合、数学の「宿題は」なーんにも考えずに普通に問題なく解けたのよ。でも、なぜかそれと同じ問題をクラスで小試験（クイズ）として出されると、なんか「あれ？私家でどうやって解いたっけ？」って、パニクって解けなくなったりした。
（先生によっては、宿題をやったか確認するのに、ノートを提出させるのではなく、同じ問題集からいくつかピックアップして授業の始めにクイズとして出してた。）
なので、数学の宿題をやる時は、「なぜ、そうやってるのか」という筋道をちゃんと納得した上で解かないと、短時間でヒラメキに頼れないクイズでは私は使い物にならないという事を学んだ。
あと、微分あたりの数学の宿題も、教科書の宿題は教科書の内容に沿ったシンプルなものが多く、「ああ、これはあのページに出たのと同じやつ／やり方ね」という感じで、問題なく解けてた。でも、この先生は、テストには今まで見たことのない問題を出してきて、もう意味不明だった。この先生で微積分3と微積分4の２つのクラスをとったけど、両方単位落とすかと思ったもん。
（あるクラスメイトは、微積分3を別の先生で取った後、この先生で微積分4で一緒のクラスになったのだけど、「私前のクラスではAだったのに、この先生のテストは全く解らない！」と２つのテストでFをとった後、ドロップしてました。）
でも、この先生のおかげで、数学とは／物理とはなんぞやというのが、ようやく理解できましたよ。（もともと物理の人で、リタイヤ後に数学教えてた。）
「見たことない問題」というのは、まあそれはそうだったんだけど、でも実はそれまで習った公式を「本当に」理解してれば、単なる応用だったわけ。
つまり、それまで私は内容を「本当に」は理解してなかった、というか、そこまで理解する必要があるということを、判ってなかった。
まあなので、数学／物理に関しては、単に与えられる宿題をやってるだけじゃ、Aは難しいかもよ、ということね。(まあ先生にもよるけど。)
なので本当、気合いが必要なのよ。（特にこのあたりのクラスになると、周りみんな理系なわけだし、中には物理や数学専攻の生徒もいるわけだから、彼らに負けずにAを取る必要があるぞ。）
単にパスするだけなら、宿題さえやってればいけるでしょ。
あ、ちなみに理系のクラスで怖いのは、前のクラスの内容をちゃんと理解できないと、次のクラスも難しいということかな。
だから頑張ってね！
コンピュータサイエンスのクラスに関してだけど、まあ一般的に、そういう物理•数学的な思考回路ができてれば、問題ないんじゃない？（むしろ、そういう思考力を育てるために、これらの教科が必須なのかと思ってしまうが。）
なんていうか、もう頭がよければ、なんでもいいんじゃない？？
そしてプログラミング系のクラスね。コーディングがうまくなる方法はねえ、うまい人のコードをたくさん読むことかなあって思う。
私の場合、昔MITの卒業生が起業したソフトウェア会社の日本支社で働いてた時、もちろん普段の業務でも必要だったのもあるんだけど、でも製品の細かい仕様を知る為に、たくさん製品のソースコードを読んだのよねえ。
そのコードがあまりにもすっきりシンプルで読みやすくて、本当に綺麗でびっくりした。無駄がないというか。（コーディングがシンプルになるように、デザインされてる。）
私のコーディングもそれですごい上達したと思う。
学生だった時、あるクラスの学期末プロジェクトで、先生が私の成果物を見て、「あなたのコード、シンプルでびっくりした！もし仕事探しでリファレンスが必要な時は、私に言って」と言ってくれた。
シンプルはいいんだよ。というか、シンプルに落とし込めるスキルがいいんだよ。
あんま苦労して無理くりコード書いても、時間がかかるだけだし、バグが出やすいし、後で読み返すにも単純に読みにくいし。
まあ今も仕事や（以前だと学校なんかでか）なんかで他人のコードを読むことが多いけど、たまに下手なのに当たるとわかるね。ていうか、「苦労の後」が見えるんだよ。「あー、この人、苦労して書いてんな」って思うのがたまにある。
ぶっちゃけ、ある時ある同僚のコードを初めてみて、「この人コーディング下手だなあ（苦労してんなあ）」と思ってたら、その後彼はマネージャー職にジョブチェンジしてました。
まあ、そういうことなんで、コーディングがうまくなるには、うまいコードを読むと良いかと。
それがどこで読めるかとか知らんが。オープンソースプロジェクトのコードとかかなあ。
オープンソースプロジェクトに参加しろとは言わん。（私もしてない。）
でも、ひたすらコードを読むのはいいかもね。単なるメソッドの実装だけじゃなくて、もっと鳥瞰的に？どう全体をデザインしてるかを見るといいかもね。
あと、もちろん普遍的なコーディングのお約束ごともあるけどね、メソッドの実装はできるだけ短くするとか、同じことをやるロジックを何度も書かない（コピペしない）とか。そういう読みやすいコードを書くコツは、多分初級のプログラミングの本に色々散らばってると思うよ。そういうのもちゃんと学ばないとね。
あと、学校でも習うけど、デザインパターンの知識は必要かな、大抵Java のプロジェクトのどこかには、デザインパターンの何かが使われてるはず。あらかじめパターンを知ってれば、「ああ、ここのコードはあのパターンを使ってこういうことしてんだな」ってのが、ぱっと見でわかる。
あ、あと、もちろん、他人のコードを読むだけでなく、自分でもちゃんと書かないとね。
自然言語の習得でもそうだけど、インプットのほかに、アウトプットも必要よ。
なんか自分の興味あるもの、自分用に書いてみたら？ 小さいものから初めて、徐々に機能を拡張していくといいよ。バージョン１、バージョン２ってね。
設計がまずいと、拡張が難しくなるかもよ。機能が拡張しやすいデザインができるといいね。
あ、あと、アメリカの大学に行くには、英語力も必要なのか。
ひたすら色々読んで聞いて（インプット）、ひたすら書いて喋る（アウトプット）するしかないねえ。私はいわゆる「単語帳」みたいなので単語を勉強した覚えはあんまりないんだよね。私は使って覚えたかな。ていうか言語は使わないと覚えないよ。
もし単語帳を使って単語を覚えるなら、私だったら多分その単語を使った文章を書くとかかなあ。時間はかかるけどね。
英語で日記書くとか。あと、英語で読むなら、技術書はプレインな英語で書かれてることが多い。文系の本はなんかもっとまどろっこしい英語が多い印象。どうせ今後必要になるんだし、プログラミング言語とかデザインパターンとかの本とか試してみれば？
例えば大学３年生レベルのアルゴリズムの教科書までいっちゃうと、逆にちょっとアカデミックになって難しいかもしれない。
別におすすめの本はないんだけどさ、私あんま本読まないから。。
リスニングのインプットは、テレビはあんまり役に立たないかなあ。ニュース英語とか、あれは綺麗すぎるんじゃないかなあ。アナウンサーみたいな英語はみんな喋らないよ。
私的に、こっちでリスニング強化にすんごい役立ったのが、ラジオのスポーツとか政治のトークショー番組だね。一般参加型の。DJが好き勝手に喋るし、電話で参加する一般視聴者なんかも勝手に自分たちのアクセントで話すし、言い合ったりするし、ホストが複数の場合も多いし。要は、複数の人がなんやかんやで談合してるのを聞き取るのが一番むずいんよ。
一対一なら、相手がちゃんとあなたにわかるように話してくれるし、何か聞き漏らしても、聞き返しやすい。
複数人の会話では、そういう考慮があんまないからね、特にネイティブの集まりに外国人が自分一人の場合。下手すると平気であなたそっちのけで会話が進むぜ。
まあ、そんななんで、ラジオや、今ではポッドキャストとかかな、ホストと視聴者、複数のホストなんかがネイティブ相手に容赦なくマシンガントークをお互いにしてるようなものを頑張って聞くのが一番効くかなー、と私は思う。
まあ、映画の「13ウォーリアーズ」じゃないから（見てない人は見て）、周りの会話をただ聞いてるだけでいきなり話せるようになる、なんてミラクルは起きないけど。
ちなみにこれがそのミラクルシーン。
まあそもそも、対面で話すよりも電話なんかで顔見ずに話す方が一般的により難易度が高いんだわ。やっぱビジュアルから入って来る情報がないからね。だからその点でもテレビよりラジオなんかがおすすめだな。
radio talk show とかtalk radioとかでグーグル検索すれば、いろいろステーションが出て来るかと。今は多分どのラジオ番組も、オンラインで聴けるようになってると思う。日本の番組って、アメリカでは聞けない／見れないようにブロックされてるんだけどさあ（なんなのあれ）、多分アメリカのは日本でいけるんじゃないかなあ。昔日本で働いてた時に、同僚がSFベイエリアの音楽ラジオ番組を日本でオンラインで聴いてたし。
例えばSFベイエリアのだったらhttps://www.ksfo.com かな。
バックグランドで流しとくってよりも、ちゃんと内容を理解しようと頑張って聴いた方がいいかも。
ちょっと早口かもだけどね。