Category Archives: Coding

Outsourcing overseas

I find this is a question that comes up very quickly to business owners looking to hire a developer/freelancer. Why would you hire a developer from North America when you can outsource to someone in India or China? I briefly touched upon this in a previous post about things you should know about freelancing, and I will explain this a bit more in detail based on my experiences.

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”.

Continue reading

My Amazon interview experience

It all started back when I was still working at SAP. A few colleagues mentioned Amazon was opening up another office in Yaletown. I believe it was in January 2013 or so. I wasn’t very interested at first, but after hearing about it a couple times, I gave it some more thought and decided it wouldn’t hurt. I was going to leave SAP at the end of April, and if Amazon turned out to be a good fit, I just might go there. This was before I interviewed and got offers for Palo Alto, one other company, and the company I worked for from May to July.

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. Continue reading

Pushing code to GitHub as Linus Torvalds

I had no idea what I was doing. It was my first time using GitHub. I had an account for a while but didn’t have any code to open source. All of my freelance work is bound by NDA, as is the work I’ve done at my 2 previous full-time positions.

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