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.
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.
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.
That's brilliant. Now I have to learn myself some COBOL just for that.
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.
Thank them for their time, leave, move on to next company.
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.
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...
Also I'm not sure about the use of floating point here...
[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...
I'd respond to that by drawing one huge semi-colon that spanned all 20 lines of pseudo-code.
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 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.
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.
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.
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.
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
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.
# 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 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.
Really? That's incredibly rude.
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.
for i in range(len(items)):
do_stuff_to(items[i]))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.
You should not be expected to write syntax-error free code on your first pass while solving a problem , without machine assistance
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.
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.