今日推薦開源項目：《舉個栗子 tdd-tetris-tutorial》
今日推薦英文原文：《The Tech Interview Prep You Forgot》
今日推薦開源項目：《舉個栗子 tdd-tetris-tutorial》傳送門：GitHub鏈接
推薦理由：測試驅動開發，簡稱 TDD，簡單來說就是以通過測試為目的的開發方式（儘管眼光直接放在了結果上，但是這並不代表能夠忽視代碼質量）。這個項目通過一個簡單的俄羅斯方塊的例子來介紹 TDD，初學者可以通過編寫代碼完成預先給出的測試來加深對 TDD 的了解。不過即使學習了新的開發方式，也不要忘記它們只是工具，選擇正確的工具使用而不是只吊在一棵樹上會更有效率。
今日推薦英文原文：《The Tech Interview Prep You Forgot》作者：Chris Cooney
原文鏈接：https://medium.com/better-programming/the-tech-interview-prep-you-forgot-2df05998044
推薦理由：面試問題——只不過這次被詢問的是面試官那一方
The Tech Interview Prep You Forgot
Be certain this is your perfect company
Interview prep typically refers to the answers we』re going to give. Technical test practice, reading articles about the latest messaging system, or even reading up on body language. But we rarely think long and hard about the questions we』d like to ask.I』ve interviewed candidates for a while now and I』ll be honest, I don』t remember those that answered questions easily. Their relaxed, casual confidence didn』t stick in my mind. They were qualified and I probably recommended hiring them, but I can』t pick out a single name as I type this.
I』ll tell you who I do remember. I remember the candidates that asked me some tough questions. Individuals that had a self-possessed, candid way about them. It gave them a whole new type of intelligence. They knew what good looked like and they wanted me to pass their test.
Below are some of the best questions I』ve been asked, and some questions I』ve asked myself.
I』ve thought long and hard about these questions and, if you can get these topics discussed, you』ll have a much clearer image of the various facets of a technology company.
Do You Have a Growth and Progression Plan in Place?
Any company that has thought seriously about progression would have come to some quite important features of an effective growth policy.- Progression needs to be fair and meritocratic.
- People shouldn』t be forced into roles that they aren』t comfortable with.
- We should be aware of what each colleague wants to achieve, whether at or outside of work.
This typically translates into a set of processes that both managers and colleagues can use to develop their career.
Make no mistake, the process can be lightweight. A simple reminder meeting every few months or a couple of measurable objectives here and there. It doesn』t need to be endless form-filling.
What I look for in the answer
A good answer is simple. The interviewer should talk you through their process in a clear and confident manner. I always start by looking for some kind of cadence — every six months, annually, monthly, whatever.Secondly, I look for some kind of peer review. That is, a manager can』t just keep giving money to their best friend. This helps to maintain a meritocratic policy that doesn』t stifle the growth of a capable engineer, simply because they』re not in the right circles.
Finally, I look for it to be colleague-driven. That is, the company isn』t going to force me down a track I don』t want to go down.
I provide my goals and work with my manager to marry that up with a profitable journey for the company. This usually takes the form of objectives, so pay attention to how those objectives are formed. It』s important.
Red flags
There are a few red flags that can appear. They』re simple to detect and should be cause for further probing. They aren』t instant fails, they』re prompts for investigation.- The interviewer takes offense that you』re talking about progression before you』ve got the job. This points to a traditional atmosphere where progression is earned with something useless like time-served.
- 「We just do it as and when」. Ad-hoc progression can work but often, it translates into insufficient planning being done for progression and thus, a battle every time you want that 1% salary bump. This isn』t a guarantee, just probe a little deeper to find out the truth.
- Awkward silence, followed by exasperated, tired laughter. This is the reddest of red flags — it indicates that it』s absolutely mental and progression is very much an unsolved problem.
How Do You Encourage Consistency Between Teams?
Consistency is all the rage in larger organizations, with drift and poor alignment regularly introducing problems for operational performance.A company of a sufficient size (>~40 engineers) will have had long, frustrated, and serious talks about how to ensure the same problems aren』t being solved over and over again.
What I look for in an answer
There are a few simple ways that organizations can maintain team autonomy and encourage alignment across products and services. It takes practice and effort, but it』s perfectly possible.- Engineers are encouraged to assist in multiple teams and cross-pollinate knowledge between those teams.
- In larger organizations, individuals have been hired who encourage teams to talk to one another. Roles such as principal software engineer, architect, or development lead can have this responsibility. If you hear these roles, it』s worth checking.
- Automation. Instead of forcing teams to spend effort doing something a certain way, automate it and remove it as a problem for all future teams. We call this 「paved road rather than guard rails」. Make the ideal choice also the easiest choice.
Red flags
There is one monster, mammoth red flag that would be an immediate deal-breaker for me. Any kind of hint that a design is pushed from the top down is a strong no from me.
Ivory towers are not a good look for a tech company
This type of organization will stifle innovation and attempt to reduce their engineers down to typists.
In the past, I』ve inquired further about how they maintain team autonomy, but I』ve never, ever seen a satisfactory answer, when coupled with a top-down information flow.
How Often Do You Have Outages?
You』re going to be told that this company is working on all the latest technology. They』ve got serverless, Kubernetes, jQuery threads that are run on exclusively green energy, across eight cloud providers, and one 「on-premises」 datacenter in a secret location (usually Milton Keynes).Don』t be dazzled. You』re getting the sales pitch. What you need is a metric, some kind of clear picture of technological capability within the organization. Outages are very useful for letting you know how their machinery is running.
What I look for in an answer
The absolute ideal answer includes a rate, 「3% of our deployments fail」 or 「we had 99.995% uptime last month」. That lets you know two things.- If the number is low, you have a clear indication that their software is running smoothly. It might be a madhouse underneath (read: the Amazon model) but things are still running.
- The fact that a number exists at all means they likely have a mechanism in place for measuring and responding to issues. This data-driven mindset indicates an intelligent approach to operations, rather than firefighting without any mind on improvement.
This is the human approach to the problem. It』s less data-driven but it reveals their attitude. They』re happy to discuss them.
Red flags
「We never, ever have problems」 is a worry for me. Unless it』s a tiny organization with very little code, this is a potential symptom of multiple problems.- They have no idea how many issues they have, i.e. they aren』t tracking them.
- They』re lying to you and know that the truth would make you head for the hills.
- What is your testing strategy for your products?
- How do you ensure deployments can be performed independently?
- How do you manage your technical debt?
- How much work in progress (WIP) do you have? How do you manage it?
- How much automation do you have around your deployments?
The interviewer will be aware of their weaknesses as a company and have no problem discussing them with you. In an unhealthy interview, it will become stand-offish and defensive.
How Do You Regularly Inspect and Improve Your Working Practices?
This question has been a very, very faithful friend for a number of years.Typically, your interviewer won』t have heard it from many other candidates and they won』t have a pre-canned answer that they can wheel out. Some of the most candid and useful conversations that I』ve ever had in an interview have been in response to this question.
What I look for in an answer
I want to hear three things mentioned before I consider an answer to be satisfactory:- A mention of feedback loops at multiple levels. Lower-level colleagues can engage in a smaller feedback loop that cascades upwards and impacts larger feedback loops. Anything from running scrum to a suggestions box. Just something that makes it clear that they care about feedback.
- A regular opportunity for genuine introspection. This might be a coffee morning or a 「town hall」 meeting. It might be 「show and tell」 meetings on pay-day, or it could be pizza and beers every few months. It doesn』t matter so much, provided the event is inclusive and the event is regular.
- A story of a time when some feedback made its way all the way up to the decider at the top of chain and influenced genuine change in the company. I want to hear a specific example with a tangible output.
Red flags
Look out for a lack of detail. Almost every successful tech environment has a few mechanisms by which they surface improvements. Very, very few just 「go with the flow」.You might be talking to that 「one-in-a-million」 company that has got improvement baked into its very fabric, but you probably aren』t.
Press for a story, some scrap of history that points to their ability to react to the feedback of even their lowest ranking colleague. It』s important, it』s the difference between leadership and management.
If you can』t get a single story and the company isn』t new, that』s a worrying sign. Either none of their employees are coming up with ideas, those ideas are being stifled or, worst of all, they』re being ignored.
You don』t want to put yourself in any of those environments.
What Do You Normally Look for in a Candidate?
As soon as you ask this, you』re likely to get a technical response. 「Great core Java skills and a proven track record of operating production systems」.Press further, look for more. See what type of person they think will thrive in this environment. You』re looking for two key pieces of information.
- Are they completely insane?
- What kind of environment do they have?
「Yeah, we just want someone to write the code, define the strategy, design the architecture, manage the stakeholders and make us coffee whenever we want it.」
What I look for in an answer
This is a subjective question, so I can』t give you an objective answer.It comes down to what you want out of a workplace. What I want is simple. An open, collaborative environment where I have the permission to innovate, make mistakes, and learn, without fear of punishment.
To that end, there are some key attributes that I always look for when I am interviewing people.
- The candidate gives and receives feedback without ego.
- They enjoy technology. They might not be the best but they really, genuinely love it and it』s obvious when they speak about it.
Red flags
If I hear any of these phrases, I have to resist the urge to scream.- 「A real go-getter.」
- 「Someone who can take the heat.」
- 「A hustler.」
And that means you too, friend. You』re just a lean piece of meat to them and boy, are they gonna burn you out. Don』t get suckered in to 「the hustle」. As the founder of Ruby on Rails likes to say:
「It doesn』t have to be crazy at work」
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
