I’m extremely sorry that the associate made a false promise. Could you please help me with the associate’s name? We do not encourage such behaviour and a strict action will be taken against the associate.

Here is the response I received from Amazon’s customer service, following a false promise by another agent about refunding my Prime membership. Each time I read the response, I can’t help but feel really disappointed, as both a customer and a former employee of the company. At the beginning I thought that it was just a non-professional agent but when I take a look at my past experiences, and after hearing similar stories from friends, I really wonder:

Is promising punishment a deliberate strategy to make customers feel guilty, preventing them from pursuing their rights?

To provide some context, I had an annual Prime membership with Amazon. However, due to reasons that are not relevant to this discussion, I decided to cancel it. I was seeking a refund for the unused portion of the subscription. The initial agent I spoke to promised me a full refund for the entire membership — a promise that didn’t entirely surprise me, given my past experiences with Amazon’s usually benevolent customer service.

Several days passed without any trace of the refund in my account and this led me to contact the customer service team again. After being transferred multiple times between various agents, the final one delivered strange the news that the previous agent had made a “false promise.” Here are the issues that surfaced from this situation:

1. Misleading Promises

The first agent made a promise they couldn’t keep. This forced me to chase them down again, wasting my time on something that should have been a one-and-done deal. Sure, people make mistakes. I get it. But this wasn’t really my actual problem. In the world of customer service, the first impression you get from the beginning can really shape how you feel about the whole thing. When promises are broken, it’s not just an inconvenience. It can seriously damage your faith in the company. You will always question whether you can trust the info they’re giving you.

2. Employee Punishment as a Means to Customer Satisfaction?

The next thing that bugged me much more was when the agent promised to take “strict action” on his coworker. This had me wondered why I would feel better knowing someone was getting in trouble because of a simple mistake? Threatening employees with strict actions for small errors dramatically increases the pressure, potentially leading to even more mistakes instead of addressing the real issue at hand. When I have an issue, I want it sorted out, not to hear about how someone’s getting punished. The guilty agent could probably have been found out internally, but the customer service rep decided to frame it as them trying to please me by disciplining the agent. It seemed like they got the idea of customer satisfaction all wrong, and frankly was too extreme.

3. The Guilt Imposed on the Customer

The most bothersome part of my entire experience was that after all this, instead of feeling a relief of a resolved issue, I was left with feeling of guilt. I started thinking that my follow-up has jeopardized the first agent’s career. It dawned on me that just by trying to get a simple issue fixed, someone could end up in serious trouble. I mean, come on, after chatting with customer service, the goal is to feel heard, valued, and confident that everything’s been taken care of. The last thing you’d expect is to be on a guilt trip, wondering if you caused some harm to the person on the other end of the line.

But what made me wonder even more was that this wasn’t a one-time thing. I had déjà vu from a similar experience last year with Amazon Fresh. I received a torn bag of frozen blueberries, and when I asked for a refund, the agent told me they’d flag the delivery driver for messing up. And there I was, again drowning in guilt and discomfort. I remember I was almost begging the agent not to punish the driver until the agent let the punishment part go.

Tactical Guilt Gaming or Company’s Culture of Blame?

Looking at the bigger picture and given how often this has been happening, it’s got me wondering two possibilities. On one hand, this could be a sign of inadequate training for agents or maybe it’s a company culture that leans more towards penalizing than understanding. Those familiar with Amazon’s work environment know how stressful it can be, especially during on-calls when dealing with external customer-related issues. For customer service agents who frequently handle unhappy or even angry customers, the pressure is even more dreadful, and under such stress, mistakes are inevitable.

On the other hand, is this Amazon’s new strategy? Loading customers with guilt, making it feel like some indirect way of telling us to back off without actually saying it?

What do you think?

Punishing for Pleasure? My Experience with Amazon Customer Service was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

ChatGPT was released to the public on November 30th, 2022, and it marks the start of a new era in AI. Large Language Models (LLMs) have become really popular and many companies are trying to use AI to improve their operations. Industries like tech, publishing, accounting, and legal already experienced a significant impact, with many more industries likely to be affected soon. Generally, the industries working with a vast amount of information is going to be the most impacted by this trend.

Following such growing demand for AI, the ability to properly feed AI models with information has become as important. That’s where “Prompt Engineering” comes in — a new type of job to ensure the AI models are fed with the right “prompts” to satisfy business requirements. But does prompt engineering play a key role in the future of AI job market?

What is prompt engineering?

Prompt engineering refers to the process of writing concise, comprehensible, and effective prompts that direct an AI system towards a specific outcome or decision. This is done by providing the AI model with a sequence of input prompts that enable it to recognize patterns and connections in data and generate predictions based on that information. Generally, I see two primary objectives for prompt engineering:

The first objective of prompt engineering is to devise text-based inputs that can guide the AI model more effectively. Prompt engineers provide the model with various inputs and then evaluate the output. If the output does not meet the expected level of precision, prompt engineers collaborate with developers to fine-tune the model. For instance, the model may be required not to use any any aggressive tone or avoid expressing any political viewpoint, and it must also be safeguarded against threats like prompt injection.

In the second scenario, different industries engage prompt engineers to write text inputs that will provide the optimized results while meeting domain requirements. For example, in the healthcare industry, it is critical that the AI model does not leak any personal or confidential information. Another example is developing efficient prompts to get the most out of the model while utilizing the fewest number of tokens to minimize the cost of utilizing the AI model.

What skills are required for a prompt engineer?

There are essential skills that a prompt engineer should have:

1. A deep understanding of linguistics: without a profound understanding of human language, it can be challenging to work effectively with language models. Prompt engineers need to be really good at understanding the little details in language, like slang, idioms, and sayings. By being able to pick up on these nuances, prompt engineers can create prompts that work well in different situations and industries.
2. A good understanding of how LLMs are structured: this involves having a grasp of the underlying technology that powers LLMs. With this knowledge, prompt engineers can make informed decisions and quickly adapt their prompts to improve the AI model’s performance. Keeping up-to-date with the latest advancements in LLM technology can also help prompt engineers stay ahead of the curve and create more effective prompts.
3. Domain-specific knowledge: prompt engineers who understand the specific domain can create prompts that are not only linguistically accurate but also relevant to the industry’s specific requirements. For example, in the legal industry, prompts need to be precise and unambiguous and leave no room for ambiguity. On the other hand, in creative design, prompts should be designed to inspire exploration and the discovery of fresh ideas. Therefore, it is crucial for prompt engineers to have domain-specific knowledge to create prompts that achieve the desired results in different industries.
4. Familiarity with computer security : Prompt engineers must have a thorough understanding of security engineering to ensure that LLM systems are safe to adversarial attacks, including prompt injection. They must be able to spot vulnerabilities that may arise during the prompt testing process, and work closely with security engineers to design models that can withstand malicious attacks while maintaining accuracy and consistency.

A simple Google search yields many courses and resources about working with ChatGPT and LLMs in general. Some of these resources mention prompt engineering in their outlines, but they only cover the basics of creating effective text inputs. However, a few resources go beyond that and provide more comprehensive knowledge on the subject.

One such resource is Learn Prompting, which offers open-source courses on communicating with artificial intelligence and covers both the fundamentals and advanced topics of prompt engineering. Additionally, DeepLearning.AI provides a short course on prompt engineering for developers. As AI continues to grow and evolve, we can expect to see more resources that provide essential prompt engineering skills.

The Potential Future of Prompt Engineering in AI Job Market

Prompt engineering is becoming more and more popular in the AI job market. Many experts view prompt engineering as the future of AI development, as there is a growing need for human input to interact with and control these sophisticated systems. The increasing complexity of AI models requires prompt engineers to continuously adapt and acquire new skills to create effective prompts. Despite these changes, the need for prompt engineers is not expected to diminish any time soon.

A report by Business Insider shows that almost a third of business leaders plan to hire prompt engineers this year and

some companies are even willing to pay prompt engineers with no tech background up to $335,000 a year.

These are the folks who train AI chatbots to give the best possible results. Lots of workers are already using ChatGPT to make their jobs easier, whether that’s writing code, coming up with marketing copy, or creating lesson plans.

The report adds that prompt engineering is a really important skill to have if you want to work in AI development. And it looks like demand for prompt engineers is only going to keep going up in the future!

People who are fans of prompt engineering say that it makes AI systems easier to use and more user-friendly. And that, in turn, can make them more efficient and effective. When users are able to interact with and control these systems more easily, they can get better results from them.

Criticism of Prompt Engineering

Despite its growing popularity, Some experts are worried that relying too heavily on prompts could lead to bias in AI systems.

Sam Altman, a high-profile figure in the tech industry, has said that prompt engineering is just a phase in the bigger goal of making machines understand human language more naturally.

In a 2022 interview with Reid Hoffman, the founder of LinkedIn, Altman said that he didn’t think we’d still be doing prompt engineering in five years.

Another concern is that prompt engineering may be overhyped and not as essential as some claim.

While some experts have criticized prompt engineering for its potential to introduce bias into AI systems and questioned its long-term relevance, I’m optimistic about prompt engineering because it’s fundamental in enabling AI systems to understand human language and interact effectively. Without well-crafted prompts, AI models can’t identify patterns or make reliable predictions. So prompt engineering is essential to make sure AI systems produce meaningful results across all industries. Plus, prompt engineering is always improving, with new techniques and tools to create more effective prompts.

In fact, in my opinion, prompt engineering skills will become a must-have for everybody to do their regular work, similar to how Google search is widely used today. However, as the complexity of AI systems increases, prompt engineering skills will remain sophisticated, and there will always be a need for prompt engineers.

More content at PlainEnglish.io.

Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord.

Prompt Engineering: The Future of AI Job Market or Just a Trend? was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Layoffs are an unfortunate reality of the current IT industry, which may not be a desirable topic to begin the new year with. As companies struggle to adapt to the economic challenges resulting from the pandemic, many are faced with difficult decisions, including implementing layoffs. Even major tech companies such as Meta and Amazon, which had hired significant numbers of employees during the pandemic, have had to let go of a significant portion of their workforce, including some of my colleagues and friends. Unfortunately, layoffs have remained a reality in early 2023 (updated list of tech lay offs), and there is no clear indication of when the trend of layoffs will decrease.

Although layoffs may seem daunting, it’s a natural part of any career and even many industry leaders have experienced it at some point. However, it’s important to stay informed about industry trends and be prepared for the possibility of layoffs in the future.

Keep calm and don’t panic

I recall the feeling of dread that overcame me when I was laid off some years ago. However, by speaking with some friends who had gone through similar experiences, I was able to manage my stress and stay grounded during that difficult time. Even if you are not affected, it’s natural to feel stressed and tempted to work harder to protect your job security, but remember that other decisions outside of your control also contribute to layoff decisions. These can include the company’s overall financial situation, the specific needs of the business, and even factors such as company culture and politics. While continuing to do your job well and being a valuable member of your team is important, remember that your job security is not solely determined by your performance. Instead of panicking and overworking, take a rational approach and focus on what you can control, such as preparing for potential job loss, staying informed about the company’s situation, and exploring opportunities for professional development and advancement.

Stay positive and don’t blame others

I have also seen examples where individuals have directed negative language towards leaders and placed blame on others for the current situation. Even if you have not been affected by the layoffs within your company, it is understandable to feel angry and upset after a layoff, especially if you knew the individuals who were affected. However, it’s important to remember that blaming others and cursing leaders will not improve the situation and can actually create a negative atmosphere for everyone involved. This negative environment can further exacerbate the company’s situation.

Show empathy to colleagues who were let go

It’s important to remember that those who have been affected by layoffs are going through a difficult time and may need support and understanding. Try to reach out to your colleagues, especially the junior ones, who have been impacted to see how they are doing and offer any assistance or support they may need. This will help them to feel more supported and valued during this challenging period. Make contact to your professional network and see if there are any job openings that they may be a good fit for your laid off colleagues.

Remember that showing sympathy and support for your laid off colleagues is not only the right thing to do as a human being, but it can also be beneficial for your career. It allows you to gain insight into their job search progress, including potential job opportunities. This information can be useful if you are also considering a job change in the future.

Develop a plan for financial security

Building a financial safety net is important for protecting yourself and your family from financial insecurity in the event of a layoff. Having a safety net in place can provide a cushion of savings or other resources that can help you maintain your standard of living in case of job loss. This includes things like an emergency fund, investments, or other savings that can help you pay your bills and expenses if you are unable to find a new job right away. To build a financial safety net, it is important to focus on saving money and reducing debt. This may involve cutting back on unnecessary expenses, such as dining out or subscriptions you don’t use, and creating a budget to help you manage your money more effectively. Additionally, paying off high-interest debt, such as credit card balances, can help you free up more money to save for your safety net.

Freshen up your interview skills

While there is no need to panic and spend excessive time on interview preparation, it is important to refresh your interview skills. This can include researching common interview questions, enhancing your technical knowledge, and familiarizing yourself with the company and position you might plan to apply for. Having strong interview skills helps you stand out among other candidates and increases your chances of getting the job. Additionally, updating your resume and LinkedIn profile can also be a good way to make yourself more visible to potential employers. It is always a good idea to be ready for any unexpected job search opportunity that might come your way.

Conclusion

In summary, it’s important to remember that even if you are not currently affected by layoffs, it’s still a good idea to be prepared for potential changes in the job market. This can include staying informed about the company’s situation, identifying signs that your job may be secure, and building a contingency plan. Implementing these measures can enhance your capability to overcome any obstacles that may arise in the job market. Additionally, it’s important to stay calm and positive, and to continue engaging and being productive at work. Remember to always be vigilant and to continue developing your strategies, so you’re always ready for any uncertainty that may arise.

Surviving Layoffs: How to React When You Have Not Been Laid Off was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

I left Amazon to pursue other opportunities to fuel my career growth. When I joined Amazon Vancouver, the office was small with less than 200 employees. At the time I decided to leave, Amazon Vancouver had offices in multiple buildings incorporating thousands of employees. On my last day with the company, more than 97% overall of Amazon employees were hired after me. Both Amazon and myself experienced growth simultaneously.

TL;DR

I joined during one of the darkest times at Amazon. Thanks to the New York Times controversial article in 2015 (one year after I joined), Amazon started some internal changes to improve the work environment. I came on board as a junior engineer and left as a senior. Looking back on my time as an Amazon employee, I do realize that I had made a lot of mistakes on the job. However, I’m happy that at least I can now recognize what I did wrong and avoid making the same mistakes again over time. To cut the story short, it’s hard for me to think of specific times where I felt indifferent regarding Amazon. My emotion toward the company was basically either love or hate. Based on my personal experience, I would like to share some of the things that I liked the most about Amazon and what I think could be improved or changed altogether.

What I liked a lot about Amazon

These are some of the reasons I enjoyed while working at Amazon. The company possesses many positive traits that can be beneficial to the growth and development of your career and expertise.

The ultimate ownership

One thing I really loved about working at Amazon is that you are not simply assigned a task to follow blindly. Instead, you are responsible for owning a project from start to finish. In some instances, you are only given a vague description of what needs to be done. Therefore, you have to communicate with many people to clarify the problem. Then, you follow suit by preparing a design, talk to more people, and revise the plan till you reach the final consensus. Afterwards, you can continue with implementation, testing, and a launch plan. Even after the completion, you continue watching the project to make sure it has been a successful feature.

Even as an engineer, you are expected to evaluate if a project really makes sense and make the necessary adjustments to create a path for successful implementation.

Engineering Excellence

Many services at AWS (Amazon Web Services) are pay-as-you-go. This means that the customers are only charged whenever their services are running reliably. Consequently, AWS receives nothing if the services are not running as expected. A similar situation exists for the retail website as customers cannot purchase efficiently if any of the dependent services are not working properly. So, it’s not hard to imagine that engineering excellence should be a key factor in any feature launches at Amazon.

That’s why as an engineer, you should always prioritize keeping engineering excellence in mind. For every feature launch, you need to have enough code coverage, reliable tests, proper metrics and alarms, an effective dashboard, and last but not least a detailed runbook to reduce the possibility and effects of potential issues.

A lot of learning resources

A wide range of learning materials are available internally at Amazon to help you ramp up quickly and resolve almost every possible issue in a short space of time. There is a Youtube-like channel for internally sourced and created educational videos, a stack-overflow type website in which engineers can seek help from their peers, and an efficient searching system that looks for anything inside wikis, emails, or codes to name a few.

Your [technical] voice is heard regardless of your seniority

In engineering discussions, what you say matters more than your level. In my “customer obsession” training class for the new hires, I was always encouraging them to challenge others’ decisions, especially if there was no clear rational reason behind them. I have been also advising them to not accept things just because they were expected to. In many meetings such as special design review sessions, I’ve seen many occurrences in which a junior asks challenging questions from a senior and the senior had to present a meaningful answer. No engineer should respond in a way that gives the impression that they are always right because they have seniority. They should be open to discussion, no matter their level.

Things that could be changed (in my opinion)

Amazon has some great initiatives but there are some aspects that I believe could be improved or changed for the better. Especially when it comes to creating a more efficient and happy workforce, Amazon could prioritize their human resource a bit more.

Promotion is a game, you should know how to play it

I guess this is not limited to Amazon and is valid for many other large corporations. At Amazon, you should have enough stories for almost all leadership principles and have enough supporting senior people to back your stories. As your rank goes up, it’s harder to be promoted. If your manager is new, your colleagues are juniors, or the team’s projects are not impactful enough, it’s much more difficult for you to move up.

It’s not about what you like to do or how well you do your job. It’s about finding the right team with the right projects. If you are missing a story for a leadership principle, you need to talk to your manager to find a project to address that. If you need a feedback provider, you also need to somehow connect to a senior with a plan to get feedback later. Sometimes, if you are lucky that you get into the a right environment from the beginning, all of these things happen naturally. However, in most cases, you need to pre-plan well before the promotion dates.

Amazon pays more attention to the customers than employees; A lot more!

In most of our product decisions at Amazon, we were considering our customers as the highest priority. Although there were some cases in which I believed that the business needs were put ahead of customer requirements, in general, customer needs are assumed as the highest priority. Even when dealing with tickets, we were always looking for customer-originated ones to take care of before anything else.

Customer care is important, but on the other hand, the pressure always falls to the employees’ shoulders. You would face hard times if customers were not happy, for whatever reason. On-calls could be especially frustrating without getting paid extra or receiving acknowledgement for being up all the night to work on operational issues. I have seen talented people left just because of on-call frustrations.

I remember a time when I asked a VP visiting our office about the possibility of benefits for on-calls (like extra paid hours for extra time you spend during your shift). I received the response of “if you do your on-calls perfectly, the Amazon stock goes up and you would benefit from it.” I don’t know how it can be justified these days when the stock prices are dramatically falling down.

There is always something against you in the Leadership Principles

While many companies stick to a couple of values to define their culture, Amazon leadership principles are ever increasing. At the time I joined, Amazon had 12 principles vs. the 16 principles they currently have. These principles have been part of the Amazonians’ daily communication whether you want to raise or destroy someone. For example, it’s not uncommon to hear things like “you need to show better bias for action” or “thanks for your bias for action”.

In the annual peer review, you have to choose at least one leadership principle as an area for the improvement. Managers are always equipped with a large selection of contradictory-like principles if they want to use them against an employee. For instance, if you deliver a feature under a very tight deadline (which naturally is delivered with limitation due to time pressure), a manager might say that you are good at delivering results and bias for action, while another can claim that you need improvement on “Insist on highest standards”.

I believe that a large number of cultural items can be deliberately misused to get the most out of an employee while promising the least in return. For instance, sometimes they can be vague like “Always Right” , or can also be contradictory like “Bias for Action” and “Insist on highest standards”

Amazon pushes you to the last, not necessarily to the best

When I joined Amazon, I had a week to complete the boot camp and the ramp-up process. On the second week, I got a real task. I should confess I really enjoyed “getting my hands dirty” as quickly as possible. However, the expectation from the new hires quickly increases over time to make sure that the employees can catch up to the Amazon-expected speed in no time at all.

New recruits often struggle to work faster to keep up with pace of the company which can affect the quality of their work. The best sentence to describe the situation is the one I was told when joining the Alexa team, “Drink water from the hose” meaning you need to learn a lot and work hard at a really fast pace.

To ensure that employees always “meet the bar”, every quarter, each manager would give the names of the 10% bottom performers to the HR or has to bring some proof to show if nobody is reported. Then, HR would ask the manager to present plans for the people on the list. If manager puts them in a mentorship program (which is usually the case), the employee then works closely and officially with the manager in a 2-month program. During this program, the employee cannot switch teams or take leave of absence. In the worst-case scenarios, the employee might enter a more serious 3-month performance program (like PIP) with harsher consequences which can lead to termination of contract. Unfortunately, I’ve seen many new hires end up in one of these plans in the first few months and quickly go under a huge amount of stress.

With such high expectations in the mentorship programs, many employees are pushed to their limits and not always to their best potentials. I remember during a design phase of a project, my manager assigned a colleague to help, however, he was in one of the programs which required him to deliver more code. In that situation, he was so stressed and desperately asked me to add some coding tasks to the project. I ended up asking him to write some integration test codes to satisfy the program needs, although I really needed him more for preparation of the design doc. After a couple of months, he ended up moving to another company despite them providing a lower income.

Another instance I recall is during one of the Amazon Prime days. The on-call from one of the Prime teams made a mistake causing the customer to not be able to purchase for a while. I don’t know if he was punished by his manager or whether the whole incident was considered an honest mistake. What I heard from his colleagues was that he took the next day off and was thinking of committing suicide by jumping from the Lions Gate bridge!

Even managers can be affected by the high-paced environment. I’ve seen managers who did their best to alleviate some of the pressure experienced by employees. Yet they still ended up being crushed and left Amazon. New and less senior managers often get dealt the most stress because they have to experience the pressure from both engineers and higher managers.

On-calls kill your life, unless you choose your team wisely

Picture going to bed at 12am, getting paged at 1am, fixing the issue, going to bed (again) at 2am, only to get paged at 3:30am. It sounds very exhausting, however, this is a familiar story for many Amazonians who experienced on-calls at Amazon. Some teams suffer from a significant amount of operational issues causing terrible frustration for the on-calls. They are usually so overwhelmed with list of new features that they can barely spend time on operational excellence to make the mandatory on-call shifts more tolerable.

You have to choose the right team from the beginning to ensure that you can professionally grow in that team. Being on a team that works proficiently and having colleagues who can stand up to the challenges the team may encounter can make a huge difference.

Final thoughts

It’s hard to make a generic statement about a very large company like Amazon. Factors like managers, colleagues, and projects to name a few can have huge positive or negative impacts on your career. Therefore, these factors don’t necessarily relate to or can’t be generalized to Amazon as a whole.

In a nutshell, Amazon is a great engineering company with a lot of highly impacting and technically challenging projects. This really helps employees to learn top-notch concepts at a very quick pace. However, it comes with a price, which can affect other aspects of life such as your health, or relationships with loved ones if the situations are not managed properly.

Left Amazon after 7.5+ years; Here is my honest review. was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

In both our work and personal lives, conflicts are inevitable. Some common sources of conflict include opposing positions or views, competitive tensions amongst colleagues, or even jealousy. Power struggles, ego, pride, performance inconsistencies, and compensation issues are also areas where conflict can arise. Sometimes, a conflict simply occurs because someone is having a bad day.

It’s important to distinguish between disagreement and conflict. In a workplace, disagreements can help you to assess situations from different perspectives. But if not properly managed, disagreement can quickly convert to a destructive conflict.

As a leader, you should prioritize developing skills that prepare you to handle any form of conflict in a professional manner. Here are eight simple steps to handle conflicts like a leader:

1. Communicate Face to Face

Communication is key when it comes to resolving disputes. However, text-based communication such as emails, instant messages, or notes may not diminish the conflict. On the other hand, it can also potentially escalate the situation due to misunderstanding. Body language, tone, and eye contact are important communicative cues that help people better understand each other. Try to book a meeting in a safe space to discuss the issues at hand. If the parties involved cannot meet at the same location, a virtual conference call is your closest alternative.

2. Be a Good Listener

Conflicts consist of two or more persons. Everyone has a voice, opinion, and way of perceiving problems. You also have your own prejudgment of the circumstances. It is important to remain objective when listening to your colleagues and gather as much information as possible. This can be achieved by:

• Listening to what is being said before reacting
• Not interrupting when the other person is speaking
• Making sure you understand what is being said by rephrasing and repeating the points made
• Asking questions to clarify your understanding of the situation further

Sometimes conflicts occur because people feel like their voices aren’t being heard. Encouraging open communication and giving colleagues a platform to voice their concerns can significantly impact conflict resolution.

3. Identify the Areas of Conflict

Before moving forward on any resolution, you must have a firm understanding of the conflict. You can then prioritize which areas need urgent resolution. Identify the disagreements, and discuss the unmet needs of both parties that have caused the conflict. Finding out what can be compromised or agreed upon is also important to work on a solution. Summarize the points and ensure that both parties can reach a mutual understanding of what the problem is based on your assessments and investigation. This should be accomplished before moving on to any further resolution and may be a lengthy process.

4. Gather Information

Ensure that there is enough information to identify the conflict. Sometimes, the lack of information may be the source of the conflict. As such, you should then plan how and where to get more information to make a better decision. This can involve looking for deep underlying issues. For example, talking to other colleagues to find out how they feel about the conflict or in what ways it affects them can provide valuable insight and feedback.

5. Find Short- and Long-Term Solutions

It’s not uncommon to meet engineers who try to find the perfect solution. However, most of the time, that solution is cost-effective and not practical. Differing views will also come with different proposed solutions. Each party may think they have the best approach. It would be wise to break up the solution into phases to avoid confusion and chaos.

Short-term goals should be quickly agreed upon to address urgent concerns. In other words, the solution may not be achieved in one fell swoop but may require work over time. In my experience, I noticed that people are more likely to agree on a good enough (vs. perfect) solution for the short-term solution, and consequently, a common consensus can be reached more quickly.

Every a short-term goal reached, however, can alleviate much of the stress and tension caused by the conflict leading to more constructive discussion about the longer-term goal.

6. Assign Responsibility

Solving conflict takes time and commitment. Each involved party has to work on finding a good enough solution that benefits everyone involved. Each person should contribute to different areas to improve the situation. They may have to take steps to rectify the issues that they are facing. Setting common goals that align with the company objective or determining ways each colleague can work together is beneficial in the long term. This gives each person time to fix discrepancies and reasonably reach common ground. Taking responsibility also boosts accountability and makes each person more dependable as they work towards a sustainable solution.

7. Present a Tangible Agreement

When a solution or method is agreed upon to mitigate conflict, it should be written down and sent to the stakeholders to ensure that everyone has a mutual understanding of the agreed approach. Documenting each phase of conflict resolution is vital to prevent future occurrences and provide tools to resolve similar issues quickly. This makes it easier to follow through on your plan and make adjustments as needed.

8. Evaluate the Solution Over Time

As a leader, you should closely observe and point out progress made over time that shows a positive outcome of the proposed approach. Being actively involved, guiding colleagues, and keeping communication open will help with the long-term success of the solution. You can also keep looking for ways to make the solution work better or be more efficient over time. Changes may occur, roles are often switched around, and balance may be thrown off, which can affect your plan. Keep a ‘let’s work out a solution’ attitude when faced with adversity in the workplace.

Conclusion

In conclusion, everyone faces conflict at various times in their home or work life. Therefore, one must be well equipped to deal with conflict when it appears. Finding a solution may not be instantaneous. Most likely, it will consist of several meetings, back and forth correspondence, and brainstorming before an appropriate resolution can be found. How you handle conflict also helps with future proofing against the same problem. Good conflict resolution should provide insight and expertise on managing situations professionally when issues arise.

8 Simple Steps To Handle Conflicts Like a Leader was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

First, I have to mention that this preparation plan is based on my own experience and might not necessarily work for others, however, there are general recommendations that can be beneficial to anyone interested in the process.

TL;DR

Here’s a little background story about myself. I worked at Amazon for 7.5+ years. At the time of my departure from the company, more than 97% of Amazonians were subsequently hired. The decision to leave came as a result of wanting to look for opportunities elsewhere, explore new challenges, and increase my total income. I was a semi-active interviewer at Amazon, but apart from that, I haven’t prepared for technical interviews in several years. After a couple of months of preparation and interviews with some software companies, I received multiple offers. Then, after some negotiations, I signed an offer and accepted a senior engineer position at Meta (formerly Facebook).

Determine if you are really a senior engineer

If you do a quick Google search, you’ll find many articles talking about the definition of seniority for software engineer positions. However, years of experience don’t necessarily translate to a seniority level. For example, if you have done any of the following, consider yourself a senior engineer:

• Led a project with a larger scope than your immediate team which included a large amount of communication with external teams.
• Are familiar with System Design concepts and independently designed a semi-complicated system.
• Your code is clean, well-documented, and with proper test cases.
• Mentored other engineers/interns. Mentorship can have different forms and range from reviewing others’ code, active participation in design meetings, or setting up learning sessions to fully mentoring engineers from the beginning till the ramp-up goal is reached.
• Proactively look for ways to solve a problem without being told

Personally, I consider the above items to be the basic or the minimum requirements a senior engineer should possess. If you are missing one or more of the above items in your experience, you should actively plan to gain that valuable experience before applying for any senior position. Landing a senior position at other companies also requires a preparation strategy as well as consistency and commitment. Here is a breakdown of what my preparation plan looked like.

Before Preparation

1. Determine how much preparation you need

The first step I took was solving popular easy questions on LeetCode without timing how long it took to solve each problem. I solved about 70% of the questions without paying attention to the time. This also provided a great refresher course for certain data structures like PriorityQueue (Heap) that I never used in my daily job. Based on the outcome, I noticed that at least 3 months were required for me to pass the onsite interviews.

2. Find out the target companies

It’s important to research and compile a list of companies that you want to apply for. For each company, I read descriptions for available positions to determine if they were aligned with my interests and check whether I met the requirements. This step can be also done weeks before your preparation and gives you a better idea of what to expect from certain companies and positions.

Week 1–4, Before phone interviews

1. Focus on Algorithms/Coding

In my former position, I was already designing large-scale systems. The challenging part is the coding questions that required more time for practice. In terms of the difficulty of the questions, I spent 20% of my time on easy, 70% on medium, and 10% on popular, hard questions (e.g. Word Ladder 2, Alien Dictionary, Minimum Window Substring, and Word Break 2). Again, I didn’t time myself but made sure I thoroughly did my best to solve the problems before jumping to the solutions. To make more use of the limited preparation time, I created a 10 Not-To-Do list when solving questions on LeetCode.

Another strategy was booking mock interview sessions on TechMockInterview to better understand which areas I needed to improve from a professional’s point of view. I booked coding sessions with Google and Meta interviewers which ended up being quite beneficial.

2. Apply for the positions

I applied to my targeted positions during the first 2 weeks. The response time varied with some companies responding in a matter of days, some in 1–2 weeks, a few never responded and others sent rejections within the resume evaluation phase.

During this period, I took the initiative to set up the phone screening around the 6th week with the recruiters. Once the phone screening dates were finalized, I created a doc for each company and gathered all coding, system design, and behavioral questions I could via searches on Glassdoor, LeetCode discussion section, and preparation materials that those companies had provided.

Week 5–6: Final preparation for phone screens

The phone screens are heavily focused on coding and perhaps a few behavioral questions. It’s good practice to have a margin of at least 2–3 days between each interview and use it for reading the company-specific docs mentioned in the previous section. This time, I timed myself during the coding preparations.

An important but commonly overlooked part is the behavioral questions. A company like Snap mentions that one of the must-know questions would be “Why Snap?” and fair enough this was the first question asked. I also gathered a list of behavioral questions and tried to answer each precisely in a STAR manner.

Week 7–12: OnSite Preparation

I managed to pass all the phone screens except for one. Ironically, it was the same interview I felt most confident about. It’s important to note that you will encounter disappointments during the process. However, instead of trying to analyze the reasons behind any rejection, it’s more feasible to shift your focus to the rest of the interviews that you have lined up.

1. System Design

For the senior position interviews, you should expect at least one system design round. This plays a significant role in determining your seniority level in the final offer. Note that

If you do a commendable job in coding but perform mediocre in the system design round, they might reject you or offer an intermediate position.

If you consider yourself a senior engineer based on the minimum requirements previously mentioned, then you should be familiar with basic system design concepts and have led design sessions in your current position. For system design, I studied the following materials:

Tech Dummies Youtube Channel: His videos are based on his research on many technical blogs. The designs that he explains are very close to the architecture of real-world services. Some videos might look lengthy but there are many concepts to be learned (e.g. Count–min sketch) from watching the videos.

Gaurav Sen Youtube Channel: The explanation style of this particular channel is very close to what is expected in a system design interview. One downside for me, however, was that he sped up the voice on some videos which may be a little frustrating to some viewers.

Grokking the System Design Interviews: My personal preference is videos over text so the tutorials were a task for me to endure. Also, they are highly focused on gathering a lot of numbers and calculations which isn’t truly necessary. Unless you are specifically asked about something like the number of needed servers, you simply just need a rough idea about the scale of the system from the gathered numbers. For instance, you should know whether storing data in memory is a feasible option considering the requirement or if you need another way or even a hybrid approach to store your data. It’s solely dependent on the question and the interviewer’s preference.

I followed a very simple structure in my system design interviews unless the interviewer wanted to lead me in a different direction. In a nutshell, these are the methods that worked for me:

• Clarifying questions, gathering functional, and non-functional (e.g. availability, consistency, latency, durability, numbers related to the usage of the system, etc.): 10 mins
• API Design: 5 mins
• High-level design (most of the cases following a micro-service architecture): 10 mins
• Data Model (e.g. table designs): 5 mins
• Answering follow-up questions or going into details of a component: 10–15 mins

2. Coding

Regardless of your position, the software engineer interviews are heavily focused on coding. You should expect on-site questions to be somewhat more difficult than phone screens. At this stage, more focus should be placed on timing.

During my preparation, I noticed 6 really popular topics in the questions asked by the interviewers. I spent extra time pursuing the relevant questions to these topics.

There are also algorithms/concepts that are highly recommended to review in case they appear in hard questions, these include Dijkstra shortest distance, Bellman-Ford, Prim algorithm on MSP, Fisher-Yates Shuffle, Quick Select, Graph Coloring, Interval Tree, and Segment Tree.

3. Behavioral

Never underestimate the importance of behavioral questions. Failure in this section is a failure in the interview regardless of your performance in the technical part. At Amazon, I saw many candidates (although they performed well in the technical part) got rejected solely because they didn’t provide acceptable scenarios in the behavioral section.

4. Mock Interviews

There are some mock interview platforms online. As mentioned before I used TechMockInterview.com and was quite happy with it. Before the onsite round, I booked a couple of more sessions with Google/Meta interviewers and received valuable feedback on my performance. It should be noted that their questions were more interesting and more challenging than what played out in my real-life interviews. They were so efficient that I felt more stressed in the mocks compared to the real interviews! This is why having mock interviews with friends or sessions with professional services are essential to assess your performance in real interview situations.

Negotiations and Final Offer

My personal goal was to get multiple offers from the companies I admired and wanted to work for. Multi-offer situation gives you more power to negotiate and choose your happy path more confidently. In the end, getting a good position is not all about the money. It’s about what makes you feel satisfied in the new role. If you turn down an offer just because another company offered you a higher salary, you might end up working in a role you don’t like. This could potentially lead to working in an environment that is frustrating and misaligned with your career goals. Think deeply about what you want (growth opportunity, work-life balance, learning new tech stacks, etc.) and negotiate until you reach a final decision that presents the closest representation of your expectations.

Study Plan to Land Senior Software Engineer Positions at Meta, Google, and More was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

All of us, officially or unofficially, have participated in a brainstorming session at some point. When you discuss weekend activities with some friends and everybody shares ideas, you are brainstorming to ensure that your weekend is well-planned. Brainstorming is a mechanism that allows everyone to share ideas in a common forum that allows everyone to reach a consensus. As Vincent Van Gogh once mentioned:

Great things are done by a series of small things brought together.

This exemplifies what brainstorming brings to the table. It helps to figure out a new direction or confirms the current direction or pathway that’s already panning out. Whenever you don’t know many aspects of a problem but you need to make a prompt decision, brainstorming can help to make up your mind by collecting and trimming ideas from other people with diverse backgrounds. For, instance, if you plan to implement new mechanisms in your service for better user engagement, you might decide to brainstorm with your colleagues. In this article, I try to bring some guidelines to better organize the brainstorming sessions in your company.

Benefits of a brainstorming session?

Before planning for any session, think about how the various ways brainstorming can help. Some of the major benefits of brainstorming include:

Boosts group morale: When brainstorming, every individual’s ideas are brought to the table in a setting that makes everyone feel welcome to share. This leads to people in the group feeling that they’re valuable and that their insights are going to be useful.

Creative thinking: Brainstorming inspires and nurtures creative thinking. In a great brainstorming session, you can ask questions and immediately receive random ideas. The momentum and ease at which ideas flow can spark many different perspectives to deal with the topic at hand. It’s important to take note of all the ideas generated in a session.

Lots of diverse ideas: This can sometimes be difficult because what we want to focus on is not just the quality of the idea, but the number of ideas that arise. This could be hard, especially when you or others want to be ‘right’. Brainstorming is not about who is right, it’s not about who has the best or worst ideas, it’s about getting all of the ideas out there. When the brainstorming session is completed, then the team can review the ideas and start harvesting the most suitable proposals to be able to come to a consensus as a group.

What to do before hosting the session?

Allow people to prepare

People are more creative, and generate better ideas, when they have a head start working on their own. This preparation can be accomplished in a couple of different ways.

• Send out emails with documents to review: Before the session, send out relevant documents to view via email so participants can read them, ahead of time.
• Email the agenda early: You want to make sure people know what to expect from the time that they are dedicating to this process. Therefore, emailing the meeting agenda or giving a breakdown of the meeting goals can be helpful.

These two simple tasks can be good practice whether the grain production is being done in person or virtually.

Set a clear goal

Sometimes, the goals get confusing and people are not sure what they are supposed to achieve at the end of the session. Something like “we need to create the next generation of our current product” is too vague for a brainstorm. People won’t know how to prepare, the discussion will go all over the place, and it is unlikely anything actionable will result. A better approach to a big problem is to start with an organized framework or have a set list of sub-problems to discuss.

Invite the right people

When inviting people to a brainstorming session it’s vital to make sure that they are people who are invested in the success of the session. In other words, don’t invite guests just because they’ve got a big reputation. Invite participants who have a deep interest in the topic or have working experience with matters related to your quest.

Essentially, you want to identify with the people you are inviting and that they are people who can impact the outcome These individuals can be stakeholders, subject matter experts, engineers, or designers to name a few.

You should also aim to keep spaces limited. The reason for this is because when you get too many voices and opinions involved it can create excessive noise. This can cause the team to lose sight of the goals you are trying to accomplish and be counterproductive.

What to do at the beginning of the session?

Choose a reliable facilitator

In a brainstorming session, you will need some form of mediation. This job is usually tasked to a facilitator. The person chosen for this role should have experience in brainstorming, be organized, and most importantly, be unbiased. A good facilitator will ensure that the session runs smoothly, take account of participation and meter the exchanges so that everyone gets a fair chance to shares their ideas.

Introduce everyone

Before getting into any discussions, you should conduct introductions. It is not only just for courtesy but an important part of any brainstorming session, especially in a virtual environment. Everyone should know who they are talking to. If it’s a new group, you may not know each other at all. Just saying “My name is Steve and I’m a product manager,” is not very meaningful and doesn’t give a clear insight into what someone’s purpose is. Everyone needs to know what is the actual contribution of each person to the topic of the session.

One popular method to get the ball rolling is to have icebreakers. If the group members are meeting for the first time or are unfamiliar with each other, icebreakers are great to allow them to get to know each other better. Brainstorming has a degree of vulnerability attached. You are trying to open yourself up to suggest ideas that may be kind of stupid and that’s fine Silly ideas can sometimes lead to incredible breakthroughs, but you have to be willing to be vulnerable with that group of people.

Think about smaller groups

Divide people into smaller groups when it comes to brainstorming highly technical areas. Or when you have to brainstorm areas where there’s an overload of information that makes it difficult to filter through what you need to achieve. Small groups allow members to take a big or complicated idea and break it down into something more concrete and specific. The key is then to bring those groups back together again later on and review what was learned to fine-tune the findings.

What to expect during the session

Choose a proper technique

Even after introductions are completed, if people are new to each other, it’s better to start with an open conversation, typically with a time limit. This allows everyone to set the pace for the meat of the discussion and feel each other out. At the end of the conversation, the facilitator might find one of the below approaches (or a combination of some) better than another depending on the group:

Brainwriting: Allow some time to write your ideas on pieces of paper with a time limit (typically 5 mins) to warrant that your opinions are not influenced by others. Facilitators can then collect the pieces of paper.

Starbursting: As an alternative to writing the suggestions, ask questions instead. Why should we charge for this? Why can’t it be free? Is there a better tool? Is there someone else that can help us? The advantage is to evaluate the topic from different aspects. For example, we might ask why we are doing it in this way. The answer might be because it’s been always like this for years.

Round robin: Give one idea at a time as a method to collect ideas one by one. This creates a more inclusive and supportive environment where everyone gets a chance to be heard.

There is a wide range of other techniques that might be helpful depending on the subject and the involved people.

Write everything down

Use a whiteboard or digital board to capture and display the ideas that are given. List everything as it comes and proceed to trim down the ideas later. If you don’t have access to a large whiteboard, take a photo, before erasing it to add the new ideas.

Never criticize or purposefully remove any ideas!

Everything should be written down. This method allows the output of the session to consist of the most favored ideas or particular themes that came up and need to be highlighted. Additionally, the output should address any highly creative and innovative ideas that stand out, even if they were not voted on to any great extent.

Wrap up the session

After the meeting is complete, there is still a lot to be done. Brainstorming helps you get ideas, but you are then faced with choosing the best approach as well as implementing the most suitable suggestions. To keep things simple, consider the following:

• Assign tasks appropriately — Does the task require a second opinion or require more data?
• Set due dates for follow-up meetings.
• Assign a point of contact if a person is blocked for gathering data, for instance.
• Send an email about the dates, copies of data, or relevant information that is necessary for moving forward.

What should be done after the session?

Schedule a follow-up conversation (if needed)

Some ideas may take more time to understand or be discussed thoroughly. Therefore, it may be necessary to schedule a follow-up “immediately” to make sure that they are managed. If a solution is not finalized and needs further discussion it is important to get it underway as soon as possible to avoid delays and prevent problems that can affect deadlines or delivery dates.

Email the result

After the session has concluded, send an email containing recognition and acknowledgment of the meeting and the result. Make sure that it gets the visibility of upper management to get their ongoing support. All participants should receive copies of the meeting agenda, minutes or notes, the list of ideas documented, and any requests for follow-up or clarification.

You should also thank your group members for their time, expertise, and contribution to the brainstorming. Showing appreciation leads to building better relationships and networks that can be a great asset for future brainstorming sessions!

How to Run a Successful Team Brainstorming Session was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

The simple goal of a code review (CR) is to ensure that the code is in a better state after the review. Through efficient CRs, we want to catch potential issues without hindering the process of deploying the code to production. Studies have shown that peer reviews are generally more effective than testing at finding software defects. In his book, Code Complete, Steve McConnell affirms that software testing as a standalone method has proven to display limited effectiveness:

… software testing alone has limited effectiveness. The average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.

The CR author is the ultimate owner of the change. He/she is also responsible for ensuring that the change is error-free and aligned with the team policies. The author should do the best to send a clean, correct, and well-tested code to the reviewer and should not solely rely upon others to detect issues.

If you do a quick online search, you will find excellent CR best practices like the one by Google. In this post, I’ll provide my take on what to consider for an efficient code review.

Who Should Review the Code?

CR is a learning opportunity for both the author and the reviewers. Consider adding these people as your code reviewers:

• Domain experts — It’s clear that a person with domain knowledge will have more context. They also need less time to look at new revisions compared to a less-experienced reviewer. Thus, saving time as a team.
• New engineers — Reading the code is a great opportunity for new hires to learn the code base and understand what code styles are being followed in the team. It can help them to understand the service underlying logic quickly and can be beneficial when writing their own code or during their on-call shifts.
• Someone better than you! — Try to find people that have more expertise than you and get their opinion on your code. Sometimes, they can recommend a new design logic, a library or design, for instance, that makes your code better to perform and understand.

Note that people will have personal preferences and different people may come up with different non-blocking comments. Therefore, keeping a low number of reviewers on a CR could reduce excessive back-and-forth amongst different people.

What to watch in the CRs?

You should review the code with several key questions in mind to retain focus. For instance, you might evaluate the code to answer the following:

Code Correctness

• Is the code functioning as it should? Are there any ambiguous requirements? Are there unwritten requirements that you need to contemplate? Does it activate a suitable response when things fail?
• Are there any bugs or errors?
• Did side effects occur because of the change?
• Are there sufficient unit/functional rests to cover the change?

Clarity

Simplicity: The code should be easily understood even with a quick scan. Especially at 3 am in the morning, when the on-call gets paged and wants to find the issue quickly! Are you using cascaded calls? Are the names clear? For example, if you are using a Java lambda, think about if it’s even necessary. Lambda often makes the code cleaner and easier to understand.

Arrays.sort(arr, (s1,s2) -> s1.length() — s2.length());

However, it can quickly become a complex and difficult-to-understand code block if too many cascaded logics are introduced.

Stream<Pair> allFactorials = Stream.iterate(
  new Pair(BigInteger.ONE, BigInteger.ONE),
  x -> new Pair(
    x.num.add(BigInteger.ONE),
    x.value.multiply(x.num.add(BigInteger.ONE))));
return allFactorials.filter(
  (x) -> x.num.equals(num)).findAny().get().value;

Style: As part of a CR, you are assessing if the code is consistent with the surrounding ones. In many IDEs, you can set a specific code style (indentation, remove unused imports, documentation, etc.) to be applied automatically on the code. If you are a Java developer, take a look at the Google Java Style Guide for comprehensive best practices documentation.

Brevity: Each function or method should be brief and straightforward in its expected intent and limited to a “page” (a few dozen lines of code) at most. Instead of putting multiple independent changes (e.g. multiple unrelated fixes) into a single CR, consider splitting the change into multiple ones.

Every CR should essentially have a single goal.

Single responsibility makes the code easier to review and much easier to roll back if a specific functionality is problematic. If the CR is serving a big goal, think about breaking it down into individual, self-contained sub-goals.

Documentation: Consider if the code is appropriately documented for someone else to comprehend and maintain. Are the comments easy to understand? Does it add value to the surrounding code? Do the functions have clear intent? Would a few comments outlining a description of expectations help?

Design

In most scenarios, the CR might affect either low-level or high-level design. When reviewing the code, try to answer the following questions:

• Is the design sensible? (with changes or without)
• Do the changes mesh well with the existing design? (e.g. do new responsibilities belong to the changed entity?)
• Will any changes reveal weaknesses in the existing design? (e.g. simple behavior changes that require complex code changes to fix)
• Does the change fully cater to all of the features / issue’s requirements? Is there any uncertainty or doubt with regard to the interpretation of the requirements that could create issues in production?
• Is there adequate room to apply an enhanced design pattern? For example, if a method has a large number of inputs, can a builder pattern for improved clarity and extendibility be applied?

Backward Compatibility

• Is the code backward compatible with pre-existing API?
• Is it backward compatible with the pre-existing configuration?
• Are there backward-incompatible changes that aren’t really required?
• If there are backward-incompatible changes, how can they be managed in terms of package builds, deployment, and communication?

Reuse

• Does the package contain duplicated code?
• Are there any local functionalities that should be in a shared library?
• Can any code be completely removed or replaced with existing libraries to boost efficiency?

Config or Constants

• Does behavior activate random constant values that ought to be configurable?
• Are there magic numeric or staring constants found or repeated in the code?
• Are there default values available for all config settings?
• Is the behavior of the configuration setting properly documented?

Performance

• Does anything indicate that there is premature optimization?
• Are there obvious performance or efficiency problems that are not deemed important to address?
• Does the code take longer to perform even if most of the additional time is spent blocking?

Dependencies

• Are there novel external dependencies being implemented that could potentially introduce a brand new availability or operational risk?
• Is each new library dependency compulsory? Are existing dependencies indispensable? Is it possible to solve the issue in a simpler way?
• Are there other “lighter-weight” dependencies that could be utilized instead?

Failure

• Is the code able to garbage return values from any library code that’s called?
• Will the code handle edge cases?
• Does the code handle just the happy path or does it also handle all the error conditions?
• Is there transparency and a reliable strategy to handle exceptions?

Logging and metrics

The code should have ample logging mechanisms so that in case of an issue, it’s easy to evaluate and troubleshoot the problem quickly. Always ensure that a sufficient amount of information is being logged. However, keep in mind that over-logging, in turn, can trigger security concerns (e.g. confidential information such as customers’ email addresses in logs) or performance issues (a large amount of I/O caused by a significant amount of unnecessary logging).

For the metrics, try to determine if the code is being used with performance metrics. This includes items such as rate of calls, type and latency to name a few. Do metrics exist around all remote calls leaving the process and host? How are you able to pick up on stress/load/deviations?

Security

Try to evaluate if the code violates any data handling policy. Is the current code exposed to any security threat? For example, if the code handles user inputs, is the code secured against SQL Injection?

What information should be included in a CR request aside from the code?

A CR request isn’t only about the code. Essentially, it contains all relevant meta-data and code reviewers’ discussions that can be used as references in the future. I recommend putting data into a CR request that include:

• References (ticket number, wiki doc, design doc, etc.)
• Descriptions of changes: Highlight major touchpoints (again, imagine that something goes wrong at 3 am and somebody wants to see if your change is related).
• Alarm and metrics pending configuration
• How the testing is instrumented
• Any specific considerations such as deployment order, backward compatibility, or dependencies)

How to Efficiently Add Your Comments

A reviewer should be ready to differentiate between blocking and non-blocking issues. Blocking issues would be things that prevent a CR from being shipped. Non-blocking issues specialize in more subjective matters and may well be discussed to achieve consensus, or addressed in follow-up CRs. Note that although in theory a CR with only non-blocking comments can potentially be shipped (since it won’t cause production problems), it doesn’t mean non-blocking comments are to be ignored.

Blocking issues

Most blocking issues are things that affect production and tend to be objective. For example:

• CR violates one or more of the “author guidelines” listed above
• Code bug
• Any potential performance issue
• One-way door decisions
• Missing critical tests in production code
• Having insufficient comments

Non-blocking issues

Non-blocking issues are mostly subjective opinions that require a consensus. Keep in mind that different people have varying styles of executing things. Therefore, there will be several different solutions. Some examples of non-blocking comments are:

• Code enhancement proposals
• Refactoring suggestions
• Code maintainability discussions
• “You can also change this” type of things. Everyone is part of the team. If you want to make a change without waiting for the CR submitter to get back to you, in addition to commenting in people’s CR, you can go ahead and do it yourself!

Comments

To make comments more effective and save back-and-forth time, try to have a clear action item that the author could work on. Some examples are:

• “Have you investigated X?” in addition to “Other options exist”
• “How about renaming to Y?” in addition to “The name needs clarification”
• “Move A to B and make C call D” in addition to “This should be refactored”

If a subject requires a lot of back-and-forth dialogue, rather than having a long thread of comments, do the review in-person and only put the end result in the comments.

How should the author handle the comments?

Receiving non-blocking comments doesn’t mean they can be ignored. An author needs to respect others efforts with feedback:

• Take time to put together a formidable reply to reviewers’ feedback, regardless of blocking or non-blocking, to reach a consensus.
• Always reply to comments that lack clarity or instigate drawn-out discussions as soon as possible (especially before you publish the new revision), to avoid publishing a 3rd revision based on comments from the 1st revision.
• Follow-up offline with a reviewer to address any lack of comprehension in their comments and summarize the resulting outcome in the CR for other reviewers.
• Update the CR title and description of messages when publishing new revisions.
• If you received your required approvals but somebody else commented on the CR without approval, follow up with him/her to determine if the concerns were addressed.

Happy coding!

How to Make Code Reviews More Efficient was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

As an active interviewer, I can say that the complexity of interview questions has increased over the past couple of years. These days there are many preparation resources and candidates are more prepared. Consequently, wrong or right, the expectation of the interviewers has increased. Companies like Facebook/Meta expect you to solve 2 coding questions in less than 45 minutes.

In this article, I gathered the most popular concepts/algorithms that a large number of interview questions are based on. You need to fully understand these concepts to be able to implement the related coding questions in a reasonable amount of time. Obviously, there are many other concepts that you need to be aware of to successfully pass coding interviews but put the ones here on top of your list.

1. Topological Sort

In a Directed Acyclic Graph (DAG), topological sort puts vertices in linear order so that one vertex comes before another one. Many coding problems can be presented through a DAG. If you identify dependencies between items that require operations in a specific order, topological sort immediately should come to mind. A very popular problem is course schedule 2 in which courses are prerequisites of another and you need to find a correct order to complete all courses. When working on topological sort problems remember:

• Topological sort is not possible if the graph has a cycle. For instance, if you need to complete course A to take B, B to take C, and C to take A, there is no way that you can take any of the courses. Confirming the possibility of cyclic dependency is one of the first questions to ask the interviewer and most of the time you have to plan for cycles in the graph.
• A popular mistake among candidates is the assumption that the graph is connected. This can lead to mistakes in the code. For example, in the course schedule, some courses might have no dependency and are not present in the dependency list respectively.

A simple topological sort implementation involves two maps, one to store a list of all items (value) dependent on each item (key) and the second to count the number (value) of dependencies for each item (key). A sample implementation can be found here.

Popular related questions: Course schedule 2, Order of packages to compile, Alien dictionary

2. Binary Search

At a first glance, the binary search looks very simple but you are amazed by a significant number of binary search interview questions specially in the Google interviews. The tricky part is to identify a problem as a binary search one. In the simplest form, you are given a sorted array to find the existence of a specific item. However, in a real interview, you need to first convert the problem to an array of sorted items to be able to apply the binary search. If there are multiple possible numeric answers in a specific range and you want to find the most optimal solution, the naive approach is to examine every single possibility and choose the best one. In this scenario, think about if binary search can be beneficial. An example is the number of days after which tank will become empty. At first, you need to find the minimum and maximum possible values and update the upper and lower bounds in your search till you reach a final optimal answer (or find out that there is no answer).

Popular related questions: Relay Stations

3. Working with Intervals

There is a set of problems such as Meeting Rooms involving time intervals. In these types of questions, you need to find out at what periods of time, there are interval conflicts. Usually, you should have the intervals sorted first through one of the below ways to find the points in which the conflicts take place:

• Regular sort techniques (e.g. Arrays.sort() in Java).
• Min/Max heap.
• Self-balancing tree data structure like TreeMap in Java.

popular related questions: Meeting Rooms 2 , Merge Intervals, Car Pooling, Minimum Number of Arrows to Burst Balloons, My Calendar 1 & 2 & 3.

4. Heaps (Priority Queues)

Heap is a simple data structure but it can solve interesting problems in the real world as well as coding interviews. Two main heap structures are min heap (min element at the root) and max heap (max element at the root). Most important things to remember about heaps:

• Insertion in a binary heap is O(log n) but finding an element is still O(n) since you need to examine all the items. Keep in mind that heaps don’t necessarily give an advantage when you are trying to search for an element.
• The elements are not in order in a heap. You only know that the top element is the min element in min-heap or max element in max-heap. In order to find the next element, you need to delete root (O(log n)) first.

Heaps are specifically good if you need to know the top K elements specially in a stream of data without a need to know their specific order. A very popular example is to find the median from a data stream in which you need to keep the first [almost] half of data in a max-heap and the second half in a min-heap. Here, you actually don’t need to know the order of elements in the first or second half but you only need to know the max element of the first half and min element of the second half to calculate the median.

Related Questions: Top K elements, Kth smallest element in a sorted matrix

5. Sliding window

I should confess that this is my least favorite must-know concept since it involves extra care when working with pointers and it’s easy to miss edge cases. On the other hand, this technique efficiently reduces time complexity for complex problems.

A general pattern like what we see in the minimum window substring requires two pointers. The first one greedily expands the space till it meets the problem requirements (e.g. in min-window-substring to find a substring containing all the matching characters) and the second one to reduce the space as much as possible to ensure that an optimized solution is reached.

Related Questions: Longest Substring Without Repeating Characters, Longest Substring with At Most K Distinct Characters, Permutation in String

6. Graph Traversals (DFS/BFS)

I’m really surprised that many candidates still struggle with Depth-first-search (DFS) and Breadth-first-search(BFS) implementations. If you are going to rock any coding interview, you must know graph traversal algorithms by heart and be able to distinguish their differences. In many graph traversal problems, it doesn’t make a huge difference to use either DFS or BFS as they have the same time/space complexity. However, keep the below in mind:

• If you need information related to a level like the max item in each row or printing a tree level by level, BFS is your best option. On the other hand, if you need information related to branches/paths like maximum path sum try to solve with DFS.
• Shortest Paths: If the problem involves the shortest distance to an origin, BFS is the best option because it examines all the neighbors level by level. If you reach an element in a BFS, it has the shortest distance to the origin.
• Puzzles: If the problem involves exhausting all the solutions like in Word Search, using DFS or backtracking is better since it goes deep to find every possible option, and sometimes like in Word Search the first find is enough. Backtracking and DFS are closely tied together and you can find that there are many different opinions about their differences. But here for simplicity let’s consider backtracking a technique that uses DFS on a reduced problem space.
• Memory Usage: Although both algorithms have the same space complexity but they have different memory usage pattern. If the graph/tree is very wide, you need to consume a significant amount of memory in BFS. On the other hand, if the graph/tree is too deep, in DFS you need to store a large number of items in the stack memory because of recursive calls. Also, since the DFS uses the stack for recursive calls, it’s a high chance that you get a StackOverflow exception if the stack capacity is small.
• Graph vs. Tree: A Tree is a simplified version of a graph. Trees are connected graphs in which a node always has a single parent (except root) and there is no cycle. Both time/space complexity of BFS/DFS traversals for trees are O(n) considering n as the number of nodes. In graphs, however, the time complexity of traversal is O(V+E) where V is the number of nodes and E is the number of edges. In the worth case scenario where a graph is complete (E=V*(V-1)/2) we need to visit all nodes and edges. If we consider n as the number of nodes, the worst-case time complexity becomes O(n²). Further, to avoid getting stuck in a cycle, in the BFS/DFS traversal, we need to mark elements as visited which is not needed in a tree traversal.

Popular related questions: A lot! In most of the graph problems :-)

Good luck and happy holidays!

6 Concepts You Must Know to Pass Coding Interviews was originally published in My Interview Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.

Technical Debt can be defined as a gap between making a change [almost] perfectly (flawless architecture design, using good programming practices and standards, updating the documentation, testing the changes thoroughly, etc.) and making a change work as quickly as possible with a few resources available.

Remember that technical debt is a metaphor and not a scientific concept. Analogous to “monetary debt”, technical debt is not necessarily a bad thing and sometimes it’s required to move a project forward, however it MUST be managed properly.

Think about an example of buying a house. If you want to wait to have enough cash to buy a property, you need to wait for a long time. Given the current resources, you can get a mortgage and buy a house now and pay it off over the time. You end up paying more in the end but there might be advantages like if the house price goes up.

Respectively In a software environment, there is value in releasing a feature at a particular time. If we are aware of a technical debt and discuss its pros/cons, it might be good to release the software sooner in order to get some advantages. However, you should manage the technical debt and do not allow it to slip. In the example of buying a house, you will get bankrupt if you decide to buy a car and then a boat while you haven’t calculated the economic risks. For software development, you cannot ignore the debt because the next cycle you might not be able to release another feature efficiently. But how to ensure that we properly manage our technical debts?

1. Identify your debt

There is no specific tool to run on a project to identify its underlying technical debts, however, some tools like smart IDEs can flag some potential debts in the project code. On the other hand, “outdated wiki” is not something that can be caught by automated tools. Here are some samples of technical debt indicators that you can identify in your daily communications:

• Don’t worry about the documentation at the moment!
• It’s ok for now, we will refactor it later.
• //TODO: this should be fixed before release.
• I know if I touch that code everything will break.
• It’s good enough, we will finish the testing in the next release.

You might find similar statements like above in your current role that indicate a possible technical debt (please add your examples to the comment section).

2. Estimate the costs and risks

For every technical debt, there is a trade-off between immediate benefit and potential future cost. Carefully assess the potential risks of the debt before making the final decision. “Not updating a wiki” might not seem a significant risk at a first glance but imagine a scenario in which you add a critical feature but skip spending a couple of hours on updating the playbook wiki with instructions on how to deal with production issues. In case of a failure, the on-call person cannot quickly mitigate the issue or even worse might add up more problems during his/her shift.

3. Communicate and make the decision

Once the technical debt is identified and the associated cost/risk is assessed, the team need to decide if they really want to add that debt to their system. More importantly, they need to decide how to keep track of the debt and what steps to take in order to pay it off.

4. Keep track of technical debts

Regardless of how you plan to log your technical debts, try to document the below information:

Description: What, where, why (e.g. I didn’t write the wiki because I wanted to spend time on the release and test cases.)

Principal: Cost of doing the work (how much time you saved by not doing that, updating the wiki maybe it’s an 8 hr job)

Interest: What happens if the work doesn’t get done and the amount of extra work if this causes the problem later. Also, document the probability that this will cause problems later.

5. Plan for paying off your debt

The feature is released successfully, you well documented the debt, and everybody looks happy. Great! Now, how do you plan to pay it off? It should not remain as a low-priority item in your backlog. As the debt owner, you need to actively keep track of the action items to ensure that the debt is addressed in a timely manner.

Conclusion

Technical debt is not necessarily a bad thing and if properly added to the system can be beneficial to the business and the customers. The challenge however is to efficiently assess the pros and cons and more importantly to manage and keep track of it. Adding debts on top of each other without a concrete resolution plan increases the cost and risk to the business over the time.

How to Properly Deal with “Technical Debts” was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.