The many recent grads that step their foot into the Bay Area to begin their career are highly ambitious, motivated, full of good intentions, and in general, just want to do well. There are many opportunities, meetups, people to talk to, and things to do that revolve around careers, so at times, there are a lot of low-hanging fruits for us to pick. We have a lot of questions. Recently, I hit my six month mark working as a software developer at Looker Data Science. I was very curious about my progress at the company so far – am I hitting my stride? Am I meeting expectations? How and what can I do better moving forward? Have I disappointed? Am I going to be fired today?
As you can already tell, I had a lot of questions. After speaking with my mentor and manager, I learned that I was asking myself the wrong questions.
One of my favorite things about working at Looker is the culture of mentorship – it is one of the core values of Looker. The first day I joined Looker, Adam Markowitz, a senior engineer at Looker, was assigned as my mentor. I am able to go to Adam and ask him pretty much anything. Mentorship extends to the higher ups as well, as I have weekly one-on-ones with Roland, my manager, to also discuss pretty much anything - my progress, what is stopping me, what I need help on, what is going well, how many dogs I’ve pet, and more.
Recently, I scheduled a lunch chat with Adam to talk about my career. I also told Roland prior to our weekly one-on-one that I wanted to talk about my progress so far in the past six. I prepared a few questions going into each conversation:
1. What are an engineer’s expectations at Looker, and how does one meet those expectations?
2. How does one exceed those expectations?
3. What are some things you wish you learned earlier when you first started your career?
4. And a super open-ended question – how do you become successful?
While talking to Adam and Roland, one thing is clear – hitting expectations is easy. Hitting expectations as an engineer can be as simple as doing the work assigned to you to the best of your ability, testing your fix or feature to cover many cases, and not rushing to finish in order to make a release. That’s really not that hard.
The parts I was dying to know were – how do I exceed these expectations? How do I become successful working at the company?
To sum it up into one sentence, exceeding expectations is about saving time. Are you saving the company’s time? Are you saving a department’s time? Are you saving someone’s time? Are you saving your own time?
After talking to them, I summarized what I learned into five points:
- Work on side projects that helps the company in some way
An example of a side project is the recent Slack bot for Looker created by Wil G, one of our product engineers. Slackbot was a weekend project Wil implemented that ultimately received a ton of use by customers and good press. The use is stupidly simple – you ask a question on Slack, and the Looker Slackbot returns the answer about your data.
- Check out the open issues an engineer may have on their Github and dive right in
Every engineer has a task list on their Github. Check out what is an open issue and dive right in (permission may or may not be needed). Before you dive into someone else’s issue, ask yourself – will this issue save not only the engineer’s time, but also someone else’s time? Will it bring the team or company forward? Do note, this is not an excuse to ignore smaller bugs or maintenance issues, so use your best judgement!
- Just ask
Talk to fellow coworkers, ask them what they need help in, what is blocking them, what is something they would like to implement, and then work together on this.
Adam is one of the engineers that works in the performance and scalability side of Looker, something I am also interested in. I talked to Adam expressing my interest in this area, and at the same time, requested with Roland that I would like to work more on projects that involve the performance of Looker. If there is something you are interested in, it doesn’t hurt to ask.
- Do things that ease the burden of other departments at the company
Does our customer support team, as an example, have a bottleneck on a certain issue that continuously wastes their precious time? Can you think of a solution and implement it? If so, this could be a good problem to solve. Saving time and providing a solution to a problem is not confined to just the engineering team – if you can ease the burden of another department, it is highly encouraged to do it.
- Do things that save engineer’s time, where time quite literally is money
Looker’s dialect unit tests routinely take over two hours to complete. Adam knew this was an issue, so he just went ahead and worked on a fix that optimized the tests to run up 30 to 50% faster. Saving an hour or so time from an engineer is quite literally saving money. That’s huge.
Other than saving someone’s time, all of the previous points also have another thing in common – they are proactive actions. If your company culture permits this sort of attitude, when you see a problem, just go ahead and fix it. No permission needed. No barking at the fence. Just do.
In response to the question of “what are some things you wish you learned earlier when you first started your career”, the general consensus seemed to be that if there’s an opportunity that scares you, will challenge you, and is difficult, you should take it. Leave yourself little room to regret. Also, take maximum advantage of what you have right now, which is time. Invest in your 401k, no matter the amount. The earlier you start, the better.
It turns out, being successful at the company is about bringing success to the company, the team, and your customers. Here are some questions you can ask yourself to reflect on what you do:
- Are you doing things that save someone’s time?
- Is it easing a particular burden that someone, some team, or some customer is experiencing?
- Are you communicating with others on what should be done?
- Is there an inefficiency somewhere that you can provide a solution to? Can you do it?
- What am I doing well? What can I do better in?
I entered the conversation with Roland and Adam with questions for them, and I left the conversation with questions for myself. Six months went by quick; I wonder what other questions I will come up with in another six months?