Hacker News Reader

Your interview experience depends a lot on the recruiter that's working with you. And this applies to all companies. Although I didn't get an offer from them, my experience interviewing at Uber was extremely pleasant and I made sure to connect with the recruiter, now at another co., on LinkedIn. I told myself that I'd hire that recruiter if/whenever I started my own company. After passing the phone screen, I still remember that the recruiter working with me called me back within 10 mins after I hung up with the interviewer and got me an onsite scheduled immediately on the spot. I didn't hear back about the offer for a few days after my onsite interview, but I was able to get someone to call me up and deliver the bad news immediately after I pinged the recruiter.

But the key here is first impression. It applies to you the same as it applies to them. Be it Google or FB or anyone else...these companies are nothing special.They create an illusion of an elitist club but in reality it's the same old bureaucracy / corporate bshit that awaits you anywhere else.

Why should I bother and be religious about the company If I do not even know what I am getting my self into.

First impression is for marriage not for work. Most of the best coworkers I have ever had gave me a very bad first impression... Uber sucks for a lot of other reasons other than there is some creepy guy who can't handle relations with women or their recruiters are not people I would choose as bff.

Yeah sure but if the recruiter / hr acts like you are piece of meat and would become a mere grunt to keep the machinery running what should you do ? I mean you are either desperate and badly want to work for the company but why pretend ?

It's not like in this era people stick to one company working there for a lifetime.

> It's not like in this era people stick to one company working there for a lifetime.

Agree.

Since HR is far from a typical tech company's core competencies, they often don't focus on it and don't realize the damage these employees can do, both by turning off potential hires, and by pissing off employees. You could argue that you would not want to work for anyone dumb enough to let clowns run their HR, and I wouldn't fault you, but you might miss some otherwise good opportunities this way. I have had at least a couple of experiences where HR was not in any way indicative of the quality of the company and colleagues, except for the fact that they were too busy to put much effort into it.

Until we get completely AI run companies like in Accelerando, hiring needs to be one of every companies core competencies. A company can't do anything without having employees.

In a great organization it will not depend on the individual recruiter because the organization as such makes sure that candidates are handled well. Same for management or other traits of an organization.

> And they have over 1000 microservices. And its normally to rewrite them often.

> To me that seems like a bad architecture.

I don't know, the part about it being "normal to rewrite them often" is worrying, but having fleets of microservices managed like Erlang processes or supervision trees sounds interesting and possibly pretty good — assuming that's how they're architected, I've no idea about that. And rewriting a service might be less of an issue if each service is just a small processing loop.

The idea about microservices is that they are small and self-contained. This makes them easy to rewrite completely. Now I wouldn't say it is the goal to rewrite them all the time, but it is not a bad sign if some of them get rewritten occasionally. Microservices are somewhat new and a lot of architecture and infrastructure is being built around it. Companies like Netflix and Uber take the lead in this. Susan Fowler wrote a book about this during her time at Uber, you can find it here:

http://shop.oreilly.com/product/0636920053675.do

I've been programming a while now and it definitely is a bad sign if you're rewriting any code often.

Firstly, it takes a lot longer than just making the necessary change. It's a waste of time.

But more fundamentally, I can understand getting it wrong the first time. Throwing what should have been a prototype up without rewriting it. Whatever.

But how the hell did you get it so wrong the 2nd time? And the third time? And the 4th, etc., etc.

Now I'm not afraid to do refactors, massive ones if needed. But there's a big cost to doing it. The big problem with constantly rewriting stuff is that you almost always introduce new bugs. Or you misunderstand the reason behind some of the edge cases and cut them out.

Sounds like the actual problem here is classic NIH syndrome with new programmers coming in, not liking the old programmer's style and rewriting the whole thing.

Part of the appeal and one of the advantages a microservice architecture gives you is that you no longer have to do massive refactors. The services should be small, focused and easy to reason about. Part of me likes the idea of never having to deal with legacy code written 10 years ago in Java 6. Constant rewrites of the same microservice might raise a flag due to unnecessary churn, but I welcome this new era of "immutable" code.

Not trying to sound like a wise guy, but I can see another option: the state of the system is in flux, constantly trying to improve, finding new ways to do it, using new and updated technologies etc.

On top of that, microservices are supposed to be self-contained, but they do depend on each other to some degree.

>They where looking for people who really want to work at Uber

Unless they were looking specifically for you (TeeWEE) and not a random search on LinkedIn, it is very elitist of them to expect that. I cannot understand how so many companies and interviewers fail to realize that interviews are not a one way street. Interviewees should also be evaluating the company for a fit as much as the interviewer does.

People who "really want to work at Uber" are easier to take advantage of. They will work for being able to say they work in cool company and will be willing to take lower salary and worst working conditions. (Being woken up often to quick fix broken things screams disorder and broken process. Being asked to do 80 hours of work in 40 hours time screams incompetent tech management.)

IMO, all the jobs you are supposed to do out of passion tend to be like that (hello game development).

> Being woken up often to quick fix broken things screams disorder and broken process.

Why? Things break. Critical things act up. You patch it up and work towards automating the fix or fixing the problem during business hours. Maybe you are focusing on the "often" part? Depending on the stack you work with, I think often has a different meaning.

I have never met anybody who really wanted to work for Uber. There are some companies that people really want to work for, example Google, Facebook etc depending on interests, but even then, it is usually not just the company but the pay, nature of work. perks etc. Most people enjoy interesting/boring work irrespective of the company. A person willing to work 80 hours at Uber will probably work 80 hours elsewhere too.

> I told them I was also interviewing at other companies, to see what was available. They told me this was not "the people they where looking for". And it wouldn't be "OK" to say something like that in America.

In case you're not aware, it's totally normal to say that in America, particularly if you're a recent graduate. Your recruiter will need to know if you're expecting another offer or something like that, as competing offers can affect your schedule and compensation.

> An old colleague of mine is working at Uber, and he says the working times are flexible, but more than 40 hours per week. And they have over 1000 microservices. And its normal to rewrite them often. To me that seems like a bad architecture.

Maybe... probably. Red flag is "more than 40 hours".

and yeah, I too have decided I have no time for companies who screw around during the recruiting process.

> not "the people they where looking for". > asking if they where going to check..

I think you're confused with the meanings of were and where. Were - plural of was Where - denoting a place. As in - where was this?

I hope you take my comment in positive light. Not trying to be snarky. English is my second language and I appreciate being corrected when I make a mistake so I can learn.

They actually got you to build a linked list from scratch? That's somewhat hilarious, considering you can get a book within 10 minutes that'll show you how to do it, not to mention unless you're a terrible programmer who reinvents the wheel and doesn't know how to google, that situation isn't realistic at all.

Nearly every interview is not realistic at all. At least it's better than whiteboarding.

Fair point, but I'd at least expect an original assignment to be submitted later that isn't like in thousands of data structure programming book out there. Well, maybe expect isn't the right word, but I'd never run my interviews with such trivial requests that don't reflect what the actual work will be (hopefully they aren't writing LLs from scratch, anyway).

Do you have an example what would you ask on an interview ? I am just curious.

Sure. If it's say a web application, I'd invite them to install the framework(s) / libs used and to implement a basic feature that could actually be used in an application they'd be working on. Nothing super complicated, but something that wasn't "reinvent the wheel that's googled easily". I'm not aware of many major programming languages these days that are missing linked lists or similar data structs.

I'd also pay them for their time, regardless if they got the job.

The best interviews are those that make an attempt to be realistic rather than assuming correlation between ability and knowledge of some of the more rarely used textbook knowledge.

Think of it as a slightly less insulting form of FizzBuzz.

I regularily used a similar exercise to weed out bad candidates. The task was to build a stack with based on a double linked. Looking up stuff was okay, but straight copy paste was not. I gave them half a day and told them to write the best code they can.

There where many discussions how that exercise is relevant to the junior PHP dev position we were hiring for (spoiler: it's not). But it gives you a good idea what the candidate considers good code (consistent code style, documentation, tests,...)

I'm curious about the stats (if you have them): how many of the candidates added documentation ? because one could argue that documentation by itself is not DRY since now you have both the code and the description of the code (the docs). if the code changes - you MUST change the docs as well (otherwise the docs and the code are not overlapping, which is much worse than not having docs in the first place).

I might be completely wrong about documentation not being DRY, but this by itself could be a good conversation with a candidate .

People complain a lot about basic CS assignments in interviews. Just thinking out loud: it's an important skill to be able to put together libraries and existing code to get a working product. But a lot of software is crap, and I think often one of the contributing factors is a lack of knowledge about data structures, design patterns, algorithms... in other words, the stuff that a CS education might actually teach you about. You can't look something up if you don't know enough to look for it (and to understand the answer) in the first place. So the "irrelevant" basic CS problem interview questions might be a way to check not only if you can build a product, but if you can do it well?

I think the irrelevant CS problems are an okay test to see someone's style and thought process where they shouldn't be too worried about solving the problem (they should have at least a meager basis of understanding to begin with) and can spend time cleaning up, and preparing their thoughts for presentation. I think this is fine as one of multiple measures.

I graduated from CS, and the only reason I knew anything at all about how to handle multi-tier architecture is because I was employed previous to my graduation. How do you keep configuration from being a mess? Hard coded values all over the place, etc. CS courses give you the theory needed for getting started down a path of understanding, but it does not make you understand, nor does it actually prepare you for the real world. Data structures are one thing, micro services, unit testing, configuration management, dependency injection, and persistent storage are beasts all unto themselves.

My interview at other $BIGNAMECO was "fix" an existing Linked-list implementation on site. That was pretty fun, IMHO.

That does sound fun! I think figuring out bugs is a good way to find out if someone knows what they're doing at all. My main objection was "implement a LL from scratch in X language!" -> googled in 5 seconds and slightly modified, done as a work-from-home and hand in assignment.

I'd enjoy a good debugging question for sure.

OK since I'm being down voted for this post, let me clarify: if you read the context which the OP mentions in the blog post, he/she was given a take-home assignment.

I agree, rooting out people who can't do basic things like linked lists is desirable, however, if you're going to send a take home assignment, my point was, you're not going to get a very honest measurement of their capabilities on one that they can google in a few seconds. That's all I meant.

You are a terrible programmer if you can't implement a linked list. It's so basic that not being able to cope with it means you don't understand indirection, which is the fundamental of all programming. Is it a good interview question? Depends on the language: its perfectly valid to ask for a C programming position, but makes little sense for a JavaScript role (as in there are more meaningful problems for assessing their knowledge).