The author forgot to mention how much he paid for the offshore team. There was no mention of money in the things that went wrong. I think the cost is a very important factor if you expect a high quality project.
I have seen many people who bash India and Indian engineers for low quality work, but lets get to the crux of the problem. Its not that Indian engineers are all bad. They come in all shapes and sizes. You will get the best ones if you pay enough. You pay cheap, you get cheap.
Where can you get cheap ones ? From those big IT companies who treats employees as resources. The employees in turn will also treat their jobs along those lines.
So if you need high quality work, please don't go to these giant corporations. If you look hard enough, you will find small high quality places, but they are not cheap and not 'scalable' like your manager wants them to be.
The last time I managed outsourced developers I made this joke.
"There are some truly amazing Indian developers, it's just a shame none of them are in India".
My observation was that the outsourced developers I managed, the good ones usually got visa's and buggered off abroad even though they where getting near UK wages in India they could earn more by moving.
Agree. What I see is, skilled ones are flocking to Canada and Australia because of their merit based immigration system.
H1B has lost its luster because its now a lottery visa, no place for skills. The Indian IT biggies flood H1B market with petitions claiming high skills for a meager developer.
There are also a lot booming startups in many cities spread across India. You can find the best ones there too.
Not really, I don't know a single top student who is studying in Canada or Australia. Maybe you are referring specifically moving for work.
Australian wages are significantly lower than those in the US and for the most part, it isn't on anyone's mind to apply there. In my experience, students apply to Australia when they can't compete for good universities in the US. Canada is very sensitive to GPA values.
I know of cases, where literally the absolute cream of the cream, with a strong profile to show for it, have been rejected from Canadian institutes, for reasons that no one seems to have figured out yet.
In the past few years, I know a lot more people who are gravitating towards the EU over the US, but I don't don't hear much about moving to either Canada or Australia for work or education.
That being said, the lottery system for giving the h1b is universally loathed.Some of smartest people I know are struggling to get one, while Infosys keeps sending utterly mediocre people in droves to the US. I hope it does become a merit based system (assuming the number of spots stay constant), I however have no idea as to how merit should be decided.
Alternatively, the good ones that stay in India may not be interested in working as contractors for Westerners. India has a population of 1.3 billion - there are certainly some top of the line engineers and computer scientists there.
>the good ones that stay in India may not be interested in working as contractors for Westerners.
I had plenty of brilliant IT colleagues in a nondescript small town in rural south India. Almost none of them wanted to do any contract work or even get in the rat race.
They were working on porting BioShock to Mac OS and I was amazed at what they could achieve in a limited timespan
Very interesting story ! Did they worked for a local firm contracting with the Bioshock publisher or a indian subsidiary of this publiesher ? How did the publisher find them out ? How did they meet and acquire their competencies ?
There is also the culture of "making it to management". For some people being general staff is not prestigious enough, so some people pursue a managerial path and leave their programming skills behind.
This statement screams failure - "We would have one week to recruit developers from our company's off-shoring pool and then two weeks to coach the team."
Basically, they were forced by their corporate entity to hire people that did not have the right experience and then train them in two weeks? <sarcasm> Sounds like a recipe for success! </sarcasm>
I've been in the position before where I had to work with a staffing firm and the majority of the resumes they provided were not a fit in any shape or form. Management did the smart thing and we found somebody else who could give us a better pool of candidates.
The whole article is one red flag after another. Judge developers individually, judge harshly, and fire quickly. Bad developers require endless management while great developers require minimal oversight.
In my experience with off shore development I found the people I worked with to be extremely hard working and eager to learn. The programming was never the problem, the problem was the lack of understanding the business use cases of what we were building. Because they had no proximity to the business problem we were attempting to solve, they had a hard time making the right decision on their own. Specs had to be very, very detailed.
The thing is that you don't really buy developers or even developer's time but a service which is a more complex package where your interests and those of the people who sell you the package are not alligned.
> From those big IT companies who treats employees as resources.
I've worked in those companies, they do treat employees as resources. I was amazed how executives, RH and even Project Managers refered to developers literally as "resources", example: "We are happy to announce we have five new resources in project X".
No one seemed to care, that mentality was just sad.
The best response to people calling individual contributors "resources" is to politely correct them. If the abusive terminology continues, then the "resources" have the right to "return the favor" by setting the standard in the culture of referring to managers as "overhead" (e.g. "I should ask my 'overhead' if I really need to attend that stupid meeting. I might be able to dodge it so we can get this new feature checked in.")
Problem is large orgs are political by nature. If you acted that way chances are you'd be sidelined into some dead end thing, given all the crap work, or even laid off as "not a good fit" or something. If you were the kind of person who didn't care about those possibilities then you might as well be working for a small company where you'd have a lot more fun... which is a backward way of saying that the people who work at large corps often do value security and stability and do care about keeping their jobs.
I once had a lead engineer refer to me as a "resource" during a meeting while I was in the room. As in, my boss was having a discussion with a senior manager and pointed at me, referring to me as "that resource."
My boss has often used the term ressources when talking about me and my collegue, usually saying that she has only two ressources to work on the current project. But since it's usually when pushing back against more demands of the sales people, I don't mind.
Although I would be offended (and weirded out) too, is it possible it's a quirk of geographical variation in language? Resources are by definition valuable, after all.
Any outsourcing firm, though, has a basic dilemma. Even firms that outsource to other expensive US locations.
It's the bait and switch. They give you the top talent at first, to make the sale. Then they slowly swap them out, because they are trying to use the top talent to close a sale with a different client.
There's no real way to remove that incentive. You can try, but the time and energy needed usually invalidates the initial business case.
A modestly sutainible consulting business probably bills at about 2.5x salary. Without considering any materials cost (which is a dubious assumption) that puts average compensation of the ten member team at 40k/year. Note that the senior person or people on the team responsible for attending meetings and communications almost certainly make a multiple of that. And the juniors who are most profitable for a "body count" type contract often make a fraction of that and perform most of the work.
On the other hand, organizations that allow themselves to be in the business of saving money are not really results focused anyway. They're often buying based on the difference between a team of ten and a team of eight because the team of ten is easier to defend to the next layer of management. Team count is the same sort of metric as lines of code.
How much of those million Euros went to the actual employees ? I agree with you that the pay was split unfairly by the “hierarchy”.
Big Indian IT firms makes a killing when it comes to billing clients. Not much of that money trickles down to the employees who actually do the job. The employees are plagued with "performance appraisals", "yearly evaluations" to fight for meager raises.
It is possible to read that sentence as "million Euros spent to deliver working solution, which includes a full rewrite of everything employing well-paid senior-level engineers in Europe".
I read it as costing a million euros to clean up the mess afterwards and get the software that should have been done into a state where it could actually be released.
The author says they spent a million euro for a year. Even assuming that includes the one FTE in Germany, for 10 devs in India, they definitely weren't paying bottom dollar.
Running my own startup I have one absolute rule: If you are not an expert in it, then don't outsource.
I outsourced my business and marketing to team in US/UK and it was an absolute disaster. Took me long to realize that you can only outsource tasks which you have expertise in and which can be measured.
Most of us are not the ones making the decision to offshore, or the ones choosing the firm to outsource to. Most of us are likely the ones that have to deal with the output.
BitKeeper guy here (predecessor to Git and Hg). If you think about the capabilities of a distributed source management system you can quickly see it's an enabler for out-sourcing.
As a commercial DSCM provider, we got to watch a lot of out-sourcing attempts.
In 18 years of doing that, I've only seen one really successful one. Which was a Portland based dev team and a Singapore based test team. Every day, the dev team would check in their stuff (or make it available in a test tree) and the Singapore team would wake up, pull it, test it, document the failures, the Portland team would wake up fix and dev some more, lather, rinse, repeat.
As I recall, the Singapore team was out-sourced, different company, but they had a stable group of people dedicated to working with the Portland guys. It was more like two teams working on the same project.
I've seen countless efforts based on "I can get 3 guys in India for what I have to pay one junior guy here" fail. The time difference makes communication hard, you have to send someone to manage the India guys and communicate what you want, there is zero loyalty, if a better gig comes along all the time you put into onboarding those guys is lost, the quality of the code is pretty crappy, etc.
In business, even in the US, there is almost never loyalty. Or, perhaps more precisely: In business, you have to buy loyalty.
I guarantee that there is a price at which you could buy a very stable, very competent team in India. But then it wouldn’t be super cheap outsourcing any more, and the benefits aren’t so great.
If you want stability in your workforce, you gotta pay for it. Whether in cash, working conditions, or some other way.
Pay for cheap labor, get cheap labor. And don’t be surprised or disappointed that you got it.
I think there is some loyalty. As an example, my younger son is looking for his first job, I'm gonna see if the local grocery store will hire him, but I talked to him and said "Look Dylan, if you get a job there then you have to stick with it. They are going to spend time to train you, that's an investment, you need to stick with it even if you get bored."
If US engineers bounced from job to job as much as the out-sourcing guys seem to it would be a red flag. I don't know what the norm is today, but back when I was hiring, people that didn't stick it out for at least a year at each company (and had no explanation, things happen, I'd allow for that), were considered less desirable than someone who stuck it out for longer.
But in general, I agree with your point that you gotta pay if you want quality people. Good people are expensive. The lure of out-sourcing is a pipedream so far as I can tell.
> In business, even in the US, there is almost never loyalty.
There is loyalty here. You don't hire someone and they come in to work and work on OTHER PEOPLE'S PROJECTS. You don't get people lying to your face daily about their skills, it comes up pretty quickly that they can or can't do the work.
Loyalty isn't just leaving because you have got a better offer.
This jives with what I've seen. One company I was at created a subsidiary company offshore and made the effort to hire FTEs. The offshore teams at that location were pretty damn good actually.
Yeah, the drawbacks of it being absurdly easy to get a "computer science degree" in India are real. And something I've also seen other major companies encounter is the total lack of any respect for IP law. If you want to get your app built cheap.... and then find your competitor running a reskinned identical version a month later... sure, outsource it.
Absurdly easy to get a "computer science degree" in India
It wasn't easy at all for me. I spend three years doing graduation in Bachelor of Computer Applications in India (early 2000). The coursework alone was so much that you would have "learn" something. On top of that, I did private diploma from NIIT for "practical" exercises (at that time NIIT and Aptech were quite popular among students)
While I came to Australia for Masters, most of my friends did Master of Computer Applications (three years) in India. Six years of computer studies are bound to give you some knowledge!
I shouldn't have spoken so generally, and I apologize. My knowledge of the situation is derived from researching the coursework involved in receiving a PhD in Computer Science from Bangalore University. At the time I researched it, it required (American) high school level math and then 6 months of additional courses. I had a professor who had 2 PhDs from this 'school'. In an 'Intro to Object Oriented Programming with C++' course, he taught us the wrong way to use cin to get a number from the user then assigned homework writing a program that accepted two integers and printed out their sum. At the next class, he announced that anyone who wrote the code as he instructed would receive an A despite it not working... and anyone who looked up how to make it actually work would get an F for not listening to him. A group of fellow students and I went straight to the department chair and he was shortly fired. That inspired me to research where he got his 'degrees' from.
Getting a sub-par CS degree in India is extremely easy. There are a good number of bogus universities in the countries.
Getting into a well reputed (top 50?) Indian CS program is multiple orders of magnitude harder than it is in the west. Most students qualifying for any of these programs would be capable of aceing the SATs.
To give you an idea, the Indian equivalent of the engineering/CS SATs are taken by 1-1.5 million student annually. The top 50 programs have less than 20,000 combined positions. You need to be in the 98th percentile and above to get in.
It is common for students to study 10+ hours a day for 2-4 years straight, to meet the above requirements. Whole childhoods get sacrificed for the rat race.
That process worked for us too. We developed all day; the Indian team did full test sweeps their day and debugged issues; rinse and repeat. Trying to replace local devs with equal remote devs not so much.
> we needed to reject some candidates because we simply could not understand their English pronunciation.
That could be a mistake - If you find someone who has good skills, and would otherwise make the team, there are language bootcamps you can send them to, which will help with their English. I have sent people to them, and they ended up being wonderful members of my team, once we got past the communication barriers. If you are willing to coach on other topics, refusing to coach on communications is an odd choice.
For my part, when building an offshore team, I did a few things:
1) Brought them here for a couple weeks. Seeing how we work, and getting to know each other in person made a huge difference, including being able to get used to accents and mannerisms. Like any other team, it built trust, which goes a long way towards working well together.
2) I took lessons in Hindi. Never spoke it to them, never got fluent, and many Indians don't speak it anyway... but just trying to learn it helped meet in the middle on accents, and helped communications to the point that I often ended up translating between 2 English speaking people who just couldn't understand each other. And they appreciated having an American who would just laugh with them when we couldn't understand each other vs. getting frustrated and making them fear for their job.
Nice points. Unfortunately the type that is looking to offshore has a lot in common with those who are not interested in training or coaching at all. No, must "hit the ground running."
I imagine if you're hiring offshore workers you aren't working at a large tech company, and there might be a more standard work day which is expected to be adhered to.
For example, I doubt most of the time the IT or programmers working for a bank can expect to roll in at 10 or 11. Different jobs have different expectations.
The last two places I worked, the devs were expected in at 7:00am, and 8:00am. The second place gave you a five-minute grace period.
These weren't "tech" companies. They were companies in other industries. You're not going to find a lot of 11am devs in finance, healthcare, or manufacturing.
> These weren't "tech" companies. They were companies in other industries. You're not going to find a lot of 11am devs in finance, healthcare, or manufacturing.
Considering these developers usually work with people in time zones west of them this is actually the expected time. 11AM would mean 7:30AM German time. Which would align much better with the German dev hours and make working together smoother.
I'm in at 9 or 10. In our remote offices, the devs are often in by 8am (partially because that's the only time of day when our hours overlap, and thus the only time when live communication is possible).
This was a real insightful look at how "clients" feel when coming down to India. There are some great points made on how things don't gel well together.
I have been on both side of the fence - both as a "resource" for an offshore client and contracting a team for work. If I reading this correctly the issue might have started from candidate selection itself.
You have to be strict when it comes to hiring. Startup scene has ensured a good developers are paid well. But most offshoring firms tend to keep the salaries low even for in-demand stuff like mobile app development.
So, offshoring pools can be dry. In which case, companies tend to fudge resumes or provide some low quality devs.
So, look out for people being unable to answer basic stuff, that is red flag 1. And if they are unable to explain their past projects, that is red flag 2.
Apart from that, there is another thing you have to answer - What is more important? Good candidate or quickly selecting one?
We had to spend 8-9 months looking for a candidate. We found one who fit nearly 80% of our criteria, even with the best pay possible.
But when we tried building a team quickly - the overall pay rose exponentially.
IMO, a better idea is to open an offshore center and fester a culture that you want. It is difficult to ask people to follow one company's culture while they are working in another.
I owned a company that provided off-shore services to companies in the US, it worked perfectly.
If you are doing off-shoring, you really need to insist on the independence and the ability to speak up of the team, it doesn't work if you get yes-men, sadly that's the general case for India-based offshore companies
It's an old, old story; middle management's never ending quest to commoditize and automate software development. They'll never accept software development has almost no commonality with assembly line work. But they keep trying.
Although I never got an explanation, their managers were probably selling their employees to multiple projects. I've heard that this happens from people working there.
Offshore developers from a body-shopping company who are shopped to multiple customers is common. I've seen it happen multiple times in different countries.
I have over a decade of experience trying to make off-shore development work with several off-shoring companies, one of which was a wholly owned subsidiary (to avoid the various overbilling strategies). I've never been convinced it is worth it overall. The semi-irrational insistence on off-shoring was actually one of the primary reasons I quit my last job.
> But that was very exhaustive and couldn't obviously go on like that forever. Then we switched to weekly meetings, reviews were mostly done by their team lead.
That's where you went wrong first. You let go of the responsibility and handed it over to people who did not necessary have your best interests in mind. Quality, schedule, outcomes etc need to be managed, and managed so problems can be picked up early.
Secondly "It turned out that from those 8-9 developers we hired, at the end of the project only 3 of them were actually committing code. Although I never got an explanation ...", point to another management issue.
I am sitting in a country with a reputation for being an outsourcing hub, I am from the western world and I can tell you that there are many talented developers. The problems are the same as I have had with managing western teams, personal issues, skill levels etc though some of higher or lower impact. But the basic fact remains, the further you distance yourself from responsibility the greater the risk of failure.
I always thought this. However, it seems like this would require a lot of direct management. Who was the PM for you - was it you? if not, was she/he local to the devs? What was your timezone?
My struggle with offshoring to India (from PST) is that the nearly opposite timezone affords minimal overlaps, and thus either the offshore personnel or the local person managing would have crappy hours.
There’s a right way to do this and a wrong way to do this.
More than a decade ago I started out as a developer on an offshore team for a US based product startup. We grew from 2 people to 19 people and the US based company did well in its market and got acquired in a successful exit a few years later.
There are numerous success stories like this for every engagement gone wrong.
Now days I run an India based offshore team from Europe. The cost model has changed dramatically over time, but the premise that you can ship quality code with an India team is very much viable. Every large tech company does it. I’m happy to chat offline if you want.
I've hired a lot of remote developers over the years and it has pretty much been a flop 2 / 3rds of the time. I had some reasonably good success with Columbian developers a few years back, but the two most outstanding devs I hired on a remote basis were based out of Utah and Connecticut.
I hired one a few months ago from Ukraine who absolutely blew the competition away when it came to the coding test, but then failed to actually put in the work hours when he started the job.
Any advice for interviewing / hiring remote devs that don't suck?
I think the engagement model is equally if not more important than the recruiting. Tie their growth into yours. The startup I mentioned above gave the India team stock options.
I’ve heard and read so many “here is how my offshoring went wrong” (or even just outsourcing locally), that I am really looking for successful examples and what one can learn from them.
I'm currently working with two developers off-shore (through Upwork). I've used off-shore in the past for small jobs, basically to MVP a feature or so.
For example, I currently have someone building a small raspberry pi program that takes RFID input, and posts the ID and date to our API. I want to demo this to some clients and if it's well received, we'll build it out fully.
I think offshore can be great for small projects like this, I have no experience with larger, longer off shore projects.
I work as offshore / remote consultant with entrepreneurs and small-medium sized companies in the US. Some of these clients are working with me since 5-6 years.
You're not a good example though. You can definitely build a successful relationship with a single dev in India. An easy route is to start on upwork, pay well, churn a bunch of people until you meet someone good, then hire them. The complexity comes when you need a team of people to build more than one person can do.
Building remote teams is tough, agreed. But it can be achieved. Off-shore does not / should not mean cheap labor in some obscure part of the world. There are plenty of examples of companies thriving with remote teams, such as:
I would say there aren't so many examples of companies with heavily remote workforces thriving. As a founder, this was the subject of a lot of internal debate. I largely came to the same conclusion as a lot of companies: remote slows down execution, and execution is probably the single most important thing for a small company.
Also, this article discussed something different than building a remote team, and more in line with what most customers want: hire a mostly pre-made remote team all at once. The desired advantage is less cost savings and more speed. Building a remote team yourself is much more likely to work, but also probably slow enough that it's not worth it. You have to find a remote teach lead + hiring manager, work with him or her enough to trust him or her, and then empower that person to run hiring cycles.
We had it work, but out tech lead was onshore, would have daily standups, and would review all there code.
The biggest problem we had is that when they had a problem, such as access or a backend system not working, they would not tell us until the standup. They would not email us so we could start working on it 5 hours before the standup.
I don't think it matters where people are as long as there isn't some hindrance to their work ethic or shady work schemes going on. You simply have to be due diligent AND be a tech lead at the same time. You cannot offshore that part. No way. Instead, you directly know each person working on the project and directly work with them, while providing guidance to the entire team. (Directly meaning on Slack since its offshore) For example, a coder puts out something sub optimal. You then correct that code, then go through this with your coder in a constructive way why this way is better and more efficient, while also noting to the group here is an example of X where you do Y. I make repos specifically for projects to refer to as example code scenarios that commonly crop up. For example, here's how you do a background image on a flexbox that auto sizes itself or here's how you destructure a promise.all easily, or here's a baseline project to start from with basic bones and structure to work from. You have to really guide and lead and there is no easy button where more time spent is the trade off of the cost savings.
In India hiring decisions, on any level, are mostly based on which college one comes from, how many random buzzwords one can speak, and not based on the actual skills one has learned during college or picked up at work. People 'learn' things by reading nuggets from interview prep sites, they memorize things and repeat like a tape-recorder during interviews. No wonder their 'understanding' is non existent.
At one end of the spectrum are people who come from 'premier' colleges (term invented by HR folks, I guess), like the IITs and NITs. Although these institutes produce some brilliant minds, the majority of graduates have no skills whatsoever. Most of the skilled ones go abroad while the'unskilled' ones get hired in India. So it's not uncommon to come across people, who have fancy titles, get paid insane salaries (by Indian standards) and who have been selected through 'rigorous' technical interviews to fumble when writing a simple application program.
At the other end of the spectrum is a huge number of people graduating from private colleges. The quality of teaching and learning at these colleges is abysmal. Most of them end up at one or other 'IT giants' doing menial maintenance work and earning a pittance.
The salary varies a lot across the spectrum but the quality of work is equally bad. Their approach to programming, and problem solving in general, is trial-and-error combined with some Googling. As the author points out the code that is produced by these 'engineers' and 'programmers' is compiler-ready not production-ready.
Of course there are exceptions too. A small minority of people who stay back in India working for startups or as freelancers are amazing at what they do irrespective of which college they went to or how they learned to program.
When you're sampling from this pool, your hiring process has to be ingenious or you end up with insurmountable technical and financial debt.
Another approach would be to start with one developer living in europe/US already but wants to live in India. Example: I have an Indian friend who was working in Seattle but ultimately wanted to go back to India. He found a job where he started at the headquarters on the east coast for a few months then moved to India to build a team there.
The key thing is patience on these projects and paying people well. FWIW I'm impatient and when I had a similar discussion with management as in the blogpost I openly said it was a bad idea and found myself laid off months later. The company eventually had changes in upper management and closed it's India design center.
A plug and play never works when it comes to scaling engineering function through not just india but anywhere.
One must invest from a long term standpoint. Offshoring isn't a shortcut to scaling, its better from cost perspective.
Its best to first get someone on the team who knows local ecosystem(offshore) and is good fit from your culture standpoint. Its a harder process but once you get this right you are most likely to succeed.
I kinda blame the dotcom boom for this. Everyone lamented the bad habits developers learned but from my perspective it was the managers who picked up the worst tricks. As a manager you can make any lie work for about 18 months. After that the devs know if you’re full of shit and by the two year mark you have to find a new group of developers to feed your lines to.
You aren’t building a product. You’re building a team that knows how to build that product. If you don’t then version 3 won’t ever happen. If you do it poorly enough version 2 will not happen.
And once you’ve taken that risk of making a new product, why wouldn’t you want a version 2 or 3? Isn’t that where all the money is?
I'm from SF. Living in Saigon now for almost 2 years. Lots of people reach out to me to 'offshore' here because they hear that VN devs are pretty good and salaries are a fraction of the Bay Area.
What I've learned is that Vietnamese developers are generally smart and hard working. There is a lot of young hipster attitude. They don't suffer from some of the same cultural issues I've seen in other countries. They have their whole own baggage here. ;-) They really love the latest technologies and strive to keep up to date on things. At the end of the day, it is quite hit or miss, but that could really be said anywhere.
In the past, I've never really been a huge fan of offshoring, but with the right company, I've seen it work here on several occasions now. If you're willing to pay a bit more (but still way less than the bay area) for the better dev houses here, you can really get some quality work done.
Off-shoring is hard. But it can be done right. It requires honest intentions and a commitment of enough financial resources. If a firm is off-shoring simply to get the cheapest devs, its not going to work.
One of the first companies I worked at had an India office even though the company was pretty small (~50 engineers in total). The Director of the India office was good at recruiting good engineers and they were paid much above market rates for the city they were based in (still less than what US based developers were making). This situation worked out best for everyone. The only problem was when scheduling long face to face meetings, which had to be done either super early or later in the night. But I felt it was a small price to pay to get to recruit a lot of good talent.
Do the Indian developers get "cross-cultural training" in how to deal with Americans, Germans, or other people from 'hiring' countries, or is it assumed that only the Europeans and Americans have the aptitude to accommodate unfamiliar cultural expectations?
I am sure they do, it is very common to have cross-cultural training. Go back 30-40 years and the Japanese and Korean professionals were getting cross-cultural training to work with US teams.
Most MBA programs also include this kind of thing regardless of what country you get your MBA in.
Of course you get a lot of generalities like:
- Americans like fast decisions
- Americans would rather fix a wrong fast decision after the fact than wait to make the decision
- Europeans generally prefer analysis and deliberate decisions
The punchline: "It cost us nearly a million Euros to get both applications to a state that was acceptable to our customer. That did not include the actual personnel, coaching and travel costs."
Was asked to give an estimate on a project that was offshored and I was amazed at a.) how few commits the developers did over several months b.) how little the person who hired the offshore developers was monitoring them. It's just so trivial to just check progress once a day, I like to commit to a development branch at least every day because I am paranoid about losing progress or experiments that I can reference even if I decide on something better later.
Because there are no junior developer jobs advertised.
That’s almost not sarcastic. Realistically though there is a lot ambiguity over what defines a senior dev. If postings said 10-15 years experience or experience in building stable and complex architecture across the whole lifecycle...or something similar...that would clarify things.
It's very confusing honestly. If I wanted to apply for a job right now I've got 1 year professional iOS development experience and 2 years Android... So I don't really feel like a senior Android developer at all but junior positions are incredibly scarce.
Most places I've seen are asking for a lot more experience or just saying senior with "deep knowledge of Android framework"... Whatever that is supposed to mean.
Like are you asking me to know the exact implementation of the stock ArrayAdapter for ListView so that I can tell you why we'd need a custom one or are you looking for someone to debug Dalvik/kernal issues?
Like I can architecture good clean code (and have done so for personal projects as well as professional) but I still feel junior because it feels like junior should until be 4+ years of experience.
>Like are you asking me to know the exact implementation of the stock ArrayAdapter for ListView so that I can tell you why we'd need a custom one or are you looking for someone to debug Dalvik/kernal issues?
In my experience, both. They will hire for someone who knows every detail of one field, and once you're hired, put you to work on a 5-year-old bug queue for a technology you know nothing about.
I find it important to have a off shore managerial team fully responsible for the project in the same manner as the home office. You can't just hire the off shore team and tell the home office engineers to make use of them. Also the project should be divided so that there is minimal need for daily communications between the teams.
Yes, you need someone onshore to inspect every bit of work. Offshoring can be done if you expect it. You don't just give them a project to work on an check in when it is done, or once a week.
We would have standups every day, and tech leads in our country. They would explain the work needed, make sure they were on task, and check there work.
Sometimes its about ... everything. Time difference * culture difference * tool availability * hierarchy * quality expectations. If they are all 90%, you still end up at under 50% of the expected result.
Interesting read. I would like to read something written from the perspective of the team in India that maybe explains some of their impression of the companies they are working for.
You pay peanuts you get monkeys !!! If you want to outsource for cost then good luck with that, but if you want to do it for skill then you have options. There are really good shops who provide amazing service.These companies hire from the right schools and provide great training . Too much generalisation and lack of information in the article.
Indian engineers in India are like animals in a zoo. Indian engineers outside India are like animals in a forest. They thrive and shine because they are free. It's all in the environment. The only way to add "offshore" teams safely is to find people who refuse to accept a code review comment because that's not the right thing to do, no matter which part of the world they are in.
>Indian engineers in India are like animals in a zoo. Indian engineers outside India are like animals in a forest. They thrive and shine because they are free. It's all in the environment.
These kind of generalizations are useless. There are "zoo animals" and "forest animals" all over the world regardless of location.
I have seen many people who bash India and Indian engineers for low quality work, but lets get to the crux of the problem. Its not that Indian engineers are all bad. They come in all shapes and sizes. You will get the best ones if you pay enough. You pay cheap, you get cheap.
Where can you get cheap ones ? From those big IT companies who treats employees as resources. The employees in turn will also treat their jobs along those lines.
So if you need high quality work, please don't go to these giant corporations. If you look hard enough, you will find small high quality places, but they are not cheap and not 'scalable' like your manager wants them to be.