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

241–250 of 305 posts

Re: How to win the coding interview

#241

Post by sokoloff »

vonmoltke wrote: post #199
ori_b wrote: post #181

Earlier quoted context omitted.

> 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.

Trivial to have a breaking DB change or a software push where the only part of the app that works is the little part that tells the load balancer, "yep, I'm alive and healthy; send some traffic my way".

There are probably way more successful (100-million to couple billion dollar revenue) companies that can be brought offline with a bad push than can't.

Re: How to win the coding interview

#242

Post by Clubber »

chvid wrote: post #149

Honestly; the example answer is not good. If I was in a hiring position, I would at least talk to the person writing this and ask them to change their style. The problem is that the answer is slightly over-engineered, over-commented, checks for input type, logs in a corner-case, looks-like-it-has-been-written-by-a-teacher-with-too-much-time-on-their-hands. These are not problems in themselves but when you have a new…

Hah. I was thinking that too. While I was reading the article, I was thinking about how I would do it. Then I read the wall of text that was the ideal solutions and thought, "wow, what the hell are coders doing these days?"

Re: How to win the coding interview

#243

Post by nulagrithom »

billsparks wrote: post #12
sundvor wrote: post #4

Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test?…

That particular comment (the @param) is for JSDOC. It's so that one can generate documentation for the code. http://usejsdoc.org/about-getting-started.html

The comment is still optional. You don't have to give @param a description. @param stringToTest would suffice. http://usejsdoc.org/tags-param.html

Re: How to win the coding interview

#244

Post by jameshart »

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.

So in an interview, I would probably try to guide the interviewee to explore some of these things. "Okay, that's a good first pass. Have you taken a look at all the example cases we started with, will your code handle all of those correctly? Can you think of any other input for this function that might return surprising results? Is there a way we can verify that we've covered all these edge cases? Oh, and what was that you said about unicode support? Can we just dig into that a little..."

Seems like we could find out plenty about how a candidate thinks and codes by pursuing this line of questioning. So long as the candidate doesn't respond to these questions by saying "Look, this is stupid, I'm not going to dig into requirements, that seems like I'd be trying to game the interview. This is my final answer - it tests palindromes. Next question.".

Re: How to win the coding interview

#246

Post by ubercode5 »

Kesty wrote: post #148

The problem with all this "advices" is that they boil down to "just study". I agree that been prepared for an interview is a good thing, if you are ready and have studied you show that you are willing and that you put in the effort. But what about people that are currently working ? You are trying to get the best programmer, and chances are is that the best programmers out there are currently working (minus a small p…

It depends on your schedule, but prioritize time to study every day in your down time. You don't have to do a "night before the test cram session" all the time, just a little every day and within a few months you'll find yourself much more prepared.

Re: How to win the coding interview

#247

Post by gmarx »

Says in the definition a palindrome can be a number then filters out number. Also, and most importantly, doesn't check to see if the items within the string are words.

The incredibly frustrating thing about interviews is that the interviewer is right, even if he is wrong.

Re: How to win the coding interview

#248

Post by Clubber »

sklogic wrote: post #231
vonmoltke wrote: post #209

Earlier quoted context omitted.

I have been an engineer for 14 years and writing software full-time for 8 or them. I have never written code on a whiteboard outside of an interview. I have drawn circuits, flow diagrams, UI wireframes, ERDs, memory layouts, and so on. I don't have my own whiteboard now and it drives me crazy. I have never had a need to write actual code on a whiteboard. Neither has anyone I have ever worked with.

Flowcharts are code. Pseudocode is a code.

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.

Re: How to win the coding interview

#249

Post by Programmatic »

YeGoblynQueenne wrote: post #229

>> On this particular challenge, I am expecting many will use RegEx as a part of the solution. The regex needed for this is some of the most basic regex out there Woohooa, cowboy. The language of palindromes is a classic example of a context free language that is not possible to describe with a regular grammar, such as accepted by a regular automaton... in other words a regex. In Recruiter-Parseable English (RPE): yo…

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, '');

Re: How to win the coding interview

#250

Post by thefastlane »

this shows me that there seems to be a cottage industry sprouting up around 'technical interview prepping' (this blog post is an advert for such a business). it's interesting that we've arrived at this point. curious to see the direction it takes
Post reply on HN