From Mechanical, Civil or Electrical to a Software Job: The Realistic Route

You Chose a Branch at Seventeen. It Is Not a Life Sentence.

You took Mechanical because the counselling rank allowed it, or because an uncle said core jobs are stable, or because CSE seats were gone by the time your number came. Now you are in third year, the CSE students in your own college are getting internship calls, and you are wondering whether you spent four years locking a door.

You did not. But you also did not get a free pass, and anyone who tells you branch is "completely irrelevant" is being kind rather than accurate.

Here is the honest map: what your branch actually costs you, which doors are genuinely shut, which are wide open, and what the switch really takes in months of your life.

Does Your Branch Actually Matter to Employers?

It matters at exactly two points, and almost nowhere else.

At the eligibility filter. Some campus drives and some job postings list eligible branches. If a company's campus process says "CSE/IT/ECE only", no amount of GitHub gets you into that room. That is a hard gate, and the real cost of a non-CS branch.

In the first thirty seconds of a resume scan, where a recruiter with 400 applications is looking for reasons to cut. A Mechanical degree with no visible software work gets cut. A Mechanical degree with three deployed projects and a good GitHub does not — the projects answer the question the degree raised.

Beyond those two points it stops mattering fast. Nobody asks a developer with three years of experience what their B.Tech branch was. The question is loudest at the start and gets quieter every quarter after.

So the strategy writes itself: choose routes where the filter does not exist, and make the first thirty seconds about your work rather than your degree.

Which Doors Are Genuinely Closed

Being straight about this is more useful than cheerleading.

Branch-restricted campus drives. Some companies restrict on-campus shortlists to CSE/IT, especially for product engineering roles. You cannot argue your way in. Apply off-campus to the same company instead, where the criteria are usually broader.

Most government and PSU technical posts. These notifications list eligible degrees explicitly and enforce them literally. If it says B.E./B.Tech in Computer Science or IT, a Mechanical degree is not eligible, however good you are. Read the notification; do not rely on what a coaching centre tells you.

Some M.Tech CSE admissions. Eligibility varies by institute — some accept candidates from other engineering branches, some do not, some only through specific GATE papers. Check that institute's brochure for that year.

A handful of research-oriented roles. Compiler teams, systems research, ML research at labs often want formal CS or maths depth, sometimes a postgraduate degree. Not impossible, but a long road, and worth knowing before you aim at it.

That is the list. Shorter than the anxiety suggests.

Which Doors Are Wide Open

Mass recruiters. The large Indian IT services companies run stream-agnostic hiring at scale. TCS's National Qualifier Test, and the equivalent fresher processes at Infosys, Wipro, Cognizant, Accenture and Capgemini, are open to engineering candidates across branches, and in several cases to science and computer-application graduates too. Criteria change year to year, so read the current notification rather than a senior's memory of it. These companies have hired non-CS engineers into software roles for decades. It is not a loophole; it is their normal intake.

Off-campus applications generally. Most off-campus postings for developer roles ask for a degree, not a specific branch. Read fifty postings on LinkedIn and count how many specify CSE. Far fewer than you assume.

Startups and product companies hiring on skill. A startup with 30 engineers reads your GitHub before your degree, because it cannot afford a bad hire and a degree does not tell it much. This is where a non-CS candidate with real projects competes on level ground.

Domain-adjacent software. Underrated. Companies building CAD, PLM and simulation tools, EDA software, industrial IoT, automotive software, BIM and construction-tech platforms, energy and grid software, manufacturing execution systems — all constantly need engineers who understand both code and the physical domain. A Mechanical graduate who can code is not a second-class candidate there. They are the candidate.

Testing, data and support-engineering entry points. QA automation, data engineering and solutions roles have historically been more open on branch, and they are real routes in if you keep moving after you land.

The Learning Order That Actually Works

The most common failure is not lack of effort. It is doing everything at once — DSA, web development, machine learning, cloud certification, competitive programming — and finishing the year with nothing complete.

Do it in this order. Do not start the next step until the current one is genuinely done.

1. One language, properly. (6-8 weeks) Pick Python or Java or JavaScript. One. The choice matters less than the depth. "Properly" means you can write 200 lines without looking up syntax, you understand functions, collections, error handling, and file I/O, and you have solved maybe 80-100 basic problems.

2. Programming fundamentals, not competitive programming. (6-8 weeks) Arrays, strings, hashmaps, sorting, searching, recursion, basic complexity. This is the layer that written tests and first-round interviews check. You need to be solid here. You do not need to be a Codeforces specialist — that is a different sport, and treating it as a prerequisite is how non-CS students lose a year.

3. How the web actually works. (3-4 weeks) HTTP, requests and responses, status codes, JSON, what a client is, what a server is, what an API is. Most freshers skip this and then cannot debug anything.

4. One backend framework plus one database. (8-10 weeks) Django or Flask if you chose Python; Spring Boot if Java; Node with Express if JavaScript. Plus real SQL — joins and indexes, not just SELECT *. Build something with users, authentication and data that persists.

5. Git, and deploying something to the internet. (2 weeks) Not a tutorial. Your own project, on a real URL a stranger can open. The number of candidates who have never deployed anything is remarkable, and the ones who have stand out immediately.

6. Two or three real projects. (ongoing, 3-4 months) More on this next.

7. Then, and only then, specialise. Cloud, DevOps, mobile, data engineering, ML. Choosing a specialism before you can build anything is how people end up with four certificates and no working software.

Roughly 7-9 months of steady part-time work alongside college. Not three weeks. Anyone selling you a three-week transformation is selling something.

Projects That Do the Arguing For You

A non-CS candidate's projects have to do more work than a CS candidate's, because they are also the evidence that the switch is real. Three rules.

Solve a problem you actually have. A hostel mess bill splitter. A tool that scrapes your university result portal and mails you when results drop. A lab-equipment booking system for your department. Real problems produce real edge cases, and edge cases are what you talk about in interviews.

Use your branch. Deliberately. This is your advantage and most people waste it. A Mechanical student who builds a beam deflection calculator with a proper API and saved projects has something no CSE student in the room has: work nobody can accuse them of copying from a tutorial, in a domain they can discuss for twenty minutes. A Civil student building a material-estimation tool. An Electrical student building a load-monitoring dashboard from an ESP32. Interview gold, because the interviewer becomes curious rather than sceptical.

Deployed, documented, and yours. A GitHub repo with a README explaining what it does, why you built it, what broke and how you fixed it. A live link. Commit history spread over weeks, not one commit dated last Sunday.

Three projects like that outweigh eleven tutorial clones, every time.

How To Explain the Switch Without Apologising

Freshers ruin this in the first sentence. They open with the apology: "Actually sir, I am from Mechanical, but…"

That "but" hands the interviewer a doubt they may not have had. Try the structure below instead — cause, evidence, direction.

"I did Mechanical, and in second year I built a script to automate a lab calculation we were doing by hand. That turned into a small tool the whole batch used. I have been building software since. Here are the three things I have shipped, and this one" — your domain project — "came directly out of my branch."

Three things happen there. The switch has a cause, so it does not read as escape from a failed core-job search. It has evidence. And the branch becomes a source of the work rather than an excuse for it.

Prepare the honest version of "why not core?" You will be asked. Good answers: the feedback loop in software is faster and I found I liked that; core roles in my area meant plant postings I did not want; I started building things and it stuck. Bad answers: core has no jobs; core salaries are low. Both may be true in your experience, but a complaint about the old field is not a reason for the new one, and interviewers hear it as "you will complain about us next".

Do not over-explain. One tight paragraph. If you talk about it for four minutes, you are signalling that you think it is a problem.

How Long It Honestly Takes

Two scenarios, both labelled as examples rather than promises.

Example A — you start in second year or early third year. Seven to nine months of consistent part-time learning puts you in a position to sit fresher assessments with the rest of your batch and to apply off-campus with real projects. You may well land a comparable first role to your CSE batchmates, typically in the ₹3.5-7 LPA band for a fresher software role in India, with product companies going higher and service companies clustering at the lower end. Bands, not quotes — the actual number depends on the company, the city and the year.

Example B — you are in final year, starting now. Be realistic: you will probably not out-prepare three years of CSE coursework in six months. The high-probability path is to take the service-company or domain-software role you can get, join, keep building in the evenings, and switch after 18-24 months as an experienced candidate — at which point nobody asks about your branch at all, because you have a work history. Unglamorous, and it works.

The trap is joining, getting comfortable on a bench or a support rotation, and stopping. Two years of a job where you built nothing leaves you no better placed than the day you joined. The switch only works if you kept working through those months.

What Recruiters Actually See

Take two resumes for the same fresher backend role.

B gets the call. Not because branch does not matter, but because she gave the recruiter enough evidence that the branch stopped being the most interesting thing on the page. That is the entire game.

What To Do This Week

• Pick your one language and commit to it for two months. Write the date on something. The single biggest cause of failure here is switching stacks every six weeks.
• Open a GitHub account today, even with nothing in it, and start committing daily. Fourteen months of history cannot be created in the final month, so it has to start on an ordinary Tuesday.
• List three problems from your own department that software could solve. Pick one. That is your domain project.
• Read the current eligibility notification for two mass recruiters. See for yourself which branches they accept, rather than trusting corridor rumour.
• Write your switch story in five sentences. Say it out loud until it sounds like a fact rather than an apology.

Your branch decided your first filter. Your last eighteen months of work decide everything after it.

When you do start applying — and non-CS candidates usually need to apply to more roles to get the same number of calls — JobApplyAI drafts a personalised application per job post from your LinkedIn tab, so the volume does not cost you the personalisation that makes a branch switch believable.