When To Reject Your Software Employer

1-A failure is never time wasted. It is new learning.

2-Repeatedly failing for the same reason means you have not learned at all.

In my 20 years long software career, I have faced about 500+ rejections.

Most of them (350+) was on the CV level. Now before you think I spammed them: I received a polite No from HR email.

I don’t regret it, because, in those 350+, despite personalized cover letters, I wasted very little time per employer.

In the rest (150), I fell facedown. When I complained, my friends would say: “A failure is never time wasted. It is a new learning.”

But repeatedly failing for the same reason means you have not learned at all.

If I had wisely rejected employers, my rejection number would be far less than 150.

Why rejecting a software employer is sometimes important?

Not only to save time but self-esteem, too.

Software hiring processes have become full of subjective practices. As a result, biases inevitably creep in.

In the beginning, I believed them: I wasn’t good enough. Traditional wisdom told me I should equip myself with the rules of the profession. Craft alone is never enough.

But past following the industry best practices, when I didn’t see a noticeable change in the interview outcomes, my confidence took a shakedown. You don’t want that to happen to you in the ever-changing software industry.

The mindset of a serially-rejected candidate is much more terrifying than the time wasted. Lost self-esteem is very difficult to regain.

When I took a rational outlook, I concluded that repeated rejections without concrete information meant:

• Stereotypes exist in every person’s mind. Software interviewers aren’t exempt from it. They always try to box you, no matter how harder you try.
• Just like any other industry, ageism, sexism, and racism exist in the software industry too.
• Sometimes you have arrived, but the world around you has not.
• Irrespective of all that, there will be people who would recognize you one day. They may or may not be your future employers. You don’t want the burden to overwhelm you until that happens.

Software hiring processes have become full of subjective practices. Interviews and assignments have little objective indicators associated with candidate performance. As a result, biases inevitably creep in.

So here I list symptoms that signal when you would be better off rejecting the employer — to save your time, energy, and self-esteem.

The Job Advertisement:

AKA Job Description:

HRs do a great job sugar coating the job hassles involved, but experienced devs see through it quite easily. If the job poster is a copy-paste intern or is not smart enough, a bad job always reveals itself in the job advert:

You are an experienced developer with an exploratory mindset. In an environment which is constantly moving you must maintain a sense of structure.

You are not afraid to speak your mind, here we embrace new and fresh ideas. You’re truly passionate about the tech, and doing something for a greater cause. 

As the rest of your future colleagues you always have the customers in mind.

Culture is very important to us. We regularly take employees to Friday beer nights. Once a year, we take them on full week trip to Bali. We expect them to enjoy to the fullest with the team.

Hustle is in your blood and sweat. You are a rockstar. Yet getting your hands dirty is never a problem for you.

The bold letters quite describe the underlying adversities, in the following order:

• They expect you to be ready for requirement changes when half of your design is done.
• Your love for tech isn’t enough. You must own the dream of the founders, though not share their assets.
• You are not only tasked with programming, but also refreshment activities. You must be mentally ready all time to enjoy them with the team. The family can wait.
• You have an emboldened role with a lot of respect but minimal compensation.

Also, notice that none of them include analytical thinking or problem-solving ability. There are old-time software companies that still use them, but they are in minority.

Because they are taken for granted.

In an industry that demands the picture-perfect attention of a theatre artist and the stress-survival ability of a C-level manager (minus stock options & looming layoffs), the remuneration remains unchanged for decades.

Chances are: You might survive all the interviews with flying colors, but the actual job might kill your well-balanced life.

Takeaway?

Reject them. There might be good ones waiting for you. If you don’t have choice or patience, know fully well what you are getting into. If you fit, jump in. If you don’t, be ready for a rollercoaster.

The Personality Assessment

AKA HR / Recruiter Screening Interview Round

Accepting the current interviewer as the judge of the past jobs is something one could totally avoid. Yet, we all are too vulnerable to even detect it during the interview.

A small chunk of my rejections (10–12) happened between HR and the technical level.

This meant that HR interviewed me to know about my past, reveal the company’s background, and describe the job opening. Then they rejected me.

In the earlier stages of my career, they were quite formal, and I almost breezed through them with fluent English. So I strongly believed that rejection at this stage was impossible unless my CV data was fake.

HR interview is a colossal waste of time.

However, past the 2008 market crash, I found that every recruiter vetted CVs in a highly personalized manner. The grilling grew longer. HR interviews (meant for introductions) begun to average around 40+ minutes for senior developers.

In the worst cases, they lasted about 90 minutes. Whenever this happened, I could sense a rejection.

Reason? Apart from asking me my best and the worst career moments (a thing that I wasn’t expecting yet managed to survive), they asked a lot of psycho-analytic questions about hypothetical situations.

Why do you want to join this company?

What will you do when you are on the front line during a production bug?

How will you act the next day if you had a heated argument with your boss during a meeting?

Did you ever have delivered low-quality code (knowing it fully well) during your freelance career?

I tried answering all of them with utmost honesty but failed to provide the proper context in a short time against the surprising questions. Even when I tried, the interviewer being an HR (often 10–15 years less experienced than myself) failed to relate to it.

So many negative things happen in a software developer’s life, but for a person with an HR background, they are merely checkboxes.

Here were my realistic answers:

• There is nothing so special except that it needs programming skills that I happen to have. Passion for domain matters for product/marketing/management roles, not so much for software making. Software geeks are required by everyone — porn websites, pet care organizations, booze retails & churches/orphanages included. It doesn’t mean they are passionate about any/all of them.
• I had never been on the front-line during a production bug. But my capability of writing bug-free production code is what matters to you.
• I had a heated argument with my boss, yes, but the situation entailed a long series of misjudgments by the boss + management combined. It is impossible to explain during this interview why I did not speak a word the next day.
• I delivered low-quality code, yes, but so did my many fantastic colleagues, and they were too smart to admit it.

So many negative things happen in a software developer’s life, but for a person with an HR background, they are merely checkboxes.

In all the situations, accepting the current interviewer as the judge of my past jobs was something I despised, and I could totally avoid it. I could have simply refused to answer the question, or presented a curt, presentable lie.

I could mentally reject the employer right at the moment and would relieve myself. If the outcome was still positive, I would rejoice. Yet I was too vulnerable to even detect it. I was too engrossed in the interaction to turn on my diplomatic tongue or shrug off the question completely.

Outcome? Injury always followed insult:

- We are not sure about the proper match between you and the company’s present path of growth. We will be glad to keep you on file.

- We regret to inform you that while your abilities are best, your stress handling skills are no match for our current requirements.

- We regret to inform you that while you are highly talented in your tech skills, your interpersonal skills are a hindrance to the company’s current roadmap.

- We regret to inform you that XYZ company believes in hiring candidates with utmost integrity.

I felt violated, not because of the rejection, but for the part of me that I had honestly exposed about my past. Those were the things that were played on against me, with my full consent!

A background check would have exposed the same details, and the rejection would be a lot more bearable.

Nowhere in the job description of an artist is the requirement that I must validate your taste.

James Turrell

I understood what one of my rejected friends meant when he said “HR interview is a colossal waste of time.”

Takeaway:

Minimize your time / mental energy to fit culturally.

Too many personality questions with little bearing on the job experience? Cut short on the expectations. Minimize your time / mental energy to fit culturally.

You can’t change who you are, but you can change what you can be, by cutting the crap.

The HellHole

AKA The Coding Assignment

I am still wondering where can I find this ideal developer, and take lessons from him.

About a decade ago, soon after the great recession, employers became too wary about fake developers. Agile meant hiring those who could quickly get their hands dirty. Hands-on experience became the #1 requirement.

This directly resulted in live code-share interviews. Platforms like Codeshare.io allowed employers to witness every keystroke by the candidate during the technical assessment.

My first such encounter happened in 2015. Despite accomplishing the assignment target, I was rejected. My steps weren’t those of an ideal developer. I am still wondering where can I find this developer, and take lessons from him.

I quickly started avoiding companies that enforced live code-share sessions. They were too stressful, not unlike whiteboard interviews that are loathed throughout the industry.

Max Howell, the creator of Homebrew, was famously rejected by Google for being unable to finish a task in time during a whiteboard interview.

Enter At-home Coding Assignments:

Finally, I could show what I could accomplish in enough time. What could be more awesome?

When I started seeing companies giving code assignments for at-home exercise, I jumped to my feet.

After all, it was to be done at leisure — mostly within a week. I could spend sleepless nights and weekends to make it the best.

Finally, I could show what I could accomplish in enough time. What could be more awesome?

My mental plan:

• Day 1: Mental design.
• Day 2: Finding the best source to copy the implementations for every component.
• Day 3–5: Coding.
• Day 6–7: Tests (I know, TDD advocates would shout, but it often doesn’t work that way), documentation, adornments (UI layout, animations) — anything that could give me an edge.

The entire experience is joyful. My GitHub is full of coding assignments disguised as community contributions (with no copyright/NDA violations). The learning was immense.

Except for the outcome:

Out of 25 week-long coding assignments I did, I was rejected in 24 of them. 96'% rejection rate.

That time I could have dedicated to launching a clone website, or quick & dirty app that makes serious cash from advertising.

Why?

Because coding assignments are designed like traps.

Whiteboard interviews challenge you with atomic tasks (sort an array / find the number shortest path etc). Interviewers want to see you question during the problem, and are eager to answer. Their time is at stake too.

Whiteboard interviews test your capabilities in symbolic ways. If you are able to show your modular approach in one place, it is not expected at every possible place. Your mentioning about it marks your positive.

No one submits as soon as the output is achieved.

At-leisure coding assignments are exactly the opposite. They are headless challenges that tempt the programmer in you to be fully immersed in themselves. When you emerge back, rejection awaits you.

Without requirements or design, programming is the art of adding bugs to an empty text file.

-Louis Srygley

• They are defined concisely (usually in < 10 lines), but not always precisely.
• As a result, Design the most efficient car parking system can be a problem statement. (Yes, it happened to me). The ideal answer depends on what the interviewer has seen (probably on TopCoder or a similar place), not what you tried + achieved.
• If interviewers saw the problem somewhere online, they always assume you would copy the solution. You must meet/surpass that level. If you haven’t, you can’t win. It would amount to reinventing the wheel, and they weren’t looking for it.
• Sample of good code # Demonstrated capability. You are doomed to show consistency, and even past that, you are doomed anyway.
• Choice of a design paradigm = Inability in other paradigms: If you choose MVVM, you do not know VIPER, and vice versa. Since the team uses former (/later), and you chose later (/former), you are unfit. No questions asked, no expectations set beforehand. Plain rejection.
• Interviewers can be queried via emails, but their responses are mostly cryptic. Documentation of the problem is non-existent.
• Assumptions are considered part of the challenge. The promise is that if you make the right ones, you will succeed. And it’s merely a promise.
• The requirement is to design a miniature system, not a component. This means that you must design + develop UI, models, services (networking/file/database), and everything in-between. If you don’t see those parts, you missed serious lessons in design. If you do those parts, you have over-engineered the problem.
• On paper, it is stated that it should not take more than 2–4 hours of your time. But it can rarely be finished even on a full weekend unless you did it already and just need to copy-paste.
• And it’s not them, it’s you: You can achieve the task output in no time, but no one submits at that stage. It’s not greed to innovate, but fear of rejection due to spaghetti code that achieves 99% output.
• You will rarely admit it took more time because you fear rejection for having taken longer.
• You could be rejected for brevity, coding style, lack of tests, abundant tests, or project folder structure
• If you are lucky, you will be shamelessly notified about the pettiest rejection reasons. The HR ticks a checkbox named feedback to candidates, but it is a one-way street. If you provide your perspective or ask for an explanation, the line goes dead.
• If you are luckier, you get a creatively drafted rejection that summarises your assignment shortcomings in unforeseen words. The meaning of those words is often null (pun intended). My mailbox has a special folder with tech team emails citing the most creative rejection reasons.
• I am yet to receive a rejection that cites non-functional code or an unusable test case. I got a design that needs further explanation, but when I explained/asked, the line went dead.
• You have no right to contest the decision.

Coding assignment becomes the strongest weapon in the hands of racist, sexist or prejudiced tech team

Due to highly subjective selection criteria, the coding assignment becomes the strongest weapon in the hands of racist, sexist or prejudiced tech team, and you have no way to dismantle it from the system because it can never be proven. Gaping inequalities can hide behind the veil of the insistence of merit.

The best use of a (failed) coding assignment done well is to fork off a kickass side project off of it. Making it your portfolio project for a future job — the second best.

Again, I do not say it is boring. It is full of life. It improves your design skills. It liberates you to be creative by leveraging your technical strength. It strengthens your coding muscle.

But associating its outcome with a singular job position is the most hopeless thing.

The best use of a (failed) coding assignment done well is to fork off a kickass side project off of it. Making it your portfolio project for a future job — the second best.

Basecamp cofounder @DHH, who has championed many work-life balance solutions for software employees strongly advises against even 10 hours of at-home coding assignment.

Takeaway?

Don’t take their word for “You are not good enough”

As soon as you receive the assignment, ask succinctly as many stupid questions as possible. If you face rejection for asking questions at this stage, it is totally worth the time saved. You don’t want colleagues who shrug off accountability for documentation.

• Beyond modularity + output, what are the other expected outcomes?
• Are nice to haves (i.e. tests, UI adornments) going to have a decisive impact?
• Is good code design an end-goal or a requirement?

You can still face rejection, but having their word opens up a window for arguments. They will not respond, especially if it’s a losing argument for them. An organization will always fear possible legal/PR outcomes.

At least you can make them / HR think twice about the time you spent after it. Future candidates will have a better time. Your good karma will pay you back someday.

Don’t take their word for “you are not good enough”. Demand from them to be good enough to select someone based on measurable efforts, without mammoth unpaid assignments.

Conclusion:

Raising your self-esteem involves asking the right kind of questions, and valuing the time + energy you spend after unpaid ordeals.

Rejections always entail learning. But that learning need not belong to software/programming alone.

Spending a lot of time on software interview preparation makes you a lesser programmer. I already wrote about it here.

Rejecting your employer requires self-esteem.

Raising your self-esteem involves asking the right kind of questions, and valuing the time + energy you spend after unpaid ordeals.

If you do it on a consistent basis and also share your experiences, the world will be better for programmers, including yourself.

Originally published on Medium by Pen Magnet.