Time differences

For starters, let’s say you’re in San Francisco and your work hours are 9~5. There is a 12.5 hour difference between you and your developer if you were to outsource. This is ignoring the fact that many freelance workers can work obscure hours, including myself. However, more often than not, you will find that nearly all of your communication with an outsourced developer will be via asynchronous communication, which can be extremely problematic when tackling projects of higher complexity. It also means that any urgent issues will take at least 24 hours to resolve (if you’re asleep and your SaaS comes back online, it’s not completely the same as you seeing it come online and getting a chance to make sure everything is in order).

Cultural differences

Before I continue, I’d like to point out that I have worked with freelancers in India and China both directly (hired by myself), and indirectly (hired by my clients). Not everyone is aware that there are significant cultural differences between North America and India. One of the most notable ones I like to use as an example is that developers in India tend to be “yes (wo)men”.

There are many times where project requirements can be vague, the developer may be having issues, but these things will not be clarified/communicated with the client. Throughout the project, you will often get the impression that everything is sailing smoothly, and it won’t be until the project is coming to a wrap, or when you get a demo of the project at regular intervals (you should be asking for this) that find you out a lot of things may not have turned out as you expected/imagined. Of course this varies from person to person and happens in North America too, and I’m not sure why this seems to be more prevalent in freelancers from India. Perhaps it’s because they consider asking questions and bringing up technical challenges a sign of incompetence.

Communication challenges

This is actually not as big of an issue if you can find a developer with a good grasp of the English language. Though most freelancers in India are knowledgeable of English to some degree, more often than not, the challenges with communication begin to surface as you get into more detailed parts of the project. This, combined with the 2 points above, make it very difficult to move a project along and adapt to changes smoothly/efficiently.

Maintenance and code quality

Okay, this one is highly subjective and really happens within North America too. Often times, you will find that the code delivered by an outsourced developer works. Maybe you find a few bugs, and they get fixed. Great, right? The challenge is not actually getting everything to work. A huge issue that clients don’t consider when choosing to outsource is code maintainability. You might say, “I don’t understand code, and I don’t write code, so why should I care?”. Really, you should care a lot. Many times, instead of working with the client through technical challenges and pointing out that the deadline may be too rushed, outsourced developers will come up with “hacks”, and many of these combined end up making the product extremely brittle and prone to breakage. Breakage aside, any developer who has to work on this product further down the line will have to battle themselves whether to retroactively clean up those “hacks” and risk breaking things that appear to be working, or just building on top of the technical debt that has already been accrued. As the technical debt builds up, you will find changes taking more time, and (seemingly randomly) breaking other unrelated parts of the product. A quick hack can cause many headaches and become very expensive in the (near) future.

Cost

By and far the number one reason to justify outsourcing overseas is the cost savings. Many small business owners who are not technical and have not had prior experience outsourcing projects overseas are not aware of the risks and headaches that come with outsourcing. It’s not uncommon to have someone contact you about estimating a project and having them scoff at your rate then talk about how they can hire someone in India for $5 an hour (to be fair, these kind of clients are on my never-ever list too). And to get a good developer in India, even $5 is too low.

However, as mentioned in one of my previous posts, the math doesn’t usually work out the same way you’d expect it to. On one hand, the developer from India might quote you 700 hours at $5, which ends up at $3500. Someone local may charge you $150 an hour, but only bills 30 hours, which ends up only being $1000 more than the alternative. This is a bit of an extreme example, but it also disregards the savings from avoiding the issues related to outsourcing overseas. This discrepancy in hours billed may be caused by a different skill level, or they may simply be billing dishonestly (which can occur anywhere). Hourly rate is not a good indicator of value provided. This is the reason why some of my clients are charged based on blocks of time (think day/week basis). In fact, the working relationship between client and freelancer is also incredibly important. Someone who has worked with your company for an extended period of time likely has a better understanding of your business and is able to provide solutions that are tailored specifically towards your business needs. From personal experience, there have been times where I would propose a different solution, one that would make me less money, but would ultimately be a better choice for the client.

Okay, but when should I outsource overseas?

As someone working mostly in North America, my opinion is definitely biased. But while I have seen first hand the many issues that come up with hiring someone overseas, I do believe there are instances where it can make sense for your business. Projects that are smaller in scale and more isolated from the critical parts of your business, which have clear requirements specifications, may be a good choice for overseas labor from a cost perspective. The issues listed above may still apply, but having a smaller project, along with clear requirements specifications will go a long way towards helping mitigate/lessen the impact of the those issues. Depending on your budget, it may be your only option.

The post Outsourcing overseas first appeared on Jay Huang.

There were a few listings on their website, so I applied to a “Web Development Engineer” posting for Vancouver as I felt it was the best match for my skills and experience. I wasn’t actively looking for a job at that point, so I didn’t think much of it and pretty soon, forgot I had even applied. Then, out of the blue, I was contacted by one of Amazon’s recruiters on May 24th 2013 for an interview on the 29th. I seriously considered declining it as I had just moved to my new job for a month, and was certainly not looking to leave (yet).

As many people know, I absolutely hate speaking on the phone. First of all, I’m more of a listener, and when I’m speaking with a stranger for the first time on the phone, that comes across as unenthusiastic or uninterested. Secondly, it forces me to context switch and break my mental train of thought. Whether or not it’s pre-scheduled does not matter; I’m forced to abruptly pause my work and move my attention to something else. As a freelancer, I have the option to cut myself off from virtually any environmental disruptions, and prefer to allocate small time blocks to update or communicate with people/clients. Third and most importantly, it’s synchronous communication. When I have to pick up the phone and speak to someone, not only am I making an expensive context switch, I have to be wary of tone, wording, and other things that cause the other party to misunderstand me. Aside from that, I’m unable to give any issues more in-depth and careful thought, which really defeats the whole purpose of discussing them. But in those recent months I had been looking to make a conscious effort to expose myself to more social/human interaction, so I decided I would give it a try. I had nothing to lose anyways; I was working on stuff I enjoyed and this phone call would have no effect on me other than cause a bit more nervousness.

Phone interview:

I took the morning off (and made it up later) to do the phone interview. When I picked up the phone the interviewer introduced himself as a Web Development Engineer from Seattle. Immediately I noticed the Indian accent and became nervous because I realized I already had trouble understanding him. He thanked me profusely for taking the interview (literally 5~6 thank yous), which was quite unexpected but also helped relieve some of my anxiety. Nevertheless, we proceeded with the interview. We went on collabedit and he tested my understanding of some of the key features of Javascript, the design and implementation of a type of web component, a bit about HTTP and servers, understanding and application of CSS, and an algorithmic implementation question.

The hiring team has really enjoyed speaking with you and we would like to schedule a time for you to come to Amazon for in-person interviews!

Although I was able to answer all the questions, I was second guessing myself because I felt that I must have misunderstood something between the foreign accent and the poor phone connection. I thought that was the end of it and wrote it off as a nice experience. Then on June 11th, I got an email from a different recruiter saying that they would like me to go in for on-site interviews. Weird, I thought — almost everyone who I knew that interviewed with Amazon went through 2 or more phone interviews before going on-site. I’m certainly not going to complain about having less hurdles to jump through. Upon reading the email more closely, I realize they want me to fly down to Seattle for the interviews. I was perplexed; I thought the position was in Vancouver? It was, they said. But they still wanted me to fly down.

Paid flight, travel, food, and lodging? Okay I guess I’ll take a vacation day and head down. Better not forget my passport! Oh, passport…let me take a quick look. My passport was about to expire in 3 days. I quickly let the recruiter know and started the passport renewal process. After a long 3 weeks, I finally got my new passport. We scheduled the on-site for Monday, July 8th, arriving Sunday around noon.

Sunday comes around and I’ve arrived in Seattle. I didn’t have time to prepare for any of these interviews because of my full-time job, my freelance work, and attending night school. I decided I would walk around and figure out how to walk to the building (they have 7 in the area), and just roam a bit. Returning to the hotel, I headed to sleep early so I would be well rested. Unfortunately, I got no sleep that night. Something about the nice hotel bed or the fact that I was not doing my usual late-night freelance work made me restless.

Interview #1:

My first interview was at 10:15am and a 20 minute walk from the hotel (note that Amazon pays for your interview transportation expenses, which includes your flight + taxi to the interview should you need it). I headed out at 9:35 and arrived 20 minutes early to check-in, sign the non-disclosure form (which means I will not be sharing interview questions in this post; just a broad overview), and sit there to calm my nerves. I wasn’t nervous so much about the prospect of getting an offer or not as much as I was about sitting in a small room with a stranger and writing code on a giant whiteboard. There was a sudden change of the first interviewer, so it took him some time to come get me. Immediately upon sitting down, I was presented with a problem that was an integral part of Amazon’s marketplace websites. It was an algorithmic problem that the team had run into and solved, and on the front-end. I wrote the algorithm in Javascript.

Interview #2:

The next interviewer came to pick me up and go to lunch. He introduced himself as a developer on the team, but was acting temporarily as the manager because the previous one left recently. I didn’t have a specific preference in mind, so he took me to a small local sandwich shop where I ordered chicken ciabatta and he paid with a company credit card. He asked if I was interviewing for a position in Seattle, and seemed confused why I was flown down to Seattle when the position was for Vancouver. I was asked a lot of questions about my previous technical experience, technical challenges I faced, asked me to elaborate on some of the more interesting architectural solutions I’ve implemented and discussed trade-offs between other solutions. We had a pretty good discussion, but responding to his questions left little time to finish lunch, so he gave me the last 10 minutes to eat while he answered a few of my questions.

Interview #3:

This interview did not involve writing code. The interviewer was the manager of a major team within Amazon. He gave me an algorithmic question (also very relevant to Amazon), and I came up with a solution fairly quickly, but he noticed I was still deep in thought. I explained that it was the best solution I could come up with, but I was wondering if there could be a better way to do it. We ran over some of the details together, discussed potential trade-offs in a different algorithm, and decided my solution could not be any more efficient. I was also asked a behavioral question specific to Amazon’s business and core values.

Interview #4:

For this interview I had two interviewers; one of them was shadowing as he was fairly new to the company. They tested my understanding how browsers handled various things in HTML/CSS, then gave me a screenshot of a new release about to be pushed live, and asked me to write the HTML/CSS for the whole page.

Interview #5:

Here I ran into my interviewer from the phone interview. He asked me to explain the differences between two implementations in Javascript, and use cases of each one. I also wrote HTML/CSS/JS for a webpage component, with a focus on modular code. He then tested my low level understanding of how browsers handled the DOM, and I had to implement that from scratch. I was pretty tired at this point, and had some problems understanding his accent, but I think I did okay.

Interview #6:

When I send you the offer on Wednesday…

The last interview was with the lead recruiter from Vancouver (apparently he flew from Vancouver to Seattle to interview me, a candidate that was in Vancouver and had to fly to Seattle for the interviews…). He asked if I was tired after such a long day, and then counted 7 interviews. I only remember 6, but he had the official list so I guess it’s 7. Maybe he was talking about interviewers. He mentioned I had received great feedback and that they were excited to move forward. He then spent the remaining 35~40 minutes drawing on the whiteboard the compensation details of the position, including the signing bonus(es), equity options, performance bonus, how I could choose between more options or cash for the bonus, the benefits of choosing one over the other, the base salary, etc. He said “when I send you the offer on Wednesday, you will see _______” on a couple occasions. Then he walked out with me and explained that the team in Vancouver was very diverse and full of cool people, how it was much like a startup, and that I would love it. He then said “once you accept the offer, we will fly you back down around 3 weeks later to do the training here, because the Vancouver offices are still quite small and we don’t have many hires that week”.

After not hearing back from him, I emailed him to follow up. I didn’t hear back so I emailed him another two times, with no response. It’s been months and he has yet to reply to me either with an offer, or a rejection letter. I guess it didn’t work out after all.

Aside from the lack of response from the lead recruiter and the weird logistics of sending me to Seattle to interview for a position in Vancouver and having all the interviewers puzzled, the interviews were pretty interesting. Each interview during the on-site tested a specific skill/topic required for one to be successful in the position, ensuring that there are no glaring gaps in knowledge. I would say it was one of the best interviews I’ve done for a front-end position in terms of getting a full picture of the candidate’s knowledge and experience.

Edit: I’ve received some questions regarding reimbursement; Amazon does provide reimbursement for travel and other expenses. You are assigned a daily budget for each category (food, transit, etc), and are asked to keep the receipts and send them in as long as they were for the purpose of interviewing (not for your personal leisure). They also paid for my hotel, but did not pay for damage deposit. Your situation may differ but it’s good to keep that in mind should you be asked to pay before getting your room.

I received a cheque covering all receipts I sent in (I forgot most of the food receipts) after about 6~8 weeks. Rental car wasn’t offered, but taxi receipts were reimbursed, up to the daily limit as well.

Join the discussion on HN: https://news.ycombinator.com/item?id=7040382

The post My Amazon interview experience first appeared on Jay Huang.

I decided to give it a try and just push anything onto my GitHub account. But soon the realization that I will never be able to showcase any of my biggest accomplishments on GitHub settled in and my curiosity and eagerness to break things took over.

Let’s backtrack a bit. Due to our financial situation, I never really had any toys as a kid. I have fond memories of assigning myself the impossible task of persuading my mother to buy me one of the huge bouncy balls at Superstore. For years. In the end, mom won; Superstore no longer sold the bouncy balls, so I would be unable to beg any further. Then, one day, a family friend came to our place and brought me a little mechanical dog that would bark and spin in circles. It was probably more expensive than any toys that I had up to that point combined. It didn’t matter, it was only a few months past my 4th birthday, I did not yet possess a firm understanding of money, and I was intrigued. I raced into the bedroom and immediately began systematically tearing the dog apart — screws, rotator, gears, plastic bands, batteries, etc. Once I had figured out how everything was working together to create this dark magic and it was time to put the dog back together, I never bothered to. A couple years later when I would finally get my first computer and learn how to create websites, I quickly moved on to learning how to break them. I always had an eagerness to break things, but I digress.

I didn’t try to break anything, but I had discovered a peculiarity. I was able to push code to GitHub as Linus Torvalds, the creator of Git (or you may know of him from something called Linux…). While I was using my own SSH key to push to a repository that only I was allowed to push to, GitHub showed ‘me’ as ‘Linus’, effectively making one of the most highly respected programmers in the world a contributor to my project. (Yay!)

Here is one such commit:

What’s more, clicking on the author of that commit takes you to Linus’ GitHub profile, where he is a frequent contributor to the Linux kernel source tree.

Note: This has been accomplished without compromising anyone else’s GitHub account. Read on for the details.

All I had done was setup git with my SSH key for Github, then changed my git user.email to the same email that is being linked to Linus’ account: torvalds@linux-foundation.org (note that this is publicly available).

It seems after I have already authenticated myself against GitHub, it just tries to grab whichever user is associated with the email I’m using in commits, and voila!

It’s occurred to me that many people already know about this, and was probably by design on GitHub’s end. Nevertheless, although it did not contribute to the compromise of any accounts, and did not open up any unintended privileges, I thought the behavior was incredibly misleading and disruptive. Any user in the world is effectively able to push commits (to repositories that they already have permission to contribute to), as any other user, potentially using the reputation of someone like Linus to cause mischief and malice. So I decided to report it as a bug to GitHub anyways.

They got back to me 4 days later, on October 17th, and explained it was in fact, by design as I had suspected.

Hi Jay,

Thanks for getting in touch.

It’s important to note that this is not a security concern or a bug – impersonating another GitHub user in this fashion doesn’t grant you access to any of their repositories or give you any privileges you didn’t already have.

Rather, this is a feature of GitHub that can be abused. We take abuse very seriously. If someone is wrongfully impersonating you, please let us know and we will remove the impersonated commits and deal with them as quickly as we can.

Over the past several years, millions of people have used this feature to collaborate with colleagues and strangers successfully. Yet rarely, if ever, has anyone used it to abuse another user. Usually, we find that people impersonate others by creating a fake account with a similar username and your avatar, then they leave offensive comments on issues.

The sad truth is impersonation is rampant on the internet and removing legitimate features won’t stop an individual with malicious intent.

Rather than make this feature less useful for everyone who uses it responsibly, we strive to make GitHub a fun and safe environment by swiftly dealing with bullies and giving you ways to ignore them.

If you are still concerned about this, your team can choose to use Git’s built in options to sign with a GPG key. If you are concerned about having a verifiable identity on your commits, you should check into the `git commit -S` command.

Hope that helps.

Cheers,
Petros

Well it’s certainly their decision whether or not this is a “feature”, but I do feel it’s quite misleading. Sure the internet is rampant with people creating fake accounts with a similar username and avatar in an attempt to impersonate, but in this case, the impersonator has the help of GitHub. Exact same username, exact same avatar, even exact same profile link. The commit doesn’t seem to show up on the “victim’s” commit activity, but it’s certainly real enough. Rather than getting reports of this behavior and then removing commits and “dealing with” the user, perhaps this feature should be better refined to reduce this support overhead and chaos.

I understand this feature has the benefits of allowing people to push commits with emails they don’t own, such as ‘example@example.com’ that I occasionally use, but having your commits attributed to a different user is a whole different issue.

It may be a nice feature, but it’s also quite the design flaw.

Join the discussion on HN: https://news.ycombinator.com/item?id=6918343

The post Pushing code to GitHub as Linus Torvalds first appeared on Jay Huang.