CO-OP at insightFinder

After my summer internship at Facebook, I started to work at insightFinder during my second master’s year. As a star-up company, insightFinder gave me a lot of different experience than working at a large tech company such as Facebook, and taught different things.

The Story

Onboarding

Starting to work is quite simple here. One of my friend as well as classmate took me to our office on my first date to work. He worked here during summer and will continue for the following semester, and he will be the one to guide me.

We had lunch together with two other co-workers and they introduced our overall infrastructure on the first day. Then I spent most of the day setting up my environment and making things running.

Our stack includes Java backend, javascript UI, RabbitMQ, in-house C++ machine learning library and several agents on Splunk, AWS and Logstash. I was mainly focus on the backend development at that time and got a easy-fix for warm up.

Struggle as a noob

At the beginning, I spent most of time learning and discussing. As I got familiar with the development cycle, I was soon assigned to improve an existing feature.

This is the time I really struggle with. I know the overall structure, but I hardly understand the code base, which is to me poorly maintained and documented. I have to ask people around about how things work and where should I start with, and no one knows everything! Sometimes I have to call previous employee to get the answer and even our CEO had taught me for several times.

After struggling for some days I got to know how backend is working here, and began to make progress on each tasks. Well, months later I realized the quality of work at this time is not good, code are buggy and not well formatted, and I have to rewrite some of them. But still, it feels good when making progress.

Make progress and celebrate

Though struggled, I was learning and finishing projects one after another. Gradually I realized there are parts of the system I was responsible for, and as a member in a small but busy team, that means you may working on things beyond coding. I started joining meetings with customers, writing user guides and things like that. It is interesting to know things like these and I feel close to the company.

In the mean time the team is also making progress. We got new customers and demos came one after another. And extra hours always needed before a demo day. Life is stressful but rewarding. Good news is a new investment allows us to expand the team. We some both new-grad and senior engineers coming to reduce the burden. And a bigger office is awaiting.

Dive deep with experience

After the first semester, I kept working on winter break. Since then I worked not only on individual feature projects but also on infrastructure design, performance improvement and reliability improve. I got the chance to resolve several data processing bottleneck which is much more challenging and interesting.

Also, there are new coming engineers. And we started to enhance our code review as well as CI flow. so I started to answer questions instead of asking. I need to explain some of my work as well and assign some tasks to interns. Trying to explain and help drove me to re-think and I got deeper understanding, and make me feel I am not a noob anymore.

Leaving

Graduation means farewell. Last few weeks is still busy but I put some time to turn some work into a framework and hand over my things to another full time. And kept answering questions and saying goodbye by phone after leaving office. It’s my fortune to be part on this company and really hope these guys have a bright future.

Some Thoughts

Why an existing system should sucks

Every company have old, existing system and most of time we will work based on it. I was like to complain of it, as it looks big, merely maintainable, and hard to use. However, I gradually realized maybe it was good, and expandable enough when it was first developed. It only became a monster when our needs changed, or people left or simply forgot. And when we trying to replace it with a new system, the same complains started after some times because of the same reason.

How to resolve this? I am not sure, maybe just kept a good development practice and a peaceful attitude when you encounter a problem.

Before answer a tech question

I got a lot of questions to answer when new engineer came into team. Some days I feel like my main job is to talk and answer various questions, from infra design, code base to why a little bug happened, how to use a tool. Then I found there is something wrong with it, some questions are too simple that I don’t even need to think to give the answer, some however, I have no clue to know the answer. And sometimes, even if I have a answer, the questioner came back with another question completely different to the first one.

So I start to think of how to make this communication more efficient so that I can still have time on my own work. I began to ask questioner some questions before they start their questioning:

  1. What is the task they asked you to solve?

  2. What are you working on to solve it?

  3. Do you have better plan or another idea?

It is surprising efficient, most of the time they found the solution themselves, or they realized they are heading for a wrong direction. This save me the energy of doing context switch for answer a specific questions and can get back to my work easier.

Prepare for meetings and reports

Meetings here are more frequent, and more roles are attending. CEO, tech lead, designer, sales, and even customer. I am not a good talker and I feel sad when my explanation is misunderstood or ignored. So make sure I kept these in mind when reporting:

  1. Make sure everyone have the same context, introduce previous context if someone is missing last time, update terms and make sure everyone is using the same.

  2. Stop taking about things others can’t understand. Not everyone knows “CPU bottleneck”, “network throughput”. Use “the user need to wait for around 10 minutes because our sever have a performance problem” instead of “our message queue is blocked because of CPU bottleneck”

  3. Kept the key point first. What problem you found, and what solution you are trying. You will lose audience when you start with introducing the root cause first.

  4. Stop meaningless talk. “It can not be done”, “It is wrong”, “It can not happened”. No one wants to hear them, talk about solution, reason instead.

Start-up vs Big company

There is much more freedom in a start-up company like this. We move faster than Facebook and it’s very exciting to see my own work delivered for a big impact.

However, sometimes it is too busy and I feel a little tried. And sometimes I have work on several tasks in parallel and context switch is causing me pain and make me stressful. And there is less infrastructure to help us with the quality of work.

The Pics

Coming soon

Donate