DEV Community: Rohit Sahay

What really matters in a coding interview?

Rohit Sahay — Wed, 18 May 2022 17:57:50 +0000

Let’s face it, coding interviews are challenging.

As a seasoned software engineer who has been on both sides of a coding interview at both small and big tech companies, I know what it's like.

And while it's definitely not the only way to measure your ability as an engineer, technical interviews do give employers important signals about candidates.

Below I’ve written the 4 most important things that you absolutely must do in every coding interview.

1. Understand the problem.

This is not only the first thing you should do, but also where I've seen most candidates fail.

There’s nothing worse than diving straight into a solution without asking any questions. Especially when the solution doesn’t solve the exact problem at hand.

Even if the problem is obvious, it’s important to repeat the question and meet an agreement with your interviewer on what problem you’re solving.

This is also the best time to verify your assumptions, and talk through any edge cases. Some edge cases may be important to consider, while others the interviewer might not care about as much. Sometimes your interviewer might not even require you to solve edge cases at all.

Find out exactly what the interviewer wants you to solve for.

2. Discuss your initial thoughts.

Once you’ve understood the problem, still, don’t code yet.

Pause for a moment to think through one or two possible solutions. They don’t have to be the most optimal.

This is where a solid understanding of data structures and algorithms comes in handy. With enough practice, you’ll be able to solve coding problems using common algorithms and patterns.

Take the time you need to learn these concepts often tested in coding interviews. Take a look at my online course on data structures and algorithms to solidify your understanding.

Once you’re ready with at least one solution, clearly articulate the approaches at a high-level with your interviewer. Feel free to talk through the approaches as well as draw diagrams to help explain your thoughts.

Remember, coding interviews are not only testing you on your ability to come up with a solution. You’re also being tested on your communication skills.

This gives the interviewer an idea of what it would be like for the team to actually work with you on a technical problem.

Finally, I highly recommend asking the interviewer if they have any questions about your solution. Make sure to refine your solution based on your discussion with the interviewer.

3. Code a solution.

Now that you and the interviewer have some sort of understanding about your solution, you can finally write it up.

Obviously, you want to make sure to write clearly written working code. Again, it’s more important to come up with a working solution, even if it’s not the most optimal.

I usually use Python for coding interviews, since it has good standard libraries and its syntax looks most similar to English. This helps me explain the solution better (more on that soon).

But it’s always best to use the language that you’re most comfortable with. This gives yourself the best chances of coming up with a working solution within the time constraints.

One critical tip I have here is to go ahead and use those standard libraries to do boilerplate work for you. As long as you explain to the interviewer what’s happening under the hood, and its underlying time and space performance.

For example, if you want to convert an array of integers into a hash table of each elements counts, go ahead and use Python’s collections.Counter(arr) instead of manually writing out a for loop that updates a dictionary with each element’s count. As long as you explain what collections.Counter does, and the underlying time and space performance.

This will save you time, and let you focus on the actual problem at hand that the interviewer cares about most.

4. Explain your solution.

If you’re able to explain what you’re doing while you’re writing code, great!

If you can't, its okay. It’s more important to write clearly-written working code. You can explain your solution to the interviewer afterwards.

When talking through your solution, it's important to express the solution's performance in terms of memory consumption and run time with respect to the input size.

We formally call this Big O Notation in computer science.

Next, step through your code with an example input and explain how your solution would handle it.

Make sure to talk through edge cases and how your solution would handle them as well.

As you go through your solution, refactor your code wherever there's a meaningful opportunity to do so. Your goal here is to make your code as easy to understand as possible. This gives a signal to your interviewer that code readability matters to you.

In reality, code is read more than it's written. There's a high chance that someone else will have to read and even change your code.

Finally, retrospect on your solution. Often times you might run into something you didn't think about.

This is totally fine, as long as you express how you could correct it. After this reflection, discuss the pros and cons of the approach you went with.

Conclusion

Software engineering interviews can be pretty challenging.

No, you probably won’t have to use a linked list in your next job.

And yes, there are many other important factors that go into a hiring decision, beyond the coding interview.

But coding interviews can give employers key signals about how you work as an engineer.

With enough practice, you can give put your best foot forward in any coding interview.

Best of luck!

Rohit is the Founder of Stack Bash, the ultimate guide to coding interviews for both new and seasoned software engineers. While much of the course is free, you can upgrade to the full course with the discount code DEVDOTTO50 for 50% off for a limited time.

How a side project helped my resume stand out by 10x

Rohit Sahay — Mon, 16 Dec 2019 14:47:14 +0000

I started my career as an embedded engineer after graduating from Georgia Tech with a Computer Engineering degree. I learned a lot from working on the firmware layer of ARM-based mobile chip processors. I had the opportunity to work on software projects with millions of lines of C and Assembly code as part of a large team of very smart people.

But there was a lot about the work that I didn’t like. Working on special hardware in the lab started becoming less fun. I had to deal with long compile times, sometimes hours. And many of those times, I’d find out that I need to recompile for some unrelated reasons. Logs had to be extracted from memory and were very limited. Worst of all, breakpoints were not reliable, making it hard to know what code paths were being executed. So disappointing!

I wanted to do something different. So I began reading more about building web applications, which is how I heard about Node.JS for the first time. A Javascript runtime environment that can handle many asynchronous, non-blocking operations? Sign me up.

I went through some basic Javascript exercises using native Node libraries — And I was in love!

Writing Javascript was very different. No need for typing allowed me to write more code faster. Debugging was also way less painful. The feedback right in the console, right when you expect it, was amazing — Print statements and breakpoints actually worked 100% of the time. Best of all, no long compile times.

It was a relief to be able to develop software with just my laptop. No need for big bulky FPGA boards or other special hardware.

Sounds silly, now that I’m many years into my software engineering career. I can’t imagine operating in a flaky development environment. And I definitely appreciate the safety of typed code 🙂.

I put together my resume and applied to multiple small startups working on web-based products. Most of the job descriptions included jargon that I didn’t understand at the time — Ruby on Rails, Backbone.js, Socket.IO. I had no idea what any of that was. But the job title said “Software Engineer”. I figured that perhaps the fundamentals are the same, so I should just apply.

I didn’t get many responses. Except for one company. I got on a phone screen with an engineer, where he asked me what a REST API was. I had no idea at the time. And I failed the phone screen!

After talking to a few friends at web-based startups, I realized that I’d have to give employers more confidence that I can translate my embedded engineering skills into the kind of engineer that they need.

So I decided to improve my candidacy to stand a better chance at getting the role — which I later learned was called, a full-stack engineering role. I picked up Node.JS again. But this time I took it a few steps further. I went through dozens of exercises to create simple programs. I worked my way up to create the infamous To Do app in jQuery and Node, which persisted Todos in MongoDB using Mongoose.JS. My first full-stack, simple web app. I finally learned what a REST API was. I got so into it.

I decided to take my skills a step further and solve a real problem for even just a few users. I worked with a healthcare consulting company to create a web application that helped them coordinate tasks with their clients. This was one of my favorite learning experiences. I worked on small-scale yet core problems on a single page application such as user authentication, front-end and database performance, refactoring spaghetti code, etc. I was able to help people with their day jobs!

I began to re-apply for jobs. But this time, I put my side project on the very top of my resume. While my embedded engineering experience was valuable, my side project made my resume more relevant to the job.

My response rate from employers was exponentially higher. In addition, the side project prepared me for the technical interview. I even got positive feedback about my experience creating a web application that real users actually used. After a few rounds of interviews, I accepted a position as a full-stack engineer at a startup in NYC.

While online courses, interview prep books, and bootcamps are great ways to learn how to become a full-stack developer, working on side projects helped me line up almost every job I took in my career.

You don’t need to create a side project that gains adoption by users. And a side project might not be for everyone. But there are many ways to learn on your own time and prepare yourself to get the job that you want. Even if it’s completely different than what you currently do.

Rohit is a co-founder of Easy Resume, an online resume builder and career advice blog.