How to win the coding interview • Hacker News Board

Re: How to win the coding interview

#261

Post by Clubber » Tue, May 31, 2016, 6:34 PM UTC

sklogic wrote: post #256

Clubber wrote: post #248

Earlier quoted context omitted.

No they aren't. They are a diagram of a process. Code is the instructions used to implement that process. You shouldn't be so smug either.

Yes they are. A formal language is a code. Any formal language. What is the difference between code and pseudocode in your opinion? And given that on a whiteboard interview you're writing a pseudocode, it is not any different from a typical day at work where you also write pseudocode on a whiteboard, blackboard, sheet of paper or whatever. And if this is not your typical day at work, you're doing it wrong.

Look up the prefix pseudo. "supposed or purporting to be but not really so; false; not genuine." Another definition, "not genuine; sham." Pseudocode is not computer code as to your assertion.

I think you are basing your argument that anything written down that can be turned into code is pseudocode. That is also not correct. Pseudocode has a very specific definition. Here is one:

"Pseudocode is an informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a normal programming language, but is intended for human reading rather than machine reading."

Flow charts do not use the structural conventions of normal programming languages, they use shapes and text.

If you are writing pseudocode (the actual definition, not your made up one) every day, you are wasting everyone on your team's time. If you are drawing diagrams every day on a whiteboard, you are still probably wasting everyone's time.

Re: How to win the coding interview

#262

Post by logfromblammo » Tue, May 31, 2016, 6:43 PM UTC

collyw wrote: post #259

bithub wrote: post #187

Earlier quoted context omitted.

Shorter yes, but reversing the whole string and comparing it with the input value is actually slower/less efficent than the algorithm shown in the article. Sorry for my nitpicking ;)

Clean, easy, maintainable. To me that is more valuable than an increase in performance. I would be very surprised to find a palindrome checker as the bottle nek in a system.

One of the interviewee questions could be "Based on the profiler output, how many times would this code execute in a typical day, to the nearest power of 10? What code will it replace?"

string.reverse() and string.equals() is plenty good enough for smaller magnitudes or all-new functionality. Premature optimization just means you think you can outguess the profiler.

So first you code the simplest thing that works. Then you start optimizing in the most heavily used sections. If you have to go past the pointer-based solution in C to assembly that employs hardware-specific performance tweaks, it's time to just end the interview and go pet your taco cat.

Re: How to win the coding interview

#263

Post by sklogic » Tue, May 31, 2016, 6:47 PM UTC

Clubber wrote: post #261

sklogic wrote: post #256

Earlier quoted context omitted.

Yes they are. A formal language is a code. Any formal language. What is the difference between code and pseudocode in your opinion? And given that on a whiteboard interview you're writing a pseudocode, it is not any different from a typical day at work where you also write pseudocode on a whiteboard, blackboard, sheet of paper or whatever. And if this is not your typical day at work, you're doing it wrong.

Look up the prefix pseudo. "supposed or purporting to be but not really so; false; not genuine." Another definition, "not genuine; sham." Pseudocode is not computer code as to your assertion. I think you are basing your argument that anything written down that can be turned into code is pseudocode. That is also not correct. Pseudocode has a very specific definition. Here is one: "Pseudocode is an informal high-level…

I can only hope I will never have to work in a team with someone like you. That would definitely be a massive waste of time.

A typical workflow based on a pseudocode is very simple and efficient: you solve your problem in a pseudocode - an informal language that does not yet exist but captures the essense of the problem. Then, while still on a whiteboard, you refine your pseudocode into something still "pseudo" (i.e., a made up language that does not exist), but formal this time. It may require a couple of iterations to reach perfection.

Then it is pretty much done, the only thing left is to implement this DSL, which is trivial in most of the cases.

This workflow is far more efficient than anything keyboard stomping kids can achieve in their fixed, always unsuitable, overbloated languages.

Re: How to win the coding interview

#264

Post by logfromblammo » Tue, May 31, 2016, 6:49 PM UTC

YeGoblynQueenne wrote: post #233

Oh my gods! This is what passes for an answer to "identify a palindrome"? All of that ?? 59 lines to ensure a string is equal to itself reversed (hint-hint, nudge-nudge)? Why? 'use strict'; // avoid ambiguity and sloppy errors /** * Tests whether or not a given string is a Palindrome * @param {string} stringToTest - the string to test. */ function isPalindrome(stringToTest) { var start = 0, end; // make sure we have…

This is something you write only after the profiler says your previous palindrome checker function is a CPU/resource hog, a bug report says it isn't reporting all palindromes correctly, and your manager gives you the okay to spend as much time as you need to fix it forever (but really only spend like 30-40 minutes, mmkay?).

Re: How to win the coding interview

#265

Post by Programmatic » Tue, May 31, 2016, 6:58 PM UTC

YeGoblynQueenne wrote: post #251

Programmatic wrote: post #249

Earlier quoted context omitted.

He's not expecting the use of a regex to do the whole heavy lifting of checking for a palindrome, in the example he uses it for the replace functionality to remove non-alphanumeric characters. https://gist.github.com/anonymous/e8553707cd6162040e7d12b2a1... stringToTest = stringToTest.toLowerCase().replace(/[^a-z0–9]/ig, '');

Yep, should have read all the way through before posting. But the example solution is so bad anyway.

What's your preferred solution?

Re: How to win the coding interview

#266

Post by logfromblammo » Tue, May 31, 2016, 7:19 PM UTC

p4wnc6 wrote: post #222

logicallee wrote: post #152

the most amazing thing is that apparently javascript developers do not ever, ever think about any algorithms like the way a C++ programmer would. I was shocked that when the write-up explicitly calls for "the most efficient code possible" nobody cares that the example program starts off making two extraneous copies of data that might never need to be read. (why lowercase the characters inside when you can fail early…

The shocking thing for me isn't so much that certain sections of the programming community don't natively think this way (I'm not convinced that I want them to ... someone whose primary value add in life is site design, for example, should dedicate way fewer brain cycles to this kind of algorithm efficiency and just relegate it to something they will profile and fix empirically should the need arise) ... but rather t…

It is entirely unnecessary to copy the string, to stack or heap. Rather than stripping whitespace, you check for whitespace when incrementing/decrementing the index. Rather than setting everything to lowercase, use a culturally-appropriate character comparator that ignores case differences.

Just stick a Turkish dotless-i character in the unit tests somewhere, at the end of "I’m a lasagna hog; go hang a salamı." and see what happens.

Re: How to win the coding interview

#267

Post by p4wnc6 » Tue, May 31, 2016, 7:25 PM UTC

logfromblammo wrote: post #266

p4wnc6 wrote: post #222

Earlier quoted context omitted.

The shocking thing for me isn't so much that certain sections of the programming community don't natively think this way (I'm not convinced that I want them to ... someone whose primary value add in life is site design, for example, should dedicate way fewer brain cycles to this kind of algorithm efficiency and just relegate it to something they will profile and fix empirically should the need arise) ... but rather t…

It is entirely unnecessary to copy the string, to stack or heap. Rather than stripping whitespace, you check for whitespace when incrementing/decrementing the index. Rather than setting everything to lowercase, use a culturally-appropriate character comparator that ignores case differences. Just stick a Turkish dotless-i character in the unit tests somewhere, at the end of "I’m a lasagna hog; go hang a salamı." and s…

I agree, and feel it's also irrelevant for what this could possibly tell me about a candidate as far as interview questions go. You're totally right, it just doesn't mean that someone doing these wrong things in the interview setting gives you really any bits of info at all about whether they would be good or bad in a real job setting. Absolutely none.

Great programmers who would never do such unnecessary things when programming in a real situation may nonetheless think of them and do them when in an interview situation, since the kinds of situations are so incompatibly different.

I guess if they did this in a take-home assignment, then it might be evidence of something. In an in-person coding interview though, it's just not useful at all for forming opinions about the candidate.

I've even seen veteran programmers with greatly successful open source projects, lots of experience, good education, high level of intellectual independence and curiosity, excellent writing skill, etc. etc., give highly inefficient implementations of FizzBuzz during an in-person interview.

These interviews are just not at all related to the way human beings actually write code and work in real life, and so they just cannot tell you much.

Re: How to win the coding interview

#268

Post by Clubber » Tue, May 31, 2016, 7:35 PM UTC

sklogic wrote: post #263

Clubber wrote: post #261

Earlier quoted context omitted.

Look up the prefix pseudo. "supposed or purporting to be but not really so; false; not genuine." Another definition, "not genuine; sham." Pseudocode is not computer code as to your assertion. I think you are basing your argument that anything written down that can be turned into code is pseudocode. That is also not correct. Pseudocode has a very specific definition. Here is one: "Pseudocode is an informal high-level…

I can only hope I will never have to work in a team with someone like you. That would definitely be a massive waste of time. A typical workflow based on a pseudocode is very simple and efficient: you solve your problem in a pseudocode - an informal language that does not yet exist but captures the essense of the problem. Then, while still on a whiteboard, you refine your pseudocode into something still "pseudo" (i.e.…

Ok, so I guess by your omission, you agree that pseudocode is not code and flow charts are also not pseudocode. I don't care about the rest, you can whiteboard all you want. We analyze the problem, then solve it in our heads, usually by the time we've finished talking about it. White boarding just seems way over the top, especially if it takes more than one person to solve a problem every day. Sounds like development by committee.

What's 2+2? Lets go to the whiteboard!

Out of curiosity, what industry are you in and stack do you use?

Re: How to win the coding interview

#269

Post by mplewis » Tue, May 31, 2016, 7:46 PM UTC

verroq wrote: post #197

jameshart wrote: post #190

Earlier quoted context omitted.

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.

As an interviewee, you need to be asking these kinds of questions.

• Will this function get only strings, or other stuff too?

• Do punctuation and capitalization count?

• Are there any special cases I should worry about?

Re: How to win the coding interview

#270

Post by EpicEng » Tue, May 31, 2016, 8:04 PM UTC

hiou wrote: post #224

EpicEng wrote: post #66

Earlier quoted context omitted.

>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. Work that is small enough to be done in 1 week and big enough to deliver some value. Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and…

Just so you know, in the past I used to actually bother to jump through the hoops like a trained circus performer for the apparent gift of employment from some place that actually needed me a lot more than I needed them. Then I would get all the way to the end of the interview and then tell them I would never take the position because of it. I used to hope this might stop the silliness. Then I just stopped taking int…

I don't understand how asking you to write some pseudo code on a whiteboard is "(not) treating you like a human being". Honestly, if you're so willing to waste both of our time just to make some silly point then I wouldn't want to work with you to begin with. Extremely childish behavior.