DEV Community: mosbat

Diversity and Inclusion Are Officially Dead in Tech

mosbat — Wed, 04 Mar 2026 04:22:47 +0000

According to a study by Edward J.W. Park, published in 1999 in Qualitative Sociology, the tech industry have always had a problem with racism where white candidates always received more favorable treatment.

If you are a person of color or identify as non-white, you will learn in this article about the sad trajectory that tech is going and potential solutions. If you felt imposter syndrome by countless rejections, this article might help you feel better. Please note that while rejections due to discrimination are real, it's not always the case and there could be many more factors that come into play such as market saturation, skills gap or simply vacancies being canceled or frozen.

If you identify as white and this topic resonates with you, you'll learn how to hold your peers accountable for discrimination and recognize stereotypes and biases. I will not shy away from using term "White" because I have strong belief that white privilege does exist and have seen it throughout the years globally.

Few years ago, there was a serious attempt for the first time ever by corporations to be more diverse and inclusive by implementing DEI programs. while these programs were far from perfect, they enabled more people of color to get a fair chance and to grow.

Last year, unfortunately, many corporations specially in the US rolled back all their DEI programs citing financial reasons without offering any meaningful alternatives.

There is a strong narrative among the majority in Western nations that people of color had been given opportunities not based on merits but based on quotas. According to study, this narrative doesn't hold merit and instead appeals to confirmation bias.

If you're a minority or person of color, and you suddenly notice that organizations have become toxic or you're being treated unfairly, you are not imagining it. Between mass layoffs, market panic and also reversal of DEI programs, what you experience is how things used to be before DEI towards minorities and people of color including women who have always struggled to get fair opportunities in tech.

The problem becomes even more pronounced the more senior you become because unless you fit their stereotype of the low skilled labor, you'll face huge resistance and lots of rejections specially in organizations where leadership have severe lack of diversity.

If you go to LinkedIn and browse through the people in leadership positions in most tech companies specially in Western countries, you'll rarely find minorities or people of color in leadership positions. I do not have unfortunately the data but based on general trends and my own observations, I concluded this as the reality.

If you are a minority or person of color, you'll always be held to much higher standards for the same role that a white applicant got in just 1 hour interview with low effort.

There is nothing wrong with you, the problem has more to do with the hiring managers and recruiters who have untreated biases; you may ask, why would they bother calling you if they perceive you as low skilled?

If you look at the call back rates, it's actually much lower compared to white applicants in the market. Those who called you, did so because they want to seem fair but without disclosing the fact that they're exercising a double standard (which is illegal in most states). This helps them reject your job application without feeling guilty. At the same time, they do this sometimes to protect themselves legally. The whole interview process for you is about building a case to reject your job application.

For me for instance, when I used to get a rejection, I used to ask for a feedback and many times, the feedback seemed to be either untrue or made up. There were genuine cases where the hiring manager had very high standards for the role but most of the feedback I received was subjective and projecting certain stereotypes that are not based on objective factors.

**
What's The Solution?

Honestly speaking, unless we see DEI coming back with more energy and more effort, I'd recommend that you seek self employment and be extra cautious and selective about companies you'd like to work with. Ideally, via networking and making connections you might meet a hiring manager or client who is like minded or with whom you have positive rapport or relationship with.

You have a better chance landing projects as a freelancer than finding an employer who will give you fair treatment without DEI.

**
The Consequences Are Severe for Western Tech

The tech industry specially in Western countries still have a long way to go to address all of those challenges to create a more fair and equitable workplace environment that is blind to skin color, nationality or biases. Western companies are expected to struggle in the long-term if those issues remain unresolved or if policy makers won't create policies that are enforced and hold people accountable for not following them or abusing them.

According to Chicago University study, talents mis-allocation have led to a cost of 16$ trillion dollars and roughly 6 million jobs loss over 20 years. Another study in 2024, concluded that homogeneous teams are 66% less likely to outperform and persistent bias exacerbates skill gap that is costing the UK economy GBP 63 billion per year; and this is even more pronounced in AI/cybersecurity fields.

Racism and discrimination not only hurts minorities and people of color but have a long-lasting negative consequences on the entire economy if left unaddressed.

Will policy makers and corporations recognize the threat of bias and create meaningful enforceable frameworks or will talents find opportunities elsewhere?

What are your thoughts?

Why Software Developers/Engineers Don’t Matter Anymore

mosbat — Sun, 28 Sep 2025 13:44:34 +0000

Many Devs today share the sentiment that it doesn't matter anymore how well you write code or how well you can iterate a binary tree. This has become specially true with all the AI autocomplete tools made by AI developers.

It seems as if AI developers put all their strength on replacing us instead of solving real world problems. After all, how else could they market or sell their products to the greedy CEOs and investment bankers.

I spent a good several months doing research on the topic and figuring out how much impact the autocomplete tools have effectively made many roles redundant.

Do not buy the lie that those tools were made to help us be more efficient. It is all about paying less wages and hiring less people since machines and robots don't complain and can work faster than us.

At the same time, there is a clear narrative being pushed indirectly by AI Developers that AGI is coming soon and that we humans are no longer needed. All of this to boost the stock prices but without real substance or value.

While we cannot underestimate the impact of the autocomplete tools made by AI Developers, we need to understand what AI could and cannot do actually.

AI's Fatal Flaw Scientifically

What we call today AI, is nothing more than pattern recognition combined with math aimed at predicting or giving the likelihood of an input matching a certain category which depends on LLM (Large Language Model).

Understanding that AI is about statistical models and math, helps you understand that AI will never be able to deal with unique or new problems (which are almost infinite).

No matter how much money AI Developers will throw to market their Sci-fi themed autocomplete, it is not going to change science.

If your Self Driving car saw a human dressed up on Halloween, is it going to understand that this is a human if it wasn't explicitly trained for this specific scenario?

You begin to understand that AI is only good at dealing with problems involving pattern recognition given specific data or highly repetitive tasks such chat bots for common customer service problems. Even with this, the implementing organization still needs to train AI to handle their specific problem domains which also costs money.

Still, Autocomplete Tools Wrecked Software Development

Several factors have impacted Devs' lives very negatively as a result of the tools and the way how capitalism works.

The IT labor market was based on a pre-AI market where you needed lots of coders to write the software pieces and put them together or integrate them with other tools. This required a huge number of Developers who were good at writing sound clean code.

The post-AI market and supply/demand macroeconomics now made it unnecessary to hire as many Developers as in the past.

It is very logical that corporations will seek efficiency. If you hire few Developers who know how to use AI tools to generate all the boilerplate code, why do you need to hire coders if just 1 or 2 Devs will suffice?

The real problem arised from corporations silently adopting AI autocomplete tools without informing in advance the public of such changes. Otherwise, the number of Computer Science graduates would have been way less as people will begin to seek other fields that are less saturated.

The current dynamics hurt both Senior and Junior Devs permanently and the next decade will be full of pain for a lot of us as we try to adapt to the new reality and re-skilling to seek roles that have less impact by AI.

Why Not Focus On System Design and Architecture?

If you are thinking this way (which companies now pressuring us to on job interviews), you are not wrong. However, you are still missing the point.

How many software architects do you actually need? Yes, you don't need 200 Devs who are good at SD.

Even Software Architects Won't Survive The Purge

As existing wanted to be coders are now adapting suddenly to the increased focus on architecture and design, the architect role is under real threat as all the SWE are now deep learning SD and architecture.

This means, that those who studied architecture and got paid a decent wage despite the demand that was already low, they are now going to be buried even deeper under the rubble.

Mass Layoffs Aftermath

Another significant factor that will ruin SWE career, is that the market demand on SWE was highly influenced by big tech players who were already highly picky and selective in their recruitment processes.

As 10s of thousands of highly qualified SWEs are laid off and struggling to find jobs, the market has become even more competitive than before.

So even for companies that are still hiring Devs, it is normal to expect them now to post all roles as "Senior ..." since they could afford now to be more picky and selective.

So when you are applying as a Frontend Dev to your local coffee shop, you are competing with an ex-big tech Devs who are highly qualified, got exposed to big technologies (even if they are less likely going to use it in startups).

SWE Job Interviews Torture Candidates Without Real Purpose

Your local coffee shop startup will have Devs who are still stuck on the big tech hiring practices; they will ask you questions even if you have tons of experience and tons of certifications.

The practice of whiteboard testing should truly be abolished for Senior Devs specially if you have certifications for the skills that they care about. Unfortunately, the industry is still stuck on over scrutinizing candidates and dwelling on their cultural fit just to write a bunch of if statements and for loops.

Today, expect this to get even worse than before because whoever is now in hiring position, can afford to be selective, picky, test and re-test and project their ego with full force regardless of your level of skill.

In the past, it was possible for Senior Devs to push back against assessments that come out as disrespectful specially for highly experienced and qualified candidates. Now it's impossible because we have a broken market where Devs are still stuck on big tech hiring practices for local coffee shop startup and a huge influx of candidates available (laid off by big tech).

“AI Hype” Is Not a Hype

A lot of people are saying that it's a hype including Devs. This is nothing more than wishful thinking. It is naive to ignore what the autocomplete AI tools have achieved so far.

AI IS NOT A HYPE.

If you want to survive, you need to look for skills that cannot be automated.

A balanced approach is to instead focus on how to retrain yourself to focus on roles that are in high demand and cannot be automated.

Have AI Developers exaggerated? Absolutely, this had been confirmed by recent research. However, this doesn't mean we can ignore what these autocomplete tools have been able to achieve.

The CEOs and investment bankers don't care about our opinions. They care about the bottom line and how much less wages to be spent on human labor.

How Future Looks Like and Is There Hope?

The future, is something you define for yourself. If you are still looking for the cozy and comfortable job, Software Development is no longer that job. You are now no different from account executives in a company just doing paperwork and getting paid to survive.

You are now easy to replace with cheap and more skilled labor.

Do not get distracted by the "New" requirements of SWE. It's now a race to the bottom as 100s of thousands of Devs are going down that rabbit hole.

Creativity and problem solving are vague terms used loosely by companies' PR to make themselves look nice despite laying off 1000s of people who had families to feed without even a chance to re-skill or change roles.

Focus on roles in the industry where automation doesn't work or have everyday unique problems that no AI can learn or recognize.

Which ones? I'm not going to tell you any specific role because that's the problem today with media. You need to do your research and figure it out on your own.

YOU MUST READ THIS! Call to Action! Against Weaponisation of AI

mosbat — Fri, 21 Feb 2025 13:06:58 +0000

We have witnessed recently many damning reports by several investigative journalists several big tech companies including Amazon, Google having military contracts where their AI models are being used by certain state militaries around the globe.

The Threat

This is a very big and dangerous threat to humanity on a global scale and it is our duty as Devs to say No to weaponisation of AI.

We as Devs must work together to stop this madness before it goes out of hand. This is a huge threat to all humanity and must be stopped.

To understand the solution, we must understand the problem. Big tech companies leverage data they mined over decades on the internet either directly or indirectly to build their LLM models. Then, what they do is that they try to customize it in certain contexts to make it usable by military. However, this task does require probably a bit of effort on their end depending on the data collected. While their data scientists can filter out the ethical and moral constraint that might prevent AI from accepting prompts that are harmful or violent, they still need a lot of processing power to make the LLM suitable for military use.

The solution:

One way, how we as Devs can make it difficult for them to use LLMs for military use is to try to feed the internet as much as possible data is anti-war by publishing a massive number of texts all over the internet against war and against prompts that can be used for military.

This will make it near impossible with the current technology to use the LLMs for war.

Think of the LLM as a growing organism, we can manipulate it to prevent it from accepting or understanding certain content or even teach it to be against such content.

This might require a lot of help and resources to override the internet and make it difficult for companies to use LLMs for military.

> This is a call to action. If you are not scared enough, then you're probably sleeping. This is not about conflicts or wars, this is about humanity. We can't allow AI to be used for war.

Why Test Driven Development

mosbat — Mon, 30 Dec 2024 21:18:09 +0000

Many Devs I worked with in the past, do not like writing the unit tests in advance. They would rather finish writing the function quickly and worry about testing later.

I only learned the hard way when working on my hobby projects, why TDD is a game changer.

Writing unit tests or integration tests, not only help you spot bugs early on; but it also enables you to strictly follow the acceptance criteria for the features or assert the expected behavior in case you're fixing a bug.

More often than not, the requirements aren't fully clear at the beginning of the project or the beginning phases. As you go further during the development process, changes happen very quickly; but you don't want your functions to behave as they please, do you?

When you write the unit tests, it helps you understand what changes need to be made without having to rewrite everything from scratch. This doesn't mean that the unit tests will have edge cases that aren't well covered. You'd still have to figure out what are the edge cases and add unit tests for them once you've confirmed the expected behavior of your application for those specific edge cases.

Just to inspire you, I got a simple scenario from ChatGPT on how notorious it is to catch bugs without unit tests:

Imagine we have the following function:

public class ShoppingCart {
    public double calculateTotalPrice(double[] prices, double discountThreshold, double discount) {
        double total = 0.0;

        // Sum up the prices
        for (double price : prices) {
            total += price;
        }

        // Apply discount if total is above threshold
        if (total > discountThreshold) {
            total -= total * discount;
        }

        return total;
    }
}

Now imagine we were asked to calculate the discount based on the rounded total instead of total we had in the original function:


public class ShoppingCart {
    public double calculateTotalPrice(double[] prices, double discountThreshold, double discount) {
        double total = 0.0;

        // Sum up the prices
        for (double price : prices) {
            total += price;
        }

        // Apply discount based on rounded total
        if (total > discountThreshold) {
            total = Math.round(total * 100.0) / 100.0;  // Round to 2 decimal places before applying discount
            total -= total * discount;
        }

        return total;
    }
}

Even though the rounding change might have seemed small, it introduces several edge cases that we didn't account for, such as the situation when we are rounding values that won't hit 100.

From the initial phase, everything seems fine; but if you run this in production, you'll begin getting complains pretty soon!

Those errors or problems can be caught early on if you had some unit tests:

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class ShoppingCartTest {

    @Test
    public void testCalculateTotalPriceWithDiscount() {
        ShoppingCart cart = new ShoppingCart();

        // Test case where the discount should be applied
        double[] prices = {50.0, 60.0};
        double discountThreshold = 100.0;
        double discount = 0.1;  // 10% discount

        double expected = (50.0 + 60.0) - (50.0 + 60.0) * 0.1;
        double actual = cart.calculateTotalPrice(prices, discountThreshold, discount);

        assertEquals(expected, actual, 0.01);  // Tolerance for floating-point comparisons
    }

    @Test
    public void testCalculateTotalPriceNoDiscount() {
        ShoppingCart cart = new ShoppingCart();

        // Test case where the discount should NOT be applied
        double[] prices = {30.0, 40.0};
        double discountThreshold = 100.0;
        double discount = 0.1;

        double expected = 30.0 + 40.0;  // No discount applied
        double actual = cart.calculateTotalPrice(prices, discountThreshold, discount);

        assertEquals(expected, actual, 0.01);  // Tolerance for floating-point comparisons
    }
}

As your application keeps growing, you'll run into more edge cases depending on the complexity of the application and components' dependencies on each other.

To guarantee that your application is running as intended, you'd have to always work hard on writing as many unit tests as possible to catch errors or problems early on.

Worst case scenario, a unit test fails after making a change and you'd have to go back to your product owner to further discuss what needs to be done. Otherwise, it's still better than receiving complains for wrong or missing discounts from your customer!

Top 5 Things Devs Overlook When Joining a New Company/Team

mosbat — Fri, 27 Dec 2024 18:10:28 +0000

You maybe got excited for getting a job offer during the terrible job market. However, you might want to consider key things before considering quitting your current job as the new offer might not be as good as it seems; below are top 5 things that the hiring managers and recruiters won't talk about.

Disclaimer:
None of the issues I'm mentioning below are related to any people I'm working with at the current moment.

1- "Diversity,Equality and Inclusion", but we don't actually believe in it

You may wonder why I put this at the top since we have been hearing companies telling us that they are DEI for many years.

Unfortunately, 15 years ago, when I used to search for jobs, companies used similar terms such as "EOE" which meant Equal Opportunity Employer. Unfortunately, what hasn't changed is the fact that companies still use those terms as marketing labels without actually implementing them or enforcing them in their hiring process and employees' conduct at job.

A friend of mine, joined a company who claimed to be DEI, but he got not only discriminated against, bullied and harassed; but on top of that, they forced him to quit when he raised the issue to HR (HR are not your friends).

So if you're a minority, you would want to assess to what extent the organization you're joining is actually minorities' friendly.

You can ask the following questions during the job the interview, if the hiring manager dodges the questions, changes the topic or doesn't address them well, it's a red flag:

Can you give me examples of how your company implements diversity, equality and inclusion policies?
Does your policy explicitly state that racism, xenophobia, homophobia, etc... are forbidden and punishable?
Can you give me an example of how your company handles harassment, bullying or discriminatory behavior?
How many of the senior managers are of different nationalities or have diverse backgrounds?
How many of the team members are of diverse backgrounds?

Even if you're not a minority, you should still take the above questions seriously because if the above questions aren't answered properly, it means that the workplace will be toxic even to you.

2- "We treat each other like family", but we will fire you eventually

This is one of the most difficult topics that the employers and their HR are not willing to talk about or tell you.

Many companies have a very high turnover rate because they fire employees for the smallest reasons. This is specially true if those in charge have authoritarian management style or moody unorganized managers. Unorganized management is a different topic from a bias manager or manager who doesn't like you for personal reasons.

The reason that a company with a high turnover rate is undesirable to most people, is because of several factors:

Unrealistic expectations.
They want to look good to their managers by firing employees as cost reduction.
Focus on finding better candidates for the same salary instead of focusing on growing their existing employees.
Company is financially unstable.
Senior management constantly changing or getting replaced.

There are many other factors that could lead to a high turnover rate but obviously, what's the point of signing a contract and spending another year looking for a new job?!

One extremely important issue you need to ask about, is whether you're replacing someone because if this is the case, it means that they are going to fire an existing employee or the job wasn't that interesting so the previous Dev/Employee left.

3- "We are looking for an autonomous Engineer", but we suffer from OCD and trust issues

This one is very common where they claim that they're looking for an autonomous Engineer but in reality, there will be someone watching you all the time and questioning why a task took 1 day more than usual.

It's very hard unfortunately to determine whether or not there is a micromanagement culture before joining the company because obviously they don't like to talk about it; this might be related also to unrealistic expectations from employer side.

If your manager is redoing your code shortly after you without a good reason, it indicates many issues including but not limited to micro-management and mistrust. This could happen specially if the manager wasn't involved in the hiring process.

You truly don't want to work with a team or company that doesn't trust their own employees and not willing to tolerate letting their employees make mistakes; because a good manager/company doesn't care about the mistake but rather cares more about how you try to handle the mistake responsibly.

You can try to ask the manager for example "You said that you're looking for someone who could work independently, can you give me examples of how you facilitate this?", if they give you vague or unclear answers, it means that they have a micro-management culture.

4- "We follow Scrum principles", but our favorite employee can do 20 story points every sprint and everyone else is doing boring uninteresting tasks.

This unfortunately a prevalent issue where they don't truly implement scrum framework; so you end up in a situation where few favorite people are given an excessive amount of work and claiming all the awards and others are under loaded or given boring uninteresting tasks.

This one might be easier to figure out, you can ask them for example:
"Can you give me an example of how you distribute the work/tasks?". While Scrum is not strict on how it's implemented, use your own judgement to determine whether or not they are really distributing the tasks fairly.

5- "We have work-life balance", but you have to get up at 7 AM to the factory b***!

If you worked with big tech, this may have never been an issue since truly, big tech companies have sorted out this question long-time ago by addressing the difference between an intellectual creative job and assembly lines in a factory role.

Unfortunately, lots of companies don't truly think this way. If the managers are boomers, there is a high chance that they are still wearing their factory boots to write their C based application.

You need to ask about this early on. A good company will have a clear on-call scheme that is well defined as certain hours during which you need to be available instead of being asked to be on your desk 9-5.

Good companies don't care whether you're on your desk but care about you coming to meetings, finishing your tasks during the sprint and communicating any blockers clearly and promptly.

If the company has a culture where everyone is expected to be behind their desk 9-5, it indicates again that they have an authoritarian work style and potentially office politics.

Unfortunately, many companies still don't try to fix all of those issues or address them properly. Most people who are affected by the above issues are also people of minority since even if hired, are still treated with double standards depending on the company or team you're working with.

You may ask before the interview for a copy of the company employee's handbook which should address all of the above issues. If the company doesn't have an employee's handbook, it's a big red flag.

You need to be very careful before signing a contract and perform your due diligence. Ask all of the questions; if they become dodgy or don't like it that you're asking those questions, it's also a red flag.

By the end of the day, your mental health and well being is the most important thing that you should never ignore.

While even good companies may have some problems above, the degree to which they have it will differ. Some will be severe and others will be mild. What really matters, is if you're feeling satisfied and fulfilled.

If you have other points or you'd like to mention similar experiences, please comment!

"Devs do nothing all day"

mosbat — Wed, 25 Dec 2024 07:41:16 +0000

Jealousy or Pure Ignorance?

Have you heard before any comment or remark from non-Engineers implying that we just sit behind computers, having fun coding and do nothing?

If the answer is yes, you aren't alone. There has been recently a rhetoric among non-engineering communities accusing us of being a burden to society accompanied by the overall societal frustration with the negative side effects brought by big tech such as the negative impact of Instagram on mental health and the dating dynamics since dating apps made dating harder for the average person.

Unfortunately, as a person who has both tech and non-tech education background, I had to face the reality that such people exist.

I can't tell if this is due to jealousy or pure ignorance; but for sure, it amazes me.

Each Dev goes through real struggle to land a job and has to go through a broken recruitment process, gets tons of rejections and unrealistic expectations. We didn't yet mention the mental health toll on the Developer themselves.

Devs need to understand a very large number of subjects such as different stack technologies, data structures,algorithms, data storage, version control and non-tech aspects such as having proper communication skills and understands Agile. We didn't talk yet about cybersecurity and Dev-Ops.

Some people have no idea what is a binary tree and have no idea how their computers and smartphones work, yet they are critical of us Devs at a time when a grocery store is requiring Google level Devs to write a simple html website.

The difference between a marketing job and a Dev job is that you can do marketing even if you aren't really that much interested or passionate about it; but to work in tech as a Dev, it requires absolute dedication and pure passion or love for what you do.

Writing code, is like writing a book, it's an art that requires significant mental cognitive thinking and translating real world problems into a machine code is another level.

I personally do not react defensively towards such comments/remarks since I understand where they are coming from. I try to not alienate anyone and to be as much inclusive as possible. Sometimes I do have the tendency to become defensive, instead I'd encourage them to dive deeper into the topic. Sometimes, they will change their minds and say something like "No no, I'll leave coding to you" but then, it amazes me when people criticize us Devs if they aren't themselves willing to do what we do.

What are your thoughts. Have really been in such a situation before?

Open-Source for All

mosbat — Mon, 16 Dec 2024 17:20:25 +0000

Have you been treated unfairly when contributing to Open-Source?
Have your PRs been rejected/closed arbitrarily without good reasons?
Have you felt that your ideas are being constantly dismissed?
Have you followed fully contributors' lengthy guidelines but your PR still got rejected for silly reasons?

If you answered yes to any of the above, then it's time to join a new movement.

open-source-for-all, will be the new hashtag for repositories that promote inclusion and diversity.

I'll be forking every repository where it's project owners engage in discriminatory or unjust behavior and tagging it with #open-source-for-all. However, this won't be me only; you can join my army by forking those repositories and adding the hashtag.

Later, I'll be creating a site where each repository will have a score in terms of inclusion and diversity to help people assess whether or not they'd like to be part of those repositories!

Optional Steps:

Add a reporting mechanism of unfair behavior or give guidelines on how to post such issues as an issue with proper tags.
Provide an email address where contributors can reach out for help or explanations.

Let's liberate tech together!

Worst Interview Question Ever to Ask a Candidate "Show us a project you are proud of"

mosbat — Wed, 11 Dec 2024 05:56:56 +0000

I had been stunned a couple of times when employers asked me to show them a project that I'm proud of for a lot of reasons.

Such a question is wrong on so many levels. The question implies a lot of hidden messages that can be interpreted even as passive aggressive behavior rather than giving the developer a chance to project confidence.

Below are the reasons why you should never ask candidates such a question:

1- Not Every Developer has a Demo Project Sitting on Github

I'm one of those very few people who got into Development without having my own personal repository. It all happened when I was given the opportunity to work on a project that required a bit of coding skills. I was already accustomed to the idea of coding applications. However, as a fast learner, this came to me by surprise that I'm capable of coding and creating applications even when I had limited knowledge in the past.

Expecting a Developer to have a project ready to show is made on the assumption that every Developer started with an online Github or Bitbucket repo which is very narrow or shallow way of thinking about careers and how people enter into an industry.

Despite the fact that I worked on many projects, in the past, I couldn't show anything or any project due to simply NDA and companies' policies that prohibit sharing proprietary software or property.

Even in the case of Open-Source projects, there isn't always an opportunity to contribute to those projects in a meaningful way due to a lot of factors or reasons outside the candidate's control such as the project maintainers' and their strict guidelines.

2- No One Size Fits All

Today, it's pretty wild to see a project that utilizes all aspects of software development. While you can try to create your own project and try to show case CI/CD skills, you'll never be able to showcase everything sometimes specially at the level or scale of an enterprise software where you have 100s of Developers working on a solution in a company versus you alone trying to put in the same amount of effort for only the sole purpose of showcasing your skill.

Imagine that you're applying for a position for a Back-end Development but the project that you put too many hours and sweat to work on during your short weekend, is a front-end project with limited back-end development. It can also be the other way around.I know that many of you will argue that the whole point is to tell what skill level in general the Dev has but it's still considered a bit narrow-minded to try to sum a Dev's overall profile or skills based on a weekend project that they made solo.

3- Passive Aggressive Message

The question also implies that you view most Devs with a negative assumption that the majority of Devs aren't really that skilled/strong; on top of that, you're telling the candidate that you want "Top" talent depending on what does the top talent means to you.

An assertive and well aware Dev would view your question as projection rather than a question.

The question projects a negative attitude where you think that you're above and beyond all other Devs around you which raises the question about your relationship with your teammates or colleagues.

While it's not necessary to always agree on everything with your teammate, your question might imply that you have a hard time adapting to other people's views or solutions.

4- Job Interviews are Subjective

Due to the overall nature of the tech industry, there are so many metrics that makes any questions you formulated only draw a subjective image/picture of a candidate's real potential. Therefore, it's still considered a very reductive/arbitrary approach to asses someone's potential based on a single project or piece of code they wrote on their weekend.

5- The Job Interview Should Never Harm Candidate Emotional Well Being

The most important reason why you should never ask candidates such a question, is that your interview should not have any side effects that could impact the candidate's well-being regardless of the result of the job interview.

If the candidate is rejected because of #4, you're telling the candidate that their best project or the project they are proud of, is not good enough and that they are not worthy of being Devs or doing Software Engineering.

Let's admit it, there will be a lot of reasons of why job candidates will get rejected most of which are either subjective or external factors (e.g. position canceled or no longer available due to restructuring).

When you send the candidate a rejection email with generic responses which is the case most of the time, you're telling the candidate that their best is not good enough.

6- The Best Project Doesn't Exist

In real-life, most projects will have bugs, performance problems, technical debts, lack of unit tests, etc...

Most Devs aren't actually writing a project from scratch; most Devs, even senior ones, are merely making small adjustments to existing software and each task in an organized manner, most likely needs a business justification and prioritization by the project managers.

If there was a situation where a Dev single handily created a whole CRM from scratch and made it so perfect, you'd fail to assess their ability to collaborate with others in a productive seamless manner. Unless you're applying for the position of an Architect or Project Manager who will manage the whole project, neither a Software Developer nor Software Engineer will have a project that they worked on from scratch in most cases.

While there could be some cases where a Dev was entrusted to work on a whole project from scratch, it still raises doubts about their ability to collaborate/cooperate with other Devs specially on larger projects that require more man power to handle.

Not every interview question is a good question to ask. Just because others might be also asking those questions, doesn't mean that you also should. Quite the contrary, specially in the tech industry,where thinking outside the box is often a plus, you should be rather focused on approaching everything with question marks since nothing is black or white.

The job candidate, regardless of anything, they are people worthy of respect and dignity. Even if you do not see them as good fit for the role, you should respect the fact that they have given you their time and effort to engage with you in a meaningful manner.

You should view the job candidate from a more holistic point of view and even if things don't workout for whatever reason, remember that what you think is quite subjective and nothing predicts a Dev's potential more than actually working with them.

In reality, the most important factor you should be focused on, is their willingness to learn new topics they might not be familiar with and their receptiveness to ideas from others and/or considering others' feedback.

A good engineer, is not necessarily the one that has the "Best" project but in reality, they have the best willingness to learn and adapt.

How to NOT Create Leetcode Challenges

mosbat — Mon, 09 Dec 2024 15:51:58 +0000

I've been solving Leetcode challenges for over a year or so; I noticed that there is a great number of challenges that Devs are avoiding or failing to solve due to the challenge's quality.

Then, Leetcode tries to push those challenges to us via "Daily challenge" which frustrates a lot of people that Leetcode is trying hard to push Devs to do challenges that are poorly written.

Some red flags to recognize about a poorly written challenge:

Low Acceptance Rate

A challenge is not meant to be "Unsolvable". Leetcode challenges should aim to help Devs solve the challenges or have higher acceptance rate of submissions.

Poor Description

One of the worst things is poor description that leaves the Dev trying to guess what is being asked or very few test cases at the beginning that do not really help the Dev understand the core requirements.

I've often found myself writing a solution just to find myself being slapped by the test cases and adjusting/changing my code not because my solution is poor but because the description/requirements were not clearly communicated in the challenge.

So in this sense, if you spent 20 minutes writing a solution based on the description and you find yourself spending another 20 minutes adjusting your code, you easily lost 40 minutes.

Author's Solution or The High-way

What's worse than a poor description, is when the authors are forcing you to use their solution and accepting their solution as the "Ideal" or perfect solution. Most of those solutions fail several metrics such as readability and use lots of hackish techniques to squeeze few milliseconds when a more clearer solution with the same time complexity could have achieved the same result relatively; but they often place their time limits based on those hackish solutions.

In essence, time limits have become a tool that is abused by the authors to force Devs to accept/adopt their solutions instead of focusing on correctness, readability, etc... .

Time complexity should be the proper measure instead of how many milliseconds the solution takes (yep, hard coding here is still bad!). There are plenty of ways/tools in which they can spot the time complexity since there is already a built-in AI tool in Leetcode that does this so why not utilize it instead of hard coding time limits?!

If the author wants us to write an efficient solution, the focus shouldn't be on writing complicated unreadable solutions to prove how good they are at solving challenges but rather, focus on helping Devs solve the challenge with the desired time complexity without straining them or exhausting them with guessing and puzzles.

Ideally, what time complexity the challenge is solved with should be up to the Dev writing the solution while letting them also think for themselves on how to solve the challenge with better time complexity since Leetcode by default always will show the Dev the comparison chart against other solutions in terms of both time in milliseconds and memory usage.

How to Improve Challenges

The moment you think or believe that you want the Dev to "Learn" an algorithm or a technique, you need to ask yourself the question, in real life, at a company, are you going to dictate to your teammates how to write their code or solutions? If the answer is no, then by no means you should dictate in Leetcode how a solution is written; instead you should give the Dev a pathway to explore other paths without crippling them with strict test cases and TLEs (Time Limit Exceeded).

The difficulty of the challenge shouldn't be measured in how difficult is the description, or how much guessing the Dev has to do to figure out the solution but rather the difficulty should be in achieving the correct result of a complicated problem that might occur in real life.

If you adopt the above firmware (or mindset), you will be able to write more meaningful Leetcode challenges.

Maybe you can argue that on job interview, the challenges are quite often unfair, unclear and poorly communicated; this is a valid argument but then comes the question whether or not it's worth even working in such a toxic environment that is hell bent on making you feel hopeless or naive instead. That is a different problem and shouldn't be Leetcode's concern to make the challenges as poorly made as those on some job interviews.

A poor challenge or coding task on a job interview reflects on disorganized team and/or toxic environment which you shouldn't be in, in the first place!

What are your thoughts, please do share!

Push Back on Whiteboard Tests

mosbat — Sun, 01 Dec 2024 17:58:07 +0000

With the rise of ghost jobs and startups' unrealistic expectations, it's time for Senior and Mid-Level Devs to push back on whiteboard tests.

Whiteboard Tests Not Suitable for Senior Devs

If you are a Senior Dev, you probably have plenty of experience and plenty of projects that you worked on. Companies should have no excuse to keep on the circus of technical rounds at this point except maybe situational or behavioral assessments which is a different story.

I've often been interviewed by companies, and every time I push back on whiteboard tests, I got either rejected or they look at me as if I'm an imposter or a fraud despite the fact that I provided them with sufficient prove and certifications proving my skills.

Whiteboard testing is an outdated technique, and we can safely assume that putting Senior Devs with substantial evidence of their skills through such process can be considered a toxic behavior from company side (unless they have no other work to do except testing candidates).

Senior Devs need to push back on companies asking for those processes not only because it's unnecessary but it's also considered waste for both employer and candidate in terms of time and resources.

I found that serious employers didn't put me through so many loops and they were more likely to hire me even if I made small minor errors.

This is why, I encourage Devs to establish online presence on Github and also do certifications.

As a self-taught Developer, I was often slammed in the face by some employers for lacking qualifications, it's ironic that when I became qualified, they still slammed the door in my face which proves that recruitment in tech is totally broken.

When you apply to a job, you need to show them that you're not desperate and need to understand your own value and project it throughout the process.

If they don't like your approach, you have to question whether they are really that good to work with.

We need to rethink our way of approaching tech companies given all the ghost jobs and terrible treatment that many candidates in the tech industry experienced between rejection over subjective issues to outright disrespect of the candidate.

In the case of well established companies of large size, this question changes since established large tech companies are by default very competitive. However, startups and coffee shops shouldn't demand whiteboard testing if they are serious.

A question you have to ask yourself in the case of a startup, if they have a Developer who has the capacity and skills to test you, do they really need you or are they looking for a monkey?

I witnessed ironically the situation when I saw hiring managers grinding candidates with stupid whiteboard tests till they themselves were at some point put in the same position and got grilled on interviews to positions that are similar to their own. Yes! Karma is a bitch! This doesn't mean I feel happy to see this situation because it's not. It's a sad situation which reflects how awful is the recruitment process for Devs.

Regardless of the broken recruitment process, you should not let employers' unfair practices discourage you from the things that you love.

We don't learn data structure and algorithms for an employer, we learn those to enhance our own software and write better software. It's an art, not a commodity to be bought and sold; you should be proud of what you do and you need to project your confidence.

Note:
For Junior Devs, it does make sense to be tested if you're straight out of college by employers because of the misalignment usually between academia and industry; so if you're still a Junior, it's ok to be tested.

How to Remain Positive During Bad Job Market

mosbat — Thu, 28 Nov 2024 18:20:30 +0000

It is no secret that the tech industry currently sucks in terms of hiring. However, I'll help you find more meaning in your career as a Dev.

Everything began small, including tech jobs. If you are like me, you love being a Dev for either the passion of creating your own programs/software or you love it for the science; or maybe you are a Games Dev and making games to you is like an art, then we can all agree that we love what we do regardless if whether there is a salary or not.

The Larger Picture

Being a Dev is a personal choice that does not rely on anyone but yourself to be one. No matter how others try to put you down and demoralize you, you are still the one in charge of yourself.

Most job vacancies today have unrealistic expectations and it's not your fault that the market is currently this way. The real questions you need to ask yourself are the following:

Can I create my own scalable website.
Can I create my own micro-services.
Can I create my own game.
Can I contribute to open-source.
Can I learn new technologies and techniques on my own.

If you answered yes to even one of the above questions, then congratulations, you are indeed a Dev regardless what others think about you or whatever their BS criteria are.

I'm not being reductive but in reality, most of the skills or expectations on the job market are currently either unrealistic or simply speaking, the job it's self is fake which is a phenomenon we have witnessed in recent years.

Why Open-Source Contribution Matters

Your Github profile is not only a page where people can see your commits, but it's also a prove of your passion/dedication to the community. While you may not get paid for developing an Open-Source solution, the skills and techniques you learn along the way alongside learning how to collaborate with others do!

You don't need to have every PR merged but if you manage to make a commit every week for the betterment of the community, you have done great service!

Do Leetcode Anyways

I hate the view of Leetcode as just a job prep tool but rather a place where you learn new skills and sharpen yourself with problem-solving techniques.

You don't need to be looking for a job to try solve Leetcode. I do Leetcode everyday just like exercise or for fun. That helped me tremendously become not just a better programmer but also a better problems solver.

Learn Online Marketing

I can't emphasize this enough. Learning how to market yourself and creating a personal brand, opens many new windows.

I have worked with many small businesses before, created for them websites, apps, applications, etc...; and I lived and survived!

Sometimes, when you shift your focus to your community and those around you, you'll actually notice that programming is not something that only you do at big tech but something you can do to benefit anyone! Yes, literally anyone!

Quite often friends asked me to develop websites for them and they even paid for it even when I rejected to get paid! This shows, how wonderful and valuable your skills are in reality or in the real world.

Yourself worth is determined by you and you only!

I hope that this post makes you feel better and gives you more hope and positivity!

Build Relations

One of the most powerful marketing tools, is to build relations. When you talk to people, you never know if they are going to refer you to someone who might need your help with their website or even hobby project.

More often than not, I got a project simply by chatting with strangers in friendly settings and getting to know them better.

Discover Happiness and Strength Within You

Your happiness should never stop at a job interview for someone who hate their job or for those who view you as nothing more than a number!

Open-Source != Transparency

mosbat — Thu, 21 Nov 2024 11:17:04 +0000

I've been trying actively for a while to contribute to open-source projects. However, I had to come to the harsh reality that open-source is not what I thought or expected since I discovered a common pattern among open-source projects that is a bit troubling.

Project maintainers are warm and welcoming till you try to touch their code. They are fine of making Devs fix their documentation typos or write unit-tests for them. Otherwise, they become defensive and refuse contributions from those they are not familiar with even if the code makes sense (God forbid you have Arabic or Indian nickname -- sarcasm).
Open-source security tools don't allow you to post about security vulnerabilities in public. Instead, they ask you to send a private email about any critical issues which raises a lot of questions about transparency and whether they are interested in profit or giving us better product.
Corporate Devs Vs. Contributors war:
I noticed that the bigger or more popular the project, you will notice that the project already has a substantial number of Devs who are actually working for the company that is developing the product. This creates a conflict between community interest and corporate interests as Devs who are working as employees will give each other more favorable treatment in contrast to the Open-Source developers; not only that, but this divide creates outright us vs. them mindset specially among the corporate Devs who will be inclined to blame the Open-Source contributors for any issues that may arise. I haven't yet seen them do the blaming but I did notice the difference in treatment (double standards).
Project maintainers can be toxic and unpleasant to deal with. Unfortunately, reference to #3, the project maintainers can be extremely toxic. If you compare their attitude to the open-source contributors who are working for free for the betterment of the community, you will find out so quickly that the project maintainer hate their job and their company hired them because they are skilled, not because they love their job.

The above issues do not apply to all projects or all project maintainers but definitely there are bad apples which I'd recommend to avoid dealing with them if they engage in any red flag behaviors.

How can Open-Source improve?

They need to be more transparent, specially about security issues in their code/software. Lack of transparency is a major red flag which cannot be tolerated. If there are bugs or security problems, they need to be public and people should have the right to know whether or not their product is secure from cyber threats.
Segregate between employees and open-source contributors. Your employees shouldn't have the last say in regards to code changes but rather the community. Closing issues/PRs you don't like doesn't promote the culture of Open-Source that the community and consumers want! Auditors should be allowed to audit what issues and PRs on Github your employees closed specially if those issues/PRs raise important questions that could impact the product and customers.
Companies that sponsor or invest in Open-Source need to view the Devs and contributors' community as beyond just tokenism and marketing labels but rather, as part of the product's success. This means, if you want to hire project maintainers, the project maintainers need to have the correct framework and be more active and understand the culture behind Open-Source (instead of closing issues and PRs whose authors have Arabic or Indian names).

Despite the above setbacks, there are still decent Open-Source projects. I'd recommend aiming or working with less popular projects as their maintainers are less likely to view your code changes as an insult but rather as useful contribution.

Stay strong and always be #opensource contributor!