今日推荐开源项目：《样例 Compose-samples》
今日推荐英文原文：《My Advice After Interviewing 100+ Software Engineers》
今日推荐开源项目：《样例 Compose-samples》传送门：项目链接
推荐理由：该项目包含许多使用 Jetpack Compose 搭建安卓应用的示例。Jetpack Compose 是安卓用于构建 UI 的一种新方式,采用代码而非 xml 文件的方式。
今日推荐英文原文：《My Advice After Interviewing 100+ Software Engineers》作者：Hugo Rocha
原文链接：https://medium.com/swlh/my-advice-after-interviewing-100-software-engineers-e34bc3cbc669
推荐理由：一个面试官给软件工程师的一些面试和工作上的建议。
My Advice After Interviewing 100+ Software Engineers
This awkward and stressful thing between emerging a hero after completing the 12 labors of Hercules and the pointless successive hula hoops jumps of a circus trained animal, which we lightly call job interviews. We all hate them, yet they are an unavoidable fact of our professional lives.When for the first time I ventured naively into the uncomfortable and inhospitable world of software engineering technical interviews, it didn’t take long for me to feel that judging a software engineer’s ability in 2 or 3 hours is as accurate as cruentation.
However, I always wondered how it was to be like the one sitting on the other side, what it takes to understand if an engineer is a good fit for the role. For the last couple of years, I conducted over 100+ software engineering technical interviews, and although each company has its unique process, there are common pitfalls people tend to fall. Here is my honest advice on how to avoid them.
The good software engineer
“The road to success and the road to failure are almost exactly the same.” – Colin R. DavisThere isn’t a unique definition for a good software engineer. It relates to the needs of the role and the diversity and maturity of the company. A recent startup would undoubtedly need a short time to market, while a more mature company that grew to a large customer base would probably be facing some scaling and architectural challenges. Building product while understanding what makes sense to the business is different than solving complex technical challenges. A detailed perfectionist engineer is different from a fast iterating one. You need to understand what the company is looking for and frame your behavior and discourse into that mindset. Don’t do a one fits all CV, instead adapt it to that reality. If you have to do a pitch (in a way, you always do one formally or otherwise), frame it in a way that you show how you will be an asset to that specific company. You should understand the necessity the role is trying to fill and ask yourself if that motivates you if it does then embrace it. You should figure what the “good” definition looks like for the company’s context and show how your knowledge, experience, and attitude fits in that definition.
Do your homework
“By failing to prepare, you are preparing to fail.” - Benjamin FranklinGoing on an interview without having a clue about the company it’s like going on a date and talking only about yourself, doesn’t mean there won’t be a second date but doesn’t give a good impression. Put in the effort to learn about the business, its objectives, it’s mission, strategy, and results. I would never fail someone for not knowing anything about it, but it is a hint of the candidate’s motivation. Also, it is a standard criterion HR tends to evaluate. Besides business goals, be sure to check the company’s tech blog if they have one and know their tech stack. Not very often candidates show legitimate interest for the company, but when they do, it is an excellent way to stand out.
Have a critical sense
“It is the mark of an educated mind to be able to entertain a thought without accepting it.” - AristotleI’ve met exceptional technical experts throughout my career and they were all kinds of different people. Still, all of them had at least one thing in common; they were the ones who defied the status quo and made the processes and technologies improve. So many candidates, when asked if they have questions, have nothing to add. Avoiding asking questions is a wasted opportunity, grab that moment to ask about the technical decisions the company made and the challenges they are facing and discuss the tradeoffs of each technology.
Examples:
Are they considering moving to HTTP/3 yet?
Are they moving to an event-driven microservice architecture? What kind of message broker are they using? Why not use Kafka instead of RabbitMQ?
What kind of database technology are they using? What was the use case? Would ElasticSearch be a good alternative to SQL in that use case?
And so on. Questioning the technical decisions will show that not only you know these technologies and can argue when they should be used but also that you can think critically and ultimately care about improving whatever applications you work with.
Technical challenges
No amount of experimentation can ever prove me right; a single experiment can prove me wrong. - Albert EinsteinThe ungratefulness and straight-up unfairness of the current technical interview state is appalling. Most processes involve solving some kind of algorithmic problem related to computer science fundamentals like a graph search or sorting algorithm. I find anecdotal that a candidate has to implement a tree transversal algorithm with a minimal resource footprint so that when he gets the job, the first thing to do is to debug a ten-year-old monolith. As both a candidate and interviewer, I find this pretentious attempt to glorify the complexity of our work disheartening. These types of challenges are very likely to dismiss senior developers who don’t have these concepts fresh on their minds, even though they might have paramount experience in the role.
I agree these types of exercises aren’t entirely useless; the ability to solve small problems fast relates to the ability to solve complex problems that sprawl over several days, but they are fundamentally different. The interview process should reflect the best it possible can the reality of day to day work. Some processes include finding and patching bugs on a real application, pair to pair programming, or implement automated tests that I find much more adequate than an esoteric algorithmic problem. For these types of situations, be sure to feel comfortable with the company’s language of choice, and don’t be afraid to ask questions to understand the full picture of the challenge.
For most processes though, you will be faced with some kind of algorithmic or data structures problem, no way around it unless to have a sound knowledge of computer science fundamentals. Resources like the book Cracking the coding interview, Leetcode, or Pramp can be good references.
Either way, be sure to explain your reasoning out loud. Usually, problems build atop of each other, it doesn’t matter if you fail in a subject as long as you can ace the rest of the problem. The interviewer will help you if you get stuck, it is crucial to see a candidate recover from a less-known subject and do well on the rest. Also, an experienced interviewer might change from questioning to teaching when you struggle, don’t interpret this change as a failure; the changing of context helps unblock most people.
The interviewer is there to help you as well as to evaluate you, not to judge you. See him as an old colleague that is mentoring you on a problem. Make sure to discuss the various solutions and tradeoffs; it will show how knowledgeable you are with the subject.
Don’t get demotivated
Success consists of getting up just one more time than you fall. - Oliver GoldsmithI once had a candidate who was very shaky and unsure during the interview. Despite being insecure and second-guessing himself, he did well so he still got hired. However, after settling, on the day to day job, he was extremely confident, able to lead discussions, and guide the team on technical subjects. Later I asked him how come he had such a diffident attitude during the interview. He then explained to me that he had a string of disastrous interviews and at the time wasn’t coping too well with the rejection. Rejection is a part of the process and you can’t let it get to you.
It simply isn’t possible to evaluate every single ability relevant to a software engineer in a few hours. Each process chooses the relevant ones for the company and tries to evaluate them the best way possible. Which can be the ones you excel at or not.
Bad hires are tough for the company, especially the team they join in terms of morale. They also have a significant cost. Add that to many companies not having a standardized process (the point is comparing candidates, so every interviewer should tackle the same subjects, and there should be a defined process, equal for every interviewer) and you are left with a significant percentage of false negatives. Doing bad on an interview doesn’t mean you’re bad. It means that the abilities you showed weren’t the best for that process at that given time.
I know, when I fail and read or listen to something like this, I always think it’s bullshit. All my life I’ve always tried to be a fighter. However, there were times that I lost too many fights. A fighter that is always losing is nothing more than a punching bag. But sometimes you have to find that inner strength to drag yourself out of the wreckage where you have given in. To get up, raise your hands and fight one more time and not let the failure get to you.
It’s all about passion
“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it.” - Steve JobsAs we make our way through the confusion and chaos of our daily lives, we thirst for those moments of clarity, where time bends and reality fades as we lose ourselves in a challenge or a task. In those moments of transcendence, a whole lifetime can pass you by without you even noticing. That’s what programming is to me and so many of us, that everlasting and unwavering passion that is chiseled in our core. And that same passion is the secret ingredient to success.
I saw candidates ace our interview process to only be average on the role they were hired for. They weren’t bad, they were talented and knowledgeable, but they just performed averagely. Sometimes you are good at things you don’t really care for, but it’s that passion that will drive you to succeed. It’s not easy to rate a software engineer’s passion. But if I asked you what kind of side projects you have or what was the best project you ever worked on, you would probably be able to eagerly discuss a handful of projects for a whole afternoon. It doesn’t matter if it was a platform with millions of users or a side project that barely works. A passionate programmer would enthusiastically describe every pattern he applied, every challenge he conquered, even every hack and failure, with joy and nostalgia. Then any interviewer would know, the guy across the table is just like him, a fellow programmer hopelessly passionate about coding.
It is a very authentic reaction; you almost can see it on their eyes and body language. Either you are passionate about it, or you aren’t. If you are, be sure to talk about those projects that move you, that can be the difference between an average interview or an excellent one.
Wrapping up
I always felt that the stressful part of being a candidate was knowing I needed to get the job and to prove myself I was good enough. The role of the interviewer isn’t completely deprived of stress, the interviewer needs to be sure to have strong reasons to either approve or fail someone so the decision can be audited, in my case, it always is, especially by my conscience.Most interviewers had to be interviewed at some point so odds are they are sympathetic. I hope I helped to shed some light on the view from the other side, and I honestly hope my advice will help you get the job you really want.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
