[ML Engineer Stories: Lab Edition] How my lab, hackathon, and internships paid off after I joined a company

Introduction

Hi, I’m kittchy.

This is the second post in my “ML Engineer Stories” series. Once again it’s for students doing ML in a university lab who want to become ML engineers. Last time I wrote about getting hands-on with things outside ML. This time it’s about where the way I spent my student years paid off at work.

The lab wasn’t the only place I learned

As a student I spent my time in the lab, at a hackathon, and at internships, and each gave me something different.

Lab: building fundamentals through experiments and papers

My research topic was domain adaptation for speech recognition. I read a lot of related papers while running experiments, so my basic knowledge of machine learning grew a lot during this time.

Hackathon: once wasn’t enough

I only entered one hackathon: HackAichi+2023, an inter-university hackathon in Aichi Prefecture. I discovered the joy of building things, and the other participants pushed me to pick up knowledge around the edges.

Hack Aichi | 愛知県大学対抗ハッカソンHack Aichiは、愛知の企業が保有する技術シーズをもとに、大学生がサービス・アプリケーションを考案する“大学対抗ハッカソン”です。大学生の研鑽、IT人材育成に取り組むことを目的としています。 Hack Aichi

On the other hand, people who had entered many times built things fast, and I came to see hackathons as strength training for development. If you enter one, don’t stop at one. Enter many.

Internships: go to many different companies

I interned at three or four companies, and each taught me from a different angle. Running lots of model training and speech processing experiments gave me the stamina to keep experiments going, and I gained implementation skills and web service basics that research doesn’t give you. Going to many companies helps you understand companies and helps you grow.

If you want to go a step further, it’s also worth leaving school to work for a while. Personally, I think finishing your undergraduate degree, working at a company, and then going to graduate school is the better way to produce research results.

I got off to a fast start after joining

What helped most was getting up to speed right after joining. In ML engineering, the services and infrastructure that run a model come up as often as the model itself. Because I had basic knowledge, broad if shallow, I didn’t get stuck at the entrance even with technologies I was touching for the first time.

The company I joined used Kubernetes, and I got into it surprisingly smoothly. Of course I didn’t do nothing: I studied for the CKAD and read a lot of related books. I had never written Ruby either, but with help from AI I could write it better than I expected.

How I ran my research became how I run my work

As a student I had to make my research succeed and finish papers on my own, so I set up my own research management and process. At work, deciding what to do, by when, and how far comes up more often than building models, and that skill is paying off there.

Connections from my student years help too

My connections with student friends also mattered. Many of them are in mechanical or electrical engineering, and I still learn a lot from hearing what’s going on at their companies.

You should go to conferences too. I went to the Acoustical Society of Japan meetings and PyCon, and hearing talks outside my research field gave me broad knowledge. I still want to go to more kinds of conferences.

Where I still fell short

What I lacked was experience developing inside large systems. The company I joined as a new graduate taught me a lot there.

I also wish I’d learned more about project management and organizational theory, and read books on the philosophy of code and of organizations. Among the books I read after starting work, Clean Architecture impressed me most for code, and Team Topologies was the most interesting for organizations. But that’s something I only understand now that I’m working.

Clean Architecture 達人に学ぶソフトウェアの構造と設計生活・実用書「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のあらすじ、最新情報をKADOKAWA公式サイトより。アーキテクチャのルールはどれも同じである！ KADOKAWAオフィシャルサイト

チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計DXが進み、ビジネスはIT・オンラインを基準に変化が加速している。この大きな流れを受けるのがソフトウェア開発である。またソフトウェア業界としては、アジャイルやDevOpsなどの手法を開発して、時代の移り変わりの速度に合わせるように、いかに効率的にサービスを提供できるかを試行錯誤してきた。 本書は高速なデリバリーを実現することを目的とした、4つの基本的なチームタイプと3つのインタラクションパターンに基づく、組織設計とチームインタラクションのための実践的な適応モデルを紹介する。これは、ソフトウェアの組織設計における大きな前進であり、チームの相互作用と相互関係を明確に定義した方法を提示することで、チーム間の問題を組織の自己運営のための貴重なシグナルに変え、結果として得られるソフトウェアアーキテクチャをより明確で持続可能なものにする。これにより組織に適したチームパターンを選択して進化させ、ソフトウェアを健全な状態に保つことで、バリューストリームを最適化するのに役立たせることができるだろう。 【目次】 PART I デリバリーの手段としてのチーム Chapter1 組織図の問題 Chapter2 コンウェイの法則が重要な理由 Chapter3 チームファースト思考 PART Ⅱ フローを機能させるチームトポロジー Chapter4 静的なチームトポロジーチームのアンチパターン Chapter5 4つの基本的なチームタイプ Chapter6 チームファーストな境界を決める PART Ⅲ イノベーションと高速なデリバリーのため にチームインタラクションを進化させる Chapter7 チームインタラクションモード Chapter8 組織的センシングでチーム構造を進化させる Chapter9 まとめ:次世代デジタル運用モデル 紀伊國屋書店ウェブストア｜オンライン書店｜本、雑誌の通販、電子書籍ストア

Closing

What I use at work isn’t only the ML knowledge I gained from research. Knowledge of service development got me up to speed quickly, and the experience of running research on my own helps with how I run projects.

If you see your research through and also do the following while you’re a student, it will pay off after you join a company.

• Hackathons: don’t stop at one, enter many
• Internships: go to many different companies. Working once before graduate school is also an option
• Conferences: go to both academic meetings in your own field, like the Acoustical Society of Japan, and conferences outside it, like PyCon
• Books: read books on how to think about code and organizations, like Clean Architecture and Team Topologies

Next time I’ll write about what I’m glad I did in my first two and a half years of work. See you.