Forem: Udara Weerasinghege

Level Up Your Resume. Why You Should Start a Career Doc

Udara Weerasinghege — Wed, 02 Dec 2020 19:35:18 +0000

Deciding which projects to put on your resume? Searching for evidence to prove you deserve that raise or promotion? Need talking points from past projects for an interview? Want to reminisce about all the great things you’ve done in your career?

If you answered yes to any of the questions above, you need a career doc.

What is a career doc?

It is a living document with a detailed track record of your career. It’s like a journal for your job. It has more depth and detail than a resume, and it’s frequently updated.

Unlike a resume, your career doc is for future-you to read, rather than for potential employers or recruiters.

At Square, career docs are called hype docs and are a central part of our culture.

Why do you need a career doc?

Our memories suck, and we forget things all the time. It’s impossible to remember everything important that happens at work. Your career doc will remember so that you don't have to.

It helps future-you have a detailed record of your past accomplishments.

Here are a few reasons your future self will be thankful you started a career doc…

1. You’ll need projects and their details to add to your resume

Most of us only update our resumes when we are looking for a job. If you’re lucky enough to be in a stable industry, this is probably every few years. And when you do, you’ll have to recall years worth of projects and details to decide which ones to put on your resume.

Our resumes are too important to be based solely on our memory. A resume is usually the first impression we give to potential employers, so we need to be selective about what we put on it.

With a career doc, you have all the projects you worked on at your fingertips, you can pluck whatever sounds most impressive, edit it to fit your resume, and you’re done.

Bonus: Using a career document, you can create variations of your resume that are custom-tailored to the company you’re applying to.

2. You’ll need evidence for why you deserve a raise or promotion

If you google “how to ask for a promotion”, the top three results tell you to prepare a case with supporting evidence to prove you deserve it. If you have an up to date track record of your accomplishments, this is simple. You can extract projects and details that support your case the best.

With a career document, you can show how your responsibilities have increased, and how the work you’ve been doing has changed over the months or years.

Managers will also appreciate your initiative. Thanks to you, they have hard proof they can show any higher-ups in case they need to get approval. Everybody wins.

Bonus: The career document can even nudge you into realizing that you’re ready for a promotion. If you see a trend of increased responsibilities and scope in your projects, it might be a sign that you’re ready to be promoted.

3. You’ll need talking points for interviews

“Tell me about a time when” questions are common in every industry. Amazon is notorious for quizzing candidates with these during their leadership principle interviews. You are sure to questions like:

Tell me about a recent project you worked on
Tell me about a time you had to fix a bug in production
Tell me about a time when you mentored someone

Coming up with examples for these questions on the spot can be difficult, but with your career document, you will have plenty of projects and scenarios that you can use to answer these types of questions with a level of detail that very few candidates achieve.

4. You’ll build a habit of reviewing and reflecting on your work

Review and reflection are key processes for both personal and career growth. These habits are built into the career document process, as you’ll need to update it regularly. Each time you update the doc, you’ll need to review your most recent work and reflect on your most important contributions.

What should you put in a career doc?

Anything at all that helps future-you when they need details about your projects and responsibilities.

Here are a few areas that you can focus on.

1. Projects

Projects will make up most of your career doc. Record any features and projects you were a part of. Note down how you specifically contributed, and make sure you add a short description of the project for context.

If you’re stuck on what to add regarding a project, you can think about questions like:

Did you write or review a technical design?
Did you work by yourself or with others?
Were there any key learnings or challenges?

Since projects can span many weeks, you should update the document as you go. You don’t need to wait until the project ends to make an entry in the doc. If you wait that long, you might forget a lot of milestones from earlier in the project.

Don’t stay purely technical either. Include how the project impacted the business. Did it drive revenue or conversion rates? Did it address a huge user pain point?

You should also add supporting evidence. This can take the form of screenshots, or links to anything relevant (GitHub PRs, Jira tickets, metrics dashboards). This will come in handy when you need a detailed account of a project, whether it’s for an interview or when you’re pitching yourself for a raise.

2. People

As you grow more experienced, mentoring, coaching, and onboarding will naturally become a part of your responsibilities. You might also start interviewing and get involved in the hiring process.

These are all important to note down in your career doc. Over time you might notice a trend where people related activities are taking more time than projects. Since this can happen very gradually, it can be easy to miss, but you can use your career document to recognize these trends and adjust accordingly.

You may find yourself enjoying the increased time spent on people which could lead to a conversation around moving to a management-type role.

3. Community

This can include activities like speaking at events, running company-wide workshops, contributing to a blog, participating in/creating employee resource groups.

These points can be a goldmine to draw from for cultural or behavioural interviews in the future.

4. Other

You can enter anything else related to your career that you’re proud of. It’s always easier to think of what important things happened over the last week or two than over the last few months, which means that your career doc won’t miss anything about your work.

A few things that fall in the other bucket and are worth noting:

You improved a process(sprint-planning/retrospectives/how on-call works)
You got positive feedback from a manager or teammate
You fixed a long-standing one-off bug that no one wanted to tackle
You completed a career-related course
You started a blog

How should you start?

Create a new google doc or whatever else you use to take notes. Bookmark it, pin it, do anything you have to do to make sure it’s as few clicks away as possible. If a weekly or bi-weekly review is already part of your schedule, you can add “update your career document” as an agenda item to your review session.
Once a week or once every two weeks, reflect on your recent work and update the doc. You can go over recent tickets, meetings, pull requests etc. to jog your memory on where you’ve been spending your time. Note down whatever stands out to you.

Don’t worry too much about the format. Writing things down is the most important part. If you see patterns emerging in the way you’re taking notes, you can always create a template for yourself.

If you would like to start with some structure, here’s a template with a couple examples. There’s also Hype Docs that makes it simple to add and view your progress.

When you sit down to update your career document, if you frequently find that you have nothing to enter, it might be a sign that you’re working on uninteresting projects without much impact. Or you’ve made it too hard to use and edit the doc.

You don’t need to have a job to start a career document. It’s a good idea to get a career doc started the moment you start gathering relevant experience in the field. You can add details about courses, side projects, community involvement, and anything else you’re doing to make yourself a more attractive candidate for jobs.

How much detail should you enter?

Start out with as much or as little detail as you want. You’ll get a feel for the right level of specificity as you add more to the document. Think about your future self, and how much context they would need to understand the points you note down.

Final thoughts

My career document is 3 years old and 5 pages long so far. If you ask me about any of my recent work, I can give you a detailed account of my major projects, and what kind of impact I’ve had at the companies I worked at.

When I looked for a job a few months ago, it only took me a few minutes to update my resume with details about my most recent job.

There have been weeks where I didn’t have anything important to put on it, or just skipped because I forgot. And that’s okay.

I hope you start a career doc too, and that it will be as useful to you as it has been for me.

8 Terminal Tools to make you a 2x developer

Udara Weerasinghege — Wed, 18 Nov 2020 14:24:19 +0000

I spend a third of my life sleeping, and I probably spend a quarter of it on my terminal, and I don’t even use vim.

I want to spend these hours getting things done, not trying to remember commands, or typing out the same command for the nth time, or figuring out which terminal window is doing what.

The following tools help me optimize my terminal for productivity. Personally, I use iTerm2 with zsh as my terminal, but a lot of the tools below are terminal-agnostic.

Here we go…

1. oh my zsh — Manage your zsh plugins easier than ever

Oh my zsh allows you to play around with a whole host of plugins by simply updating a list in your .zshrc file.

This is plugin management made so easy your grandma could do it. For example, your ~/.zshrc might look like this:

plugins=(
  git
  bundler
  dotenv
  osx
  rake
)

If you use zsh, this is an absolute must-have. If you don’t have it already, just go download it

Oh My Zsh will not make you a 10x developer…but you may feel like one.

— oh my zsh’s github page

2. powerlevel10k theme — Make your terminal fabulous

This is one of the best zsh themes I’ve used, and I highly recommend it. It’s infinitely configurable while still being friendly and easy to use. It has a better onboarding guide than most SaaS products, which makes for an easy transition from whatever theme you’re on currently.

Different styles you can have with p10k. Credit: Powerlevel10k’s github

One of its killer features is the instant prompt. When we sprinkle our terminal with plugins, it can start to get slow. The instant prompt is exactly what it sounds like, it shows you the prompt even if zsh is loading stuff in the background so that you can start typing your next command. No more waiting around!

3. fzf — Fuzzy find everything

If you get one thing from this list, get this.

Remember that one command from three days ago that you ran? No? Me neither.

You probably use ctrl+r for reverse search hoping to get what you're looking for. Stop it! With fzf you type ctrl+r once and type anything; it will fuzzy find what you’re looking for and you just pick from a list. This video is a good intro to some of its slick features that will make you a 2x developer at least.

Don’t forget to install the keybindings with the following command

$ $(brew --prefix)/opt/fzf/install

4. zsh autosuggestions — Type less, do more

Let past you help current you!

Chances are you type the same command A LOT. For example, I used to type npm run watch a million times. Now, with zsh autosuggestions, I type n and it shows npm run watch, I press the right arrow key, and I’m done. That’s a nearly 85% decrease in keystrokes. That’s a 2x developer move right there.

The grey part is what the plugin is suggesting based on my input so far

5. z — Hop around directories like bugs bunny

You probably spend a lot of time in the same few directories. z tracks your most visited directories and allows you to access them with very few keystrokes. It’s like if cd\ and autosuggestions\ had a baby.

6. git plugin — Type less, do more pt 2.

The git plugin adds a convenience layer for git with a bunch of shortcuts and functions. gl to git pull, gp to git push, gco to git checkout. Fewer words, more speed!

7. asdf — One version management tool to rule them all

I used to have rvm for managing ruby versions, pyenv for python, and nvm for node. Now I just have asdf for all my version management requirements. it works seamlessly with all the .nvmrc/.rvmrc version files and is simple to set up.

8. Iterm2 git badges — stop getting lost in your terminal

How many terminal windows do you normally have open? I usually have a backend server running on one tab, and webpack running on another. In a microservice world, you might have multiple frontend and backend services running in multiple tabs at the same time. Badges make it easy to wrap your head around what’s going on where.

How to:

Install the iterm shell integration

2. Update your ~/.zshrc with the following. It sets an item variable called gitProject.

function iterm2\_print\_user\_vars() {
  iterm2\_set\_user\_var gitProject $(basename $(git rev-parse --show-toplevel 2> /dev/null) 2> /dev/null)
}

3. Update your iterm’s profile to use the variable we created. cmd + I in iterm to bring up the profile. Then add \(user.gitProject) to the badge field

You can play around with badges to have whatever information you need upfront and center in your terminal.

I hope these tips and tricks take you a step further on your path to being a 2x developer.

There are so many more plugins. With how easy it is to install and remove plugins using oh-my-zsh you should really play around with plugins that even remotely pique your interest. The next plug-in you install might change your life.

Interview Guide for Software Developers - Part 2: Ace the Coding Interview

Udara Weerasinghege — Tue, 03 Nov 2020 19:27:31 +0000

Over the last five years, I’ve been in over a hundred coding interviews. I conducted a majority of them as an interviewer, and in about 15 of them, I was a nervous interviewee looking for a job.

In the beginning, I dreaded coding interviews. Solving algorithm problems under time pressure wasn’t my idea of a good time. But, as I got more experience on the opposite side of the table as an interviewer, I realized that it’s not just about whether you solve the problem or not. A lot of it has to do with how you solve the problem.

In this guide, I’ll go over general tips that I’ve learned can make or break an interview.

Let’s get started...

Analyze & clarify requirements

You are usually presented with a couple of sentences of requirements to kick things off. Far too often, people will start coding right away. Coding too soon without talking through the problem to verify their assumptions is one of the most common mistakes candidates make.

A good way to start is to repeat the question back to the interviewer in your own words. Once you’re sure you understand the problem, take a few moments to think of edge cases and clarify what should happen in each situation. Common areas to ask questions about are: handling bad inputs, addressing ambiguous or undescribed behaviour, different types (strings, ints) and handling exceptions.

You can usually find a few questions to ask about even the most straightforward questions. If there are tons of edge cases to cover, it’s worth noting them down as comments so that you remember to test them later.

It’s always a good idea to go over the problem with a couple of sample inputs to ensure that your output and the output the interviewer expects is the same.

Once you’ve understood the questions and uncovered some edge cases you should have some idea(s) for a way forward. It’s best to describe your proposed solution in words at this point. If you can think of multiple solutions, discuss them with the interviewer, and weigh tradeoffs. Exploring a problem space together can give the interviewer a good idea of how you think and communicate when you’re handed requirements. After all, breaking down requirements into code is what we do on a daily basis.

Some problems have multiple parts that are introduced as you solve a portion. Each time a new requirement is given, you should repeat the process of looking for edge cases and asking questions. Additionally, look out for how the new functionality you need will affect what you have so far. What will you need to refactor, and how will it modify existing behaviour?

Write clean code

Is your code readable? Are you hard coding values? Do your variable and function names make sense? Are you writing small functions or is the entire solution in one big function?

These are some things interviewers look out for in regards to your code. Sometimes it’s difficult to write production-level code under time pressure, and It’s okay to take some shortcuts. Use your best judgment; be sure to let the interviewer know “I’m doing X so I can do this quick, but I’d do Y if I were committing to production”.

Even when the shortcuts are obvious, or the naming is bad because you’re in a rush, mention anything that makes the code messier or harder to read. Remember that the interviewer knows nothing of your coding abilities outside of what you show them in this hour. The interviewer might think the shortcuts and you use in the interview are a reflection of how you code at work.

Test your code incrementally. This will help you catch and correct syntax issues as you go. If it’s a multipart problem, as you solve and test for new requirements, make sure your tests still pass for the previous sections.

Note on Coding Language*:* Are you comfortable with the language you’re working in? Some people like to use a different language than the one they use every day at their job. If you do this, make sure you are up to date on your interview language. You shouldn’t have to google how to loop over an array during the interview. Most coding interviews are fine with you looking up documentation, but you should be familiar with the basic data structures and operations. Showing mastery over the language you choose can get you extra points!

Debugging

When you run into errors and bugs don’t panic. This is a good opportunity to show your pro debugging skills. If there are compiling errors, take your time, read the stacktrace, and narrow down where things are going wrong. If there are no errors, but you have unexpected output, take a structured approach to troubleshooting. Place print statements methodically to help you find where things are going wrong. A good approach is to print out internal data structures and other key variables in your solution. You want to avoid sporadically printing things without any rhyme or reason.

Communication

If you communicate poorly during the interview, it can overshadow the rest of the interview even if you ace the actual problem. Every company I’ve been at has a section to rate an interviewer’s communication skills. Individuals don’t write code, teams do. The interviewer wants to ensure that you’d be someone they would want to work with, and a large part of that is based on how well you communicate.

Put simply, communicate your thinking throughout the interview. The interviewer should be able to follow your train of thought as if they were a passenger on it. When you arrive at points in the question when you need to make a decision or if you hit roadblocks, talk through your how you decide which paths to take, and how you unblock yourself.

Positive communication also goes a long way. When you hit an especially difficult obstacle, where you can’t seem to find the way forward, try not to get frustrated. Approach it with a positive attitude, and ask for help when you need it.

Communicating like this while you code is is probably not something you do every day at your job. It can feel unnatural and awkward. Practicing problems with a friend while speaking out your thoughts is a good way to improve in this area.

Virtual interview communication tip: Don’t cut off the interviewer. This is very difficult to have a hold on when doing interviews virtually. Try to speak once it’s clear that the interviewer is done speaking. The minor lag involved in online calls can make for jarring interruptions.

Final thoughts on improving

That’s a lot to keep in mind while doing an interview. As with any skill, practice is the best way to improve.

Practice the different aspects I’ve described. Do mock interviews with friends or colleagues, and ask them to rate you on the criteria above.

Interview your friends. It’s easier to spot mistakes and areas for improvement when you’re on the other side of the table. This process can help you stay attentive to your strengths and weaknesses in interviews. Conducting interviews as an interviewer has been a key factor in making me a better interviewee over the years.

Do leetcode questions; practice makes permanent. The point of doing leetcode is not to memorize solutions, it’s to recognize different types of problems. When you see a new question, you’ll be able to categorize it and draw on your knowledge to have an idea of which path to take, which edge cases might be an issue, which questions you’ll need to ask, and what kind of performance implications you’ll need to address.

Thank you for reading. I hope this guide helps you ace your next coding interview!

How do you approach coding interviews? If you have any tips or tricks, please comment and share!

Interview Guide for Software Developers - Part 1: Landing the Interview

Udara Weerasinghege — Fri, 23 Oct 2020 17:49:06 +0000

Searching for a new job can be a daunting experience. It’s extremely discouraging to apply to dozens of positions online only to hear back from one or two, if any. In this post, I’ll walk through how you can leverage your network to land an interview instead of relying solely on online applications.

Most people default to applying through a company's career page when searching for a job. While this is the most common and the easiest way to apply, it’s also the least effective. You are one of the hundreds if not thousands of applicants for a single position. You're relying purely on the strength of your resume to get through to the interview stage. Even with a lot of relevant experience and a great resume, there’s a chance that yours will not be looked at due to the sheer volume of applicants.

In my experience, the best way to land an interview is by getting a referral from an existing employee at the company you’re interested in. While online applications come in the hundreds, referrals are rarer and carry more weight.

Due to the large volumes of online applications, there’s a good chance that yours is missed or overlooked. Referrals get around this problem. Referrals will generally be looked at first by the recruiter or manager hiring for a position. This gives you an immediate advantage. Referrals also carry a seal of approval that is absent from an anonymous online application.

If you submit 10 online applications, and you get 10 referrals, all else being equal, you'll probably hear back from a higher percentage of the referrals.

Asking for a referral can feel pushy and uncomfortable. However, most companies have incentives -- often financial -- for employees that make successful referrals, so the referrer benefits as well. Additionally, most people are just happy to help in any way they can if they believe you’d be a good fit for the position.

Let’s look at a couple of ways of securing referrals.

Find existing connections at the company

Friends, mutual friends, classmates, and ex-coworkers are all great sources for obtaining a referral. If they know you personally and know the quality of your work first or second hand, all it takes is a polite message asking for a referral to the position you’re interested in. You can check the company’s LinkedIn profile to discover your mutual connections. If you only have 2nd level connections, see if you get an introduction from your mutual connections. Don’t forget to look for company alumni, who are direct connections as well! They will usually still have friends at the company, and they can help you get an introduction.

Reach out to engineers & recruiters at the company

Employees at a company are often happy to talk about the work they do. You can use LInkedin to find developers at the companies you’re interested in. If it's a large company, try to find someone in the department that's related to the position you want. Employees who have something in common with you -- highschool/bootcamp/college/previous job/shared interest/hobby -- are the best candidates for reaching out, as they’ll be more inclined to reply to your messages.

Tell them you're interested in the company and the work that they're doing. Be genuine, mention anything common you have with them, and ask them if they have 15-30 minutes to chat to talk about their work (pre-COVID I’d have recommended meeting them for coffee). If they respond positively, schedule a time and send over a calendar invite. Don’t forget to add a meeting link to the calendar invite, or get their phone number.

During the call, ask them about their work, company culture, and anything you’re curious about. This is a great opportunity to learn more about the company first-hand. Also, let them know a bit about your experience and why you're interested in the company. If the call goes well, as you reach the end of your meeting time, politely ask if they would be comfortable referring you.

If you can't find any engineers that respond, reach out to a recruiter directly. While they may not provide you with a referral, they might be able to expedite the resume review process if they believe you are well suited for the position. Everyone loves initiative!

The process of finding individuals and reaching out doesn't scale if you’re applying for 100s of positions, or if you have tight timelines. I recommend choosing a handful of companies that you're most passionate about and reaching out to them.

You may find yourself unlucky with no responses. In this case default to applying online. Any application is better than no application.

When you begin your next job search, I encourage you to leverage your network to help you get referrals. They take more effort to secure, but you almost guarantee that your resume will be looked over and considered. Very few people actually use their network in this way, so this is an easy way to stand out. It might seem scary at first, but the worst that could happen is you don’t get a reply and you apply online, which you would have done anyway.

As you rack up industry experience, your network and the strength of your connections will naturally grow, making this process easier and easier. Early on in your career, you’ll have to work hard for referrals by scouring LinkedIn for the right people to message, but I promise it’s worth the effort!

If you liked this post or found it useful, keep an eye out for my next post with tips for Acing The Coding Interview

Remote Onboarding Tips - Week 1

Udara Weerasinghege — Tue, 23 Jun 2020 21:31:44 +0000

Onboarding to a new company can be an overwhelming experience, even more so now that everyone is remote. It’s easy to get into a state of information overload. As a developer, you’ll not only have to handle general onboarding, but engineering onboarding as well, which can be an overwhelming experience in itself.

I started a new job as a Software Engineer last week, and I kept notes on what went well while onboarding. These are a few key things that helped me have a successful first week.

Get to know your team

One of the biggest downsides of being remote is missing facetime with your teammates.

Set up 1 on 1 virtual meetings with the members of your immediate team. I set up 30 minutes with each teammate. In hindsight, I should have set up 45–60 minutes. 30 minutes is good for a brief intro, but it's hard to do much more than that.

The meetings themselves don't need to happen during your first week, but it's a good idea to create them early on.

In these meetings, get to know your team members. Introduce yourselves, and see where the conversation goes. One question I like to ask everyone is: "What do you wish you knew when you first started?"

I'd recommend making these recurring meetings. An hour is not enough to get to know someone.

You should also ask your manager who they think you should meet outside your team, and set up 1 on 1s with them as well.

Keep a list of TODOs

During the first couple of days, you'll likely have lots of questions. You'll also have a growing backlog of forms to fill and documents to read. This can be overwhelming, and it's easy to forget some of these as you jump between tasks and meetings.

When you get an article to read or a form to fill, instead of doing it immediately, keep a list of TODOs. When something new comes your way, create a TODO with enough context so that you can pick it up later. The same goes for questions that arise, create a TODO with the question along with who to ask.

This lets you control the information flowing your way, and reduces context switching. It will speed things up as well as give you a place to check when you're not sure what to do next.

Take your time with engineering onboarding

Onboarding as an engineer takes time. To onboard completely and be autonomous it can take anywhere from 3–6 months.

It can be enticing to try to set up your local environment and get coding right away. But, I'd recommend holding off on this until all your logistical HR-related tasks are out of the way. Setting up a development environment can be time-consuming. It'll take even longer if you're constantly context switching.

You'll also likely run into issues while setting up your environment. It'll be easier to tackle these issues and troubleshoot if you have uninterrupted time to focus on it.

Personalize your workstation

If you've received a fresh company laptop, it'll take a while until it's set up the way you're used to.

You will need to install several pieces of software (make sure to only install approved software). You'll also want to customize your terminal, and adjust other preferences to suit your needs.

I found this to be the perfect activity when I needed a break from my TODO list, or had some downtime. If you have a list of software and customizations then great, just go down the list and install each one! If not, this is the perfect time to create a list as you go, so that the next time you get a new laptop, you won't be starting from scratch.

This is a set of general guidelines that can be applied to most onboarding situations. Every company does onboarding differently though, so I'll leave it up to you to take what works for your situation.

Happy onboarding!

Deciding between two job offers

Udara Weerasinghege — Tue, 16 Jun 2020 21:21:55 +0000

Recently, I had the privilege of receiving two job offers. This was the first time I've had competing offers in my career. They were both for Full Stack Developer roles at respectable companies. I'm a pretty decisive person, but this was an agonizing decision. There could be no perfect decision here due to a lack of information. The only way to know for sure which company was right for me, would be to work at each company for several months. Since that was off the table I took a different approach. Spreadsheets!

I compared the two companies across categories that mattered to me in a job. To each category, I assigned an importance factor based on my personal values. In the end, I had a weighted score for each company that I could use to inform my decision.

This is the spreadsheet I used (LIVE LINK HERE):

It was still a close call. But, thanks to the spreadsheet I came to a decision based on an apples to apples comparison rather than what felt like a coin flip in the beginning.

The importance for each attribute will be different based on your personal values, but I hope this provides a good starting point for when you need to compare offers.