DEV Community: Adler Hsieh

7 Signs You're Underperforming as an Engineer

Adler Hsieh — Sat, 23 Nov 2024 04:18:28 +0000

No one wants to be a low performer, but the truth is, we are all clouded by self-serving bias: We can easily identify other people’s shortcomings, but cannot see our own. This is one of the main reasons we often get surprised when receiving negative feedbacks. They are never on our radar.

Use this list to do a quick self-assessment. We want to spot issues early and make improvements. Remember to read until the end to see action items!

💡 Key Takeaways

Look for signs of low performance on yourself. A good indicator is to keep an eye on team metrics and to ask for feedbacks regularly.
Take actions if you spot these warning signs. Work with the team and your manager grow.

1. Constantly Sit on Problems without Actions

🚨 Warning indicators:

You sit on blockers for days without raising them
Team meetings reveal issues that should have been flagged earlier

✅ Takeaways:

Raise blockers as soon as you identify them

Constantly delay reporting blockers can happen especially on junior engineers.

Early escalation helps prevent small issues from becoming major problems. Even if you are trying to resolve certain blockers, giving the update to the team is always a good practice.

Escalation isn't a sign of weakness - it's a professional responsibility that helps maintain project momentum. Also, sometimes other members might already have an answer.

2. Avoid Challenges

🚨 Warning indicators:

You consistently choose simpler tasks during sprint planning.
You are always reluctant to take challenging tasks.
You always escalate problems easily without attempting to dig deep.

✅ Takeaways:

Identify causes of low motivations. It could be domains or burnout.
Seek help if necessary.

Your growth as an engineer stalls when you dodge difficult projects. Giant tech companies have a rule of developers needing to upgrade to a certain level in a timeframe. Stalling makes it easier to put you in the low-performer bucket.

Improvement on this could be tricky. The cause of low motivation might be due to the toxic environment, boring team domain, or career burnout, etc. Talk to peers or people that you trust. See if they feel the same, or how do they approach issues like this.

If it’s possibly caused by career burnout, talk to a professional and seek help!

3. Rarely Do Code Reviews

🚨 Warning indicators:

Your code review comments are superficial or non-existent.
You don't make time for thorough code review.

✅ Takeaways:

Regular code reviews demonstrate your contributions to teamwork
Good reviews help catch issues early
They expands your understanding & domain knowledge

Code review is part of teamwork. Since software engineers usually need to work as a team, not participating in code review is usually considered a flag.

To improve, it’s mostly a shift of mindset.

Code reviews aren't just about finding faults. They're a chance to learn new techniques and share your expertise. Make time for code reviews in your daily routine. It's a simple yet effective way to level up your skills.

4. Miss Deadlines Frequently

🚨 Warning indicator

You're constantly asking for extensions or delivering work late.

✅ Takeaways:

Follow best practices such as breaking down tasks & leaving buffer.
Identify other causes: unreasonable workload, scope change, etc.

Despite external factors, missing deadlines is a symptom that you're not estimating tasks accurately or managing workload effectively. You might be taking on too much or underestimating the complexity of projects.

"Deadlines are not arbitrary, they're a promise to deliver."

To improve, start by following the best practices such as breaking down tasks, communicate issues early, and leaving buffers. After that, identify the causes such as scope change or underlying technical debts. Work with your manager to find out action items for improvement.

5. Your Work is Invisible to Stakeholders

🚨 Warning indicators:

Your manager & team struggle to describe what you are doing and why
Your name rarely comes up during updates and discussions

✅ Takeaways:

Choose the right tasks that have impacts on the team and the business. It’s probably not wise to always pick small code refactoring tasks.
Contribute to team discussions regularly

Also, when working with your manager, you can consider creating a "brag document" to track accomplishments. This can be helpful during performance reviews and when discussing your position on the Engineering Ladder.

Remember, visibility isn't about showing off. It's about ensuring your hard work is recognized and valued. It also provides transparency that welcomes feedback.

6. Always Wait for Instructions

🚨 Warning indicators:

You often ask "What should I do next?"
You struggle to make progress when your manager not present

✅ Takeaways:

Be proactive in seeking out work. Check your team’s backlog & roadmap regularly.
Suggest improvements to existing projects or team processes

Strong engineers proactively identify problems and propose solutions. They don't wait for assignments to fall into their laps.

Look for ways to add value beyond your assigned tasks. This mindset will set you apart from those who simply follow orders.

Remember, your tech lead and manager aren't there to micromanage you. They expect you to take ownership of your work and drive projects forward independently.

7. Ignore Constructive Feedbacks

🚨 Warning indicators:

You get the same feedback repeatedly across review cycles
You acknowledge issues but there is no action plans

✅ Takeaways:

Create action items after receiving feedback
Schedule regular check-ins with your manager to discuss improvement

Take a look at your previous feedbacks. Are there items that come up often? It could be a good sign that you have not taken actions toward certain issues.

Document both the feedback and your progress. This helps demonstrate your commitment to growth and provides evidence of improvement during performance reviews.

It’s Time to Take Actions

If you find yourself matching one or more traits above, it's time to take actions. Recognizing the issue is the first step, but now you need to act. Let's explore how to improve.

Identifying Causes

Start by looking inward. Are you struggling with work-life balance? Maybe you're dealing with anxiety or personal issues. These can all impact your performance.

It’s also important to inspect external factors: Does the team have any issue? Low performance might be only a symptom and the real issue lie in the team. For example,

The team does not have a good process
The team culture is toxic and discouraging
The workload requirement is unreasonable

Try to talk to your manager or other members about these. They may share the same sentiment. Pinpoint specific areas where you're falling short. Don't just think "I'm not doing well." Be precise. Maybe you're having trouble with a particular process.

Remember, identifying the cause is key to fixing the problem. Be honest with yourself. It's not about blame, it's about improvement.

Seek Feedback From Managers And Peers

Make sure to verify the causes & improvement areas. During 1-on-1 with your manager, express your concerns. Ask for specific feedback on areas where you can improve.

Feedback questions can include:

"How do you handle X task so efficiently?"
"Can you review my code and give me pointers?"
"What strategies do you use to stay productive?"

Be open to constructive feedback. It might sting at first, but it can bring real improvements.

Creating A Plan With Your Manager

Once you've gathered feedback, it's time to create an action plan. Sit down with your manager and outline specific goals. Use frameworks like SMART to set clear goals.

Your plan might include:

Measurements such as engineering metrics
Specific actions such as doing 10 code reviews in a week
Timeline

Be realistic. You won't become a top performer overnight. Set milestones and celebrate small wins along the way.

After that, ask your manager for regular check-ins to track your progress & feedback. Improvement is an ongoing process. Set up regular feedback sessions with your manager and peers.

Thank you for reading the post!

❤️ it if you like this article.

💬 Leave a comment if you have questions. Or let me know if you are interested in knowing any specific topics.

You can also find me on:

If you want more content like this, consider subscribe to my newsletter.

See you next time 👋

Thanks for reading Tokyo Tech Lead! Subscribe for free to receive new posts and support my work.

Working at Merpay / Mercari: My Honest Review as a Software Engineer in Japan

Adler Hsieh — Tue, 12 Nov 2024 07:16:25 +0000

In 2019, I joined Merpay, a part of the Mercari Group, in Japan. As I write this review, more than five years have passed. There are so many memories, learning experiences, and insights. This article aims to provide an honest and detailed review of my time at Merpay and Mercari, covering the company culture, management structure, and challenges and opportunities.

Whether you're considering a career move to Japan or simply curious about what it's like to work at one of the country's leading tech firms, I hope my experiences will offer valuable perspectives and advice.

💡

Key Takeaways

Mercari is a Japanese company with a Western working environment. It has great resources, benefits, work-life balance, and working culture.
I enjoyed working there for it having a lot of senior Software Engineers, flexible career path, and company resources.
The company took a deep hit during the recession just like all tech enterprises in Japan. Slowdown continued in 2023 when I left the company due to limited resources.
The language environment between JP/EN remains one of its biggest challenges to move to a global environment.

An Overview of The Company and the Market

Services & Products

By the time I left the company, there were multiple services and products from the entire Mercari group:

Mercari JP: The dominant second-hand marketplace in Japan (CtoC). They have the largest market share and users among all competitors.
Mercari Shop: A different marketplace business model for merchants to sell products to customers (BtoC).
Merpay: Mobile payment including QR code and credit card.
Mercoin: Cryptocurrency trading and investment.
Mercari US: Same secondhand marketplace but in the U.S.. This post will not cover this business as I have almost zero experience working with them.

There are other new services such as Mercari Hallo which helps people find small jobs. However, that was after I left the company so I didn't have a chance to get to know them.

Management Structure

Each company has its management structure. There is a CEO, CTO, VPoE, CPO, and other executives for each company. Under them, there is an Engineering division including directors, EMs, PMs, and software engineers.

Companies work with each other when there are overlapping areas. For example, all payments in Mercari JP go through the Merpay payment system. There are a lot of interactions between the Merpay payment team and the Mercari JP accounting team. Otherwise, companies operate on their own (except all C-suite people report to the Mercari Group executives).

Pay Scale

As I am only one part of the company, I can not say that I know the pay scale very well. However, my general impression is mostly aligned with the data in opensalary.jp. Each grade in the data is mapped to its Engineering Ladder.

If you're interested in digging deep into the pay scale in the job market, I would recommend checking the salary guidelines on Japan-Dev.

The Tech Job Market Landscape in Japan

If you are familiar with the software companies in the Japanese market, there is a good chance that you know there are several categories. Mercari belongs to the category of "Japanese companies with a Western working environment". Features of this category include:

The pay scale is below the top scale but is considered good enough.
The language environment is usually a mix of Japanese and English, but foreigner-friendly.
They actively hire from overseas with their generous relocation and visa support. They are one of the best choices for foreigners to land their first job in Japan.
Other companies in this category include PayPay, SmartNews, etc.

Other major categories in the job market:

🇺🇸/🇪🇺 Global tech enterprises: Worldwide companies such as Google, Indeed, Netflix and others. It also includes smaller but well-known companies such as Stripe and Wolt.
👺 Traditional Japanese companies: The majority of companies you can find in Japan.
🤏 Small startups: This is a category on its own because everything depends on the founders. Their pay scale, language environment, and cultural environment vary.

There are also other types including software agencies, governments, and nonprofit organizations. They are not the top choices for foreigners so this post will not cover them.

My Experience with Merpay

My Team and Their Tech Stack

I joined Merpay, the mobile payment business in the Mercari Group, as a Backend Engineer in 2019. I spent all my time in the Payment Platform team. There is a very good article (in Japanese) by our senior tech lead summarizing what we do and our value to the company.

To keep it brief, here is a list of technologies that we used: Golang, PHP (phasing out), Google Cloud Platform, Spanner, Pub/Sub, Docker, Kubernetes, DataDog, and GitHub. Most of the teams in Mercari adopt the same technologies for consistency.

Team Structure

Each team looks like the following:

Engineering Manager (EM): EM is responsible for the entire team. Many responsibilities are delegated to PM or TL, but EM is the guardian. There are a variety of responsibilities but most of the time the priority is on strategy and people management.
Product Manager (PdM) / Project Manager (PM): Depending on the complexity and impact of the product in the team, there could be PdM (more senior) or PM in the team. They are responsible for the product roadmap and the project planning and monitoring.
Tech Lead (TL): Tech Lead is the equivalent of a senior developer that is in charge of the team. All important technical decisions have to go through this role. TL still needs to code, but they also spend quite some time reviewing codes, designing architectures, and designing teamwork processes.
QA: Not all teams have a dedicated QA member. For some reason, QA talents are scarce in Japan. Most of the time multiple teams share the same QA member. Their responsibilities are manually testing the features and applications.
Design: I focus more on the backend, so I have zero experience working with design members in Merpay. However, as far as I know, they are responsible for designing the UI and UX of the website and mobile applications.
Developers: Developers other than Tech Lead belong to this category. There are one or two senior developers, some mid-level, and some junior developers. Sometimes there are interns.

Language Environment

The environment in Merpay was quite Japanese-dominated when I joined. The management members were making all the effort to create a language-inclusive environment. I saw a lot of progress in those years, but there was still a huge gap in what we wanted to achieve.

Most Merpay product teams need to talk to accounting, legal, compliance, and customer support teams. These teams do not have any English or bilingual speakers. In that case, most teams need to have at least one or two Japanese speakers to bridge the communications. This is also one of the main challenges in promoting English communications.

When I left the company, the environment looked like the following:

English-speaking Teams: This includes 3-4 teams. PMs are mostly bilingual so they serve as the bridge in communications.
Teams with mix JP/EN: This includes another 3 teams. There are both Japanese and non-Japanese speakers. This includes the team I stayed with at Merpay. We tried very hard to preserve both language use in the team and it worked well so far.
Japanese-speaking Teams: The rest belong to this category. There are still bilingual speakers in these teams, but most communications are done in Japanese.

Note that the above is in Merpay. Mercari JP has a better language-inclusive environment.

Work-Life Balance

I have no complaints about this part. The company does not require people to work overtime. The standard working hour is 8 hours per day.

Sometimes when projects are in a rush, overtime can happen. My highest record of doing overtime was 60 hours in a single month, but that happened only once. Most of the time my overtime was within 8 hours.

Professional Growth

There is an Engineering Ladder defined in the company. It indicates the level and sets up a career path for every software engineer. There is also a clear definition and exception of Engineering Managers.

There are no restrictions for Software Engineers to move to a different grade within a specific timeframe as in FANNG companies. However, if you are in MG1 or MG2, managers will strongly encourage you to move up to at least MG3 in the future.

What I Enjoyed Working There

Learning from Experts

There are many senior developers in Mercari and Merpay. They have been in the company for a very long time so they know the codebase inside out. There are also GDE (Google Developer Experts) in the company. It includes tenntenn (Go) and the other person that I forgot the name 🤦‍♂️ (GCP Spanner).

When I was in the Payment Platform team, there was a senior tech lead who designed the entire payment infrastructure. There was no need to worry about any technical issues. He was the guy who went to the stakeholders and finished all the complicated pre-work.

I see it as an opportunity to work with the best in the industry. You have to be at the same level as these senior members to discuss with them, so there are a lot of things to learn in a short time. Every team has a similar structure, so if you join any team, find that expert and try to learn as much.

However, sometimes it could be a double-sided sword. When members are not proactive enough, senior members will handle the work for them. Members only have to deal with minor details and alignments with stakeholders. They miss the opportunities to learn and grow in that case.

Flexible Career Path

For most of the time, the company is willing to support your career growth, including:

Changing to a different team
Move to a different company within the Mercari Group
Changing from IC to the EM track (MG3 and above)
Changing from EM to the IC track

It's really good that there are a lot of teams and companies in the group to be able to provide flexibility and support.

However, sometimes I saw managers discourage members' career change and did not provide support. For example, members expressed strong interest in moving to be an Engineering Manager. Those members might not be the best fits, but their managers did not identify the gaps or provide support, either. They only criticized that the thoughts were impractical.

If you run into situations like this, I would encourage talk to your skip manager. It could be either your manager's issue or how this message is communicated. It's always good to find out. If it happens multiple times, consider moving to a different team.

Sufficient Company Support

Visa and Relocation Support

The relocation and visa support were some of the best I had in my entire career. They have a relocation allowance for you to move to Japan, help you get a working visa before you arrive, and provide a temporary residence before you find your own.

Language Support and Learning

They have interpreters ready to handle any interpretation and translation request. Sometimes it might not be as effective, but it's a great temporary measure for eliminating the language barrier.

As for language learning, they have in-house Japanese training until you can use a basic level of Japanese. They claim that it's CEFR B2, but I found that it's still far from being able to live in Japan without any language barrier. You need to spend your own time studying Kanji and other materials to be able to handle most daily conversations.

If your team is using Japanese, they provide reimbursement for you to participate in external training even after you reach CEFR B2. However, this part of the benefits changes all the time. Please refer to the company policies.

Childcare Support

Unfortunately, I did not have the opportunity to utilize this part, but they provide great benefits in childcare. I've seen a lot of colleagues having a great family life with these supports. Some include:

Full-amount paid parental leave (The legal parental leave is up to 67%)
Infertility treatment
Egg freezing reimbursement
Nursery reimbursement

Likewise, these supports have high costs so things might change in the future.

Challenges and Opportunities

Slowdown during Tech Recession

After COVID, the global tech industry entered recession. Many layoffs occurred in the U.S. and other countries. Japan, on the other hand, due to its strict employment policy, is one of the countries hard to fire employees.

Same for Mercari. They tried their best in cutting costs. This included the closure of the Sendai office, which a lot of employees were not happy about. They thought that the company was finding an excuse for a mass layoff. Other than that, they also slow down hiring and salary growth, as well as putting more restrictions on benefits.

The slowdown impacted the secondary businesses such as Merpay and Mercoin even more. As the secondhand market is the most profitable business model, resources are prioritized there. Other businesses did not get as many resources. For example, some divisions in Merpay could barely get 1 new hiring when they needed more than 10. Or, some teams could not even get backfill. It obstructed the progression of these secondary businesses.

Also, tasks during that time were not the most exciting either. Every business had tens of items on their roadmap, but due to resource restrictions, the progress became slow. Management tasks became "how to cut costs" instead of doing innovations.

The Glass Ceiling from the Language Barrier

Embrace the fact: a glass ceiling exists in any culturally divided environment. This situation is more obvious in Japan where companies try to create a language-inclusive environment. The glass ceiling comes from the language barrier. The higher you want to go, the more language barrier you need to overcome.

There are many factors, but one important cause is Mercari's pattern of creating a new business. Mercari usually starts a new business (e.g., mobile payment or cryptocurrency) with a group of Japanese-speaking members. After the business is steady, it starts to move to a language-inclusive environment. This is good for starting a business in Japan because it streamlines the communication process. The efficiency allows them to test the MVP ASAP.

However, this strategy is less ideal for creating opportunities for non-Japanese speakers. When a business is ready for a language-inclusive environment, the communication pattern is already all well-established in Japanese. It takes a huge cost to translate them into English and establish a new communication pattern.

If we look at the businesses in the Mercari Group now, there are only a few businesses that are easier for non-Japanese-speaking members. They are Mercari JP and Merpay. All the other businesses are struggling with hiring non-Japanese speakers.

Even within these two businesses, we still see language barriers from time to time. This naturally creates a glass ceiling for non-Japanese speakers who want to make an impact in the business. For example, they usually need to communicate with Japanese-speaking stakeholders to agree on important decisions. In an organization that is Japanese-oriented, they require extra time and effort on communications. This dilemma is more struggling for those who are at a senior level.

As far as I know, Mercari JP has less of this issue. Most executive members are bilingual, and their communication patterns are more mature. I think other businesses are able to navigate through this issue following the existing pattern in the future.

Negative Reviews of Traditional Management Style

There is an infamous review on Glassdoor about Mercari's management culture. It points out that there are many examples of the management members' incapability. Yet they still manage to take control of the organization, which leads to an unhealthy work culture.

I did see multiple reviews like this both externally and internally. Fortunately, during my time at Merpay, I did not have any similar experience. I believe the majority of the organization does not need to handle an extreme management style like this. If you find yourself in such a situation, my advice is to move to a different team or division.

Conclusion

On my journey at Merpay and Mercari, I'm grateful for the mentorship, experiences, and the career transition to Engineering Management. Each moment has been a valuable lesson. As I move forward in my career, I carry the skills I learned as well as an appreciation for those who have helped me.

For those who are interested in the company, feel free to leave a comment or contact me if you would like to understand the company more.

Frequently Asked Questions

What is some advice you would give to those who are interested in joining?

Mercari is a good company to work in. Career-wise, I would suggest:

Learn from the best: There are many senior Software Engineers who are the best in the industry. Be proactive in taking responsibility and try to learn as much as possible from them.
Find the best environment for yourself: There are many teams and companies in the entire Mercari Group. Your first team might not be the one that suits you the most. I would suggest switching to a different team in a different domain every one or two years. It is refreshing and motivating at the same time.

What is the interview process like for Software Engineers in Merpay?

As in 2023, it was as follows (order might be different):

[optional] Casual chat
Resume screening
Recruiter screening
Take-home assignment
Technical interview / System design interview by peer Software Engineers
Behavioral interview by EM
Final interview by VPoE or CTO
Offer

What is it like working in Merpay as a Software Engineer?

I have a YouTube video explaining the life of a Backend Engineer in Merpay.

What are some other foreigner-friendly companies in Japan?

I have a YouTube video explaining my story of how I found my first job in Japan. You can also find a job listing on japan-dev.com.

Any other question? Feel free to leave a comment or contact me :)

8 Slack Tips Every Tech Team Should Know in 2025

Adler Hsieh — Mon, 11 Nov 2024 05:00:00 +0000

Messaging apps like Slack offers many features that can help with teamwork. But for those who just got into the messaging ecosystem, it could be tempting to bring the same habits from our daily messaging app like Whatsapp or Messenger. Workplace requires productivity. With some adjustments, it would make the communication more effective.

Here are some tips that every tech team should know:

🙅 No "Hi". Cut Straight to the Point.

You have probably heard of nohello.net. It promotes this universal issue that everyone faces on their messaging app like Slack: Someone dropping a "hi" without saying anything else. It can even happen outside of workplace. It can happen on Facebook, Whatsapp, and other places.

Remember, saying only "hi" is a waste of everyone's time. People have to come back and forth, and the context-switching is a productivity killer. Lay down the context + questions directly so that it can be digested in one look.

Screenshots from nohello.net

👥 Use Team Channels instead of DM

The benefits of using team channels instead of DM:

✅ Everyone in the channel can help
✅ Someone else who has the same question can get answers as well
✅ The answer is available in the channel for future reference

When having a question, it's tempting to go to that person directly by using DM. For example, where to find a certain document, or how to connect to VPN. Dropping a message to your manager or mentor would be the first method that comes into your mind.

However, using DM has several issues:

You'll need to wait for that single person's reply.
Someone else might have the same question.
People who have the same question in the future will need to ask the same question.

Team channels (either public or private) are for this purpose. They are great for sharing updates, asking questions, and discussing projects.

Concerned that it's not related to the team? No problem. In larger organizations, there are so many messages everyday. No one really cares if there are more irrelevant messages.

Unless it's sensitive information, using team channels instead of DM is always better.

🕐 Scheduling Messages

When out of working hours, or you know someone is almost clocking out, use scheduled messages instead!

Image borrowed from Mio

Schedule the messages and send them in the next morning. You can set a time and send them in the morning. Since they are already off, you cannot get a response, anyway.

"Hi! There's something important. I've set up a chat with you next Monday."

I once received this message right after I got off work on a Friday evening from my manager. I kept thinking about it during weekends and could not really relax 😅

🏗️ Start with Important Messages

Put your main ideas at the start of your message. This helps readers grasp the key info quickly. This is the writing style of the inverted pyramid.

You can see the difference in the following two different styles:

Inverted Pyramid

New Policy: "No Meeting Wednesdays" starts next week.

Impact:
* Protects time for deep work

* Improves team productivity

Regular messages:

Hi. Recently team members have reported difficulties focusing on deep work, and our productivity metrics show a concerning trend. After discussions, we've concluded that we will start "No Meeting Wednesdays." This policy will take effect starting next week.

Be honest. There's no way people are going to finish the second message. Good message structure & brevity helps teams communicate clearly and efficiently. There is also an insightful article on Poynter.

Even though it is journalism, it applies to any business message. Everyone is busy, and we want readers to understand us right away. We can add details & contexts after the main point.

Quick recap:

Main message on top
Use formatting like bold text & bullet points.
Contexts at the bottom

📟 Acknowledgement

When someone messages you in Slack, a quick reply can work very well. Even a simple "Got it" or thumbs-up emoji 👍 shows you've seen the message. This is super helpful in busy channels.

On the other hand, not replying at all can leave the impression that you have not seen the message yet. This can create confusions for other members especially if you are on a on-call rotation.

For longer messages, try a brief summary. "I'll look into those three points" tells the sender you've understood. If you need time to respond fully, say so. "I'll get back to you by EOD" sets clear expectations.

💡 Bonus tip: use Slack reminders if you need to come back to the message later.

🔄 Follow-Up Messages

What if someone is not replying to your messages? Do follow-up.

"Hi. Could you take a look at me previous message?"
"Gentle bump"
"Ping"

Anything is ok as long as it's friendly.

Some people might be concerned to be "too buggy". Here is my guideline of how much time we should wait before we do a follow-up messages:

Regular messages: 18-24 hours
Urgent messages: 20-30 minutes if you are certain that the person is present

Everyone is busy, and it's important to do follow-up once in a while if we want to get things done properly.

💡 Pro tip: Save that message to "later" list so that you remember you're waiting.

🔒 No PII

When using Slack, it's crucial to handle Personally Identifiable Information (PII) with care.

The principle is that: no PII should be posted in public channels. PII includes customer name, phone number, home address, etc.

Big companies usually have guidelines about how to handle PII on Slack. However, if you're in a company with no such guideline, don't do it either. It will come back and bite you one day.

With the rise of privacy awareness, companies usually regulate the access to PIIs, and one day they will require the team to either remove those PII or change the channel access to private. It's a headache if it has not been handled with care.

👓 Using TL;DR

With Slack AI, it's now a lot easier to read a summary of the messages. However, if you're posting a long message, it's still better to have a TL;DR at top as a summary. It helps readers to understand the key points.

Here is an example:

Example of TL;DR on Slack from Adama Berete

By checking TL;DR, readers will know that whether the information is relevant, and they can choose to skip the rest of it or not.

Also, TL;DR isn't just for long messages. Use it for meeting notes, project updates, or any communication that might be time-consuming to read in full.

Last Words

As always, if you find it helpful, please consider subscribe or follow me on LinkedIn.

This post was originally posted at adlerhsieh.com

How to Become a Software Engineering Manager in 2024: An Essential Guide

Adler Hsieh — Sat, 09 Nov 2024 02:30:06 +0000

If you are a Software Engineer interested in transitioning to an Engineering Manager position, you are in the right place!

We're here to demystify that process. Discover the skills we'll need and the mindset shift essential for success. Whether deep in code or already mentoring peers, this guide is our first step toward leadership. Let's explore how to become an engineering manager without the fluff – just the facts we need.

💡 Key Takeaways

We don't need a proper degree to be a Software Engineering Manager (but it's a plus if we have one). Skills and experience are more important.
It is easier to transition to an Engineering Manager role within the organization. Look for internal opportunities.
Before seeing any transition opportunity, we prepare ourselves by gaining more software engineering experience, finding leadership opportunities, and demonstrating a proactive mindset and management capabilities.
Identifying the gap between our current and an Engineering Manager position is also essential. Understand the process and requirements. Use those requirements (if there are any) to build a strong track record. It makes us stand out when the opportunity arises.

Identifying the Requirements of Engineering Managers

First, let's define our end goal. We want to be qualified as an Engineering Manager. However, there are specific skills required for this position. Unlike software engineers, every company has a different definition for the role of Engineering Managers. Some require specific technical skills, such as blockchain, and some need the role to do hands-on coding. However, the following are the essential skills and experience required by most positions:

Strategic Thinking and Problem Solving

These skills are very similar to working on technical projects, but one key difference is that engineering managers work on people and organizational problems.

Strategy thinking and problem-solving involve:

Identifying the problem (this is the key!)
Finding multiple solutions and knowing their tradeoffs
Making a decision
Getting feedback and adjusting executions

One classic example of problem-solving is handling low performers. The most straightforward way to resolve this is to jump right into the solutions. However, it's equally important to understand the problem first.

Consider David's example: David is assigned the development task of adding the payment function on the checkout page. It takes him one week, and there is almost zero progress. Colleagues complain that David is not making progress. As managers, how should we cope with this situation?

A premature manager might rush to find a solution, asking David to speed up, pass the task to another member, or check for any motivation issues.

However, a sound engineering manager would sit down with David and see how he navigates through the problem. He might find that there needs to be more documentation on the checkout page codebase, and it's challenging for David to move forward without understanding the codebase. Thus, the problem is not on David anymore. Adding more documentation to the codebase is the issue. A problem-solving skill like this is essential to distinguish between a Software Engineer and an Engineering Manager.

People Management

For engineering managers, people management is a balancing act that involves

Aligning individual goals with the objectives of the team and project
Building trust
Understanding personal career goals through regular one-to-one meetings
Encouraging and providing growth opportunities

Project Management

Project management is an overlapping area with the Product/Project Manager role. However, Engineering Managers are usually required to have the same sensitivity and skills in project management to move the project forward.

Good project management skills include choosing the right tools and patterns for the development process. For example, everyone loves Scrum and Agile methodology, but only some teams can implement 100% scrum patterns. Some projects use a Kanban method, some use 2-week sprints, and most don't use story points. Managers oversee the process and find the best approach for the team to move forward.

Technical Expertise

Although many engineering managers no longer need to code, they should still be skilled in technical skills. Most managers still need to understand the domain and the technology to make the right decisions when facing problems.

For example, if the engineering team has a problem choosing whether to build their new entity in service A or B, managers should be able to jump in and make the call for the team. To do this, managers need to know what questions to ask (e.g., which approach is faster and whether it provides better system stability) and what technical debts might emerge when using different approaches.

On the other hand, if we are managers that need to code, technical skills would be required.

How to Become an Engineering Manager?

Transitioning from a hands-on software engineer to an engineering manager can be challenging but rewarding. This shift often requires technical skills, a change in mindset, and the development of a new set of skills.

These are some aspects I consider essential:

Internal or External Opportunities?

When considering a move to a management role, it's important to note that companies often prefer promoting from within rather than hiring external candidates because management abilities are more challenging to assess in an interview than technical skills. Therefore, it's usually more feasible to aim for a managerial position at our current workplace before looking elsewhere.

Finding Out The Recommendation Process

The transition from a Software Engineer to an Engineering Manager within an organization typically involves a recommendation process, necessitating a set of specific qualifications. These qualifications range from rigid criteria, such as job level, to soft qualifications, like the ability to resolve conflicts.

Software Engineers usually need to be made aware of these criteria. It's best to talk to an Engineering Manager to understand the responsibilities, requirements, and recommendation process. Every organization has a different process.

After finding the recommendation process, we could talk to our manager to set up a career plan.

Build a Leadership Track Record

Gaining several years of experience in software development is generally a prerequisite before considering a managerial role. Some say having a bachelor's or master's degree is more advantageous, but I don't think it's necessary.

Being in the same organization for a while could also contribute to a good leadership track record. It allows us to understand the technical aspects of the job, the challenges faced by our team, and the processes involved in the project lifecycle. During this period, it's also essential to cultivate soft skills, such as communication and teamwork. As software engineers, we rarely have opportunities to manage people directly. However, having other leadership responsibilities, such as leading cross-team communications or process revamping, would be a big plus for this track record.

How to Build Leadership Track Records as a Software Engineer?

The opportunities to transition to Engineering Managers are usually less than expected. We want to be ready when they arise. We can achieve this by seeking leadership opportunities, learning from engineering leaders, and gaining experience outside our current organization.

Taking Leadership Opportunities When Possible

To prepare for a management role as a software engineer, seek out leadership opportunities within our team. Some examples:

Taking the lead on a big project: Be that person to take the lead and gain experience by communicating with multiple team members, finding a solution that stakeholders are happy about, and delivering the result through teamwork.
Mentoring junior team members: It could be in a casual form where we always reply to their messages on Slack or in meetings. It could also be arranging regular check-ins with them to see how things go.
Proposing and implementing a new process: Basic agile approaches such as daily standup, retrospective meetings, or technical processes, including CD or load testing.
Leading by example to build a healthy team culture: There are many theories and practical steps to creating a good engineering culture in the team. Find the improvement points, discuss them with our manager, and implement them.

Observing and Learning from Engineering Leaders

We can learn insights into effective management practices from experienced engineering managers. Here are some steps we can take to learn from them and progress in our careers:

Engage in high-visibility projects to provide opportunities to observe and learn from experienced engineering managers.
Don't hesitate to contact them and express our interest in transitioning to a managerial role.
Seek their advice on progressing in our careers.

Gaining Experience Outside of the Organization

Note that in most organizations, leadership experience outside the organization is usually disregarded in our track record. However, the point of gaining such experience outside the organization is to learn and practice leadership skills for similar situations inside the organization. Some examples include:

Leadership Programs

Participating in a short-term course (example) or program could enhance our understanding of leadership experience. These experiences are organized as learning materials so we can absorb them quickly (i.e., there is no need to reinvent the wheel!).

Working with a career coach

If we ever feel lost in our pursuit of a management position, aside from talking to our manager, it's also helpful to find a career coach to work with. If you're unfamiliar with the concept, career coaching is a series of one-on-one sessions where we work with our coach to define our goals, identify gaps, and create an action plan. It's a very similar process to working with our manager.

However, the difference from doing it with our manager is that sometimes our manager has their agenda. Some managers want to achieve specific goals, so they may not prioritize our career goals. This situation is more common in smaller organizations where resources are limited. Working with a career coach ensures they are 100% devoted to helping us achieve our career goals (partially because career coaching is quite expensive 💸).

Despite going for career coaching, an ideal scenario is having a good manager willing to help and support us in our career path. I hope that is true in all cases.

Make Ourselves Standout when Opportunities Arise

When opportunities present themselves, it is essential to make ourselves stand out from the crowd. Establishing a strong track record in people and team management, engineering project management, and developing a strong professional network are key to distinguishing ourselves in the field.

Track Record in People and Team Management

Possessing a solid track record in people and team management signals our readiness for an engineering management role. Keeping a record of achievements that match the requirements of an engineering manager can be beneficial.

Sometimes, it is not very clear which achievements we are after. In principle, we want to have supporting materials that help them understand that we have the core skills of engineering managers. Some good examples include:

Lead the team to create the team OKR for the next year: This is usually the Engineering Manager's task, but from my experience, they are usually open to letting someone else do it for them. Ask them for this opportunity.
Lead a complex discussion and find the best solution: In technical discussions, team members may have different opinions. It would be helpful to write down a specific discussion, listing all possible solutions suggested by different members and how we successfully found the best solution.

It has to be in written form so that it is presentable to those who have impacts during the recommendation process. Our manager might be able to do it, too, but we know our track record best.

Developing a Leadership Network

A robust professional network can prove invaluable when preparing for transitioning to a managerial role. Establishing relationships and being seen by senior and successful individuals can lead to being perceived as a peer among high-level professionals.

I suggest reaching out to different engineering leaders in the organization to casually talk about their experience in moving to the management path and whether they have any suggestions for us. This will leave an impression on our motivation to move to the management path, and it could work as a reminder when opportunities arise.

It would be even better to have regular check-ins with leaders closely working with us on specific projects. This way, we enhance our motivation in their mind and get practical suggestions on improving our leadership skills.

Ask for Them when Opportunities Arise

Once we have a well-connected professional network, it is natural for someone in the network to think of us when an opportunity arises. However, everyone has a lot on their plate, so we have to be active in this process. As soon as we hear anything, it's critical to express our interest.

Summary

To wrap things up, the leap from being a software engineer to an engineering manager is a whole new game. It's about more than just coding; it's about learning new skills, stepping up to lead, and being ready to take charge when the time comes. Yes, it's a tough climb, but it's also the kind of challenge that can be incredibly fulfilling for those who are up for it. Every Engineering Manager began their career somewhere, and with the right strategy, that starting point could very well be where we are right now.

So, if we want to make that shift, start by plotting our course and actively seeking out leadership roles, even small ones. Build up skills in managing projects and people. And remember, it's about being proactive—don't wait for opportunities to find us; go out and grab them. With determination and a clear focus on our goals, we can transition from the world of software engineering into management and leadership.

Frequently Asked Questions

What degree or experience do we need to be a software engineering manager?

An engineering manager typically requires 5+ years of experience in software engineering. A degree is entirely optional. Skills are more important than having a degree. The vital part is possessing the skill set that the organization requires from an Engineering Manager. Nevertheless, a relevant degree would lay a good foundation for demonstrating essential skills, such as problem-solving and stakeholder communication.

Is it easier to transition to a management role within my current organization or to seek opportunities elsewhere?

It is generally easier to transition to a management role within our current organization before seeking opportunities elsewhere. Transitioning within the organization allows us to leverage our existing experience and network. Also, organizations don't usually hire someone as an Engineering Manager without prior leadership experience (a Tech Lead role might count).

How do I become an Engineering Manager without any Software Engineer experience?

An engineering manager's job is essentially managing a group of software engineers, so performing well would be very challenging if we did not understand the technical knowledge, working patterns, and challenges. We have already seen so many Software Engineers complaining about the ignorance of Product Managers if they lack experience in software development. Having software development experience is almost always a requirement for Engineering Managers.

How can I stand out when opportunities for a managerial role emerge?

To stand out when opportunities for a managerial role emerge, focus on building a solid track record in people and team management, engineering project management, and developing a professional network. Write these down to match the requirements of the management role's responsibilities. This will help us distinguish ourselves in front of our manager and those who evaluate us.

Mastering Engineering Manager Interviews: The 6 Resources I Use to Land My EM Jobs

Adler Hsieh — Thu, 07 Nov 2024 08:27:42 +0000

Are you ready to take the next step in your career as a software engineering manager? Facing an interview for this role can feel intimidating, but there's a method to mastering it. Understanding how to navigate both the technical and behavioral aspects of the interview is key to standing out.

To help make the preparation process more straightforward, we’ve compiled ten essential resources along with practical tips to focus on key areas! With the right tools and knowledge, we can enter interviews feeling confident and ready to make an impact!

What to Expect: Interview Question Types

1. Coding Interview

While not all engineering managers are expected to code regularly, these interviews ensure that we can engage in technical discussions with our team. Typical questions focus on algorithms, data structures, and problem-solving techniques. It’s beneficial to prepare by reviewing coding platforms such as LeetCode to practice writing clear, efficient code. Our goal should be to demonstrate that we are capable of guiding technical decisions and offering meaningful feedback to our teams.

Example Questions:

Implement a function to find the shortest path in a graph.
Write a program to sort a list of numbers using merge sort.
Given a string, find the longest substring without repeating characters.
Design a stack that supports push, pop, and retrieving the minimum element in constant time.

2. System Design Interview

These interviews focus on how we approach designing complex systems, considering factors like scalability, performance, reliability, and security. We may be asked to design a high-level architecture for a given application or solve a specific problem, such as handling high traffic or ensuring data consistency. Our approach should include breaking down the problem, outlining our design choices, and explaining trade-offs. This type of interview helps showcase our ability to think strategically and translate business requirements into technical solutions.

Example Questions:

Design a URL shortening service like Bit.ly. Consider data storage, API endpoints, and system scalability.
Create a high-level architecture for an e-commerce website. How would you handle inventory management, user authentication, and payment processing?
How would you design a distributed caching system to improve the performance of a read-heavy application?
Design a notification system that can handle millions of users receiving real-time updates.

3. Technical Interview: Technical Questions & Experience

The technical interview is distinct from the coding or system design segments and is more focused on evaluating our overall technical expertise and experience. This could involve discussing our past projects, our knowledge of various tools and frameworks, and how we’ve applied technology to solve complex challenges. Questions may touch on specific technologies we have worked with, architectural patterns, or our understanding of software development best practices.

Example Questions:

What are its benefits and drawbacks compared to monolithic systems vs micro-service architectures?
Describe a challenging technical problem you encountered in a past project and how you resolved it.
How do you ensure the quality and scalability of the software your team builds?

4. Behavioral Interview & Leadership Interview

Behavioral and leadership interviews are designed to evaluate our management style, problem-solving approach, and ability to lead teams effectively. It's the core part of the interviews for management positions.

For behavioral questions, they often use questions that start with “Tell me about a time when…” and focus on past experiences, including conflict resolution, motivating teams, or managing stakeholders.

For leadership questions, the emphasis is on our ability to build and maintain strong, high-performing teams. It’s helpful to use structured frameworks like the STAR (Situation, Task, Action, Result) method to answer these questions, ensuring that we clearly outline the context, our approach, and the impact of our actions. Preparing concrete examples that demonstrate our leadership principles and management style will allow us to highlight our strengths and establish our credibility as an engineering leader.

Example Questions:

Tell us about a time when you had to manage conflict between team members. How did you resolve it?
Describe a project where you had to balance technical debt against the need for new features. How did you prioritize?
How do you provide feedback to team members who are underperforming or need improvement?
Can you share an example of how you influenced a major technical or business decision without having direct authority?

Six Essential Resources

Video Course Platform: Exponent (Paid) Exponent is a platform that offers resources and guidance for preparing for interviews in various technical and management roles. I took their EM prep course and I found some piece of knowledge very valuable. It's also my first materials for preparation so it has a very comprehensive guideline of how to start the preparation in each part.
Interview Guideline Book "The Software Engineering Manager Interview Guide" by Vidal Graupera I would say this is the Bible during my Engineering Manager interview preparation process. The content is highly practical and focuses on real-world scenarios and best practices. Without exposing too much details, I would recommend everyone who is doing the preparation to take a look. You can check this mock interview video with the author on Exponent to get his insights.
Video Course Platform: AlgoExpert.io (Paid) AlgoExpert is a platform offering video (mostly) courses on technical & behavioral interviews. The content is mostly duplicate with the previous materials but they have their own way to explain the same problems and questions. I personally find them easier to digest than on LeetCode or System Design Interview. It's not free, but we probably only need one or two months to digest most resources on this platform.
Coding Interview Practice Platform: LeetCode (Freemium) LeetCode is one of the most popular platforms for practicing coding problems. Start from the easy questions LeetCode to brush up on coding basics, and gradually move on to the medium questions. It's going to be overwhelming at first even for the easy questions, but we'll usually start to be able to keep up. Spend 10-20 minutes a day for this. We'll see the progress. I personally would suggest focus on the top 150 problems that are the most fundamental for any type of questions.Books and Courses
Coding Interview Book: "Cracking the Coding Interview" by Gayle Laakmann McDowell (Paid) I personally didn't use this, but it is highly recommended by a lot of online platforms. It provides guidance on how to approach technical interviews with an eye on clarity and communication, which are the skills important for both engineering managers and individual contributors.
System Design Book: "System Design Interview - An Insider's Guide" by Alex Xu (Paid) This book is a must-read for anyone preparing for system design interviews. It goes beyond the basics and dives deep into large-scale distributed system design, providing examples that closely mirror real-world interview questions. It's helpful not only for interviews, but for training a systematic approach to problems in our daily workflow as IC or EM as well.

Preparing for the Upcoming Interview

When getting ready for a software engineering manager interview, it's important that we focus on understanding the job role, researching the company thoroughly, and clarifying the process with recruiters. Let's break down these steps to ensure success.

Understand the Job Description

When applying for an Engineering Manager (EM) role, it's essential to thoroughly analyze the job description to understand the unique expectations. Here’s how to approach it:

Identify Management vs. Technical Responsibilities: Some EM roles are purely focused on people management, mentorship, and strategic oversight. Others require us to be hands-on, contributing code and actively participating in the technical development process.
Scope of Technical Leadership: Certain positions emphasize cross-functional leadership, where we’re expected to manage teams across the full stack (frontend, backend, and sometimes DevOps). Others might require domain-specific leadership, such as being a specialist in either Frontend (FE) or Backend (BE) development.
Understand the Team’s Needs: We should look for phrases like “full-stack leadership” or “deep knowledge of FE/BE technologies” to gauge whether the role is broad or specialized. It’s important to determine if the job description mentions specific tech stacks or methodologies, as these details signal what the team values in a technical leader.
Tailor Our Application: We should highlight experiences and achievements that align with the role’s requirements, whether that’s managing diverse engineering teams or driving hands-on technical projects. Our resume and cover letter should reflect our adaptability, technical expertise, and strategic vision as required by the role.

Breaking down the job description this way ensures you present yourself as the right fit, showing a clear understanding of the company’s specific needs.

Research the Company

Knowing about the company is just as vital. We would want to dive into the company's mission, values, and culture. This information gives insights into whether our own values match and how we can contribute to their goals.

A practical step is looking into recent projects or technologies they focus on. Understanding their products and innovations helps us tailor our discussions, showing how we fit into their future plans. Exploring their challenges and how our unique skills can address them gives us a competitive edge.

Clarify the Process with the Recruiters/HR

Let’s ensure we have a clear grasp of the interview process. Usually, there is a recruiter or HR representative when setting up the interviews. There might also be a casual chat session. Here are some questions I would clarify when talking to recruiters or their HR:

Understand the Interview Stages: We should ask the recruiter for a detailed overview of the interview stages and what each step involves. This includes finding out if the process will include coding tests, system design interviews, behavioral rounds, or panel interviews.
Clarify the Evaluation Criteria: It’s important to clarify what skills and experiences will be evaluated at each stage. I usually go with the question: "what does a successful candidate look like for this role?"
Confirm the Participants and Roles: We should ask who will be involved in each round. Knowing whether we’ll be speaking with other managers, senior engineers, or HR will help us tailor our responses. For example, if the interview involves cross-functional partners like Product Managers or Designers, we should be prepared to showcase our collaboration and cross-team communication skills.
Check for Pre-Interview Materials: Inquire whether there are any specific resources or preparation materials provided for candidates, such as case studies or coding challenges. Some companies may offer a prep guide or outline key focus areas, which can be invaluable for targeted preparation.

Other Tips for Preparations

Preparing for a software engineering manager interview takes more than technical knowledge. Practice, mindset, and understanding the interview process are key. Let’s explore some effective practices to give us an edge.

Mock Interviews & Practice

Engaging in mock interviews can greatly improve our chances of success. By simulating real interview scenarios, we become more familiar with what to expect and gain confidence. We should set up these practice sessions with peers or mentors who can provide constructive feedback.

Practicing answers to common questions sharpens our responses. Resources like software engineering manager interview questions can be valuable. Focusing on clarity and conciseness helps us communicate effectively, which is crucial for a manager's role. Recording these sessions can also help us find areas for improvement.

Dos and Don’ts During the Interview

Dos:

Discuss Real-World Scenarios: Use specific examples to illustrate our management style and problem-solving approach. Using the STAR approach would be a good idea.
Ask Thoughtful Questions: Toward the end of the interview, use the opportunity to ask questions that show our genuine interest in the company’s team structure, culture, and challenges.
Be Honest About Challenges: When discussing past experiences, be honest about challenges you faced and how you overcame them. This demonstrates our ability to handle setbacks and find solutions.

Don’ts:

Don’t Give Generic Responses: Avoid vague answers like “I manage teams effectively.” Instead, provide detailed, context-rich examples that highlight specific actions and results you achieved in our previous roles.
Don’t Skip Behavioral Questions: Some candidates neglect to prepare for behavioral questions, thinking their technical experience is sufficient. Instead, practice behavioral questions about leadership, teamwork, and handling difficult situations to round out our interview performance.
Don’t Shy Away from Discussing Failures: A common mistake is avoiding questions about projects that didn’t go well. Being open about failures and what we learned from them shows resilience and a growth mindset, which are valued traits in engineering leadership.

Final Thoughts

Preparing for the interview can be challenging, but by focusing on key areas such as coding, system design, and behavioral skills, we can approach it with confidence. The process is not just about showcasing our skills but also about demonstrating how we can align with the company’s vision and support the team’s growth.

By understanding the job requirements, researching the company, and clarifying the interview process, we’ll be well-prepared to present ourselves as well-rounded candidates ready to take on the challenges of leading high-performing engineering teams. Our path to mastering these interviews involves understanding our strengths and presenting them clearly.

Let me know if you have any questions! Feel free to drop a comment or send me a message to see if I can help!

This post was originally published at adlerhsieh.com

Effectively Onboarding Software Engineer Contractors: A Smooth Start

Adler Hsieh — Wed, 06 Nov 2024 12:13:25 +0000

Bringing software engineer contractors onto the team is a great way to speed up project development. They usually equip with skills that we need, and they are ready to do it. With a proper plan, it can be a great tool to the business. In this article, we’ll go over the best practices to onboard contractors based on my experience.

💡 Key Takeaways

A structured onboarding process/plan helps contractors integrate smoothly and start contributing faster.
Setup a feedback loop to help moving the process faster, as well as making a decision on whether we should keep these contractors. Use performance metrics to support those decisions.
Utilize tools to speed up the onboarding process such as documentations & automated tools. This ensures good product quality when new contractors join the team.

Managing Contractors vs. Permanent Members

Working with contractors and permanent employees are very different. This article describes well on the difference, and here is a summary.

Flexibility vs. Stability

Contractors offer us great flexibility. We can bring them in for specific projects or to fill skill gaps. This helps our engineering teams stay agile and adapt to changing needs. When there is a big project coming in, we bring more members in; on the other hand, we keep a smaller them when we are only working on smaller projects.

Permanent staff give us more stability. They stick around longer and really get to know our systems. This can be great for long-term projects/products. Most IT companies hope to work on long-term products.

We often find that a mix works best. Contractors can jump in to tackle new tech or tight deadlines. Permanent folks keep things running day-to-day. The proportion can be tricky, but I would recommend keeping around only 10%-20% contractors. Too many contractors will add instability to the team.

Onboarding Differences

Getting contractors up to speed is different from permanent hires. We need to move faster. Here's a quick comparison:

Contractors: Brief overview, focus on project specifics
Permanent: Deeper dive into company culture, long-term goals

We make sure contractors get the key info they need to start coding ASAP. For permanent staff, we take more time to build strong connections.

Junior engineers often need extra support, no matter their status. We pair them with senior engineers when we can.

Communication & Engagement

Keeping everyone in the loop is crucial. We use different strategies for contractors and permanent members.

With contractors, we focus on:

Clear project goals
Regular check-ins
Specific task assignments

For permanent staff, we also need to discuss:

Long-term career discussions
Involvement in team initiatives

However, it does not mean that we don't discuss careers with contractors. In my experience, most contractors are eager to grow in their career as well, but for practical reasons, staying in an contractor agency is the most reasonable choice for them. It's best to clarify with them whether they are looking for long-term career growth as well. Mixing some career-related discussions in the communication with contractors can contribute to stronger bonding.

Performance Management

Tracking performance looks different for each group.

For contractors, we usually:

Set clear milestones
Do frequent project-based reviews
Focus on deliverables

With permanent staff, we:

Have regular performance reviews
Set long-term growth goals
Look at team contributions beyond just code

Our hiring managers play a big role here. They help make sure everyone's on track, whether they're with us for a few months or the long haul.

There is an exception that if contractors are interested in contribute beyond code, make a plan to do it. For example, if a member is interested in creating a technical debt list and try to eliminate the debts, work with the team to see if there's any opportunity for that member to do it. I would recommend allowing them to try. It's a positive sign that they are able to contribute what we usually only expect permanent employees to do.

However, we want to make sure that they are not contributing "too much". One trait with contractors is that, comparing with permanent members, they might be removed from the team for any reason. We want to ensure that core responsibilities in the team are still handled by or shared with permanent members, in order to avoid bus factors.

Preparing For Onboarding

Getting ready for contractor onboarding takes some planning. We need to set clear goals, define needed skills, and establish a trial period. These steps help ensure a smooth start for new developers.

Define Clear Goals & Schedules

We should start by outlining what we want to achieve with our new software engineer contractor. Let's create a list of specific projects or tasks we need help with. This gives our contractor a clear direction from day one.

We also need to set realistic deadlines. A schedule helps everyone stay on track. We can use a simple table to lay out key milestones. For example:

The schedule can be flexible, but remember to review the progress at the end of each period. Write down what went well, what could have been don’t better, and is it necessary to adjust the schedule.

Define Required Skills & Domain Knowledge

Next, we need to pinpoint the exact skills our project needs. This helps us pick the right person and plan their onboarding.

Let's make a checklist of must-have skills:

Programming languages (e.g. Java, Python)
Frameworks (e.g. React, VueJS)
Tools (e.g. Jenkins, JIRA)

We should also think about the domain expertise needed. If we're working on a finance app, some experience in working with banking could be helpful.

Set a "Probation Period"

There's usually no agreement of probation period for contractors, but we can have one in mind. We would decide a timing when we make a decision on whether we continue to work with them or not. A common timeframe is 90 days.

During this time, we should:

Have regular check-ins
Offer extra support
Give and ask for feedback

This period is key to a good onboarding experience. It lets us address any issues early on. We can use this time to see how well the contractor fits with our team. It's also a chance for them to decide if they like working with us.

At the end of the 90 days, depending on the progress, we will decide whether we should continue working with the contractor. Compared with working with permanent members, it's easier to replace contractors so it usually has less emotional impact if we decide to end the contract.

Assign a Mentor or Onboarding Buddy

Assigning a mentor or onboarding buddy can make a big difference in how quickly a contractor feels comfortable and productive.

The mentor should be:

experienced with the team and can answer questions, provide guidance, and help the contractor understand the team's processes and culture.
Have regular check-ins during the initial period with the new member

Continuous Feedback & Improvements

A well-planned onboarding process helps software engineer contractors quickly adapt to their new roles. We've created a sample plan that covers essential aspects like orientation, tool setup, and project integration.

Continuous Feedback Loop

Try to reach out to everyone working with the member and get feedback from everyone. For example:

Daily/Weekly 1-on-1 with the contractor
Weekly 1-on-1 meetings with the contractor's mentor
Bi-weekly check-ins with the project manager
Monthly performance reviews/feedback with the contractor and their agency

These help us address any concerns and ensure that they feel supported.

Reflect On Initial Period

After the 1st & 2nd month, we schedule reflection sessions. We discuss:

What went well
Areas for improvement
Any challenges faced

Like any retrospective meetings, these help us revisit what happened during the onboarding period.

Addressing Challenges When Working With Contractors

Working with software engineer contractors brings unique challenges. Some issues that I ran into:

Product Ownership

Ownership is rarely a priority for contractors, since they are here for completing the assignments, not for running products (even for long-term contractors).

That is not a problem if the team has 80% permanent members; but I've been in a team where 95% members are contractors. Lacking ownership means:

Members only care about finishing features, but do not care about technical debts.
Members handle incidents, but do not think about prevention measurements.

There is no perfect solution to this so far, but I would talk to those contractors who are more senior, to see if they are interested in taking bigger responsibilities, such as creating guidelines, hosting knowledge sharing sessions, and mentoring more junior contractors. I would put emphasis on the career growth.

It then becomes a win-win situation. They have the opportunity to work on team leadership, and I have certain members be better owners of the product.

Managing Different Time Zones

Working with members in a different timezone can be tricky sometimes, especially nowadays a lot of software engineering work are outsourced to Vietnam or India. If contractors do not have sufficient ownership, they might not use their time very well when the managers and permanent team members are outside of working hours.

A solution to this is to evaluate the output based on deliverables, instead of purely working hours. For example, we expect contractors to deliver their work based on their weekly 40 hours, instead of checking their clock-in & clock-out records.

As for collaborations, we ensure sufficient overlapping work hours to have real-time communication when needed. This might mean asking contractors to adjust their schedules slightly or finding a middle ground that works for everyone.

Also, make sure to involve them in regular meetings such as daily stand-ups to discuss progress and any blockers.

Maintaining Code Quality

Maintaining code quality process would be similar to how we do it with permanent member, but having documentation becomes more important.

With contractors, we expect them to onboard as fast as possible. They will start working on projects right away. Without that extra care, it's very easy to see contractors coding differently from the team and no one knows how to handle that difference. A worse situation, for example, is that there are multiple ways to handle logging, package locations, and validations.

In that case, having good documentation adds an extra layer of communications. For example:

Domain knowledge explanations
Coding & style guideline
Workflow explanations

These documents ensure that the new contractors won’t solely rely on the help of the mentor. They will be able to follow the team's workflow and style.

It's also helpful to have other workflow best practices such as using CI, having sufficient unit test coverage, linters, etc. This allows an automated check on contractors' code submissions.

Keep and Eye on Performance Metrics

Similar to monitoring the performance metrics of permanent employees, it’s going to be easier if we use metrics to measure contractor performance. One big benefit is that everything with contractors are more objective and delivery-based.

While there are a lot of tools out there, here are some tools that I use with my teams:

LinearB:
- Metrics: Cycle time, coding time, review time, deploy time
- Usage: Set benchmarks for each metric and compare contractor performance against team averages.
SonarQube:
- Metrics: Code coverage, code smells, technical debt
- Usage: Set quality gates that code must pass before being merged. Use the "Issues" page to assign code quality improvements to contractors.
Jira:
- Metrics: Sprint velocity, bug fix rates, ticket resolution time, time in status
- Usage: Create custom dashboards to track metrics related to project progress. A more specific example below.

For example, we can use Jira to track the duration of each status such as in-progress and in-review. We can use plug-ins or create a custom dashboard with Jira API to track these numbers.

If you notice a contractor's tickets consistently have longer review times, investigate potential causes: Are they submitting large, complex changes? Are they not responding promptly to review comments? Is there a communication issue with the reviewing team members? Use these insights to coach the contractor on creating more reviewable code chunks or to adjust your team's review process.

Frequently Asked Questions

How does managing contractors differ from managing permanent employees?

Key differences include:

Contractors offer flexibility for specific projects; permanent staff provide long-term stability.
Contractor onboarding is faster, focusing on project specifics.
Contractor performance is measured by clear milestones, while permanent staff have more comprehensive evaluations.

What strategies can help maintain code quality when working with contractors?

The primary focus is alignment. Strategies include:

Implementing thorough documentation
Using code quality tools like SonarQube
Conducting regular code reviews and feedback sessions

How can companies effectively manage contractors in different time zones?

Effective management across time zones involves:

Evaluating output based on deliverables, not strict hours
Ensuring overlapping work hours for communication
Involving contractors in regular team meetings
Using project management tools for asynchronous tracking

Making Better Decisions with AI as Engineering Managers: A Prompt Guide

Adler Hsieh — Tue, 05 Nov 2024 01:31:18 +0000

We've all been there as Engineering Managers: facing a complex issue that does not have a straightforward answer. We apply our past experience but are not sure whether we miss anything. For example, we were looking for that rockstar candidate during hiring, but all we found were candidates that were not perfect. Among these candidates, who is the best for the team?

There is never a perfect decision. Fortunately, with generative AI rising, it also becomes a great tool to help us in such situations. AI is not just about automating tasks anymore. One of the most powerful uses of AI is for brainstorming. I often use them to help with decisions like hiring, team structure, and technical architecture choices. It can digest team context and provide recommendations.

With the right amount of help from AI (we don't want to go too far!) it supports our judgment to make a better decision.

💡 Key Takeaways

Engineering leaders can brainstorm solutions by describing their problems and situations to AI tools such as ChatGPT (with proper care of PII & business secrets).
Working with AI is a process of "interactive brainstorming". Start broad, refine, and find the answers.

Gen-AI as a Decision-Making Partner

Interactive Brainstorming

The strength of AI tools like ChatGPT is to provide endless ideas toward a question, and we would utilize it for brainstorming solutions. Unlike traditional search engines, we can always ask follow-up questions.

The cycle looks like this:

We start from broad/basic questions (e.g, how to improve team productivity)
AI provide general suggestions
We either:
1. refine our questions by adding more context; or,
1. dig deep into one (or more) of the suggestions
AI provide more suggestions
Repeat 3 & 4

I call this "interactive brainstorming". It's a cycle where we gradually move toward the answer that we are looking for. It's like talking to a consultant or coach, but with unlimited time ⏱️

Expect Multiple Options, Not A Single Answer

If you remember all the memes on internet about AI making mistakes, you are probably aware that do not rely on AI to provide one perfect answer. Instead, think of AI as a tool that presents multiple options with pros and cons.

AI can make mistakes

Your job as an engineering manager is to evaluate these options using your experience and judgment. AI provides the data, you provide the context and make the final call.

Remember: AI is a partner, not a replacement for your decision-making skills.

Techniques For Providing Relevant Context

To get the best results from AI in decision-making, you need to feed it the right information. Here are some examples of context:

Team dynamics: team members, skill sets, workload, etc.
Goals: Be specific about what the team wants to achieve.
Historical data: Important past project outcomes and metrics.
Constraints: budget, time, and resource limitations.

You don't have to provide everything, but anything can be helpful. I would suggest building a prompt template that can be used in different contexts. Save it as a text file and add details to it every time you provide new contexts to AI. It will turn into a knowledge base.

By giving AI this context, you'll get more accurate and useful insights. It's like briefing a new team member – the more they know, the better they can contribute.

Problem-Solving Example: Hiring Decisions

Hiring is common in managing a team. However, for new Engineering Managers, it's always overwhelming when making the first hiring decision.

Companies usually provide a guideline in hiring, but it won't tell managers how to find the best fit for their specific team. In addition to Googling various resources, it's also helpful to seek answers from AI. It's common to have one candidate that is good enough to pass all interviews, but we are wondering whether we should keep looking.

Let's use hiring as an example to see how can we have a conversation with AI and move toward the solutions that we are looking for:

1. Start with the Basic Questions

Let's start with the basics and use ChatGPT as an example. I would start with the prompt:

What factors should a manager consider when evaluating a software engineer candidate for the team? There is a candidate that has passed all interviews but the manager is wondering if they should proceed.

ChatGPT will give me a list of factors. For example:

Technical Skills and Fit
Team Dynamic Compatibility
Cultural Fit
...

The benefit of using AI is that we can continue the conversation. Let's add some details in the next step!

2. Refining Questions by Adding Contexts

Seeing all the options provided by AI, you probably will have some ideas what to look for. But in case it's still unclear, it's always good to look at our problem statements: Why are we hiring? What problems are we trying to resolve?

Let's say the reason why we are hiring is due to addition of some big development projects. In that case, give this detail to AI and they will help us narrow down the options.

For example:

The main reason of hiring is that there is a big project coming, and the team needs an extra hand. In that case, what factors should the manager prioritize?

And we'll get some more accurate answers such as:

Project-Specific Experience
Team Dynamics and Workload Management
Communication Skills
...

Now we have more accurate options to consider. Since AI knows that the main reason of the hiring is for a new project, it will surround its answers with the project. If there are other issues that we are resolving, such as having not enough senior members in the team, it's also helpful to provide those contexts.

3. Provide Constraints

One common challenge for managers is that they don't know whether they should keep looking or move forward. Often times there is no rockstar candidate. In that situation, we can provide this context to AI as well:

The candidate is good enough to pass the criteria, but the manager is wondering whether they should keep looking. What are some factors that can support the manager making this decision?

We'll get some more factors from AI:

Urgency of the Hiring Need
Fit Beyond Minimum Criteria
Potential Risks vs. Benefits
...

You might feel that AI is just giving a list of options without ranking their priority. No problem. Just ask them to do it:

Rank these factors

It will give you a more accurate ranking of which factors should you prioritize.

Remember, the brainstorming process is always interactive. Imagine AI as a consultant. Ask all questions that you want.

4. List Priority Factors and Make a Decision

At this point, you probably already have more than 30 factors to consider thanks to AI, but we are not going to use all of them.

Create a document and put all the important factors for the team, and add details to those factors. This helps organize our thoughts in decision-making. For example:

🟢 Good Skills match. Shorter onboarding time.
🟢 Available immediately.
🟡 Might have language barrier. Still learning English.

Just like a hiring scoreboard, once you are happy with the list, you'll make a well-informed decision.

In this process, AI helps rank the most important factors related to the team. It might not seem very difficult for experienced managers, but for those who are not familiar with this topic, it could be a great learning opportunity.

Best Practices For AI Collaboration

Start Broad, And Refine

Begin with a wide-angle view when using AI for your projects. 🔍 Cast a broad net with your initial prompts to get a comprehensive overview. For example, ask "What are the main considerations for refactoring a legacy codebase?" This approach helps you understand the full scope of the task.

As you gather info, narrow your focus. Refine your prompts to dig deeper into specific areas. You might follow up with "What are best practices for refactoring JavaScript in a monolithic app?"

It's like zooming in on a map - start with the whole country, then drill down to your exact destination.

Ask For Structured Response Including Guides, Examples, And Risks

Request guides, examples, and potential risks for each task. This approach helps you get actionable insights and spot potential issues early.

For instance, when planning a new feature, prompt the AI: "Provide a step-by-step guide for splitting the frontend and backend in a monolith app. Include best practices and risks."

💡 Key elements to request:

Clear, numbered steps
Potential pitfalls and how to avoid them
Best practices specific to your tech stack

Techniques For Iterative Refinement

Refining AI outputs is crucial for getting the best results. It is like a conversation - you're guiding the AI to bring you close to the answers.

Start by analyzing the initial response. What's missing? What could be improved? Use this to form your next prompt. For example, if the AI suggests a database schema, you might ask, "How can we optimize this schema for read-heavy operations?"

Some suggestions:

Ask for alternatives: "What are other approaches to solving this problem?"
Request pros and cons: "List the advantages and disadvantages of each method"
Seek real-world examples: "Show me how top tech companies have implemented this"

Each iteration brings you closer to the optimal solution for your software development process.

Challenges While Working With AI Tools

Handling PII & Private Business Information

When using AI tools like ChatGPT, you need to be careful with sensitive data. Companies like OpenAI usually train their model using your conversations with AI. In worst scenarios, they might accidentally store or leak private info.

Here are some key points:

Always check your company's policies & restrictions on AI use.
Be cautious about personal information or private business data. We don't want names, phone numbers, and addresses to be leaked.
Always use role-playing in conversations with AI. Avoid using "I" and "we" to indicate that this is your real situation.

Balancing AI And Human Creativity & Accountability

While AI can generate code and ideas quickly, it's crucial to maintain human oversight. You don't want to lose the creative spark of your team or end up with AI-dependent processes.

We have seen so many developers abusing AI and use ChatGPT-generated codes directly in their codebase without modifications. We don't want to see that happening on Engineering Managers.

Use AI as a helper, not a replacement for human thinking. Combine AI insights with human expertise for better quality control. The goal is to enhance your team's capabilities, not make them AI-dependent.

Other Use Of AI In Decision-Making

Supporting Materials

AI can find relevant info & ideas to back up your decisions. You might ask for insights on similar decisions, industry trends, or past examples. This saves you time digging through docs.

Sounding Board

AI can act as a brainstorming partner when you're tackling tricky problems. Describe your situation and ask for different perspectives or solution ideas. This can help you spot angles you might have missed.

You can also use AI to simulate team discussions. Present a potential decision and ask how different roles (devs, QA, product) might react. This lets you anticipate concerns and refine your approach.

Frequently Asked Questions

What AI tools are best for interactive brainstorming?

Most popular tools like ChatGPT, Claude, or Gemini are useful in this case. Different tools have their own strength and insights, so I would recommend use multiple tools if you struggle with finding insightful answers on one tool.

However, it would be helpful if the tool has a "knowledge base" functionality available, so that you don't have to input your prompt from scratch every time. So far, I think Claude is the best for usability, but ChatGPT has better insights sometimes.

What are the best practices for integrating AI into engineering management processes?

Start small when adding AI to your work. It would work the best with areas that you are not familiar with. AI can provide general advices to lead you through the door.

Always check AI results. Don't rely on them completely. Use your own judgment too.

Keep learning about new AI tech. It changes fast. Stay up to date to get the most benefits.

This post was originally published at adlerhsieh.com

Is Ruby on Rails Worth Learning in 2024? A Quick Insight

Adler Hsieh — Sun, 03 Nov 2024 05:13:44 +0000

As we delve into 2024, many developers might wonder: is Ruby on Rails still worth learning in 2024? In recent years, other emerging technologies and frameworks have gained popularity. However, Ruby on Rails, based on the Ruby programming language, maintains its reputation. It is a highly efficient, mature, and developer-friendly solution. Its advantages in rapid development, a thriving community, and a mature ecosystem make it an attractive skill for developers.

However, like any other technology, Ruby on Rails has advantages and drawbacks. When considering whether to learn this versatile framework, it's important to weigh the pros and cons and evaluate the future outlook.

💡 Key Takeaways

Ruby on Rails is still a valuable skill in 2024. Many major players in the market, such as GitHub and AirBnB, are still using it.
Although its usage rate is not the highest in the market, Ruby on Rails remains one of the top-paying technologies in 2023.
Its popularity creates a lot of self-taught learning resources, making it one of the most accessible technologies.

Strengths of Ruby on Rails

An Overview of the Tech

Ruby on Rails (Rails or RoR) is a Ruby framework that has been a game-changer since its first public release in 2004. Over the years, it has matured into a stable and reliable framework, becoming a popular choice for web developers. It remains one of the popular choices of frameworks due to:

Flexibility: Rails allows you to work on various web projects, from small to large-scale.
Convention over configuration: It follows guidelines that help you build applications faster.
Active community: Rails has an active and supportive community. Developers can find lots of resources, such as tutorials and documentation, to help you in your learning journey.

Rapid Development (Great for Startups)

One major advantage of learning Ruby on Rails is its focus on rapid development. Its doctrine captures its design philosophy and focuses on development efficiency. For example, getting used to a new Rails codebase usually takes very little time due to the "convention over configuration" philosophy. It minimizes the need for lengthy configurations.

Furthermore, Rails has many built-in tools and features, such as scaffolding. It automates the generation of your application's basic structure. By learning Ruby on Rails, you'll be able to create functional web applications in a fraction of the time compared to other coding languages.

Strong Community

Another reason to learn Ruby on Rails is its strong community support. The Rails community is vibrant and active. It has a rich ecosystem of Gems (libraries) that allow you to extend the functionality of your application without reinventing the wheel.

Some examples of popular Rails Gems are:

Devise - for authentication.
CarrierWave - for file uploads
ActiveAdmin - for administration interfaces

This extensive library of Gems lets you focus on what makes your application unique. The community's expertise helps you lay a solid foundation, allowing you to build applications more efficiently and with a higher level of quality.

Challenges of Using Ruby on Rails

Performance Concerns

While Ruby on Rails can help you build and deploy web applications quickly, one downside is performance concerns. Due to its language design, scaling Rails applications could be more complicated than other popular alternatives, such as Go and Java.

However, scaling could be a complicated issue. It involves not only the programming language itself but also database tuning, application logic, and others. The programming language is only one factor in scaling. So, don't let performance be the sole reason to skip learning Ruby on Rails.

Trend Shifts

Another factor that might cause hesitation when learning Ruby on Rails in 2024 is the technological trend shift. Newer frameworks and languages like Node.js and Go are gaining popularity in the web development community, which might make you wonder about the long-term relevancy of Ruby on Rails.

However, it's important to remember that Ruby on Rails still has a thriving community and a strong foothold in the job market. Technology trends can change, and it's often more valuable to have a strong grasp of languages and frameworks to stay adaptable.

The State of Web Development

Comparison with Other Frameworks

Here is a list of notable web frameworks to compare with Rails:

Django (Python)

Django is another mature and feature-rich web framework. Python is also widely adopted in general computer programming education due to its simple syntax. According to a StackOverflow survey 2023, Django has a bigger market share of 11.47% compared with Rails' 5.49%.

Python and Ruby are known for their friendliness to beginners and abundant learning resources. However, both languages have the same scalability issue when businesses and applications start to grow.

Their differences mostly lie in the coding style. Python is well known for its use of indentation in the codebase:

def hello():
  print("hello world")

If the indentation breaks, the code breaks. Some consider this style clean, but some consider it hard to read when the codebase is large.

Express.js (Node.js)

Express.js is a minimalistic web framework that brings server-side JavaScript to the table. It is known for its ease of use and performance. It doesn't include many features out-of-the-box like Rails, but it utilizes great features in Node.js, such as scalability and performance.

One of the most common reasons for adopting Node.js for companies is that they can use JavaScript for both frontend and backend. It's easier for companies to hire full-stack developers. According to the StackOverflow survey, it has the highest market share in web technologies, with the usage of 42.65%.

Node.js and Ruby usually have different use cases. Node.js is strong and stable on a single thread. So, businesses usually use it for messaging apps like chatrooms and games. Thus, Rails is widely used for CMS and prototyping minimum viable products.

Is Ruby on Rails dead?

There is an ongoing question people ask every year. If you search for "Is Ruby on Rails dead in 20XX?" you will likely find 10+ articles, including forums and blogs, discussing this topic.

The short answer: No. Ruby on Rails is far from dead. Some simple reasons:

The community remains strong. There are many learning resources, discussions, updates, meetups, and conferences around the world.
Ruby and Rails' versions are still evolving very quickly.
Major companies like Shopify, GitHub, and Airbnb continue to use and invest in Rails.

Job Market and Opportunities

Real-World Applications of Ruby on Rails

Ruby on Rails serves as the core technology for numerous online platforms. For example:

GitHub: The world's leading software development platform runs on Rails. There are several tweaks to run an application with such scale, but it is still Rails in its foundation.
Airbnb: Changing how we travel and stay around the globe, Airbnb's seamless user experience is powered by Ruby on Rails.
Shopify: E-commerce at its finest. Shopify makes selling online easy for over 1 million businesses worldwide, all thanks to Rails under its hood.
Twitch: Before becoming a live streaming giant for gamers everywhere, Twitch started its journey with Ruby on Rails.

These companies started small and scaled up big time, all while sticking with Ruby on Rails throughout their growth phases. This highlights Ruby on Rails's adaptability as a tool for crafting web applications and underscores its significance in scaling projects from startups to enterprises.

Demand for Ruby on Rails Developers

As of 2024, Ruby on Rails continues to be a highly lucrative skill. In a recent survey on StackOverflow, Ruby's popularity is behind languages such as JavaScript and Python. Its use rate is 6.23%. However, Ruby took 4th place as the top paying technology, making it worth considering for your career path.

It's also one of the Ruby community's features that there might not be as many job openings in the market as JavaScript and Python. Still, every opening is a gem worth digging.

Learning Resources for Ruby on Rails

Diving into Ruby on Rails? There's a sea of resources, whether you're just starting or looking to level up. But let's be real: not all resources are created equal. Here's a curated list that'll take you from zero to a seasoned developer:

Ruby on Rails Guides

These guides are the holy grail for Rails learners. They thoroughly cover the framework's initial understanding to a solid knowledge of its features.

Codecademy's Learn Rails Course

Do you love interactive learning? Codecademy makes it fun and engaging with its hands-on approach.

GoRails

It is a collection of videos that dive into the ins and outs of Rails. Its paid plan would bring you more professional knowledge.

The Odin Project - Ruby on Rails

Want something more structured? Embark on a journey from the fundamentals of web creation, all through this no-cost educational pathway.

The journey might seem long now. But remember that every expert was once a beginner wondering if they could do it too. Spoiler alert: You absolutely can!

Frequently Asked Questions

What are the job prospects for Ruby on Rails developers in 2024?

The job prospects for Ruby on Rails developers in 2024 remain promising. Compared with popular languages such as JavaScript and Python, Ruby on Rails might have a low usage rate. However, it is still a popular web framework in strong demand in the job market. Ruby took 4th place as the top-paying technology based on the StackOverflow survey in 2023. With this in mind, learning Ruby on Rails is a viable option for a rewarding career in the tech industry.

It is for you if you love its coding style, design philosophy, and thriving community. Don't let the popularity of other languages scare you away. The most important factor is that you love this technology and will master it.

What are the latest major projects or companies adopting Ruby on Rails?

Major tech companies like GitHub, GitLab, AirBnB, and Shopify still use Ruby on Rails. They might not use Rails for their entire codebase, but it remains one of the core technologies in their stack.

Can learning Ruby on Rails provide a stable career path in the tech industry nowadays?

Yes. Learning Ruby on Rails can provide a stable career path in the tech industry. Its continuous popularity and the high demand for Ruby developers among startups and agencies.

We are in the tech recession in 2024, but it's important to remember that every challenge brings new opportunities. The Rails community continues to thrive, offering support and resources to developers at all levels. There are still emerging opportunities in startups, established companies, or freelance projects.

What are the key advantages of using Ruby on Rails for new web applications today?

Ruby on Rails offers several key advantages for new web applications today:

It emphasizes convention over configuration. Developers do not need to make decisions about the application's basic structure.
Its syntax follows a natural language format, making it easy to learn and understand.
The strong Ruby community support makes finding resources, solutions, and assistance easier when needed.
Rails is an excellent choice for creating Minimum Viable Products (MVPs), which is important for startups.

This post was originally published at adlerhsieh.com