Both Mandarin and Wu (or to be specific, many variations of Wu Chinese) are often heard in Shanghai. Mandarin is used as the common language for people who come from all over China.
312 karma · joined January 11, 2011
I personally prefer to think of Chinese as a language family. It would be a much larger, and very interesting, topic. For the discussion on this thread, I use "dialect" other than "separate languages", since Cantonese, We Chinese, etc. are described as dialects in most materials I read.
Cantonese is a dialect, with very different sound system, although it shares the same writing system with Mandarin. The difference between their sound systems could be larger than that between English and German, or between Russian and and Bulgarian. It makes sense if one considers the size of China. It is as big as Europe sans Russian. There are as many dialects in China as languages in Europe. In some remote parts in East China, the people in the towns next to each other could not understand each other's dialects. So a common writing system was enforced more than 2000 years ago so that people could communicate with each other in writing.
Native Cantonese speakers is less than 5% of total population in China. http://en.wikipedia.org/wiki/Chinese_language. It is mostly spoken in Canton and Hongkong. A helpful analogy (not accurate definitely) is to think of it as Spanish in the scope of Europe. A native Mandarin speaker will not understand Cantonese if he doesn't study it, just as a native English speaker will not understand Spanish without study.
Strictly speaking, 1) there are many dialects of Chinese, not Mandarin. 2) the language many Beijing people speak is not a dialect. It is an accent. Cantonese is a dialect. Wu Chinese is a dialect. Beijing Chinese is an accent. It is definitely not the national standard, although it is the closest to the national standard, compared to other accents.
I went to Beijing for college, started speaking Mandarin, and picked it up quickly. But until now, I still regularly make the mistake between /z/ and /zh/, and the other two pair. I am able to easily tell the differences between the sounds themselves. If the sounds are included in a sentence, however, I simply can't tell which is which.
Here is the interesting part. I have no difficulty in distinguishing these sounds in English. I can clearly hear the differences between words like 'sip' or 'ship', no matter if they are spoken as single words or are part of a sentence. My ears will immediately catch the difference. But if it is Mandarin, i will get lost between words like 'ziji' and 'zhiji'.
For recruiting technical people, it is ideal that the recruiters has relevant technical background. The reality is mostly the opposite. So you never know how many good candidates are filtered out because their resumes are lack of flashy keywords.
If the recruiters don't feel hurt, I prefer to screen the resumes by myself. The worse scenario is that you are scheduled for a phone interview. When you look at the resume, it is full of flashy keywords while lack of experience in "serious" projects. I fully understand the candidates are eager to get a job. But after you spent dozens of hours to talk to these unqualified candidates with flashy resumes, it becomes a negative flag. Well, these flashy resumes are a result of the tech-recruiting industry.
HR people are not necessarily better in identifying these "signals". They might emphasize on "signals" that are not a big issue for technical people. Some technical people could be a little quirky. As long as it is not serious, it is not a big deal.
浣花流水水西头， 主人为卜林塘幽。 已知出郭少尘事， 更有澄江销客愁。 无数蜻蜓齐上下， 一双鸂鶒对沉浮。 东行万里堪乘兴， 须向山阴上小舟。
[edit] The English translation is excellent.
[edit] I am NOT a native English speaker. Is OP's blog supposed to be a joke and I don't get it?
If the OP understands the difference, has a reasonable estimate on the number of listeners for broadcasts, and is reasonably good at calculation, he would find out that Pandora actually pays more.
Plus, Pandora provides more and better services to the listeners for the artists than terrestrial broadcasts. A simpel example. I am working and listening to Pandora. A nice song catches my ears. I could immediately look at the song, its album, the artists, and all other related information. Terrestrial broadcasts don't provide such a service. So Pandora is providing a deeper and more comprehensive marketing for the artists than terrestrial broadcasts, and it reaches more diverse population. That is a big benefit that the OP does not consider.
<edit> grammer
I am able to make context switch very quickly and am very focus when working. So I am not bothered if my colleagues interrupt me for questions or jokes. I am willing to help as much as I can. I am not bothered if I am under the crossfire of a nerf-gun fight. Still, pair programming is not for me. My productivity would drop like a rock.
The only docs I found in the company website that goes deep into the internals are Advanced FAQ (http://www.rethinkdb.com/docs/advanced-faq/). It is more of an architecture view, though.
The reason I ask is that with a good understanding on the internals, the engineers who understand database internals and distributed systems will have an "more" accurate idea on the capabilities and the limits of the features. Thus, if they decide to adopt RethinkDB, the understanding will help them design their applications to take advantages of the benefits and avoid the potential issues (or surprises!). MongoDB was not very good at documentation. It claims this or that feature works smoothly. Then, people found out many potential issues and limitations. That is one reason it leaves a bad tastes to many engineers.
Also, claiming any interview question as <bold> MOST </bold> revealing is simply simple-minded.
Disagree to the books recommended. SQL is only a query language, not the database itself. It definitely should be part of the consideration. Understanding how database engines works under the hood is more important in terms of performance in high-concurrency, high load scenarios.
In general, I love the ideas behind NoSQL. I can still feel the excitement when reading the BigTable and MapReduce papers. HBase, Hadoop, Radis, etc. are awesome products. I use some of them in my work. But some other NoSQL products? Being engineers, we must understand the implementation and be full aware of its limitations, instead of believing their marketing materials. Well, if all you want is to test a toy product, to build a prototype, or your product is of low concurrency and low data size and you have no concern on operation, it certainly looks that they make your development easier. But in these scenarios, any good relational databases won't add significant burden either.
Learning the fundamentals doesn't mean not doing actual programming at the same time. You have to code to have a better understanding on the fundamentals.
My personal experience is that after many years of programming, the fundamentals I learned in school still help me get better. There were many such moments that you were digging into some interesting technical topic and you suddenly realized that some fundamentals had another layer of meaning or application you didn't know or I didn't fully understand before.
Also, understanding different types of programming languages, like OOP, FP, logic programming, declarative programming, etc. help improving one's programming skills, no matter what programming you primarily use at work.
As a team lead, please be careful to decide who are good interviewers and who are not. A bad interviewer, which doesn't mean a bad person or anything else, could drive a good candidate away.
I was once contacted by a company which was in urgent need for a position. The interview went well with the first two interviewers. The third one was young and aggressive. He was almost mad when I disagree with him to a technical question. When I knew he was one of the 4 team members including the position, I already decided not to join them before the interview was ended. They gave me an offer. No surprise, I didn't accept it.
- "While replication is indeed very important, are users actually setting up replication each time with MySQL or is it to only have the option later?"
Replication is not an option. It is a must-have for any serious products, both in scaling and in operation.
- Windows functions: They are wonderful and I love them. But it is not an important factor at all.
- Flexible datatypes: True in certain scenarios. It allows to create certain types to map a business object with unusual requirements. Otherwise, the requirements have to be implemented in application logic. But data type of Array? IMHO, use of Array data type in relational database usually means there are some issues in data modeling and design. The performance is another issue. If you have to use array, consider NoSQL options.
- Functions. Although I am a database architect, I use database functions only for simple poking around. For any serious work, I prefer to write application code. It is easier to maintain, to test, and to extend. I don't want to have a big muddy ball. I prefer to have structured, well-decoupled application code.
- Custom Language. Same as above. Why not just write application code?
- Extensions: Geospatial is awesome. It is better than that in MySQL. But for many extensions, I prefer not to do the computation in database. Databases are usually the most expensive resources (in operation costs) and are usually the performance bottle neck. It would be better to have the computation in app servers. It is easier to scale and it is cheaper.
- Custom Functions: see above.
- Common Table Expressions: Recursive queries are awesome. I t is nice to have for ad-hoc data inspection, but I wouldn't encourage its usage in application code. The risk to use it wrong vs the benefits are high if used in application code.
I want to work on products that I consider meaningful and work with good and serious engineers. It is nice to hang out with colleagues, have drinks, saying jokes, etc. I am a big fan of classic rock. But calling engineers as rock stars, ninjas, etc, or engineers labeling themselves as such personalities, really convey a somewhat negative impression to me.
Exactly.
I heard many horrible stories about Foxconn from my friends. They should be exposed and punished. But fabrication is definitely wrong. It is especially so for a journalist reporter.
For example, it is simply not true that factoreis could <b>force</b> abortions. Only the government has the authority to force abortion due to the one-child policy. Foxconn is a private factory. Pregnant women would for sure get discriminated against in Foxconn. They decide to either quit, or choose abortion to keep the job. Discrimination against pregnant women is definitely wrong. But such discrimination and forced abortion are completely two matters.
As a side note, discrimination against pregnant women is a wide-spread matter in private companies in China. A good friend of mine worked in the China headquarter of one of the "big four". Her boss gave her such a hard time when my friend got pregnant and could not work 12 hours a day. My friend simply quit. She is a happy mom now.
I think many people may have the experience that an interviewer was so rude and arrogant that no way would you join the company and work with the interviewer.
Engineering is a combination of technology and art. Therefore, it is impossible to have a simple process for interviewing engineers that magically works. Otherwise, such posts would not have been brought up so many times in HN.
Also, some people are good at people evaluation, some are not. An excellent engineer could be a lousy interviewer. On the other hand, a mediocre engineer is lack of the ability to evaluate a top engineer within an hour. Therefore, the employer must first know who are his/her best interviewers. If s/he can't identify her/his own people, I highly doubt s/he is able to identify good candidates.
The hiring signals I pay attention to are one's curiosity and one's depth in understanding in at least one programming language or one computer science topic, no matter if that topic or programming language has any relevance to the position to be filled. Here is the rationale. To be a very good engineer, one needs both internal motivation and intelligence. Both of the two signals speak for internal motivation. A deep understanding on any topic shows the candidate is sufficiently intelligent. Such a candidate, even if s/he knows little about the languages and/or the frameworks the position requires, s/he would learn it very fast and would be very good at it. To be realistic, it is really not hard to learn a programming language and a framework.
Not sure about this. It is fine to have lunch together twice a week. Do it every day? Unless someone really enjoys talking and being listened.
I enjoy discussion with colleagues. I find, though, if more than 4 persons are involved, it is more efficient to be in a formal place or follow a formal procedure. Otherwise, 90% of time tends to be on trivial issues.
If lunch together is for socializing, I don't see why twice a week is not enough. I worked in such an environment before and the topics during lunch were mostly the same everyday. Most topics were not interesting. To be fair, it is hard to have an interesting or insightful talk with 10 people. The talks that made me think and made me intrigued were always with 1 or 2 colleagues. We can go out for a drink. If the topic is work-related, we can have a 15 minutes coffee break and discuss it.
I understand that lunch is also supposed to give people a break after working hard for 3~4 hours. But lunch together might not be a break for some people. Sometimes after constantly working for 3 hours, especially if the work requires me to be very concentrated, I just want to have a quiet lunch time, to relax, to read 20 minutes of history or other books to adjust my brain, to plan what to do in the afternoon, or walk in the sun for 10 minutes. At these occasions, lunch together and talking to other people only make me exhausted.
People are different. It is fine, though, if the boss wants to establish this lunch-together culture and exercise the cookie-cutter. There are always start-ups that don't require this.
Other than the three types you mentioned, I come across another type. They don't learn new stuffs that quickly. They might look dumb when they are introduced to new things. However, given more time, they are able to think and dig really deep.
Then it occurred to me that they were already thinking wider and deeper from the beginning. Because the knowledges conveyed in an introductory scenario is so limited, they have more questions and they get confused. They have no intention to hide their confusion. Once they acquire more knowledges in the field and organize the pieces into a system, they start showing how deep their thoughts have gone to.
I have troubles in finding such a position, even though I focus on start-ups only.
First, the logic in the original article is not valid. Sports and software engineering are basically incomparable. What they share as team activities don't justify the reasoning in the article. A simple counter example. In professional soccer games (like in the top leagues in Italy, Spain, Egnland, etc.), a second-tier team of ll players could quite possibly beat a top-tier team of only 9 players (the other two players are kicked out for whatever reasons). In software engineering, it is quite safe to say that 5 great engineers can outperform 30 average engineers.
Back to my original point, it depends on the technology and the application they are working on. If the technology and the application require high creativity and innovation, 1000 average engineers cann't lead it long. Most probably, it will lead to a mess that has to be cleaned up and rewritten later. On the other hand, if the application is already well designed and well-established, and the primary jobs are to add new features within the architecture, 1000 average engineers may deliver more than 5 great ones.
In reality, a good combination of both types might be the best scenario.