3 ms·
DSA questions make absolutely no sense in 99% of the cases because 1) Most modern programming languages have ready-made implementations (by way of libraries) f
by justboxing 9y ago
DSA questions make absolutely no sense in 99% of the cases because
1) Most modern programming languages have ready-made implementations (by way of libraries) for almost every imaginable algorithm, written in the most efficient way, and probably all open source, so you can modify it if you feel otherwise.
and
2) It's very easy for a not-so-capable-engineer to "hack" the coding interview by -- as you yourself have mentioned -- memorizing the DSA questions and answers from various coding interview Q&A sites.
The 1% where they would make sense is if you are hiring specifically for such a role. Example: Amazon or Fedex trying to optimize their transportation model.
I've interviewed over 30 different candidates for 3 different companies I worked at. Here's what I do, and it works for us, YMMV.
1) Before the interview, I go over what the position is, the job requirements, ex: Front-end Web Developer, or Back-end Engineer, or Full-stack Engineer.
2) I go through the code-base of a couple of projects we are currently working on, and based on the job requirements, I create 5 to 10 code-related questions. Ex: We were once hiring a C# and ASP.Net engineer and had an enhancement in our website code base, to show open-close hours of bank branches on the website. Most people miss the importance of tracking timezones of the branches and pegging the open-close hours to some timezone , ex: UTC. So I created a question to the effect of "We need to store and display bank branch hours on our website, how would you go about designing a data store, and displaying it on the website." If the interviewee does not mention anything about timezones, then you know that they are not thinking through this correctly. These type of questions are a majority of the questions I come up with.
3) I throw in a couple of simple 1 line-answer type questions that will expose any lack of understanding of the fundamentals of programming, print it, and review the question with them and give them time to read it and answer. Ex: What's the difference between "==" and "===" in javascript. Or variable scopes in a sample method. etc.
This way, you are examining the candidate practically for what he/she will be working on, if hired and he/she is likely to be productive from day 1.
- tmyklebu 9y ago> 1) Most modern programming languages have ready-made implementations (by way of libraries) for almost every imaginable algorithm, I really don't think this is true of any programming language, modern or not. > written in the most efficient way, Elementary but nontrivial problems like string matching and integer sorting often have poor standard library solutions, not to mention that "the most efficient way" is context-dependent. > and probably all open source, so you can modify it if you feel otherwise. Intel's MKL, which has a ready-made matrix multiplication that probably is about as fast as possible on their hardware, isn't AFAIK open-source. (Regardless, if you modify the standard library in your own environment, you risk creating serious interoperability headaches for yourself later on.)
- dozzie 9y ago>> 1) Most modern programming languages have ready-made implementations (by way of libraries) for almost every imaginable algorithm, > I really don't think this is true of any programming language, modern or not. Moreover, for this attitude (overreliance on external libraries) you get another left-pad.
- kevan 9y agoDisclaimer: I've done more than 60 interviews at Amazon. My views are my own. When we ask DSA questions we don't care about the data structures or algorithms. We care about the logical reasoning and problem solving skills that enable you to solve those problems. We contrive particular questions to give you chances to showcase those underlying skills. If candidates can get through an interview by memorizing problems from Leetcode or HackerRank then the interview process isn't working. Most companies miss the mark on this.[1] Sometimes I ask a question and the candidate recites an optimal solution in 2 minutes. Great, they got an optimal answer. But it's useless for me — I didn't get any data to inform my hiring decision. Maybe they created the solution from scratch using strong logical reasoning and problem solving skills. Or maybe they saw that exact problem the day before when prepping for the interview. Without digging deeper it's impossible to know. In these situations it's the interviewer's job to gather more data. Sidenote: If you've seen the same question recently it's better to tell the interviewer. If you pretend that you're solving it from scratch your interviewer can probably tell. And if they don't notice you'll just get harder questions later in the interview that you'll probably strike out on [1] Gayle McDowell has a lot of insight on how to conduct effective coding interviews if you're looking to improve your company's process.