Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to win the coding interview

blog.devmastery.com

Post reply on HN
Print view View original

191–200 of 305 posts

Re: How to win the coding interview

#191

Post by winsome »

cosmolev wrote: post #157
gregmac wrote: post #96

Earlier quoted context omitted.

> I'm tired of companies asking me to code at their interviews. I have 10 years experience I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc. Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Conver…

Disclaimer: I've never written any C# code, I write Java code. "Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr)" - while nobody writes code in this way in production this is exactly the way of coding endorsed by Codility-like programming challenges when you have 30 minutes to come up with a solution.

Maybe for someone with no experience in the desired language and minimal access to docs, but for someone that professes a knowledge of C# 6 they ought to at least know about the `TimeSpan` class.

For anyone with the knowledge the person claimed to have, that code should boil down to something more like TimeSpan.Parse($"{hourStr}:{minStr}").TotalMinutes;

Re: How to win the coding interview

#192

Post by jcadam »

My problem is not the technical stuff -- I just can't seem to pass the 'culture fit' part of the interview outside of my industry (defense/aerospace). I've been trying to get out of the govt sector for 10 years now (going on interview binges every so often). I often pass the technical screening (usually screen-sharing or "homework") and make it to the final "onsite" interview stage but something about meeting me in person puts people off. I hear "not a cultural fit" or words to that effect more often than anything else.

Hell, I was even told "We think you'd be bored here" when I interviewed at a startup several months ago. Didn't get an offer there either.

Re: How to win the coding interview

#193

Post by yoklov »

gregmac wrote: post #96
kayman wrote: post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

> I'm tired of companies asking me to code at their interviews. I have 10 years experience I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc. Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Conver…

Going to second the other comment, when you're rushed for time, you don't end up with "beautiful" code (But you should at least solve the problem).

I know none of the code I've ever wrote for a job interview was very good. Often it's total shit, hell, it often has a while (true) loop that I break out of later. (usually I ask if they'd like me to clean it up after I get it working properly).

If your interview is designed around trying to see stylistic choices such as these (yes, the distinction between writing a loop and using linq is style), you should refocus it to be about figuring out the candidate's thought process.

Re: How to win the coding interview

#194

Post by jfoutz »

scrabble wrote: post #161
hvidgaard wrote: post #102

Earlier quoted context omitted.

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

I have had a teacher that said you needed to comment every single line because that's how code is written in the real world. I told him he was wrong and argued with him on more than one occasion. In the end, I just did it his way because there wasn't a good alternative.

Sounds like a job for a perl(or whatever) script.

Might be fun to do some light ad hoc parsing.

Also, with that rule, I can't resist

    // this line left intentionally blank.

Re: How to win the coding interview

#195

Post by jdc0589 »

> Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation

I couldn't agree more. I've had interviews (with big companies in the north-west), that had NOTHING ASIDE FROM ALGORITHM questions. At one of those, over the course of a 4 hour interview EVERY SINGLE QUESTION was whiteboard coding tree/graph traversal problems, aside from one "architect a system to handle this" type discussion (which was maybe 15 minutes).

Interviewers: if your candidate knows, without prompting, that the best solution to the problem is a depth first traversal of a tree and can explain why, implementing the actual solution is not the most important part of the interview. Not a lot of people need to write tree/graph traversal as part of their jobs frequently enough to warrant assuming everyone can implement everything from memory on a whiteboard in 10 minutes.

Re: How to win the coding interview

#196

Post by rimantas »

iSnow wrote: post #137
tigershark wrote: post #131

Earlier quoted context omitted.

It's actually illegal in all the contracts that I ever had to work for someone else while you are employed for a company. And even if it was legal I would never lose a week salary for some fancy interview that takes a week, plus all the time that it takes to test the other n-people to have an answer.

> I would never lose a week salary for some fancy interview that takes a week I'd actually love to do that. The company I work for currently presented itself in a very professional light and all the questions I had were answered promptly and professionally. No red flags. Only when I started work, I noticed immediately their code base contained unfixed bugs, tests were not up to date and the databases (so called data-…

And after ten stints like this you'd find out that there is no place without a problem.

Re: How to win the coding interview

#197

Post by verroq »

jameshart wrote: post #190
verroq wrote: post #60

Earlier quoted context omitted.

I'd expect to see this (assuming that this guy is a Javascript shop). function isPalindrome(str) { for (let i = 0; i Quick check list: 1. Knows about es6 2. Knows about === and !== 3. O(n) efficiency with no memory bloat 4. Didn't write 30+ lines on a trivial function I won't even add a comment about unicode since it should be your default assumption when working with javascript that multi-byte characters and surroga…

5. Didn't meet the specification. You need to ignore white space and punctuation. 6. Didn't include any tests 7. Bonus! This function also returns true if you pass it a palindromic array! Er... Maybe it shouldn't do that.

I realise you are nitpicking. But when you ask a normal person who knows how to code to write a palindrome function, then this is what you will get.

This function is too simple to expect anyone to ask you any follow up question regarding the "spec" unless they are trying to game the interview.

Also note that the duct typing properties of JS are often used to allow such string/array ambiguities.

Re: How to win the coding interview

#198

Post by paulddraper »

eru wrote: post #124
paulddraper wrote: post #21

Earlier quoted context omitted.

Or even more clearly def is_palindrome(str): return str == str[::-1]

According to the authors spec, you have to filter out spaces, normalize capitalisation etc. So your solutions works after a preprocessing step.

Correct, I wrote this based on the parent's desired answer.

Re: How to win the coding interview

#199

Post by vonmoltke »

ori_b wrote: post #181
enraged_camel wrote: post #119

Earlier quoted context omitted.

It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates. If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.

> A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). A lot of places value people who work well under pressure. (A bad push taking down all the server's I'd stressful)

Meaning a lot of places have shitty processes and architecture and try to compensate by hiring people that fit their broken system. Case in point: having an architecture so fragile that a bad push is capable of taking down all your servers.

Re: How to win the coding interview

#200

Post by kriro »

hvidgaard wrote: post #102
twblalock wrote: post #34

Earlier quoted context omitted.

n++; // increment n

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

Why not run a parser that removes all comments over all code that is turned in. It's easier to read the code with no comments and if there are no comments the sections that should be commented really pop out (you can then check to see if there are indeed comments in the original file).

Simplistic comments actually help a lot when learning (even if they are just a reinforcement). Quite often our students write the comments first and then fill in the code which is perfectly fine.

It's also more interesting to let them freeflow it and then explain later why it might not be a good idea. The learning effect is stronger if they can go back and read their own overcommented code.

Post reply on HN