Hacker News Reader

Comment by odammit | Hacker News Reader

I was once asked a very very specific question about a conflicting setting in an nginx config and the dude actually wrote the config on the whiteboard and asked me how I would make it work.

I stared at it for what felt like minutes and then said, if I looked in your search history would I see you looking this up on stackoverflow?

The guy said "yes" and I said I would make it work by asking you to send me the link to the stackoverflow answer.

He laughed and said "you got me".

Same company different interviewer asked me to explain the "pros and cons of Java vs Rails."

I turned the job down.

View on HN

I dunno, I think Java vs Rails is a great question if asked right. There are large meaningful and practical differences between the two and every non-jr programmer should at least be able to talk about the technical and business merits of using one vs the other.

There isn't a right answer, you basically just start shallow and probe until either you or the candidate can't go any deeper. This question could lead you into exploration around the JVM, concurrency, memory management, typed vs un-typed, choosing libraries, toolchains, dependency management, strategies for persisting state(i.e ORMs), back-of-the-envelope performance, etc

I'm pretty sure I could get a full 45 minutes out of that question.

So you mean Java vs. Ruby? ('Rails' being 'Ruby on Rails')

Java vs. Rails is a bad question as it's comparing two things that aren't equivalent. One is a language, the other a web-application framework.

It's not a "bad" question, but your reply is a fine starting point for a good answer:

"Well, for starters, Rails is a framework while Java is a language. Granted, Rails is THE framework on Ruby, so I can tell you about the differences between Java-based webdev, vs Ruby/Rails. With R/R, you have convention over configuration, which means blahblahblah and is good for getting started but at times you run into blahblahblah. And community blahblahblah, etc. Java, OTOH, has stating typing, which gives you guarantees blahblahblah but there's no standard web framework like on Rails so you'll spend a lot of time researching not-so-great choices, etcetc...."

Sure, there's a good amount to discuss, but I would argue it's too open ended.

I could also, as the grandparent suggests, talk about that particular topic for a long while. But as an interviewee it would suggest to me that they possibly are just spewing out words they heard around the watercooler. Either that, or it's a 'trick' question, due to the fact that they are not comparable.

I expect chefs could talk all day on the question: "What are the pros and cons of flour vs. forks?" That doesn't make it a good interview question.

I believe there is no such thing as too open-ended a question to ask an interviewee. If you're asked something open-ended you have a glorious opportunity to define the scope of that question yourself, and to frame it in terms of things you know. Better still: you get to throw the ball back in their court by asking supplementary questions.

The point of such an interview question is to foster dialogue.

Yes. I agree with this. A strategy I employ when interviewing is to run with the first open question. It informs the interviewer about my knowledge and experience and gets me out of the majority of senseless tech questions.

Better analogy would be "What technology would you choose for building a bridge". You should compare software engineer to construction engineer or architect and not to a cook.

Valid quibble.

> every non-jr programmer should at least be able to talk about the technical and business merits of using one vs the other.

So there is no place in this world for a senior programmer who isn't particularly familiar with those two languages?

Why are they so special?

I would expect a senior engineer working on Web technologies to be at least familiar enough with what both Java and Rails are to be able to start that conversation.

It doesn’t require an in-depth knowledge of either, but this question would serve as a great way to get a basic level of an applicants knowledge.

Meanwhile I could easily imagine a senior web developer with 15 years of programming experience having used JS, Python, Perl, PHP, ASP.NET, and a dozen non-web languages but never a single line of Ruby or Java.

I have never used either Perl Or ASP.NET. I would be comfortable talking about the difference between them at a high level regardless. I don’t think it’s unreasonable to expect a senior developer to be familiar with the tools that are used in the trade generally, even if they have not used those tools themselves.

I think it is quite unreasonable.

I honestly think that talking about some tools someone never needed is a terrible way to get the feel for a basic level of that applicant's knowledge. And it really doesn't tell you anything about them as a programmer. I think even fizzbuzz and linked list reversal would be more telling, and that's not much.

Going by the translator analogy, I feel like it's asking say an Asian translator (who might command a few eastern languages with decades of solid experience) who never studied English and French to talk about English and French. Because in your world everyone skilled translator knows enough about English and French to at least have a useful conversation about them. It smells very elitistic. And pointless.

We'll just have to disagree on this one, I'm afraid.

I would consider it a necessary job requirement for a senior developer to know about common technologies in the field they are working in. If that meant working on web applications, I would expect them to know what both Rails and Java are. I don't need them to be able to program in them; I need them to know what they are, why they exist, some of the key facts about them, where they might most commonly be used, that sort of thing.

Over-specialisation to the extent that developers are unaware of technologies outside of their direct knowledge is a warning sign about a developer's skillset, to me. How can I trust that a developer is picking the correct tool for a job if they aren't aware of what tools are available?

It's possible to be aware that certain tools exist and have an idea about what they're used for, and yet know little enough about them to butt into a discussion and give any sort of fruitful, educated opinion about them.

My imaginary senior web developer knows more than a dozen languages. It is almost a given that one of these languages is technically sound and a reasonable choice for a given task, and that developer should be able to pick that language just fine. However, if there are other compelling reasons to look into other languages (for example because company wants cheap coders and think there's a large pool of cheap talent skilled in language X, or because the company needs to leverage the ecosystem surrounding language Y), that same senior developer is more than capable of doing a bit of research and evaluating these languages.

You almost sound like one of these interviewers who think that a programmer who can't implement a red-black tree off the top of his head and state its worst case insertion complexity couldn't possibly be capable of looking it up and evaluating the relative merits of different data structures -- and thus cannot be trusted to any position where he might have to pick an algorithm. Nevermind if he could implement two dozen other data structures in his sleep.

Over-specialization? Seriously? A programmer who's used more than a dozen programming languages is over-specialized because he can't discuss the two you want to talk about? The stench of elitism is only getting stronger here. You're assuming the worst of a programmer because his world doesn't revolve around the same things yours does, and you are assuming that despite their experience they probably will not try to or cannot educate themselves further.

Unfortunately I see this sort of prejudiced attitude everywhere... "I think this is important so if you don't know this, you can't possibly be any good." Such statements reveal a rather narrow world view.

Less of the personal attacks, please. I think I'm discussing this in good faith.

Yes, that's probably true. If that were the case, I would expect an answer like "I don't know anything those beyond the fact that it's a cross-platform language that runs on a virtual machine and Rails is a framework for Ruby. But I do know a lot of Python and Go, which have some similar characteristics. We could talk about the general difference between compiled and interpreted languages?"

These questions serve as entry points. I'm not expecting a developer who doesn't use these tools to have an in-depth knowledge of how everything works, but if the question kills the interview to the point where someone is unable to move forward then that is a warning sign.

You almost sound like one of these interviewers who think that a programmer who can't implement a red-black tree off the top of his head...

No. I absolutely would not expect that, and those questions are stupid. I would expect a senior developer to know what a tree is, and maybe what a red-black tree is. I would expect them to know what operations can commonly be done on a tree, or what use-cases they might have. I would expect them to be able to, say, contrast a tree with a hash table. If a developer said, however, "I have never used a tree or a hash table and have no idea what you are talking about" then I would also consider that to be a warning sign. Do you see the similarity?

You are misrepresenting my view; see above for more details. I do not think it is elitist to expect people in senior roles to know about common tools used in that role. I would not expect them to be specialists, but I would expect them to understand the state of the field and be able to discuss that. I mean, we're not talking about obscure technologies here!

That is an unfortunate misrepresentation of my view, so I'm sorry if I've failed to communicate it effectively. I guess from what you've said above that you think I'd place much more weight on the technical content of that answer than I would in practice.

Perhaps I have misinterpreted you or read too much into what you said. I'm sorry if my response came across as a personal attack.

All these threads about interviewing over the years have definitely left me with a bitter taste, mainly due to all the people who think they're clever and have figured out the most important thing, that one thing by which all applicants' worth can be tested.. if they just know about this one little thing. And in doing so, they effectively trivialize the software industry as a whole, failing to realize just how wide and deep it is, completely oblivious to how different developers with up to two decades of experience even in the same subfield may have walked rather different yet fruitful paths.

Again, I'm sorry.

I agree, question about choosing between Java and Ruby is a good question for senior software developer position. Choosing between technologies, platforms, frameworks is important and responsible part of the job.

Valid point. And we did have that discussion. They were a rails shop and not considering Java for anything ... so it was very much a very random question in regards to the position.

He also wanted the pros and cons of them verses each other based on his wording.

My original answer was "the obvious pro is a death match is always interesting"

One of my friends told me that when he was interviewed at his current company, they asked him a similar question, and he said he gave a long complicated answer that basically amounted to "I would google it."

He got the job, so there you go I guess.

Gotcha style questions like that pretty much just ask "have you been in the exact same scenario as me last Tuesday?"

My interviewing has boiled down to 30 minutes of shooting the shit to see what the person is like and to make them more comfortable and then a pair session with a ticket I haven't had experience with so we are both on approximately the same level.

My goal in the session is to see how they interact with an unfamiliar project and what kind of questions they ask and their discovery process of learning our business domain.

Your interview process is unfair.

1. The shoot the shit session is guaranteed to be driven by your personal biases.

2. Working on a different ticket with every candidate ensures you can't possibly compare one candidate's performance to another's.

Totes, but what interview is fair?

I also send the same screening test depending on role so I do have a baseline, although I'm much more interested in our interaction during the pair session.

I'd rather have an informal discussion that demonstrates competence than being quizzed on meaningless Googleable stuff[0].

[0]: https://news.ycombinator.com/item?id=14570309

I said the same thing to an interviewer once when he asked me about the syntax of some Entity Framework command and he looked at me like I had cheese coming out of my mouth.

I didn't get the job, but I'm glad. His reaction was a red flag as far as I'm concerned.

edit: I didn't even notice the "rails" until after I wrote this. My brain filled in "ruby". I agree that java vs rails is stupid.

I love the compare/contrast style of questions between languages. I try to not phrase it as "pros and cons" however. What I'm looking to see is the breadth of their knowledge and what insights they've picked up from hard earned experience. Also, showing the ability to think critically about different tools demonstrates that they understand when a hammer is appropriate vs a screwdriver.

I don't care what they think is better or worse, I want them to show me that they've traveled the world, so to speak.

It's not completely stupid. My answer would be:

If you need something up and running fast, but don't care about performance per instance, such as a marketing landing page use RoR.

If you need something very performant per instance and are willing to pay for it, such as a enterprise application or large web site, use Java.

If that's not an acceptable answer, the interviewer doesn't know what he's doing.

The "stupid" part is comparing Java to Rails, not Java to Ruby. IOW you're comparing a language to a web framework.

I agree with everything you said.

Generally, I never interview about things "I know". I want to know how the candidate approached his/her project - the choices s/he to consider while designing the solution. It gives me far greater insight into the candidate's mind than merely asking "whiteboard questions".

I don't understand how Stack Overflow is so popular for these types of questions. Usually the documentation is a much better source. So yes, using Stack Overflow instead of the documentation is a red flag for me.

I think it's because Google somehow manages to index stack overflow better than the documentation. That, and stack overflow only answers real-world questions while the documentation tends to give equal weight to rarely and commonly used features.

The reason is the text of the questions, which is what people type into the Google search bar. Documentation never has questions worded in the way people would commonly ask it.

For this reason, I wish they would allow redundant questions to be asked, if the phrasing is even slightly different. But the rule-mongering mods always remove it if they can.

I didn't think dupes on SO were removed, rather they are marked duplicate, linked to the original and closed, precisely because of discovery.

Perhaps SO could include the titles of questions marked as duplicate somewhere in the markup so that Google indexes it?

Which is exactly what they do:

Should duplicates be deleted?

In general, no: most duplicates stay around. Having multiple copies of the same question with different wording is useful as search fodder, because people looking for an answer may use different wording too.

https://meta.stackexchange.com/questions/10841/how-should-du...

That's good to see that they actually have the right rules, but I've used it many times where my questions were closed simply for appearing similar to others (when I did not even find the others in my search results). I suppose the mods can be overzealous.

Being closed is not the same as being deleted.

Exactly.

It's not due to some Google-fu though. People ask questions (on SO) in the terms they think about problems. But documentation is written according to the structure of the thing being documented.

So SO ends up being a more direct mapping from problem to solution. Google simply captures what's there (in both cases). It's certainly good to consult the authoritative docs in many cases.

Also, SO optimize for Google (it's a large part of their traffic and they are a successful business) while most documentation efforts don't have the resources or inclination to work hard on SEO.

That always annoys me. Instead of getting a link to the official documentation, I get 5 links to vaguely related StackOverflow questions, the most useful answer of which contains the link to the documentation.

the fact that you don't summon the official documentation by google search is exactly why the indexed questions are beneficial to you: being a glorified pattern matcher, google would spit out the docs only if provided by the documenatation precise wording itself, which if you knew, you wouldn't needed to find

besides, google is a knowledge base index, if you want to search a documentarion website you can both both inform google via site: or use the docs own search system which most have as of today

Google's got a lot of smart developers who you'd think would have figured out how to surface original documentation if they really wanted to.

why tho? it's easy enough to add +javadoc (or equivalent) to a class name, no need to second guess the user input

It depends, documentation is organised very differently than SO. If you want to read up on how X works in general, then documentation style is useful; but if you want to find out a single narrow application of X, then stackoverflow style is useful.

For simplified example, if you want to find out what flag -wtf does in some unix utility, the man page would be useful; but if you'd want to find out which flags should be used to achieve WTF then you'd often need to read the whole documentation to find out - stackoverflow serves as a "reverse index" in this case.

The documentation is great when you know what you're looking for.

When you don't exactly, SO is a good pointer to the part of the documentation you didn't know.

yes back in the day IBM and DEC had good documentation today not so much

Not knowing why SO is so popular is a red flag for me.

Good SO answers usually link to the documentation. Often quicker to get to it via SO than to trawl through the docs hoping to find it.

It's not on SO people search for their problem; it's Google. If SO comes up before the official documentation, then I guess by at least a quantifiable metric, SO is not that much worse than the docs, after all...

If the doc was so good there wouldn't be a stackoverflow to begin with. The documentation is a better source, granted, but most of the man pages I read over the years seem to have been written by people who don't know how to communicate and explain concepts. It's like giving someone a mendeleev's table and expect them to be able to set up a chem lab and conduct experiments.

Well for me, I use stack overflow to translate. I want to do this in this language / framework, how do I do it?

I'm sitting at a bar in Turkey. I want to know how to say, "I want a beer," in Turkish. I know how to order a beer, drink the beer, and pay for the beer; I just want to know how to do it in my current circumstance.

I think it'd be great if there was a google JS snippet documentation sites could include to have a list of dynamic gotchas or faqs.

How many times have you read docs and thought "well that's relatively straightforward" just to end up googling an error message 10 minutes later and end up on SO.

I think a real solid skill is being able to ask google the right question when troubleshooting something.

NOT using SO it's are flash. Use all your tools. But SO answers are generally easier to understand than the documentation, or the docs don't actually explain the issue you are looking for, or they are out of date.

Reply on news.ycombinator.com