windows商店应用开发
Measuring a company by its “agility”, or how cutting-edge and progressive its tech stack and development processes are, can be an excellent method upon which to compare companies.
通过公司的“敏捷性”或公司的技术堆栈和开发流程的先进性和进步程度来衡量公司,可以成为比较公司的绝佳方法。
In this article I will be comparing three real companies, known unimaginatively as “Company A”, “Company B” and “Company C”. I’ve found it fascinating to learn about each of these companies and their leaders- particularly that they all manage to be very successful, growing companies despite each having their own ways of doing things. I worked at one and interviewed with the other two, but I always ask a lot of questions during these interviews and walk away knowing a lot about how each does things.
在本文中,我将比较三个真实的公司,它们被想象为“公司A”,“公司B”和“公司C”。 我发现了解这些公司及其领导者非常有趣,特别是尽管他们各自都有自己的做事方式,但他们都设法成为非常成功的成长型公司。 我曾在其中一个工作过,并与其他两个人进行过面谈,但是在这些面试中,我总是会问很多问题,然后走开,对每个人的工作方式都了解很多。
Each of these companies has a lax culture, competitive benefits, and at least some truly-senior developers. All leaders worked their way up from software development positions, and two of the three (B and C) still write code as part of their daily job responsibilities.
这些公司中的每一个都有松散的文化,竞争优势以及至少一些真正的高级开发人员。 所有领导者都从软件开发职位逐步晋升,三个领导中的两个(B和C)仍将代码作为日常工作职责的一部分。
公司A —“成熟的创业公司” (Company A — The “mature startup”)
Company A is fast-paced, innovative, cutting-edge… dare I say, agile. Indeed, they follow Agile (or at least try to) as closely as they can, including daily stand-up meetings, sprint planning meetings, two-week sprint cycles, etc. They use the latest technologies- React (with hooks!), .NET Core, and some emerging technologies like GraphQL, RabbitMQ, and MemSQL. They have a dedicated DevOps team and an automated deployment pipeline.
公司A节奏快,创新,尖端……我敢说, 敏捷 。 确实,他们尽可能地遵循敏捷(或至少尝试着),包括每日站立会议,冲刺计划会议,两周的冲刺周期等。他们使用最新技术-React(带钩子), .NET Core和一些新兴技术,例如GraphQL,RabbitMQ和MemSQL。 他们有一个专门的DevOps团队和一个自动部署管道。
Company A is a seasoned startup that has been bought out but not completely reorganized by its new owners. Pre-buyout management has remained, and culture has “remained the same” (although it never actually does, as it turns out- benefits are always cut for example).
甲公司是一家经验丰富的创业公司,已经被收购,但没有被其新所有者完全重组。 收购前的管理一直保持下去,文化“保持不变”(尽管实际上从未如此,因为事实证明,收益总是被削减)。
基于知觉的好处 (Perception-Based Benefits)
![Image for post](https://miro.medium.com/max/9999/1*n4-_BkUmP9GFrIlh3SnGqg.jpeg)
Company A hires the best talent in town with a famous culture and the ability to work in a cutting-edge stack. They pay below market, but their devs value the culture over $10 or $20k. This culture is what I refer to as “perception based”. This means that the culture benefits are “off the record” and hidden from the parent company (if applicable) and sometimes even HR, and apply on a person-by-person basis based in part on who their manager is and which team they are on, as well as perception of the individual by others. These benefits include consistently working < 40 hours per week, taking well beyond one hour for lunch, playing video games on company time, and not submitting PTO requests when out sick. Some employees were fortunate enough to enjoy all of these benefits, while others wouldn’t be able to get away with any. These were largely benefits established in the early days of the company, passed on to new employees by the employees who have stuck around since those early days.
公司A聘请镇上最优秀的人才,他们拥有著名的文化和能够在最前沿工作的能力。 他们的付出低于市场,但他们的开发者对这种文化的评价超过10美元或2万美元。 我所说的这种文化是“基于感知的”。 这意味着文化收益是“记录在案的”,对母公司(如果适用)甚至是人力资源都是隐蔽的,并且是逐人申请的,部分取决于其经理是谁以及他们是哪个团队以及他人对个人的感知。 这些好处包括每周持续工作少于40小时,午餐时间远远超过一小时,在公司时间玩视频游戏以及在生病时不提交PTO请求。 一些员工很幸运地享受了所有这些好处,而另一些则无法摆脱。 这些主要是在公司成立之初就建立的福利,并由那些自成立之初就一直留在公司里的员工转移给新员工。
Officially the workweek is 40 hours, but varies widely from employee to employee, with some working an average of 35 hours per week and others putting in closer to 45 hours per week.
正式的工作周为40小时,但每个员工的工作时间差异很大,有些每周平均工作35个小时,而其他每周则要接近45个小时。
不惜一切代价敏捷 (Agile at All Costs)
Company A is what I would describe as “Agile at All Costs”. That is, the company’s adoption of Agile has negative impacts on the company’s culture, employee productivity, ability to deliver new features that are bug-free, etc. (I will expound on this in a forthcoming article, but “Agile” implemented poorly or incorrectly can have disastrous consequences).
我将公司A描述为“不惜一切代价敏捷” 。 也就是说, 公司采用敏捷对公司的文化,员工生产力,提供无缺陷的新功能的能力等产生了负面影响 。(我将在即将发表的文章中对此进行详细说明,但是“敏捷”的实施效果不佳或错误地会带来灾难性的后果)。
领导者A-从开发者晋升为导演 (Leader A — Promoted from dev to director)
When hiring, Leader A tends to look for devs “passionate about code” (same as the other two leaders of the other two companies).
在招聘时,领导者A倾向于寻找“对代码充满热情”的开发人员(与其他两家公司的其他两名领导者一样)。
Leader A is typically very open to change and will allow dev teams to try new things, even when it may not make total sense and is really just “for the experience” or “just to try it out”.
领导者A通常非常乐于变革,并且允许开发团队尝试新事物,即使这可能没有什么意义,实际上只是“为了经验”或“只是尝试”。
团队架构 (Team Structure)
There is a strong adherence to the company’s interpretation of Agile. Teams are usually small (3–5 developers) and each team typically has a “lead”, the most-senior developer. That said, this lead is not formally recognized as the lead, and does not actively “lead” the other developers on the team. Equality in responsibility and leadership is promoted among a team’s developers, QA and product manager although in practice the product manager is taskmaster and effectively assumes the role of “manager” for the team- managing the assignment of work items, organizing and leading meetings, and serving as the liaison to the stakeholders.
该公司对敏捷的诠释有很强的依从性。 团队通常很小(3-5个开发人员),每个团队通常都有一个“领导”,即最高级的开发人员。 就是说,这个潜在客户没有被正式认可为潜在客户,也没有积极地“领导”团队中的其他开发人员。 在团队的开发人员,质量保证和产品经理中,责任与领导力的平等得到了促进,尽管实际上产品经理是任务负责人,并有效地承担了团队的“经理”角色,管理工作项目的分配,组织和领导会议,以及担任与利益相关者的联络。
Team members are often shuffled around to other teams, sometimes as often as once every few months. In this way, knowledge is more spread-out among the developers, and developers are able to more or less choose which application or product they want to work on (as a result, they have some control over whether they work primarily on backend or frontend code).
团队成员经常与其他团队一起洗牌,有时每几个月一次。 通过这种方式,知识可以在开发人员中更广泛地分布,并且开发人员可以或多或少地选择他们想要处理的应用程序或产品(因此,他们可以控制自己主要在后端还是前端工作。码)。
好处 (Benefits)
The average developer competency is as high or higher than any other company (good habits are reinforced and advanced knowledge is passed down to the less-experienced developers)
开发人员的平均能力比任何其他公司都高或更高 (良好的习惯得到了巩固,高级知识被传给了经验较少的开发人员)
“Perception-based” benefits can be extremely generous.
“基于感知”的好处可能非常慷慨。
悲剧 (Tragedies)
It is difficult for mid-level developers to be promoted to senior-level.
中级开发人员很难晋升为高级人员。
An ever-degrading culture (which will always degrade as a company grows, especially if the company is acquired by another company).
不断退化的文化 (随着公司的成长,这种文化总是会退化的,特别是如果该公司被另一家公司收购)。
Below-market pay
低于市场的工资
Working some amount during nights and weekends is somewhat common to meet deadlines or fix unexpected production bugs.
为了满足最后期限或修复意外的生产错误, 在夜间和周末进行一些工作是很常见的。
结论 (Conclusion)
Company A is a “mature startup”- a company that is still relatively small, has a few employees who were there from the early days, may be in the transition phase from startup to enterprise- isn’t sure whether it’s a startup or a large company.
公司A是一家“成熟的初创公司”,该公司规模仍然相对较小,从成立之初就只有几名员工,可能正处于从初创公司到企业的过渡阶段。不确定公司是初创公司还是大公司。
Company A is great for college-grads and junior developers to learn from some of the smartest developers in town (and in fact junior devs who go through the internship program are paid above market at Company A as a means of incentive).
公司A 非常适合大学毕业生和初级开发人员向镇上一些最聪明的开发人员学习(实际上,通过实习计划的初级开发人员在公司A上获得高于市场的报酬)作为激励手段。
Mid-level developers are expected to work very hard on mostly feature enhancements for brownfield applications. For mids, there is plenty of learning and growth opportunity, but they are paid significantly less than their peers at other companies (where they would generally be considered “senior level”). Many mid-level developers at this company are qualified to be promoted to senior, but there is only so much room at the senior level and so the “best of the best” must be chosen. The criteria to be considered “senior” is intentionally hidden, likely because the lucky few who are promoted are chosen less by their development and leadership skills and more how well-liked they are by leadership (whether you believe this or not, watch out for it at your job).
预计中级开发人员将在棕地应用程序的大部分功能增强上进行艰苦的工作。 在中期,有很多学习和成长的机会,但是他们的薪水比其他公司的同行要低得多(在其他公司,他们通常被称为“高级”)。 该公司的许多中级开发人员都有资格晋升为高级职位,但是高级职位只有这么多的空间,因此必须选择“最好的”。 被认为是“高级”的标准是有意隐瞒的,这可能是因为晋升的幸运儿很少通过他们的发展和领导技能来选择,而更多地是通过他们对领导的喜欢程度来选择(无论您是否相信,请当心它在您的工作中)。
A mid-level developer at this company would be wise to take a couple of years of experience and growth and use it to land a senior role at another company, unless they are on the shortlist for a promotion (and the criteria for a “senior” is known, and that mid-level developer meets that criteria).
该公司的中级开发人员应明智地利用几年的经验和成长,并用它来担任另一家公司的高级职位,除非他们在晋升的候选名单中(以及“高级”的标准”, 并且中级开发人员符合该条件)。
Senior developers enjoy a lax work environment while having the ability to work on mostly greenfield development using new and unfamiliar technologies that interest them.
高级开发人员享受宽松的工作环境,同时能够使用他们感兴趣的新的和不熟悉的技术进行新开发项目。
C公司-旧血液 (Company C — The Old Blood)
Company C values and strives for that magical (if not unrealistic) blend of “speed” and “quality” same as Company A, yet somehow seems to work at a slower pace. At least, the sense of urgency is absent from the office atmosphere. Company C is slow to change and far from cutting-edge, opting to use older technologies like jQ**** and WebF****, and use stored procedures to store business logic (gasp!). I remember when I was interviewing at this company I was amazed at how, despite the long list of so-called “best practices” being broken and ignored, the company was doing well- so well in fact, that they were on a sort of hiring spree.
公司C重视并努力与公司A进行“速度”和“质量”的神奇(即使不是不切实际的)融合,但在某种程度上似乎工作速度较慢。 至少在办公室气氛中没有紧迫感。 公司C的变化缓慢,并且远离尖端技术,选择使用jQ ****和WebF ****等较旧的技术,并使用存储过程来存储业务逻辑(天哪!)。 我记得当我在这家公司面试时,我惊奇地发现,尽管一长串所谓的“最佳实践”被打破并被忽视了,但该公司的表现却很好,事实上,他们在某种程度上招聘狂潮。
All of the devs at Company C were middle-aged, which makes sense as jQuery, WebForms and the like were effectively dead by the time twenty-somethings entered the workforce. As a twenty-something myself, I was discouraged that the founder and architect wasn’t interested in using modern JavaScript, or even modern Razor (including Blazor) for anything at all- including the greenfield stuff. Yes, new projects on the horizon were slated to rely heavily on stored procedures and good ol’ jQuery + Bootstrap.
C公司的所有开发人员都是中年人,这很有意义,因为jQuery,WebForms等在二十多岁入职时实际上已经死亡。 作为二十多岁的我,我感到沮丧的是,创始人和架构师对使用现代JavaScript甚至现代Razor(包括Blazor)对任何东西 (包括未开发的东西 )都不感兴趣。 是的,即将出现的新项目计划在很大程度上依赖于存储过程和良好的jQuery + Bootstrap。
There’s a certain allure about being “stuck in time”- knowing everything you will ever need to know to do your job and do it well. There is no “keeping up” with jQuery. We’re taught as developers we need to be so passionate that we want to learn about all the new things constantly being released, but I don’t see an issue or a lack of passion with someone who is content writing jQuery for the rest of their career
“被时间卡住”有一定的吸引力-知道完成工作和做好工作所需的一切。 jQuery没有“跟上”。 作为开发人员,我们被教导要充满激情,以至于我们想了解不断发布的所有新事物,但是对于那些为其余的内容编写jQuery的人来说,我没有看到问题或缺乏热情他们的职业
领导人C-创始人兼首席执行官 (Leader C — Founder and CEO)
Leader C, from their perspective, has created a system that works well, and continues to milk it. That system- using an outdated tech stack, ignoring certain best-practices, and refusing to acknowledge Agile as something of any value whatsoever- made them their first profit and continues to do so to this day. Leader C is stubborn against any change to this formula.
从他们的角度来看,领导者C创建了一个运行良好的系统,并将继续发挥作用。 该系统使用了过时的技术堆栈,忽略了某些最佳实践,并且拒绝承认敏捷具有任何价值,这使他们获得了第一笔利润,并且一直持续到今天。 领导者C坚决反对对此公式进行任何更改。
好处 (Benefits)
“culture fit” matters less (likely influenced by the median age of development staff being as high or higher than any other company around).
“文化适应性”的重要性降低了 (可能受到开发人员的年龄中位数高于或高于周围任何其他公司的影响)。
Likely low-stress work environment (burnout may be caused by “lack of subject knowledge” rather than “working too much” — I have found this to be true — ergo a dev job where you already know most everything you will ever need to know, should be low-stress).
可能是低压力的工作环境 ( 工作倦怠可能是由于“缺乏学科知识”而不是“工作过多”所致-我发现这是对的)-进行开发工作,您已经知道了几乎所有需要知道的一切,应该是低压力的)。
悲剧 (Tragedies)
New, better ways of doing things are often ignored in favor of established convention that is “known to work” (e.g. business logic in stored procedures, no modern patterns such as MVC, Repository Pattern, etc.).
人们通常会忽略新的,更好的做事方式,而采用“工作的已知惯例” (例如,存储过程中的业务逻辑,没有现代模式,例如MVC,存储库模式等)。
Development staff stops learning and growing and essentially repeats their x year of development for as long as they are there (as the saying goes, mid-level devs can repeat their Xth year of experience over and over and never make the leap to “senior” despite having perhaps 10 years of experience).
开发人员停止学习和成长,并基本上重复他们的x年开发经验 (俗话说,中级开发人员可以一遍又一遍地重复他们的x年经验,而从不跳到“高级”水平)尽管有大约10年的经验)。
结论 (Conclusion)
Company C has been around for a long time and is startup-sized (although often such a company is a very large, stereotypically-corporate entity).
公司C已经存在很长时间了,并且规模相当大(虽然通常这样的公司是一个非常大的,具有定型意义的公司实体)。
For junior developers, Company C can be a great way to get your feet wet. Often Company C-type companies will have a stack most-similar to what junior devs learned and worked with in college.
对于初级开发人员而言,C公司可能是弄湿您的好方法。 通常,公司C型公司的堆栈与初级开发人员在大学中学习和使用的堆栈最为相似。
For mids and seniors, working at Company C means forgoing experience that is needed for career advancement, in exchange for being allowed (perhaps even encouraged) to stagnate from a knowledge and skillset-expansion standpoint.
对于中老年人来说,在C公司工作意味着放弃职业发展所需的经验,以换取从知识和技能扩展的角度出发(甚至鼓励)停滞。
公司B-两全其美? (Company B — The Best of Both Worlds?)
Company B is last in this list because Company B is a blend of Companies A and C in almost every way. Company B, unlike Companies A and C, are mercenaries of sorts. Their business model is comprised of creating custom applications on contracts for their clients. They don’t have a product, per sé. They are the product (or rather, the service). As far as the tech stack is concerned, they are solidly between A and C- not cutting edge, but still keeping up with current trends, more or less. As a contractor, Company B chooses their stack based on the client they are building for. For example, if the client intends on managing the application after Company B delivers it, Company B will use a stack their client’s developers are familiar with. Sometimes this means using jQuery in lieu of React/Angular/Vue.
公司B在此列表中排在最后,因为公司B在几乎所有方面都是公司A和C的混合体。 与公司A和C不同,公司B是各种雇佣兵。 他们的业务模型包括为其客户在合同上创建自定义应用程序。 暂时没有产品。 它们是产品(或更确切地说,是服务)。 就技术堆栈而言,它们稳固地处于A和C之间-并非最前沿,但仍或多或少地跟上当前趋势。 作为承包商,公司B根据要为其建造的客户选择堆栈。 例如,如果客户打算在公司B交付应用程序后对其进行管理,则公司B将使用其客户开发人员熟悉的堆栈。 有时,这意味着使用jQuery代替React / Angular / Vue。
Company B is “Agile”, but effort has been made to customize Agile to best benefit the company.
B公司是“敏捷”的,但已努力定制敏捷以最大程度地受益于公司。
Culture fit is important, but not in the conventional sense. Leader B hires developers who view software development through a certain lens that includes “passion” not being defined by eagerness to learn the very latest languages, libraries and frameworks.u
文化适应性很重要,但不是常规意义上的。 领导者B雇用那些通过某种视角来查看软件开发的开发人员,其中包括“激情”并没有被渴望学习最新的语言,库和框架所定义。
领导者B —创始人 (Leader B — Founder)
![A wall clock at a business](https://miro.medium.com/max/9999/1*7vgMY_X060Cg5a-QDavAyw.jpeg)
Leader B believes very strongly that the workweek maxes out at 40 hours, and actually enforces this. Employees are strongly discouraged from working more than 40 hours in a week, and if they go over 40 hours, they are subject to “frowning upon” similar to if you or I put in only 35 hours at our jobs. From their perspective, needing to work more than 40 hours per week suggests inadequate ability on the part of the employee working more than 40 hours.
领导者B非常坚信,每周的工作时间会在40小时后用尽,因此实际上是强制执行的。 强烈建议员工每周不超过40个小时的工作,如果超过40个小时,他们将遭受“皱眉”,就像您或我只工作35个小时一样。 从他们的角度来看,每周需要工作40个小时以上,这表明员工工作40个小时以上的能力不足。
Leader B rides a line between “legacy” and “cutting-edge” that seems to err more towards “cutting-edge”. For example, Leader B is all for using modern JavaScript libraries for their applications, but is not captivated by things like .NET’s Blazor or React’s Hooks, at least until they are used in a new project.
领导者B在“传统”和“尖端”之间徘徊,似乎更倾向于“尖端”。 例如,Leader B都是为了在其应用程序中使用现代JavaScript库而设计的,但至少在新项目中使用它们之前,他们对.NET的Blazor或React的Hooks并不着迷。
Leader B is pragmatic and will not change procedure simply because another company does x when Company B is doing y. Leader B is open to change, but it must be practical and for good reason. In other words, Leader B falls in between Leaders A and C when it comes to “stubbornness”.
领导者B 务实 ,不会仅仅因为另一家公司在公司B做y时做x而改变程序。 领导者B愿意改变,但必须切实可行并且有充分的理由。 换句话说,当谈到“固执”时,领导者B介于领导者A和C之间。
团队架构 (Team Structure)
Teams are small, consisting of only about three devs. Teams are almost always set in stone, meaning when you join the company, the team you are placed on is likely the last team you are ever placed on at Company B.
团队很小,仅由大约三个开发人员组成。 团队几乎总是一成不变,这意味着当您加入公司时,您所在的团队很可能是您在公司B所待的最后一支团队。
Each team has a lead developer; lead developers at Company B spend about half their time writing code and half their time doing “leader things” like code reviews, architecting new projects and even meeting with the company’s paying clients for design, deployment and troubleshooting of the application the team builds. Leads can also use their “50%” time to read books and articles, and watch instructional videos to further develop their software development and management skills.
每个团队都有一名首席开发人员; B公司的主要开发人员花费大约一半的时间编写代码,一半的时间用于执行“领导力”,例如代码审查,架构新项目,甚至与公司的付费客户进行团队构建的应用程序的设计,部署和故障排除。 潜在客户还可以利用其“ 50%”的时间阅读书籍和文章,并观看教学视频,以进一步发展其软件开发和管理技能。
好处 (Benefits)
“Agility” is balanced and driven by what is best for a particular project for a particular client (this means that harmful Agile practices are abandoned and time requirements to keep up with latest tech developments are reduced).
“敏捷性”是平衡的,并且受特定项目对特定客户的最佳推动(这意味着放弃了有害的敏捷实践,并减少了跟上最新技术发展的时间要求)。
Strict enforcement of 40-hour workweek (many companies say there is good work-life balance and will never straight-up ask their employees to work nights or weekends unless absolutely necessary, but these same companies won’t stop you, either).
严格执行每周40小时的工作 (许多公司表示,工作与生活之间存在良好的平衡,除非绝对必要,否则绝不会直截了当地要求员工在晚上或周末工作,但这些公司也不会阻止您)。
Incentives for continuing education (100% tuition reimbursement, bonuses for obtaining certifications)
继续教育的激励措施 (100%的学费退款,获得证书的奖金)
悲剧 (Tragedies)
- None 没有
结论 (Conclusion)
Company B appears to take the best from Company A and Company C to create “the perfect dev shop” to work for. Company B emphasizes management and leadership skills in their lead developers.
公司B似乎从公司A和公司C中汲取了最大的优势来创建“完美的开发店”以供工作。 B公司在其主要开发人员中强调管理和领导技能。
As far as I can tell, Company B is a great place for junior, mids and seniors; juniors and mids, to grow their software development skills, and seniors to grow their management and leadership skills.
据我所知,B公司是初级,中级和老年人的理想之地。 大三和中级,以提高他们的软件开发技能,而大三级,以提高他们的管理和领导技能。
摘要 (Summary)
The purpose of this article is to compare three very different companies, each in different positions on a spectrum of “Agility”, or how cutting-edge they are with respect to tech stack and SDLC practices. I can think of multiple companies here in my city that are virtually exact matches to Company A, Company B, and Company C. That can’t be a coincidence, and I am hoping others can use the “templates” of these three companies to compare against companies they currently work for or are interested in working for, to be aware of potential “tragedies” and ultimately to aid in the decision of which company to move to.
本文的目的是比较三个完全不同的公司,每个公司在“敏捷性”方面处于不同的位置,或者它们在技术堆栈和SDLC实践方面的前沿水平。 我可以想到我所在城市的多家公司实际上与公司A,公司B和公司C完全匹配。这不是巧合,我希望其他人可以使用这三家公司的“模板”来与他们当前工作或有兴趣工作的公司进行比较,以了解潜在的“悲剧”,并最终帮助您决定迁移到哪家公司。
Is Company B the “best” of the three because of its semi-Agility? Or is its semi-Agility merely an indicator that the company is well-led? Is semi-Agility (partial adoption of “Agile” and the “latest” technologies) a good thing?
就是因为它的半敏捷的B公司的三个“最佳”? 还是它的半敏捷性只是该公司经营良好的指标? 半敏捷(部分采用“敏捷”和“最新”技术)是件好事吗?
Regardless of which of the three companies you consider to be the best, you should try to have answers to all of these questions before accepting a job offer:
无论您认为这三家公司中哪一家是最好的,您都应在接受工作机会之前尝试对所有这些问题做出解答:
How interested is your direct report in promoting people? In promoting you? I’ve had managers express 0 interest in my professional development, and I’ve had managers explain and show me exactly what I need to do in order to get promoted- totally unsolicited (because it’s their job to move underlings up the ranks)! I suggest asking your would-be manager this question directly, even if that means arranging to meet with them yourself outside of the formal interview process (a quick phone call).
您的直接报告对促进人的兴趣如何? 在提升你? 我已经让经理对我的职业发展表达了0的兴趣,并且我已经经理进行了解释并向我确切展示了如何获得晋升-完全是不请自来的(因为将下层员工升职是他们的工作)! 我建议直接向您的潜在经理询问这个问题,即使那意味着要在正式面试流程(快速电话)之外亲自与他们会面。
Is there clear and explicit criteria the company uses to define the various levels of software developer titles? You don’t need to know what that criteria is, just that it exists in a concrete form (written down somewhere) and not in someone’s head.
公司是否使用明确和明确的标准来定义各个级别的软件开发人员职称? 您不需要知道该标准是什么,只需知道它以一种具体形式存在(写在某个地方)而不是存在于某人的脑海中即可。
Are they placing you where you feel you should be? Not every company considers me a “senior level” developer, but many do. Why would I work for the ones who don’t? This is about self-esteem as much as it is about resume-building.
他们会将您放置在您应有的位置吗? 并非每家公司都认为我是“高级”开发人员,但很多公司都认为我。 我为什么要为那些没有的人工作? 这与建立自尊心一样重要。
Are career-advancing activities on your part encouraged or rewarded by the company? Things like tuition reimbursement, bonuses for passing certifications, and paying for employees to attend conferences.
公司是否鼓励或奖励您的职业发展活动? 诸如学费退款,通过认证的奖金以及为员工参加会议支付的费用之类的东西。
Is the tech stack something you are comfortable with? Will you be able to transfer the experience gained with this stack to your next job? If you take a job at the only Ruby shop in town, don’t be surprised if you have to move in order to find another Ruby gig when the time comes to change employers.
您对技术堆栈感到满意吗? 您能否将通过此堆栈获得的经验转移到下一份工作? 如果您在镇上唯一的Ruby商店工作,当需要更换雇主时,如果必须搬家去寻找另一个Ruby演出,不要感到惊讶。
How often do employees have to work nights and weekends? The notion that this is a “startup problem” is untrue. For example, I’ve worked at a “Company C” that expected at least 45 hours per week as a minimum. I find it is best to ask former employees (who left within the last year) rather than current employees to get an honest answer to this question.
员工多久必须晚上和周末工作一次? 这是“启动问题”的说法是不正确的。 例如,我曾在“ C公司”工作,该公司预计至少每周至少45个小时。 我发现最好问过去的雇员(在去年内离职),而不是现任的雇员,以得到这个问题的诚实答案。
翻译自: https://medium.com/@jspinella_88117/3-kinds-of-dev-shops-which-is-best-for-you-fd9c020752c7
windows商店应用开发