kele

That was the intention of that paragraph.

It's a mix of what you just said, and many more.

But besides that, I work there because I actually believe that the company still does a lot of good. And from what I can tell, most people around me do too.

What's wrong with existing browser extensions like Vimperator or Vimium?

In order to learn something, one does not just invest time, but energy. It's way easier to play than to practice deliberately.

This is just a very catchy phrase.

The percentage of immigrants living in a country is a result of a long term process. I believe that what we are discussing right now is the 'refugee' crisis.

Just to be clear, I'm not saying that Switzerland is unfriendly. I'm saying that it's less friendly than the countries mentioned in the comment. That's because I believe they are too friendly.

Last time I was in Zurich, this is the first thing I've seen at the railway station [1]. This is a very reasonable thing to do for Swiss people and something very different to what is happening in EU during the "refugee" crisis. On the other hand, in the EU it would be considered anti-immigrant or even racist (especially by media).

[1] http://s1.ibtimes.com/sites/www.ibtimes.com/files/styles/lg/...

And yet Switzerland is much less immigration friendly than all the countries you've mentioned.

C++ has lots of issues, most of them due to backward compatibility and versatility. Also, the language is very complex and enormously hard to master. I've used C++ for quite a while and everybody I know who used the language for at least a few years have developed a love&hate relationship for this language, or abandoned it.

The union-find data structure (the idea is so simple and a sophisticated analysis yields a really low upper bound).

RMQ with linear preprocessing and constant time queries (which is also true for multi-dimensional cases, if the dimension is bounded by a constant).

Knuth-Morris-Pratt pattern matching is the first algorithm where I saw the usage of an additional variable in the pseudocode just to simplify the complexity analysis.

The only thing that comes to my mind might be "Discrete Mathematics" by Ross, Wright. This is quite a heavy book and you don't need to go through all of it, but there are some chapters that might be really useful (the one about mathematical induction is probably the most important).

Also, I think I can help you a bit. Send me an e-mail at throwawayt52@gmail.com

When I started learning low level programming, I've studied C and x86 assembly simultaneously. This gave me a somewhat broader perspective.

From my experience with learning Rust, it might be a little hard to grasp both "the low level world" and Rust-specific things at once.

"So Good They Can't Ignore You" by Cal Newport is awesome.

When the codebase is so big and you're hiring so many engineers it might be actually a good idea to have such an extensive style guide.

The big companies never really stop hiring, so there's no point to close a job posting.

I would actually recommend reading "So Good They Can't Ignore You" by Cal first. This book made me comfortable with the idea that deep work is what really matters. And although I understood that very feel, things tend to stick with me when I also feel them.

"Deep work" is more practical. He presents different strategies of working to get more depth. Also, there's a lot about how to stop sabotaging your efforts of working deep.

Actually, "cloning" doesn't sound easy at all. :)

I think that this is interesting question.

It has been already pointed out, that cooking/eating at home is not just a way to provide fuel for your body. There are many other reasons, like: - pure fun - social activity - adjusting the meal to your taste - not having to go outside (especially when the weather is bad or you're sick) - a way to save money (but you've proposed an alternative for this) - eating healthy (it's very hard to eat the right amount of good quality food outside)

On the other hand, I've recently heard about a new marketing campaign by IKEA in Poland, where they opened a "social kitchen", where you could book some time and hang out together with your friends.

I have read Cal's Newport new book about Deep Work (http://calnewport.com/books/deep-work/) and have been trying to adapt some of the strategies from it. So far I see positive results (less time spent working, but more done), even though I'm not doing very well.

EDIT: Congrats ;-)

I suggest you don't start reading about writing compilers if you know only C-derivatives.

As for the choice of a functional language for a beginner, I think you just should pick whatever has better introductory materials available. You're likely to experience a big mental shift by using a functional language for the first time. It was a struggle for me, at least. That being said, I'd recommend a Lisp derivative - Racket. It has a very nice tutorial and a good IDE. Also, John Carmack's son game in Racket: https://news.ycombinator.com/item?id=10111479

StyleBot for Chrome to adjust the width.

Yes, thanks!

I believe there is a big difference between Y combinator and Dijkstra. In the former case, it could be harder.

I'd add to the third point: if you see a good solution, go for it and tell your colleagues about it.

I think that the first paragraph should be like this:

Do you understand, why we're using second normal form? Do you understand why all mu-recursive functions can be formed from those three basic functions? Do you understand, why A* works? Do you know, why we're storing those things during a context switch? Are you worth your salt as a programmer?

> interview trick questions that a CS degree give you aren't very useful at all in the real world

Usually trick questions aren't the one that you expect in real world, because they're trick questions. Nevertheless, it's very easy to consider a question being tricky, while it might be just a good check of your understanding of a given technique or algorithm.

> And you won't be that annoying guy in every meeting talking about Big O notation instead of actually solving the issue at hand.

Talking Big O is the very exact thing that you should discuss before solving (coding) the issue. It's only annoying if you do that instead. Please, do not underestimate this.

Bad things happen to employees. Every employer has to be prepared for that. I see no reason to say about your condition during an interview, if they don't specifically ask.

Good luck.

That was very clever, I wouldn't thought of that probably. Good parenting :)

I have no problem with reading HN at 100% zoom, even though my vision isn't great. Is it that annoying, to use the 125% zoom or use your own CSS (I do that to decrease width)?