Hacker News Reader

Comment by bshlgrs | Hacker News Reader

Another 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 needed. If you don't handle invalid inputs for an interviewer who does care, then they'll think you're careless.

View on HN

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.

This happened to a friend. He confirmed that pseudocode would be acceptable, but then as he was writing it out the interviewer got on him about not terminating lines with semicolons (I suppose the pseudocode looked C-ish). So yeah I'd say make this clear.

Ack. I'm not sure how I'd react to that.

I interviewed quite a bit last year (on the hiring side). I was really surprised by the variation in pseudocode written by the candidates. Most wrote something JavaScript-like, a few stuck to mostly proper Java or C. But then one dumped a giant web of crazy on the board (but still made his point) and one wrote something that looked suspiciously like COBOL - still not sure if he was trolling me.

> Ack. I'm not sure how I'd react to that.

Thank them for their time, leave, move on to next company.

I always write a weird mashup between python and C for some reason haha

"and one wrote something that looked suspiciously like COBOL - still not sure if he was trolling me."

That's brilliant. Now I have to learn myself some COBOL just for that.

You will need to write a lot before you even start solving the problem.

My pseudocode used to be a sort of relaxed Haskell, because it's closer to how I think about a solution... but some interviewers rejected it as not resembling any kind of code, so now I use something imperative and Pythonesque, which hasn't gotten complaints so far. The sad thing was that in some cases the Haskell "pseudocode", unlike the Python, would have actually compiled and solved the problem quickly (within a factor of ~4 of C), and it took me about a minute to write.

Unfortunately I think Haskell is disproportionately well-suited to these kind of toy problems, so being able to answer interview questions in Haskell doesn't tell the interviewers much except that you think yourself especially clever.

I wrote some Ruby in an interview. It was so terse, I had to explain to the interviewer (who favored Java) what the code did, and why it was linear instead of O(n^2). That was actually kind of fun.

If your code is sufficiently terse that it's not very understandable (such that the complexity isn't very understandable) surely that's a realistic red flag?

If it's idiomatic Ruby (which some, like me, are not familiar with), I think it would not be a red flag if they could explain the details of what the syntactic sugar represents, and why its runtime is what it is.

My shipping boxes hold an even number of widgets, but I "have to" sell odd quantities and those need expensive mil spec styrofoam peanuts added to fill the hole. Here, have an array of possible shipment sizes. Given that array, if its shipping an odd number of widgets I wanna add an additional half widget shipping charge.

newshipping = oldshipping.select{|i| i % 2 == 1 }.map{|i| i + 0.5 }

My ridiculous fictional writing about shipping widgets is way more confusing than the idea that you can select and then chain right into a map.

This probably looks really weird to a java guy but its not really all that mysterious. I wonder what that looks like in Java.

In Java it would look like this:

List<Double> newshipping = oldshipping.stream().filter(i -> i % 2 == 1).map(i -> i + 0.5d).collect(Collectors.toList());

a bit more verbose but the essential chaining idea is there...

The above, only if you want to discard (filter) orders with an even number of things.

Also I'm not sure about the use of floating point here...

Ruby's select[1] is the same as java 8's filter[2].

[1] http://ruby-doc.org/core-2.2.3/Enumerable.html#method-i-sele... [2] https://docs.oracle.com/javase/8/docs/api/java/util/stream/S...

"Shame! You're not terminating your pseudo-code with semicolons!!!"

I'd respond to that by drawing one huge semi-colon that spanned all 20 lines of pseudo-code.

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.

I think this is less of an issue when you code in Python, where the code is already somewhat pseudocode-ish.

Except when you're used to working in an IDE that generates a lot of the syntactic cruft automatically.

That's far less true if you use several languages on a regular basis. .size .length .count, which one is used in _? Does it use () after it?

Interviews are often based more on what the interviewer knows than the project / resume.

Now what happens when someone asks about a language that you have not used in 3 years? Well it gets fuzzy. Ramping back up on an old language might take a few hours, but that’s meaningless in terms of a job.

I wouldn't call Ruby's syntax simple. Elegant, yes, but not simple. I'd consider myself a pretty seasoned rubyist, but my IDE catches syntax errors for me all the time.

Agreed. I know Python well and Perl and Java before that. Ruby code still looks unusual to me.

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 wouldn't pass then since I live in post 2000 and am used to let the IDE handle the nitty gritty details while I focus on the actual meat of creating software

I've had this problem as well. I go back and forth between Obj-c, python, javascript, matlab etc. so much without spending a significant amount of time on any one language that I often feel intellectually deficient because I don't know the nitty-gritty details of any of them. Curious to see what others think - is this something I should stop and focus on? Or in today's development environment is it considered acceptable to have to occasionally lookup language nuances in any given situation?

For example, I couldn't tell you off the top of my head how to test for null in python. I'd assume it'd be if(obj), but after a quick google search it seems like if(obj is not None) would be the correct answer.

http://exercism.io has helped me to write more idiomatic code (submit a thing, get comments, refactor, also comment on other people's code.) Maybe it'd help you for the languages they have examples for?

Thanks, I'll have to try that out.

I used to be in a very similar situation, but I was convinced otherwise by this article [1]. The fact of the matter is that, yes, it's easy to become familiar with a variety of programming languages, but I think you actually learn a lot more when you double down on a language (platform, ecosystem, etc.) for a long period of time.

Quoting from the article:

> Leaky abstractions mean that we live with a hockey stick learning curve: you can learn 90% of what you use day by day with a week of learning. But the other 10% might take you a couple of years catching up. That's where the really experienced programmers will shine over the people who say "whatever you want me to do, I can just pick up the book and learn how to do it." If you're building a team, it's OK to have a lot of less experienced programmers cranking out big blocks of code using the abstract tools, but the team is not going to work if you don't have some really experienced members to do the really hard stuff.

In areas that I'm just learning or dabbling in (for me, Objective-C), I look things up or reach out to experts. But there are areas where I want to be the expert that others reach out to.

[1] http://www.joelonsoftware.com/articles/LordPalmerston.html

The bad/goodness of your strategy I would measure by your market success or happiness. Do whatever makes you happy and employable.

Personally, I love the idea of being a generalist. But at the end of the day, you gotta code and code good, specialist or not.

I don't think it matters. No one want's to see import/includes on blackboard and they don care much if you remember if method on some object was called len(), size(), count() or length.

I don't get why. When I'm organizing my thoughts in code, I normally write something pythonish, but not really any real language. Stopping to think about the correct syntax does not make me solve the problem any faster or any better, and since I am writting on paper or a board I am going to have to rewrite everything anyhow. Maybe I'll even have an IDE to do most of that meaningless effort for me. It's like lazy syntax evaluation; don't do it until you have to.

I've been writing a comment as a placeholder for real code stating the problem in simple English when I'm stuck lately. Usually going through putting it into words really guides the code. It'll usually look something like:

# the problem is that our query only matches rows where the ID from foo table equals the ID from bar table, but we want rows from foo table that match the first part of our query regardless

This also makes it easy to ask for help, since now you've turned your "it no workie" into a question which you could ask another person on your team or in e.g. IRC for help with. They might then have additional questions, but I've found more often than not that simply getting a few minutes with someone else is enough for them to bring not-your-entrenched-perspective to the problem and hand you the (sometimes super obvious) solution in short order.

TL;DR https://en.m.wikipedia.org/wiki/Rubber_duck_debugging is great

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.

Take out any of that old stuff. It's not necessary. Your resume should fit on one page, two at absolute most, and only include things that you would expect to be grilled on. If you are annoyed about being tested on something on your resume, take it out.

There's no need to be "grilled" on something you did 10+ years ago (unless it's a requirement of the job, of course). Perhaps a "have you used Pascal since leaving ...?" would suffice.

A resume should reflect your current skills and abilities. You should feel free to leave in old positions, and the interviewer can ask about it if they want, but you should not leave in technical things you don't want to be asked about.

I see what you're getting at.

I still think that in general, people who can't be bothered to read important documents, and instead just eyeball them for keywords (and start shooting off questions accordingly) -- aren't my cup of tea to work with, anyway.

I understand your point, it drives me crazy in interviews as well. But by the same token when I'm interviewing, I want to be able to grok someone's resume as quickly as possible - I don't want to see stuff that they themselves don't think is relevant.

It's interesting that different companies will want different things on a resume. This is why no two jobs I've applied for get the same resume. If they want lots of experience in a lot of different things, sometimes they DO want the laundry list of acronyms (make sure you know what they all stand for). You might not even get through the first selection if they use XSLT heavily and you didn't think it was relevant that you had worked with it before on a project.

I've also had interviewers rip the other pages out of my resume in front of me, but everyone is different. At the end of the day, don't feel too bad about not getting an offer. A lot of it is luck.

I've also had interviewers rip the other pages out of my resume in front of me,

Really? That's incredibly rude.

> But if you end up picking something that doesn't exist, well, you aren't earning yourself any points.

I don't know about your personal interviews, but I'd find this reasoning slightly strange if I were being asked to write computer code on a whiteboard. I'd find it much less strange if I were actually handed a laptop to write a functioning program on.

Expecting perfectly correct code on a whiteboard seems to me to be a slight abuse of the medium. Whiteboards and chalkboards specifically exist to sketch things out in an adhoc fashion, often in a collaborative and easy-to-edit way.

To "not code in X correctly" is ambiguous, but I assume/hope the parent poster means that someone makes fundamental, non-syntax errors in their code - in C++ this would be something like returning a pointer to an object that's on the local stack.

If you're trying to filter for people can be productive in a particular language from anyone else, that's what you need to look for.

If you let the candidate pick their strongest language and they still make fundamental errors, you know they're not going to be immediately productive in any language.

I don't think he meant perfect code. But I've had candidates claim their main language is Java, but were unable to write a proper for loop or know basic data types like arrays or ArrayLists. I've met such people with PhDs and impressive CVs.

Interview enough people and you'll encounter some that are very convincing until you dig down into details. So you have to dig into details.

I ask questions about the language to determine if they know the language. Correct syntax isn't going to show me you understand prototypal inheritance.

It depends on what "not code in X correctly" means. If they missed a few syntactical things, it's fine. If they're obviously still "thinking in a different language", then no. For example, if you ask them to loop over a list of items in Python, they shouldn't write:

    for i in range(len(items)):
        do_stuff_to(items[i]))

Well, even though it's not idiomatic, it still works. A good question to follow up with is if the candidate is familiar with iterators.

Right, the point is that such an answer would reveal a more superficial understanding of the language than they might have earlier implied.

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

friends who are candidates, or friends who are hirers? I see that problem on the hirer side.

I hear that interviewers are really interested in seeing how you think and communicate constantly. Yet in my experience, if you solve the problem exactly the way the interviewer is looking for in a reasonable amount of time, you pass 9/10 times. If you don't, you fail.

You should be able to carefully review a few lines of code for syntax errors. This is important because incorrect syntax might be ambiguous as to what it could mean.

You should not be expected to write syntax-error free code on your first pass while solving a problem , without machine assistance

Good point, I've encountered this. Some candidates unfamiliar with the process may not even realize they want you to ask that, I didn't know when I started out and used to think a good interviewer would specify what they want, that may not be true, although it would be a nice thing to remind a candidate they can ask for clarifications not just about the question but about testing and such.

I know some interviewers may be interested in helping but it's important to note assholes exist, especially at larger companies. There can be head games and assumptions made where they needn't have been. Even when I've been hired it can feel like if I'd done it again I may not have been. Try your best but don't be too upset if it goes badly either. Similar questions often come up too, it's actually amazing how many questions there are about linked list and trees.

I also think that it's not obvious that the interviewer is doing the wrong thing here. The claim "good programmers should always think to guard against invalid input" isn't ridiculous on the face of it: maybe checking for valid input is a sign that they're careful and methodical, and of course you want to hire careful and methodical people!

Or the other way around: I can imagine someone thinking "this person spent ages on checking for invalid input; I bet their code is always bloated and ugly".

The problem is that programmers do this one way or the other based on personal preference, not because of actual differences in ability. Once you know that, it makes less sense to care one way or the other.

If you think my code's checking carefully for the validity of the input makes it bloated and ugly, you just failed my interview.

There's a correct place for every class of input validation. The point is that you don't want multiple levels of input validation for the same thing. Most of what passes for "defensive coding" is superfluous. For example, if you are passing a pointer into a function, you don't need to reflexively null check. However, null checks are important.

If I'm at a whiteboard and the interviewer cares that my syntax is accurate I'm probably wasting my time.

You can always preempt the whiteboard issue by bringing a laptop along. "Hey, I'm a lot more comfortable writing code on a keyboard and with an IDE. Lets program this together in a text editor instead of a whiteboard".

As a candidate, I feel that it is fair to stand up for this as well. If the interviewer wants psuedocode, I'm happy to whiteboard it. But I've been whiteboarding before and had the interviewer say, "that code wouldn't compile, you're missing a bracket." So I said, "If you want code that compiles, bring in a laptop and I'd be happy to put it in to Visual Studio [it was a .NET position] and have it be syntactically correct; but if I'm whiteboarding, it's going to be psuedocode."

Some places I interviewed did mostly whiteboarding, but had a problem that required producing working code. One place had a standard desktop setup aside for me - with the most popular IDEs pre-installed. Another had me bring my laptop.

"This organization uses whiteboards as their Code Editor?" - did not get the job.

But be honest....by that point did you really want it?

good point.

What was their response to this? I think it's perfectly valid to state this, and may even throw the balance of the interviewer/interviewee dynamics but I can also see other people seeing this as obtuse. But pointing out a missing bracket (in a nonconstructive manner) on a whiteboard is pretty obtuse too...

It was the last interview of the day, and I was tired and had already decided I was almost certainly going to decline any offer, if given. So, honestly, I probably said it with a little bit of an edge and that was inappropriate on me.

Nevertheless, the interviewer was gracious and replied, "Fair enough" and stopped nitpicking my brackets and semicolons.

Nice! Worth doing these things even if to personally experience the boundaries of good/bad interview practice.

I got asked to find the intersection of two squares for a Django cosing job. I pointed out that it had absolutely nothing to do with Django (after getting a solution).

I was told they thought I might be difficult to work with.

Speaking as an interviewer, don't do this to me without prior discussion.

Being able to discuss things on a whiteboard is a necessary skill for working in a co-located office. This includes pseudocode.

Indeed, having the candidate use their laptop gives the interviewer a valuable signal, too: whether the candidate has a coding environment they are comfortable and fluent in. Are they stumbling on their editor, or is it an extension of their mind?

So, what about those who only have a desktop? If you want candidates to code on a computer, provide one. Although that had its own issues as well.

Cool, since you opened <preferred text editor> and you have a dev environment. Write compiler/parser in BNF for the editing commands your editor supports. Assume non-standard encodings are possible for the key presses. Here are the examples for vim/emacs. Should work with both.

That could go horribly :)

That's a double edged sword. Now, your code has to compile...

Ok, but being effective at getting it to do that is an actual thing that every programmer has to do all the time.

When I interview, I usually ask pseudocode first, then write it out in actual code. Think of it like writing a short essay. Outline first, then actually write the essay with proper grammar to the best of your ability. There will be typos and grammatical mistakes which I don't really care about but I do want to see your style and how you use the language to express what you want it to do.

Great point. I tend to be the person that realizes that interviews are stressful and I'm not gonna hold it against you if you miss sanitizing your input or similar issues, but I will call you out on it with a question like "well, what if you get X" and at least verify that you know that's an issue and let you then add the code in to accommodate for that.

And the most humorous interviewers are those that stare at you and slowly answer "uh, mmm, whatever seems fair..." when you ask about these reasonable questions.

Reply on news.ycombinator.com