Hacker News new | past | comments | ask | show | jobs | submit login

I think the best coding interview is to test some fundamental CS knowledge.

For example: given a scanner, write a simple calculator that deals with precedence and only needs to support +-*/

It shouldn't take a huge amount of time to get a parser done, with BNF or not.




Questions like these are hit and miss tho - I can do this because I worked in a sub-field where “write a parser for that” was a common tool to reach for. In my current field I haven’t seen a single parser in any company codebase; a dev that grew up here could be deeply skilled but have a gap around parsers..


That's okay, but it is testing what it says: facility with a particular part of CS that some people have studied and some people haven't. Can't hurt, though, and it's the sort of think that ought to be in everyone's toolbox, although it isn't.


When starting to type this comment, I was going to write that I could not do it and I think of myself as a decent coder. While typing that, I had an idea and I started a stopwatch...

Made this test set in the first minute: "1 + 1", "1 * 2", "1 + 2 * 2", "1-1", "1/2", "1+2/2" which I think should cover the requirements generally. Then I took 9m58s to come up with 77 super ugly lines that, to my surprise, after fixing that I forgot to cast the inputs to floating points (lines 67 and 76), gave the right answer straight away.

Code and output: https://pastebin.com/C3RVqpjE

The correct answer would probably have imported ast but, while I know of the general existence of such tools, I never needed this in my life. It's not like I work on JSON parsers (a minefield) or wrote my own coding language. An old colleague did the latter for a commercial product by using str.split on operators (yes, strings were a major feature in the language), which went about as well as you expect... I know to stay away from these problems or, if tasked with it, where to look to solve it, but that doesn't mean I can do it in an interview.

While I'm pleasantly surprised to have gotten a crude version working and in a faster time than I expected...

...if you're not hiring specifically for a parsing job, please don't use this as a coding exercise. It could be an interview question if you just want to hear "something something AST, and not by string-splitting on operators when the language has strings with said operators potentially in them". That could demonstrate knowledge sufficient such that the coder would do the right thing if this task were to come up in their job


You forgot to test for associativity: ((1-1)-1) vs (1-(1-1)).

Your implementation does handle it correctly though, but it requires some care when using parser generators :)


Nice work. Yeah, writing a parser without knowing parsing idioms is really hard. I can't remember the idioms anyway so mine would look like yours. There's a reason there are whole classes on this in colleges.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: