Live data from Hacker News

Employee #1: Amazon

themacro.com

51–60 of 124 posts

Re: Employee #1: Amazon

#51

Earlier quoted context omitted.

Personally I actually wish more liberal use would be made of this strategy. I've worked at a lot of companies where obstructionist employees are kept in their slots due to management's concern over the personal fallout (both for their relationship with the employee and for the employee's relationships with others). It's none of my business whether they stay on payroll or not, and I don't mind at all if they do if tha…

I believe Amazon compensates with equity, so, if you were a co-worker of his, it would be your business if he stayed on payroll.

I think he means it still wouldn't matter to him because someone like the guy interviewed would have obviously already contributed/was there early/etc.

Re: Employee #1: Amazon

#52

Earlier quoted context omitted.

He failed to gain greater power in the organization and accomplish greater tasks after being promoted out of the role in which he was very competent. This implies that he wasn't very good at being a CTO. If he was, he would have had a bigger role in the projects and a larger team with which to accomplish his desired tasks. This may have been intentional as a courtesy rather than accidental due to the Peter Principle,…

Where does an awesome CTO get promoted to? It kind of seems like the end of the road, with the possible exception of CEO, but that position is probably occupied.

Other companies I'd guess.

Re: Employee #1: Amazon

#53

Earlier quoted context omitted.

So true. So, so true. So true that I often question technical interviewing practices that look solely for ability to memorize complex algorithms exactly, vs ability to seek out an even better solution and apply it effectively.

At a previous job I put this in to practice. I would give interviewees a short list of questions on a piece of paper and after the interview they could use a browser and take as much time as they needed to answer the questions. Some were logic type questions that would be difficult to Google, some were just process questions that very few people would know off the top of their head but should be able to Google. The i…

HR should have no input into technical hiring processes. I don't understand the thought process by which they feel they should have this authority.

HR interference was a MASSIVE pet peeve of mine at a previous employer. I eventually was able to strong arm them into forwarding me all resumes directly, but it was a battle.

Re: Employee #1: Amazon

#54
post #25

Earlier quoted context omitted.

http://imgur.com/gallery/SZPjHwz https://twitter.com/thepracticaldev/status/71639058321702912...

So true. So, so true. So true that I often question technical interviewing practices that look solely for ability to memorize complex algorithms exactly, vs ability to seek out an even better solution and apply it effectively.

I recently went through a final-round interview process, and a large piece of the technical part of the interview involved handing me a laptop connected to the internet and the interviewer saying "Build a REST API that can handle these 4 curl requests and respond correctly. Use any technology you want. You have access to Google and anything else you can find. You have about an hour, I'll be back to check on you in 20 minutes. Go!"

I felt like this was SUCH a better test of my abilities as a professional programmer versus remembering specific algorithms or reciting "best practices" for X, Y and Z.

Re: Employee #1: Amazon

#55
> For one reason or another, sorting out architectural issues to scale more gracefully was something I could never convince Jeff to allocate resources to do. There were always too many customer-facing features that needed to be developed.

Some things never change.

Re: Employee #1: Amazon

#56

Earlier quoted context omitted.

People, or at least children, have been running around in parks trying to catch invisible animals for decades. As adults, it has definitely been a positive development for my wife and I.

"it has definitely been a positive development for my wife and I." Seriously? Just curious... what age range are you in?

25 and 26.

Re: Employee #1: Amazon

#57

Craig : How did you troubleshoot? Today I use Stack Overflow constantly. What would you do when you ran into a bug that you couldn’t figure out? Shel : Stay up late. Hahaha. I remember building an online art gallery back in 1996. It was for an internship. I got it because I bluffed and said I knew HTML. After I was hired, I purchased a book on HTML. Turns out, the company's "CTO" did the same thing. We both learned o…

I seem to recall that googling (well alta-vista-ing) bugs in the 1990s was definitely a thing. Always seemed to end up on a usenet group though.

Re: Employee #1: Amazon

#58
post #47

Earlier quoted context omitted.

EB and I both worked at Lucid, which produced a Common Lisp system, not to my knowledge a version of Emacs (though maybe so after I left in 1989?). Some other early employees knew and liked Lisp, but we didn't use it on any core functionality. The text substitution logic you mention, that I wrote, was really simple and not particularly Lisp-like. Though again, after I handed it off, who knows what happened.

Lucid Emacs is now XEmacs. Work would've begun right around 1989, so it's likely you just never crossed paths with it. =)

[deleted]

Re: Employee #1: Amazon

#59
>We were even talking about possibly locating it in Santa Cruz. This was in spring of ‘94. Jeff went back home to New York and started thinking about where he wanted to locate. We were looking at office space in Santa Cruz but as he learned more about mail-order business he eventually decided it made more sense to be in a smaller population state or one that didn’t charge sales tax.

How California lost out on hosting Amazon because of taxes

Re: Employee #1: Amazon

#60
post #25

Earlier quoted context omitted.

http://imgur.com/gallery/SZPjHwz https://twitter.com/thepracticaldev/status/71639058321702912...

So true. So, so true. So true that I often question technical interviewing practices that look solely for ability to memorize complex algorithms exactly, vs ability to seek out an even better solution and apply it effectively.

[deleted]
Post reply on HN