Interviewing for a Technical Position Doesn't Have to Be Scary

Jacob Schatz, a senior GitLab engineer, shares how he conducted a technical job interview and his thinking process. Technical interviews are often discussed and may be a sensitive topic for some, so it is worth noting that this article expresses Jacob’s personal views and does not necessarily represent the views of his employer.

Are you an interviewer who feels fearful, exhausted, sad or disappointed? I hope to change this bias.

I believe people can have a good interview experience and I can also find the right candidates. These two things can happen at the same time! After your interview process is over, in an ideal world, you should feel good about yourself and the process no matter what the outcome is. You may feel sad because you didn’t get the job or you’re excited about starting your new job, but in either case, you should understand the reason.

At GitLab, I was in charge of recruitment very early, so I have seen thousands of resumes. When I first joined, I was asked to recruit and form a front-end development team. I'm the 29th employee (we have over 500 employees now), I'm the first front-end developer, so our team has no hiring process. We gradually created a process.

The goal of this article is the interviewer and the interviewer. For interviewers, I hope you know what a perfect interview looks like. An interview should not be scary or terrifying. Here is a guide you can follow that can help you do your part to create the perfect interview. If you are an interviewer, maybe you have perfected your process. This is my opinion on how the interview will take place in an ideal world. There are many different types of interviews, and this article focuses on interviewing developers of all experience levels. I've stuck with some great processes over the years, and this article is a behind-the-scenes glimpse into the candidate process for both parties.

Before I start, it is important to remember that everyone is human and people are imperfect. There is no perfect developer. Treat everyone like ordinary people. It is OK to be surprised by what some people have achieved, but it is not OK to worship others. Talent is both innate and acquired, and you can also learn it. Your interviewer and you are both imperfect. Interviews should not be about perfection. Here is what the interview should look like.

Five things I'm looking for in candidates

GitLab’s values ​​cover a lot of important aspects and you should read it. This is based on the loose foundation of these values.

As an interviewer, I can only focus on so many things at a time when I become a productive and active listener. But I do have five specific things I want to pay attention to:

1. Is this person "clear-headed"?
2. Does this person technically meet the requirements of this role?
3. Can this person be self-sufficient in this role?
4. Is this person strong in communication? Can they communicate well with the team?
5. Can this person handle positive and negative feedback well?

Of course, I'm looking for some other stuff, but these five things are enough to get you the job you want if you interview with me.

Forget nervous. I will never blame you for this. I know you might be nervous, it's absolutely OK. In rare cases, tension can become a debilitating factor, in which case I just ask you to reschedule it. Just don't hang up my phone!

Recognize that there will be bias

We have been trained in bias at GitLab. One thing I learned in training is that everyone has bias, whether you think you are biased or not. Once, I thought of having blind interviews like some orchestras. We never implemented it (and it's hard), but that's why I keep a list of questions and a summary of what I want to cover in every interview. There is a script I can follow for each interview. Everything is as repetitive and similar as possible. As the interview goes on, I will be able to tell if I can ask harder questions. The harder problem is not to eliminate candidates, but to qualified candidates. If you can answer my puzzles, it means you have extensive experience and knowledge. It is important to know that I have to ask trivia questions in some form, but I don't evaluate candidates based on trivia questions . This is to understand your knowledge and depth of JavaScript.

In other words, there is still a trivial question that no one has answered correctly. I will keep asking, and I believe that one day someone will answer correctly. Trivia questions are fun because I'm a major JavaScript fan. I just like talking about all the ins and outs of JavaScript. I'm looking for someone who can be my coding partner. Recruiting people is about finding people you can work with , not people who work for you.

Inexperienced interviewers tend to test you what they know (so that they feel a little safer when they can criticize you for “wrong” answers).

Instead, good interviewers focus on what you know and promote two-way dialogue to explore common fit.

— Jennifer Kim (@jenistyping) April 8, 2019

I want to know your technical capabilities

This is probably what people fear the most. During the interview we ask questions like "Why is the manhole cover round?" The truth is, some companies may ask moderately difficult questions from LeetCode, while others may not ask any technical questions at all.

What am I looking for in your skill set

Experience is more convincing than any technical interview question I can ask. For example, if I'm hiring a front-end engineer position and someone told me they built something cool themselves and we can discuss it, then this is great. After that, I might also need to ask them some questions, or the demo might answer all of my questions (not likely, but possible). But it would be great if we could browse the code for something you are very proud of together.

It would be helpful if you could tell me what you built for another company that I could look at your code, or you could explain it fully. What is the challenge? How did you deal with 10,000 comments? How do you deal with mobile? What are the challenges? Let me give you an example: you built a comment system for GitLab. An interesting challenge for the comment system is to deal with the issue of loading users in the @ drop-down menu to mention other users. It turns out that the JSON payload for this drop-down menu can get very large, and loading it when the page loads will make the page load significantly slower. But loading data is also slow on the first @ key press, as the payload may exceed 10 MB. We want users to have a seamless experience and not realize that the data takes time to load. So, a good way to talk about this experience is to describe some of the methods you have considered, such as:

1. The data is loaded when the comment box first appears in the viewport.
2. Load data when the user hovers over the text area for the first time.
3. Once the user starts scrolling with enough momentum, the data is loaded.

The last one is not a boring solution, but I did hear someone say it during the interview.

I might ask about algorithms and data structures

Hey, interviewers, are you recruiting people for your marketing website? Don't ask them the hardest algorithm and data structure questions. Yes, algorithms and data structures play a huge role in all aspects, but more importantly, candidates understand responsive design, as well as animation and performance. Now that we are talking about performance, they should understand the big O notation. They should know what caused the redraw. Take a look at Firefox Monitor and compare it to Salesforce. Firefox websites are faster in every aspect. Why is it faster? Why is the Salesforce website so bulky and slow? Resize them...Oh! Big O may help you explain some parts, but it is important to be able to explain the entire picture.

By the way, big O notation, because I mentioned it.

Big O is a way to describe your code running time and/or how much memory space your code will take in the worst case. I think it's really good to learn it and it helps with everyday programming. You can and should learn it, which can take about an hour. After an hour, you're likely ready to answer any legal big O questions the interviewer will ask.

Big O is not a course you need to take. Here are some articles that can explain it to you in less than an hour:

• I like this post.
• For more formal but ultimately easy to understand articles, check out Brillant.
• For a cheat sheet that you feel comfortable with, check out the big O cheat sheet.
• For some great examples (in different languages, but very easy to understand), check out this article.

OK, back to the algorithm and data structures in the interview.

Since these types of problems may arise, it is worth doing some homework ahead of time. There are two typical gold standards for interviews for learning algorithms and data structures.

• There is a book "Cracking Coding Interview" written by Gale Lackman McDowell.
• There is a website called LeetCode with a lot of resources.

There are many other things that are recommended for algorithms and data structures, lots of coding interviews, but instead of remembering every example in the world (which won't solve any problems for you), learn how to solve them.

As I said above, front-end engineers should learn Big O for their health, because it is good for you, just like eating your Webster cereal. Unless the work requires extensive algorithm and data structure knowledge, the interviewer should not ask a wide range of algorithms and data structure questions . If I'm designing a front-end framework, like Vue, it's very important to optimize the DOM difference algorithm or at least understand the implementation of the algorithm you're using. But does that mean I'll ask seven additional puzzles from CTCI? Won't. You are testing understanding, not memory. When people solve these problems (when I ask them), I want to see them think about this problem and we solve this problem together, not I want to see them get the right answer. It's all about figuring out what you can do as an engineer after getting the job — not what you remember yesterday. A person who understands algorithms will be better at implementing them than someone who has to learn them at work.

Are you recruiting people to build a dependency management system? This person needs to know a lot about algorithms and data structures.

These are two extremes of the spectrum, but in my opinion, not everyone needs to know how to write a red-black tree from scratch – but everyone should know Big O. However, learning typical algorithms and data structures will greatly improve your skills as a software developer.

When I do ask questions about algorithms and data structures, I ask the following questions:

• What is a linked list? Can you show me how to implement it with and without arrays in JavaScript?
• What is the difference between BFS and DFS? Can you achieve one of them?

If you answer these questions wrongly, you won't eliminate anyone. Remember, I don't use trivia to evaluate candidates.

Are you clear-headed?

During the interview, I also looked for many soft skills. This is my way of determining if you are “clear”.

Strictly speaking, it means you made the right decision, but for me it's much more than that. A clear-headed person makes reasonable decisions. It is a good thing to have a different opinion from me, but we should agree with a standard of knowledge. For example, we should all agree that it is a bad idea to just use absolute positioning to layout the entire blog. This is not a reasonable decision.

But I might create a scenario like this to check these skills:

Let's go to CodePen and create a static blog homepage. We need a navigation menu, we need a place for the title and article, and then at the bottom let us have some comments and footers.

I'll then walk you through the different ways to create navigation and the pros and cons of each. For many of the front-end developers I'm hiring, I'm wondering if they understand some core JavaScript, so I might ask them to add some small features using only native JavaScript.

When a framework does everything for you, you don't need to do things yourself. I want to know if you understand the global situation.

"Sobert" is a fancy statement, meaning that your things are organized. This is not an exhaustive list, but these are the things that caught my attention:

• Take good care of yourself

• You speak professionally (this is more influential than most people know)

• Very private details omitted

• Answer questions concisely

• Take time to think

• When you don't know, say "I don't know"

• Confident, but don't be conceited, even if you are not

• You accomplish what you started

• You are honest

• Can you say no

• You know what you want and you want to help others get what they want

• You will disagree, and even debate, but know when to give up

• You can communicate effectively during the interview

• Is this conversation easy or exhausting?

• Are you fluent in English? The accent is absolutely fine!

• Do you understand the concept being discussed?

• You are a kind person.

About the last point: Kindness doesn't mean you are a weak person. Kindness is an important part of challenging others and giving feedback.

I want to see if you are self-sufficient

It seems obvious now, but I believe – after GitLab’s job – self-sufficiency is something that interviewers should look for in everyone being hired. Self-sufficiency plays a major role in your role in the company.

For example, to get to the extreme, think of a general manager who may have the least amount of external guidance than anyone on the team. Everyone has a responsibility, but the general manager usually has to be good at many things, including (but not limited to) marketing, sales, and management. All of this will change according to the size of the team. Their role is probably the vagueest. They are very self-sufficient. In my opinion, senior developers should be able to take on the entire large-scale functionality and implement it correctly.

This is not to say developers should not communicate in the process. They should ask questions and work with others to find the best way forward.

Reviewing interviewers’ codes has a chance to get boring (in a good way) because we know what to expect from them. We rely on them to mentor developers with less experience. Junior developers should also be self-sufficient, but may not undertake large projects alone. Junior developers often do well in small pieces of work. For example, it can be a great thing for junior developers to take on small tasks that senior developers take on in large projects. Senior developers can also guide junior developers and guide them in the right direction to help them become more self-sufficient, which is a good thing for both parties – and for managers, as they can delegate more work to senior developers.

If you are a front-end developer and need to be hand-in-hand at this stage of your career, it is completely 100% OK, everyone has experienced it. Or, if you are applying a lot of places but not getting any results and are very frustrated: I suggest you become more self-sufficient before applying. One way I suggest you become more self-sufficient and get the job you want: forget about code examples, small cart apps, and their likes because they do not perform well in job interviews. Build a complete app for someone and do it at a low price or free way. Find a church, synagogue, shelter or other person near you and take the initiative to create a website for them.

Remember that free customers are usually the worst. It will be worth it when you can say that you have done work for several clients. To earn extra points, document your work in some blog posts. These content looks great on your resume and will make you stand out from the rest of the world. I know anyone can easily get a website through Wix or other website building platform, but nothing is better than a well-designed custom website. I think I made about 10 or so websites before I got my first programming job. I could write a book to tell those crazy stories.

Communication and feedback are key

This is another point that seems obvious but is difficult to do well. Communication is well documented in the GitLab manual, so I won't go into detail about it, just say I follow GitLab's values ​​and we're looking for other people who hope to follow those values ​​as well. Positive and negative feedback is also well documented in the GitLab manual, so I won't cover it here.

How do I do the rest of the interview

Because we interviewed a lot of candidates at GitLab, we followed a common process so that we could repeat it easily. I won't go into detail about our interview process, as it continues to evolve. But, overall, this is the process I followed.

Tell me about yourself

You will be asked a famous question similar to "Tell me about your own situation", "Tell me what you have been doing" or "Tell me about your situation during [Company Name]". When I ask this question, I try to find the connection between the job you applied for and your past job. It is best to find common ground in advance.

For example, as an employee of GitLab, if I apply for FAANG as a personal front-end engineer, I believe GitLab and that company are working to improve page loading speed. Maybe I noticed that when I first joined GitLab, there were 26K event listeners on one page and was able to reduce it to 0, reduce loading time by 50%, to 200ms speed. I believe this will be related to the conversation.

So, as an interviewer, I might say this:

"Hello! I'm a front-end engineer at GitLab, I've been here for 3.5 years and I've made a lot of great improvements during my tenure, and my favorite areas of work are performance, UX design implementation and architecture design."

At this point you don't want to get into too many details, but it's best to give the interviewer some facts to deal with. When I asked this question, someone started to tell 10 minutes of their entire career in detail, which was frustrating.

What made you apply for our company?

The interviewer may ask, “What made you decide to apply for our company?” Hope you are happy to work for this company—or else, why bother applying?

For some reason, this issue often over-excites candidates, who end up messing up our company’s name. This is totally normal behavior, especially if your company sounds like another company.

What I'm looking for at this point is to see if you're just looking for a job, or you're really excited to work with us. We want people who really want to work with us. At this time, I can also see whether a person understands the situation of our company. For example, some people like our values, read them, and want to work in a company that has them. Some people want to solve the big problem we are solving. Some people have read our team’s speeches and articles and want to work with people as smart as they are.

What are your five things?

Finally, I like to ask if the candidate has any questions about me. This is an important part of the interview and you should think about it carefully beforehand. Your goal is to get me to respond, “Oh oh oh, good question!” On the one hand, I’m really trying to answer any questions you ask, so don’t be shy. On the other hand, I'm also trying to measure your interest in the job, so words like "uh, I don't know" are often very frustrating because it shows that you may have been distracted or that the job is not interested in you. This can leave behind an unpleasant aftertaste.

Find your interviewer and get to know them. Doing this in advance can be an eye-opening exercise. You may understand their customer acquisition strategies, which can lead to many other interesting questions. If the company is a startup, do they plan to be acquired, or do they want to conduct an IPO? This will make you sound professional when you have a clear, well-thought-out question, which is also one of the important things I have listed.

If you can't think of any questions to ask, do you really want this job? If the interviewer has a personal website, check it out and if there are no other questions, you can ask them questions about the comic books they wrote and posted to their website.

But I suggest:

1. Ask interview questions that you are usually interested in. Consider this before an interview, because a truly thoughtful question can often greatly improve your candidacy.
2. What are you looking for in the company as a candidate? What does the interviewer need to prove to you in order for you to accept the job?
3. Are these people as clear-headed as you? You know, it's two-way.
4. Does this look like an interesting job? Do you even want a fun job?
5. Who will you report to? Have you talked to them? Can you have the opportunity to talk to them during the interview?
6. Are you underrepresented? For example, are you replacing someone or taking on a new role? How many others will do what you are doing? What signs should other underrepresented people pay attention to? What signs will show you this is a good environment for you?

Don't ask questions about salary or benefits at this point; these things can be discussed when you have a preliminary telephone conversation with the recruiter (and probably should) before you find someone like me.

in conclusion

Unlike programming, interviews are not an accurate science. You are trying to prove that you are excited about the prospect of working with the company. You want to prove this to the interviewer and yourself. Hope you want an interesting job. This guide is not a script to follow, but more of a few loose ideas to help you get into the interviewer’s mindset, which also contains some tips for other interviewers. Maybe I pointed out something you might not have known before.

Remember that, in theory, an interview shouldn’t be a terrible process, but more like a search for a partner to work together.

The above is the detailed content of Interviewing for a Technical Position Doesn't Have to Be Scary. For more information, please follow other related articles on the PHP Chinese website!