惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

P
Proofpoint News Feed
Martin Fowler
Martin Fowler
The GitHub Blog
The GitHub Blog
B
Blog RSS Feed
U
Unit 42
阮一峰的网络日志
阮一峰的网络日志
量子位
GbyAI
GbyAI
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
云风的 BLOG
云风的 BLOG
小众软件
小众软件
博客园 - 三生石上(FineUI控件)
L
LangChain Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园_首页
IT之家
IT之家
V
Visual Studio Blog
Y
Y Combinator Blog
Blog — PlanetScale
Blog — PlanetScale
宝玉的分享
宝玉的分享
Apple Machine Learning Research
Apple Machine Learning Research
I
InfoQ
D
Docker
V
V2EX

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
什么时候跳槽比较好?
三元方差 · 2024-06-07 · via 人人都是产品经理

在职场中,跳槽是一件常见的事情,但什么时间节点跳槽,就有所讲究了。作者分享了几个时间节点以及对应的规划,一起来看看吧。

第1个时间节点:6个月

有几种跳槽的节点,你可以参考一下。第一个呢是半年,也就是六个月左右。

那六个月可能你听上去会很短啊,当然这个短是相对来说的,如果说你两个月三个月跳,那么我建议你不如六个月的时候跳。

你进入了一家公司,刚进去你就发现这家公司它的工作风格环境,或者说它的工作岗位的职责跟你当初预想的千差万别,你实在受不了,你最好马上就走;如果说你当下没有决断下来马上走,等到你的劳动合同、社保等等全部都交好之后,那么我就建议你尽量拖到六个月再走。

如果说你立马就走,你可以在下一家公司面试时,提出因为当时谈的跟你自己想要的不一样,所以马上走了,那么这个理由在HR眼中你的稳定性判断是影响不太大的。因为你有自己的职业发展规划。

甚至因为你马上走了,没有社保记录,你在简历中不体现这一段经历都可以。

但如果你已经进入这家公司,并且已经待了一两个月之后你再走,这就很容易产生你的稳定性的质疑。

那么,为什么你要待满六个月呢?因为如果说你真的很不喜欢这个工作,但是你可以在那耗着,你也可以积极的去做一些事情改变自己的定位。

这六个月过完之后,你在下一次面试的时候,你可以去说:因为上一家公司在某些方面可能跟我预想的可能有点不一样,但是我后续做了怎样怎样的工作,做了哪些积极的努力?

试图把方向扭转到自己预期的方向上,但是可能经过了半年的努力,我依然没有实现我的目标,最后发现确实不太合适自己,所以我就走了。

那如果是这样的情况呢,HR会判断,你有积极主动性去适应职场环境,只要现在这个岗位跟你预期的偏差不会太大,那么你都会积极主动的去调整自己的状态。所以这六个月实际上就是死马当活马医,给自己一个比较好的离职理由。

六个月相对来说肯定比你一个月两个月跳槽会更好,当然这也是万不得已的情况。

第2个时间节点:1年

第二个节点呢是是一年。

如果你在一家公司内待满一年的话呢,一般来说,你对一些基础的技能肯定是比较熟练了,你已经初步的开始接触到业务,对业务有一个初步的了解。一年时间如果去面试初级的岗位,你是有一定的优势的。因为你基本的技能都会,那么你在进入下一家公司之后,可以省去下家公司对你几个月的培训时间。

当然了,一年的经验,如果说你之前没有别的工作经验的话,也肯定是面不到特别高端的岗位,你也最多只是一些基层执行的岗。如果你想要通过跳槽来实现你的职级上的这个跃迁,那么一年是肯定不够的。你至少要保证两到三年的工作时长。如果说你之前已经有其他公司的工作经历,现在这家公司你待满了一年,想要走了。

那么个人建议呢,还是要看薪资的涨幅,涨幅好久可以走。对于社招来说,一年的工作时长很多时候会被判断为稳定性不是特别强。

一年的时间呢,刚好是你对目前这个岗位的工作流程比较熟悉,正好是发光发热的时候。这个时候走了,其实对公司来说是比较亏的。

所以他也会担心你到我的公司之后,你有没有稳定性的问题。

第3个时间节点:3年跳槽

节点三:3年第三个时间段呢,是两年半到三年时间。这是一个跳槽的黄金时期。从你的能力成长来说呢,你在这家公司待的时间已经足够久了。

你的基础技能肯定已经没有问题了;并且你已经开始接触了更深的业务,你对业务有很多的了解;而且三年的时间足够你做足够多的项目,你也开始有了自己的方法论的沉淀。

对于你的职业成长来说呢,你目前的薪资涨幅一般来说会低于你的成长速度。所以你心中本身就开始会萌发跳槽这个念头。

然后从下家的角度来看呢,两到三年的你,你的能力已经达到了一定的层次。但是你的薪资其实并不是特别高,所以他可以用相对低的薪资来把你招进来。

所以两到三年的求职者,他的性价比是非常高的。所以你求职面试的这个成功率也相对会比较好。

第4个时间节点:5年

最后一种情况呢,就是在这家公司工作了五年。这种情况相对会复杂一点,因为你都在这家公司待满五年了,正常情况下你可能已经不太会走了。

如果你真的走了,第一种情况就是你真的找到一个非常好的岗位,能够发挥你的能力,能够实现你的人生规划。那这种人呢,我相信他也不需要看求职面试的课程,所以这里我也不多说了。那第二种原因呢,就是你可能待不下去了。

那这个待不下去呢,可能是公司裁员了,可能是业务团队发生了很大的变化,想要赶你走,你的领导针对你,你过得很不舒服。你觉得不走的话,整个人都会消磨在这边。不管是什么理由吧,反正肯定都是被动的。那这种被动的情况呢,如果说你之前是一个管理岗,手下不说人有多少吧,至少带过人,那么你的简历相对比较好写,而且求职的难度也会比较低。

毕竟有管理经验,这一条呢就能够秒杀很多其他的人了。而且你的在职的稳定性非常高,所以呢,面试会比较轻松。那么如果说你没有带人,你并且你做的事情呢,都是一些非常基础的维护性的工作,也没有什么特别的亮点,这种情况就会比较难办啊。

这种情况呢,我还是建议找一个有一定经验的简历辅导,它可以帮助你把这五年过程中你做的所有事情梳理一下,因为你的时间非常长,这五年的时间我相信一定能找出一些有亮点的东西,那么把这些东西包装出来,包装成你的简历,那么也能够提升你。也能够提升你求职面试的成功率。

本文由人人都是产品经理作者【三元方差】,微信公众号:【三元方差】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。