Edge cases, running time, and correctness. If you're not hitting at least 2 of these perfectly, then you're not writing good code.
How to Pass a Programming Interview
51–60 of 570 posts
Re: How to Pass a Programming Interview
#52The practice section doesn't mention anything other than the book. Are there any other resources that people use to prep for an interview? Looking for something that tests algorithms and data structures more than solving tricky problems.
I've had fun practicing on http://www.codewars.com/
You can choose your languages and it's all wrapped in a nice leveling-up game style. You pass and rank up based on your solutions to predefined community problems, and have a test-driven approach enforced in the editor.
Re: How to Pass a Programming Interview
#53Earlier quoted context omitted.
Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.
It sort of makes sense. If someone knows a language well, they shouldn't have much trouble writing it syntactically correctly on a whiteboard. Especially in languages which have simpler syntax, like Ruby vs eg Scala.
In his "Programming pearls" book, John Bentley stated that he always first writes non-trivial algorithms in pseudocode, and only then transforms them to the destination language.
The point is, it's much easier to focus on the idea of the algorithm when writing it down in pseudocode, without having to worry about c / c++ details that obfuscate the idea.
Re: How to Pass a Programming Interview
#54Earlier quoted context omitted.
Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.
It sort of makes sense. If someone knows a language well, they shouldn't have much trouble writing it syntactically correctly on a whiteboard. Especially in languages which have simpler syntax, like Ruby vs eg Scala.
Except when you're used to working in an IDE that generates a lot of the syntactic cruft automatically.
Re: How to Pass a Programming Interview
#55> "That’s exactly the point. These are concepts that are far more common in interviews than they are in production web programming." The list includes things like Big-O analysis. While, formal analysis is certainly not a day to day occurrence of most programming, knowing what the runtime complexity of the code you are writing is almost always important. While, I generally don't care for most algorithmic problems, I a…
I'd have to disagree. I think the interview process desperately needs an injection of pragmatism. If the actual job never requires Big-O analysis, then asking it during the interview is a waste of time. I've never had to do Big-O analysis in the real world, but I have had to fix N+1's. Ask about that.
Maybe I'm missing something but isn't N+1 the difference between O(1) and O(n)?
Edit: Anyone want to explain how I'm wrong rather than just downvoting?
Edit 2: Understanding a N+1 problem is the equivalent of understanding the difference between O(1), i.e. fetch all data with a constant number of queries, versus O(n), i.e. the number of queries scales linearly with the number of elements.
Re: How to Pass a Programming Interview
#56Earlier quoted context omitted.
Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.
I've had people interview claiming to know X and then not code in X correctly. So... that's a red flag. We allow interviewees to pick their strongest language. But if you end up picking something that doesn't exist, well, you aren't earning yourself any points.
I've had interviewers look at an unweighted keyword digest from my resume, apparently without reading said resume (which clearly states my current skill focus on the top, which has evolved quite substantially over time). And then start "grilling" me on a language that appeared on a job description from 10+ years ago.
Re: How to Pass a Programming Interview
#57> "That’s exactly the point. These are concepts that are far more common in interviews than they are in production web programming." The list includes things like Big-O analysis. While, formal analysis is certainly not a day to day occurrence of most programming, knowing what the runtime complexity of the code you are writing is almost always important. While, I generally don't care for most algorithmic problems, I a…
So, I see where you are coming from (I actually love academic CS). But the VAST majority of the programming work out there does not require any Big-O analysis. It just does not. It's used as a tool in interviews to (essentially) look for rigor. The problem is that this harms people who are rigorous as hell in low-level details of JS and V8 (something I'd posit is actually more useful to many more companies), but neve…
But the VAST majority of the programming work out there does not require any
Big-O analysis.
To make an analogy with driving: the vast majority of driving doesn't involve parallel parking. But you still need to know parallel parking to pass a driving test.
Re: How to Pass a Programming Interview
#58> Use a dynamic language, but mention C
I take issue with that recommendation. You should use whatever language you feel most comfortable with. If it's C, use C. If it's Java, use Java. You don't have the luxury of an IDE or anything like that, so you need to have enough of the language in your head to write a program without looking something up.
Re: How to Pass a Programming Interview
#59Another tip which I give: Interviewers vary widely in how much they care about whether your syntax is accurate, whether you handle invalid inputs, and whether you write unit tests. It's really useful to ask the interviewer whether they want you to worry about those things. If you handle invalid inputs for an interviewer who doesn't care about that, they're going to be a little annoyed by you going more slowly than ne…
Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.
>> I do care that they can get their point across
This is kind of the point, right? Most places I've interviewed are far more interested in your communication skills, logic and thought process than writing perfect code on a whiteboard.
Many of my friends have failed to see this is actually the reason they have you write code on a whiteboard.
Re: How to Pass a Programming Interview
#60Earlier quoted context omitted.
So, I see where you are coming from (I actually love academic CS). But the VAST majority of the programming work out there does not require any Big-O analysis. It just does not. It's used as a tool in interviews to (essentially) look for rigor. The problem is that this harms people who are rigorous as hell in low-level details of JS and V8 (something I'd posit is actually more useful to many more companies), but neve…
I have more than once in my professional career run into programmers who tested on small inputs and assumed the timing would scale at least close to linearly.
Fair point. But is it not much more common to encounter a programer who cannot break a complex system into loosely coupled components? Or who does not use consistent naming conventions? Or who is smart but lazy? I'd rate all of these as equally important things to try to evaluate in an interview.
I am a strong believer in looking for strength in an interview. Someone really rocking complexity analysis is a strong positive (shows that they are smart and pedantic in a good way). But so does clean, smart code and great loose coupling.