Get promoted before switching job posted on 18 May 2024

Quite a lot of people have been reaching out for a referral to apply to Databricks. Somehow a lot of these folks (probably ~40%) have less than 2 years of experience and have never been promoted.

My recommendation in this case is to get promoted first. The rationale being that it is difficult to understand where you are in your career – e.g. are you a bad engineer that hasn’t grown at all or are you actually very close to the next level?

  • If you apply to a new company, they may do reference check, but these aren’t necessarily the best signals for a plethora of reasons – nobody knows how well calibrated the references are, if they are actually the best ones (maybe you don’t want to provide your closest coworkers because they don’t know you’re planning on leaving) etc.
  • If you do an internal transfer, the hiring manager may have access to your perf and can directly chat with your manager – so they can much better understand your level, growth and gaps. At the end of the day, the risk is much lower in this case

Something similar can be said about senior engineers who never got promoted – did they end up with the title because a company made a hiring mistake?

Being promoted to L4 (or its equivalent) means you are reasonably independent, so while you’ll need time to ramp up on the new code base/system, you don’t need to be hand held all the time.

Lastly, though this might be more controversial, it shows the ability to push through a process – the resilience to do non interesting work but also some useful soft skills, e.g. how well you can argue for your proposal. It also reflects a lack of behavior red flags.

So if this is your first job, you should really try to get promoted once before looking for new opportunities. It will be much easier for you to find jobs and you will likely end up with a more interesting one too.

LinkedIn post

Training for code interviews posted on 17 May 2024

Coding interviews are mainstream for engineering jobs but interestingly enough these coding interviews are not always required:

  • As a new grad, I had a few offers from companies without doing any technical assessments (I only did hiring manager interviews).
  • As a senior engineer, coding interviews are often skipped if my application is done through a referral from a previous coworker (though in general I still have design, cross functional, hiring manager and other interviews)

From different discussions with colleagues, my experience as a new grad was unusual and likely a combination of a few factors:

  • I graduated from very good schools
  • All these offers were outside the US (in Europe or Asia)
  • Job market for software engineers was hot at that time

With that being said, I’m not sure this is something that can still happen because of the job market (but if it happened to you, I would be curious to know). So you likely have to prepare for these interviews.

Preparing for coding interviews is a heavily discussed topic – and sadly heavily monetized in my opinion. Here’s my (hot?) take: you don’t need to do thousands of leetcode or hackerrank questions or pay hundreds of dollars to get some training. For coding interviews the main expectation is that you can write code, so doing the easy leetcode questions is enough:

  • You should be able to write valid code on your first try – as in you should know how to create a list, for loop, hashmap etc. without needing a few attempts
  • You should know the standard structures available in the language of your choice – list, hash map, sets etc.

And that’s about it. I don’t think you need either need to:

  • Know mathematics tricks – e.g. how to find the redundant number in a sorted list in linear time with O(1) memory
  • Know weird data structures – e.g. if an interviewer expects you to know finger trees to join their company, you probably should consider another one.

It’s maybe useful to know that some algorithm exists and how good they can be (e.g. knowing that you can find the median in linear time is good and enough – even if you don’t remember how to implement it) but that’s optional in my opinion.

Expecting candidates to know exotic data structures provides no signal on how good the candidate once hired – it just reflects badly on the interviewer/company. I always thought it was a way for interviewers to flex on their dominant position.

LinkedIn post

TDD is not enough (or not for what matters the most) posted on 16 May 2024

There are many reasons certain companies want to hire engineers from Google. Facebook, Databricks, etc. – There are also times when hiring such engineers is a bad decision. One of the interesting reasons I was told is that these engineers have seen ”greatness”.

Greatness here is mostly about technical aspects – some of these engineers have worked on large scale systems like only few have witnessed, some have worked on the bleeding edge of their technical field, some have solved legal issues that exist only for handful companies etc. This experience, knowledge and skills are things you don’t find in academic books as these tend to be a few years outdated – this is one of the experiences certain companies value a lot (e.g. companies who have grown to be successful and are starting to hit similar scalability issues).

If you didn’t have a chance to work in such environments, you may not know exactly what greatness is in your field but you should be aware that greatness is a relentless chase – if you never settle for mediocre systems and continuously push for improvements, you will eventually reach such state (it may take a bit longer though).

A corollary of the statement above is that while you can witness greatness, what matters is to pursue it. This means that not every engineer from top tier companies can replicate what they have seen, especially if they were never part of such efforts. They just have a head start since they know where they should head to but they may not be capable of completing the journey. For example all engineers at Google have a sense of what a good developer experience should be, very few can make it happen in another company.

Last but not least, my 2 cents is that being hungry for greatness is a more valuable trait. There’s a French saying that goes “un intellectuel assis va moins loin qu’un con qui marche” – a smart person sitting goes less far than a dumb person walking. Journeys for greatness are never straight paths since you have many external factors that will make you drift from your goal – this is why relentlessly chasing your goal is the most important thing to do.

LinkedIn post

TDD is not enough (or not for what matters the most) posted on 15 May 2024

As you become more and more senior, you will develop opinions on different topics. It’s however important to know which of these opinions should be/are strong and why.

Everyone can have opinions on everything but not all of them matter. You should focus on developing opinions on topics that impact what you are responsible for – e.g. you should definitely have an opinion on your system, your dependencies and your upstream clients.

More importantly, you should have strong opinions on these topics. By strong, I do not mean that you won’t listen to any person thinking differently but that these are educated opinions anchored in principles shared across your company. If your engineering org doesn’t have such principles, you should make sure there’s alignment on these (e.g. reducing operational costs, having reliable systems, having consistent code etc.). External factors may change over time, and you may have to revisit these stances (and be open to change), but this shouldn’t happen every month.

On the other side, you should soften your opinions on topics where others might be bigger stakeholders and ignore other opinions from non stakeholders. The saying is to avoid “too many cooks in the kitchen” – this goes both for: You – don’t strongly voice an opinion if you know you are not impacted by it. It’s better to guide the discussion than lead it. Others – don’t invite the whole company to discuss problems they don’t care about. You won’t waste their time and you’ll reach a consensus among genuine stakeholders faster.

Once in a while, things may not go your way even if you feel strongly about it – this is where it’s important to keep in mind that you may not have visibility into everything being balanced by your leadership (e.g. maybe they are considering people aspects, strategic customers, legal concerns that you are not aware of). This is where you should also focus on being able to communicate well about these opinions such that they are properly considered (even if they sometimes get overruled).

LinkedIn post