Skip to main content

Posts

Showing posts from September 10, 2017

[找工就业] [salary negotiation] 求职如何跟公司讨价还价

[找工就业] [salary negotiation] 求职如何跟公司讨价还价   Warald 发表于 2017-7-9 12:33:39 10家公司里有8家愿意negotiate offer给涨工资,但是10个求职者里只有3个人讨价还 价了!按照本文里说的操作,你的offer有可能增长至少50% 什么样的人不适合读这个文章? 觉得谈判工资是种贪婪的表现。赤裸裸要钱之后,还是继续要钱、反复要钱,感觉这样 不好。 不想承担任何风险。讨价还价是个微妙的过程,再圆滑的处理手段,也存在谈崩了的可 能性。 能有offer就谢天谢地了,没什么资本讨价还价。 相信:工资由能力决定,公司会公平对待。 什么样的人适合讨价还价? 类似的职位,类似的背景,凭什么我的收入要低?为什么我没拿到最高工资?这不公平! 我想最大化自己利益,我有这个耐心,也愿意冒一定的风险。 我坚信:新工作的工资应该由市场供需决定,而不是我目前的工资。 相信:尽管我要了公司不一定给,但是我不要公司必然不会给。 这二者之间会有什么差别? 你的第一份工作,有可能差别不大。因为应届生背景类似,尤其是去同一家公司,年收 入差别可能只有一两万,甚至只有几千。大家在一亩三分地抖包袱里看到的offer数字 ,应届生往往是一样的。当然,即使你是应届生,即使空间不大,你也应该努力争取, Warald在这里要强调:negotiation是一种非常重要的skills,重要性不亚于刷题、大 数据、机器学习等,应该从职业早期就开始培养。 对于经验丰富的人来说,讨价还价之后,在已有offer的基础上,平均每年多拿个几万 美元,并不难,而且,工作年数越久、经验越丰富,谈判的空间越大。Warald知道有的 人谈判做的好,平均每年多拿十来万,三年拿到原本四年才能拿到工资。 有些人可能会说,我年轻,既然offer数字差别不大,那等将来再说。Warald提醒你: 收入高低是长期积累的结果。 诚然,高薪不是光靠讨价还价就能要出来的。但是,据Warald所知,很多中国人在这方 面做的远远不够。求职期间,很多人被公司牵着鼻子走,没有最大化自己的利益。写这 个文章,希望能对大家有帮助。. 交手之前,知己知彼。 先说一下公司招聘员工的费用。 大家都知道美国很多公司奖励自己的

Floyd判圈算法(Floyd Cycle Detection Algorithm)

Floyd判圈算法 ( Floyd Cycle Detection Algorithm ),又称 龟兔赛跑算法 ( Tortoise and Hare Algorithm ),是一个可以在 有限状态机 、 迭代函数 或者 链表 上判断是否存在 环 ,求出该环的起点与长度的算法。该算法据 高德纳 称由美国科学家 罗伯特·弗洛伊德 发明,但这一算法并没有出现在 罗伯特·弗洛伊德 公开发表的著作中 [1] 。 如果有限状态机、迭代函数或者链表上存在环,那么在某个环上以不同速度前进的2个 指针 必定会在某个时刻相遇。同时显然地,如果从同一个起点(即使这个起点不在某个环上)同时开始以不同速度前进的2个指针最终相遇,那么可以判定存在一个环,且可以求出2者相遇处所在的环的起点与长度。 目录    [ 隐藏 ]  1 算法 1.1 算法描述 1.2 伪代码 1.3 算法复杂度 1.3.1 时间复杂度 1.3.2 空间复杂度 2 应用 3 相关算法 4 参考链接 算法 [ 编辑 ] 算法描述 [ 编辑 ] 如果有限状态机、迭代函数或者链表存在环,那么一定存在一个起点可以到达某个环的某处(这个起点也可以在某个环上)。 初始状态下,假设已知某个起点 节点 为节点S。现设两个指针t和h,将它们均指向S。 接着,同时让t和h往前推进,但是二者的速度不同:t每前进1步,h前进2步。只要二者都可以前进而且没有相遇,就如此保持二者的推进。当h无法前进,即到达某个没有 后继 的节点时,就可以确定从 S 出发不会遇到环。反之当t与h再次相遇时,就可以确定从S出发一定会进入某个环,设其为环C。 如果确定了存在某个环,就可以求此环的起点与长度。 上述算法刚判断出存在环C时,显然t和h位于同一节点,设其为节点M。显然,仅需令h不动,而t不断推进,最终又会返回节点M,统计这一次t推进的步数,显然这就是环C的长度。 为了求出环C的起点,只要令h仍均位于节点M,而令t返回起点节点S,此时h与t之间距为环C长度的整数倍。随后,同时让t和h往前推进,且保持二者的速度相同:t每前进1步,h前进1步。持续该过程直至t与h再一次相遇,设此次相遇时位于同一节点P,则节点P即为从节点S出发所到达的环C的第一个节点,即环C的一个起点。

标题: 程序员之死:社交比老实更重要

发信人: littlesmoll(СС), 信区: Software 标题: 程序员之死:社交比老实更重要 发信站: BBS未名空间站(Tue Sep 12 08:36:17 2017,GMT) 最近一段时间,某程序员苏享茂死了,因为被前妻翟某欣索要1000万元和房产赔偿,并 以举报其创业项目相威胁,终于想不开自杀了。 而这个男人是个好人,属于那种“女孩子找个老实人嫁了”的类型,然而婚姻却最后害 死了他。 让很多人有一次不相信婚姻。一些理工科专业的男孩子,常常在相亲市场处于鄙视链的 底端。对他们普遍评价是:宅、丑、矮、胖、品味差,穿着打扮老土,聊天不够风趣。 只有那些选了IT专业的人,毕业后搭上互联网的顺风车,一些幸运儿发了财,靠高收入 弥补了以上缺陷。 他们在专业领域是骨干、顶梁柱,但出了公司大门,到了社会上,他们就是普通人,没 有经历过社会的复杂,只跟代码打交道,没有多少恋爱经历。 翟某欣就这样出现了,她看上去清纯和善,长相没有侵略性,符合直男审美。 他觉得是一见钟情,她已经布好局,深谋远虑。 一个看上去各方面条件比较优秀的女性,在婚恋网站上待了三年之久。 相识过程中,苏享茂投入了巨大的恋爱成本,109天内共花费1467万元,各种鸡汤、情 感类自媒体不是说,“高贵的女人都自带烧钱属性”“会花钱才会挣钱”么。 6月7日两人结婚,在民政局领证。 婚后,苏享茂感到不对劲,觉得“她爱撒谎,极有心机,让我觉得有种恐怖的感觉。” 二人很快决定离婚。 而三天后,翟某欣正式摊牌,要求苏享茂赔偿所谓“精神损失费”1000万。整场谈判非 常迅速,不作任何妥协。翟某欣威胁,周一就报案,故意把时间掐得很紧,不给对方有 反应的余地。 在拿到660万后仍逼苏享茂写欠条,逼迫苏享茂卖掉在西二旗的一套房子。 部分程序员对自己专业领域之外的知识缺乏兴趣,交际圈子较窄。要想避开这个社会的 凶险之处,有必要多结交些有经验、有资源的朋友。 撇开拉关系、找后门的因素,任何一个职业的人,也不得不面临需要多种不同职业知识 、经验支持和参考的局面。世界的复杂程度,显然远远超出了程序员单个行业知识的认 知范围。 比如医生:生老病死,人一辈子都躲不过的事情,没准哪天加班过劳,要在病床上躺会。 比如老师:再苦不能苦孩子,再穷不能穷教育,连咪蒙这样的大V,也靠后门才把孩子 送入了好的学校。 比如律师:旧社会讲究道德

Latency numbers every programmer should know

Latency numbers every programmer should know Latency Comparison Numbers -------------------------- L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns 14x L1 cache Mutex lock/unlock 100 ns Main memory reference 100 ns 20x L2 cache, 200x L1 cache Compress 1K bytes with Zippy 10,000 ns 10 us Send 1 KB bytes over 1 Gbps network 10,000 ns 10 us Read 4 KB randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD Read 1 MB sequentially from memory 250,000 ns 250 us Round trip within same datacenter 500,000 ns 500 us Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip Read 1 MB sequenti

Powers of two table

Powers of two table Power Exact Value Approx Value Bytes --------------------------------------------------------------- 7 128 8 256 10 1024 1 thousand 1 KB 16 65,536 64 KB 20 1,048,576 1 million 1 MB 30 1,073,741,824 1 billion 1 GB 32 4,294,967,296 4 GB 40 1,099,511,627,776 1 trillion 1 TB Source(s) and further reading Powers of two

TCP vs UDP

Transmission control protocol (TCP)   Source: How to make a multiplayer game TCP is a connection-oriented protocol over an  IP network . Connection is established and terminated using a  handshake . All packets sent are guaranteed to reach the destination in the original order and without corruption through: Sequence numbers and  checksum fields  for each packet Acknowledgement  packets and automatic retransmission If the sender does not receive a correct response, it will resend the packets. If there are multiple timeouts, the connection is dropped. TCP also implements  flow control  and  congestion control . These guarantees cause delays and generally result in less efficient transmission than UDP. To ensure high throughput, web servers can keep a large number of TCP connections open, resulting in high memory usage. It can be expensive to have a large number of open connections between web server threads and say, a  memcached  server.  Connection pooling  can help in ad

Hypertext transfer protocol (HTTP)

Hypertext transfer protocol (HTTP) HTTP is a method for encoding and transporting data between a client and a server. It is a request/response protocol: clients issue requests and servers issue responses with relevant content and completion status info about the request. HTTP is self-contained, allowing requests and responses to flow through many intermediate routers and servers that perform load balancing, caching, encryption, and compression. A basic HTTP request consists of a verb (method) and a resource (endpoint). Below are common HTTP verbs: Verb Description Idempotent* Safe Cacheable GET Reads a resource Yes Yes Yes POST Creates a resource or trigger a process that handles data No No Yes if response contains freshness info PUT Creates or replace a resource Yes No No PATCH Partially updates a resource No No Yes if response contains freshness info DELETE Deletes a resource Yes No No *Can be called many times without different outcomes. HTTP is an application lay

Asynchronism

Asynchronism Source: Intro to architecting systems for scale Asynchronous workflows help reduce request times for expensive operations that would otherwise be performed in-line. They can also help by doing time-consuming work in advance, such as periodic aggregation of data. Message queues Message queues receive, hold, and deliver messages. If an operation is too slow to perform inline, you can use a message queue with the following workflow: An application publishes a job to the queue, then notifies the user of job status A worker picks up the job from the queue, processes it, then signals the job is complete The user is not blocked and the job is processed in the background. During this time, the client might optionally do a small amount of processing to make it seem like the task has completed. For example, if posting a tweet, the tweet could be instantly posted to your timeline, but it could take some time before your tweet is actually delivered to all of your follo