中能光和 Java 实习凉经一面 (其他OC放弃)

KeyWords 中能光和 - 中能光和(北京)新能源科技 - Java - 北京 - BXXS - 25届 - 科班 - 日常实习

Collection Tragedy Op.X No.X

Locate 北京朝阳

Platform 波斯直ping

‍Status refuse by other(12.03)

‍

时间线

11.26 发起沟通, 秒接简历
11.29 视频一面 - 技术面
2024-12-03 虽然还无回信, 但是不决定走后面的了

‍

流程

‍

一面

20min

之前工作介绍, 我对你的实习很感兴趣
阿里云子公司, 流程规范吗. 说说提测这类的.
现在只给你一个人, 你有信心把你们团队的活全部包下来吗?
如果有一个基于阿里云里面内部框架的业务区域(就是我这个项目), 你能对其进行一个完整的重构吗?
我们现在业务情境是...基于阿里云服务器, 需要你手动进行发版提测什么的, 可能会有很多问题, 你能解决吗? 或者说你熟悉这一个发版的流程吗
你这个项目, 二手交易平台咋想的? 进行到啥程度了?
评价这个业务需求和产品角度的分析...再问我你怎么看这类C2C的自研产品推广不来?
对我的这个C2C平台的未来巨无霸的模式提供建议
看我的Github
对技术的想法? 纯粹爱技术?
什么代码是好的代码?
你觉得一个方法(函数)多少行比较合适?
对 Code Review的看法?
和技术或者非技术人员沟通遇到问题咋办?
如果一个公交叫你24h待命, 你能接受吗? 或者说是要随时联系你, 这种情况接受吗?
实习时间啥的问题, 未来的个人规划(职业)?
题外话, 怕狗吗
反问

‍

个人

对ToB就要投其所好, 先说是2B, 做SRM + OA等的大项目; 先笼统介绍内容, 再深入每个点(主要说第一点) 又是5min Later
叽里呱啦
最大胆的问题, 有意思, 叫我一个人复刻整个开发团队(没有前端), 后端+测试+运维+产品+PM这样, 我实事求是说, 有些难度, 但不是不行, 特别是运维有些痛点
基于一个内部框架的重构, 有难度, 但是我能行, 因为我有真实情况下的内部框架基础下的重构, 还是3年的老项目的屎山, 我还是能啃得动的.
还是针对上上条的这个全干, 我这里觉得不对劲, 难倒不是简单的提问, 而是进去之后真的要干这样的东西? 发版运维我是基本靠点点点, 但是靠记忆回忆了主要的发版流程, 包括中台和UAT环境下的具体操作步骤, 结合Jekins和Docker啥说了下, 可能第一次说真的不太流利... (虽然也没打算准备这个)

既然对面真的很想问架构问题, 我就再介绍了一下项目的基础架构, 包括Pods的组织形式, 网关 + 负载均衡 + 域名绑定 + 实例自动拉起的一些流程

说着说着把最后一个发版流程忘记了, 就说自己记了很多笔记可以用于参考 (小丑)
真就是现实需求自研的, 真不是啥抄的, 从立项到最后凉了都说了(现在还没上线, 还在内测, 褒姒!)
分析的可以, 说我项目确实可以做, 有东西. 还说自己有这方面的观察, 提了未来建议... 问我为什么? 这该问产品去(当然不会这么说的).

脑筋转的蛮快, 说了三点, 路径依赖; 安全性金钱交易的保守型考虑; 事实上现在这类场景比较少了; 之前的疫情期间造成人为的需求现在没啦
说, 不止进行闲置物品交易, 可以整些其他业务
好评!
看各人的想法, 我选择了大牛的建议(当然我也是这么认为的, 虽然有新技术我一定会去试试), 先说技术是好的, 自己喜欢去接触前沿的东西, 再说在真实开发场景下, 技术要服务于业务落地, 单纯技术是没价值的, 科技发展要落实到生产力层面, 切实的进行业务赋能与效益提升才算一个完整的闭环. (差不多这个意思, 还是要提到技术和业务的关系, 毕竟是讲企业生产嘛)
简单易懂的代码才算好的: 直接引用那句名言, 再如(Clean Code, 《代码整洁之道》等), 也可以说, 从个人理解要clean code, 从企业生产开发更要clean, 还要符合开发规范例如阿里规范手册, 等等. 再说要找到优化与简单的平衡点, 同时引申到 "银弹" 理论, 进一步升华话题质量.
先准备深挖一个字节码里面对多参数的方法的处理(JVM底层), 再引申到阿里规范等, 然后被打断了说只需要说说自己的理解就行. 哦, 差不多300行, 在企业里面看到的基本就要抽取了, 当然1000行也不是不可以....
不太理解这个概念, 答错了(实际上是说Git等规范, 我其实也能说). 先说实习的场景, 理解代码是很有意思的一个过程, 但是没说具体的Review形式, 说的很虚, 跑火车了. 然后还能学到东西这样. 一句规范没说, 好牌打得稀烂!
总之就是说实话, 肯定是惰性的先采取最简单的方法去操作, 慢慢把问题扩大化, 一开始两人battle, 之后5人battle, 最后一起battle...因为采用了扁平化的开发团队, 每个组人也比较少, 适合一起拉个会进行评审, 包括QA, 产品, PM都来, 基本问题就能解决的. 解决不了就记录, 问问需求这样, 很灵活的.

还要说一些具体的例子, (指开发说这个是特性而测试说是bug, 这个场景我是真的出过, 人家真不懂代码咋写的, 我是懂代码, 但人家懂业务, 人家就是无敌的, 毕竟代码是能改的, 需求是不好改的) -> 不敢说了, 怕得罪人
(我面的确定不是机房运维?) 肯定要先拿具体实例做分析, 肯定居家办公能够申请调休的, 在道理上毕竟是真心希望产品能上线得到用户的好评, 有些问题立即解决是对大家有利的. 但如果从个人出发, 毕竟需要有一个边界....叽里呱啦, 最后说我自己的标准, 晚上10点前, 早上起床后. (一起笑死了)
叽里呱啦, 再介绍下自己在测试, 前端, 大数据, 毕设相关的内容, 知道快结束了要表现表现, 最后呼应一下JD, 感觉是个人的完美解答 (记录)
直接说怕了. 气氛挺冷. (其实只能算有阴影).

我应该认真说, 而不是因为听到题外话就萎了. 事实上我一开始怕是因为大学前一直有不好的心理暗示, 介绍大二的时候进行的心理方向的探索, 实践率渗透疗法之后, 现在好多了. 因为题外话基本还是有相关性的...比如看下面
直接反问为什么问害怕狗, 哦, 原来是有个狗同事(字面意义), 感到不妙啊.

咋没问技术栈一些JVM啥的问题? 是怎么考量的呢? "我面试你是按照面对已经工作很久的人来面的, 从你上段阿里实习来说基础肯定是过关了, 所以我觉得没必要在细节上抬杠了, 问问其他问题", 哦? 还能这样?! 再给特米呐斯磕个, 咚咚咚!