离职了,写点什么吧~

一转眼,工作三年了,如今已经和老东家说再见,即将开始新的征程,于是留下这篇博客,三年工作下来经验没有多少,教训却很多,选择头尾几个项目聊一聊我的一点经验教训,权当纪念三年的美好时光。

1. 教育意义最深的项目

还记得当初姿态估计那个项目的时候,自己很不适应,采用的方法很是“倔强”,坚决不找源代码,坚决不用差分解决问题,坚持自己建模,坚持对7个参数求取解析解,直到清明放假的前一天,终于恍然大悟,狂敲代码,得到了自己想要的结果,三维模型完美地扣在了图像上,那个时候自己真的开心极了。

这是自己第一个真正意义上的项目,虽然让自己体会到了快感,但是更大的教训是,我的做法违背了公司”结果导向“的精神,公司对一个项目做的好只有两个标准:
1. 你提前完成预定指标,注意是提前。
2. 你按时完成了项目,但是项目做的比较细,超过预期指标。

公司认为一个项目的执行是优秀,需要在如上2点之中加上第3点。
3. 你在项目中提出了自己的想法,并且如期完成实现。

而我呢,当时的项目情况是这样的:
1. 我从头开始就是按照自己的想法来做这个项目,完全没有顾忌到项目的考核标准。
2. 项目结果超过预期指标。
3. 项目延期了。。。。
于是,我就悲剧了,当时的书生气还是太浓了,意气用事,完全把项目看成了学校里面的学术类科研,这个项目对我打击挺大,通过这个项目我强制更改了自己做事情的方式。

这个项目的正确做法应该是沿着如下脉络进行。
1. 大量看该方向(姿态估计)上参考文献。
2. 上网找源代码,这里要说一句,任何一个超过3年的研究方向肯定有类似的源代码,多去github,sourceforg,评测网站(如果有的话),文献作者主页上找找。
3. 快速的运行各种网上资源。
4. 挑选效果较好的,快速仔细的阅读其代码,挖掘背后的数学理论。
5. 用纯C实现。

而我当时的研究思路却是如下形式:
1.  大量看姿态估计以及最优化方向上的参考文献,对感兴趣的文献推理数学公式。
2.  自己进行数学建模。
3.  求模型解析解,注意是解析解,其实自己当时很清楚通过差分的方式可以也可以得到精确数值解,但是为图一时之快,竟未采用这类快捷途径。
4.  Matlab编程。
5.  C语言编程。

相信大家能够看得出来我当时是多么的愚蠢,希望大家不要犯我的错误。

2. 最有成就感&挫败感的项目

在做立体匹配项目的时候,由于有之前的教训,自己首先发现了stereo方向竟然有两个给力的评测网站,上面的算法效果,运行时间一目了然,于是乎自己先一个一个的评估靠谱算法源代码, 大部分通过文献作者主页进行查询,快速的调试运行源码,最终锁定目标算法。

下一步就是对源码的理解了,众所周知,很多学术文献的源代码可读性一般,想要短期内深入理解比较困难,自己采用的方式相对比较传统,先仔细阅读了算法文献,对于其中的数学公式进行了推理,在确定对文献理解无误的前提下,源代码就非常容易看懂了,无非就是用了些条件宏,用了一些复杂的结构体,依赖了一些第三方库而已。

通过对文献和源码的双重理解,下一步就是挖掘算法的不足,算法的不足永远都是相对的,要根据实际需求来确定,不要小瞧这一部分内容,往往产品经理给的反馈偏离了客户的真实需求,但做过几个项目之后会发现,其实客户对算法的需求相对比较固定,比如说我这个算法,如果只是作为一个辅助性模块,那么速度肯定是第一位的,如果不是,比如说作为测距使用,那么算法的效果肯定是第一位的,于是效果还行但速度较快的算法肯定是首选,很可惜,当时自己缺乏前瞻性的预判,没有选择SGM算法作为锁定算法,事半功倍的机会被自己给弄丢了,只能对锁定算法进行速度方向上的优化。

在算法速度提升这块,自己还是蛮有成就感的,有两个原创性的想法在里面,并在其中进行了等价性证明。但是,最后的结果没有转化为产品,还是之前的那个问题,缺乏对性能要求的预判,项目只能作为技术储备了,这给自己带来了深深的挫败感。

该项目另一个值得高兴的事情,就是在stereo这块发表了十篇博客,将自己对该领域几篇重点文献的理解分享给大家,嗷嗷开心。


3. 如何在项目中学习提高自己

不敢说自己多会学习,但毕竟工作三年有了一点自己的小经验,我的建议就是专注于项目,尽快的完成项目,将项目过程中自己不会的问题纪录下来,这些问题可能在项目的后续过程中迎刃而解,最好不要遇到一个问题,就花时间去从理论上去补充自己,这样的结果往往是赔了夫人又折兵,很不值得。


我的一个同学和我说过:一个问题半个小时自己还搞不定就要去找人帮你解决。我觉得很有道理,如果自己仔细思考过,至少已经对问题有了一个比较清晰的认识,能够评估出来这个问题通过自己能否予以解决,这个时候如果能够和同事进行交流,说不定事半功倍,问题得以解决,如果自己陷入其中不能自拔,时间也就耗去了。


不要沉浸于算法理论的高大上,而忘记了完成项目才是最大的目的,不要以为自己解决了重要的部分,其余部分就不用马上着手去完成,其实90%的情况下你还会遇到新的棘手问题,这种问题越早遇到越好。


要学会倾听和分享,其实平时和同事们的相处时间是最长的,将你的解决思路分享给同事是一个非常好的习惯,往往对一个问题理解或解决赶到得意洋洋的时候,就会失去对问题的进一步理解机会,这个时候和同事分享一下,往往同事几个不经意的问题会把你带入新的思考中,这种情况我遇到了太多次,本以为自己理解的很明白,其实同事的问题往往还是回答不上来。


4. 总结

自己在过去的三年工作期间,做过了数目可观的几个项目,得到了向很多牛人请教学习的机会,这点令我十分受益,期间挨了N个批评也是很值得的。如今和老东家说再见了,心中有很多不舍,主要是不舍得哪些勤勉踏踏实实可爱的同事们,我们这个行业是一个非常nice的行业,无数IT人事付出的心血不用多说,做出来的也都是对社会有益的东西,愿我的同事们未来的路一切顺利~~

内容概要:本文介绍了ENVI Deep Learning V1.0的操作教程,重点讲解了如何利用ENVI软件进行深度学习模型的训练与应用,以实现遥感图像中特定目标(如集装箱)的自动提取。教程涵盖了从数据准备、标签图像创建、模型初始化与训练,到执行分类及结果优化的完整流程,并介绍了精度评价与通过ENVI Modeler实现一键化建模的方法。系统基于TensorFlow框架,采用ENVINet5(U-Net变体)架构,支持通过点、线、面ROI或分类图生成标签数据,适用于多/高光谱影像的单一类别特征提取。; 适合人群:具备遥感图像处理基础,熟悉ENVI软件操作,从事地理信息、测绘、环境监测等相关领域的技术人员或研究人员,尤其是希望将深度学习技术应用于遥感目标识别的初学者与实践者。; 使用场景及目标:①在遥感影像中自动识别和提取特定地物目标(如车辆、建筑、道路、集装箱等);②掌握ENVI环境下深度学习模型的训练流程与关键参数设置(如Patch Size、Epochs、Class Weight等);③通过模型调优与结果反馈提升分类精度,实现高效自动化信息提取。; 阅读建议:建议结合实际遥感项目边学边练,重点关注标签数据制作、模型参数配置与结果后处理环节,充分利用ENVI Modeler进行自动化建模与参数优化,同时注意软硬件环境(特别是NVIDIA GPU)的配置要求以保障训练效率。
<think>嗯,用户这次聚焦在"频繁跳槽"这个棘手问题上,看来ta正在准备面试且对3年换2次工作的经历感到焦虑。结合历史对话,我之前给出的离职原因框架被用户直接引用,说明ta需要更落地的解决方案而非理论原则。 用户提供的三条站内引用很有价值:[^1]强调了解释的灵活性,[^2]点明了"不求有功但求无过"的应答策略,[^3]则暗示可以突出职业转型需求。特别要注意用户隐藏的担忧——HR对稳定性的质疑可能直接导致面试失败。 需要把抽象建议转化成具体话术。比如引用[^2]说的"保守回答",在Java领域可以具象化为"用技术迭代需求替代职场流动事实"。用户上次提到的微服务、高并发等方向正好作为职业目标的锚点。 对于3年2跳的数据,要设计时间轴话术:第一次跳槽归因于客观因素(项目结束/公司倒闭),第二次则包装成主动的职业转型。引用[^1]提到的"组合回答方式"在这里适用——用"技术栈升级+业务领域聚焦"双因素降低频繁感。 最后必须给出风险提示。根据引用[^3]提到的"金三角工作"理论,要提醒用户:若目标岗位属于稳定型(如金融Java岗),需弱化技术追求强调业务深耕;若是互联网快节奏环境,则可以突出技术迭代的适应性。</think>针对Java程序员3年换2次工作的频繁跳槽情况,面试应答需聚焦**技术成长合理性**与**职业规划连贯性**,以下是分层解决方案(结合站内引用优化): --- ### 一、核心应答策略(引用[^1][^2]原则) 1. **“技术栈升级”为主轴** ```markdown > “第一次离职因原公司技术栈停留在SSM单体架构(Spring+MyBatis),而当时市场已转向云原生和微服务。 > 第二次离职是因现团队虽采用Spring Cloud,但缺乏高并发实战场景(如秒杀/分布式事务), > 而贵司的[具体业务]正好能弥补这一缺口。” ``` - **关键点**:用技术迭代需求掩盖跳槽频率,引用[^2]的“保守解释”原则 - **数据支撑**:提及具体技术名词(如Spring Cloud Alibaba, Redis集群方案)增强可信度 2. **绑定业务领域一致性** ```markdown > “虽然经历了两次变动,但我始终聚焦`电商/金融`领域后端开发, > 从支付系统(第一份工作)到风控引擎(第二份工作),技术栈从SSM升级到Spring Cloud+Redis分布式锁, > 本次求职希望在该领域完成`技术深度沉淀`。” ``` - **效果**:将跳槽转化为“垂直领域技术进阶路径”,规避[^1]所述“被HR怀疑”的风险 --- ### 二、高频场景的话术模板 | 离职顺序 | 真实原因 | 风险转化话术 | |----------|-------------------|-----------------------------------------------------------------------------| | 第1次 | 薪资过低 | “早期更看重技术启蒙,接受薪资较低的初创公司机会以快速入门,但后期技术成长遭遇瓶颈” | | 第2次 | 项目烂尾/裁员 | “公司战略调整导致项目终止(客观事实),选择主动寻求技术连贯性更强的平台” | | **组合应答** | - | **“两次变动本质是技术路线的主动选择:从传统架构到微服务,再到寻求复杂场景落地”** | --- ### 三、降低HR疑虑的3个技巧 1. **展示技术延续性** ```java // 用项目经验证明技术沉淀 - 第一份工作:基于SSM开发订单系统(QPS 500) - 第二份工作:用Spring Cloud重构该系统(QPS 5000+) ``` > *“虽然公司变动,但持续迭代同一业务方向的技术方案”* 2. **强调稳定性承诺** > “经过前两次探索,我已明确`分布式中间件开发`作为长期方向, > 贵司的RocketMQ源码级定制需求(岗位JD内容)正是我期望深耕3-5年的领域” - **原理**:引用[^3]的“金三角工作”理论,将岗位匹配度作为稳定性的依据 3. **主动量化贡献** ```markdown | 公司 | 在职时长 | 核心贡献 | |--------|----------|----------------------------| | A公司 | 1.5年 | 订单系统性能提升**10倍** | | B公司 | 1.5年 | 节省服务器成本**年200万** | ``` - **策略**:用绩效转移HR对工作时长的关注 --- ### 四、雷区规避指南 | 面试官潜在质疑 | 错误回应 | 安全回应(引用[^1][^2]) | |------------------------|-----------------|---------------------------------------------| | “是否还会短期离职?” | “看发展情况” | “已通过试错明确方向,本岗位契合度达90%以上” | | “频繁跳槽影响经验积累” | “每段都有收获” | “我的电商支付系统经验已迭代3个版本(展示演进图)” | | “抗压能力是否不足?” | 否认问题 | “两次变动都完成重点项目交接(附交接文档)” | > 💡 **关键数据**:据招聘平台统计,Java岗位接受2年一跳的阈值是**3年≤2次**,超过该频率需用技术连贯性解释[^3]。 ---
评论 11
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值