DEV Community

Discussion on: On Technical Interviews

Collapse
 
kojiromike profile image
Michael A. Smith

I think you're assuming that you don't get hired in every case because you failed to implement the data structure or algorithm perfectly. Do you know that to be the case? We use theory in interviews in part to gauge a candidate's fundamental level of understanding, but we don't reject candidates outright if they don't remember how to reverse a tree, and we wouldn't hire someone just because they did, either.

Most career self-help books will say some platitude about "it's how you approach the problem."

That's not false, but it's not quite right, either. How you approach the problem isn't just a matter of thinking logically about a problem you haven't memorized the answer to.

As someone who's interviewed and screened hundreds of candidate over a 15 year career, I start every interview hopeful that the candidate will find something interesting and technical to discuss about the question. You may not find a deep dive into FizzBuzz interesting, but there is something you find interesting about software development besides the salary. And you have to be able to find it with most, if not all, programming problems, or you will burn out, fast. Candidates who are excited about programming for a living can become great programmers even if they forget the cases where a Bubble Sort beats Quicksort. But they don't just make great programmers, they create great programmers out of their teammates, too. Personally, that's what I'm looking for in a candidate – someone who is excited enough to overcome the intimidation of a boring or overly theoretical programming interview question and get excited about it, and share why it excites them with me.

Collapse
 
mohamed3on profile image
Mohamed Oun

Great response. But I think good programmers don't necessarily have to be great problem solvers. Some can turn requirements into well-written code very well, even if they don't have the ability to design a solution from scratch. I think that part of the job is not taken into consideration in interviews.
Also, 'passion' and 'excitement' is not a good metric for measuring quality IMO. There are a lot of great developers who only work with code in their daily job, and switch to something else entirely when they go home (Family, friends, hobbies, sports, etc).

Collapse
 
codemouse92 profile image
Jason C. McDonald

I commented elsewhere, but I need to correct something you just said - programming is problem-solving by nature, whether it is building, rebuilding, debugging, or expanding.

You are correct that designing a solution from scratch isn't necessarily part of every job, but you need to understand that a complete inability to design from scratch (or, in the same vein, a complete inability to build on top of existing code) indicates a lack of the core skills that set mediocre programmers apart from excellent programmers.

In case you're wondering, this is coming from someone who trains programmers at all experience levels as his full time job. I've seen all sorts of programmers, and many different approaches, styles, and talents. There is a lot of diversity in programming, but among those that excel at this craft, there are common traits - problem-solving, communication, and a dedication to excellence (often misunderstood as "excitement"/"passion"). These ARE essential ingredients.