Hacker News Reader

Comment by throwawayIndian | Hacker News Reader

> "Could you write out what an HTTP request and response looks like on the board?"

Why should anyone remember what an http request or response should look like? Statically typed vs. dynamically typed language?

Fuck.

Are these entry-level positions or for someone with 10 years work-ex? A simple search on Google can tell anyone the answer of these questions, why do you expect people to carry an imprint of it in their memory? If the problem they'll work on mandates knowing these things it'd be pretty easy to solve with just one search. It is exactly questions like these that are worth kicking the host organization back in the butt.

Either your interviewing process is hilariously stupid or you're just spiking it up to boost the ego here.

View on HN

Static versus dynamic typing is so fundamental that I don't see how a programmer could be remotely competent without having been exposed to those concepts enough to have internalized them. It would be like an accountant not knowing what the number 4 is. Yes, you can look it up, but if you need to then how did you ever get this far?

It is also a ridiculously dogmatic question. Many people believe into a fallacy that static typing makes safer programs, for example, and expect that somewhere in the answer.

Could you explain how static typing makes less safe programs?

Static typing is basically a bunch of free type-based unit tests. You can write safer programs in dynamic languages, but you need to write and maintain a lot more tests.

You can't compare static + N tests, vs not static with M > N tests.

Compare static with N tests, vs not static with N tests. In what case would the not static be safer?

If the type system is not expressive enough and you have to get around it?

The claim that "dynamically type language" allows code to more closely follows the business logic has merits. And you could follow from that to claim that type system could be causing more bugs (ie less safe).

I have yet to see a large static typed program that didn't -- somewhere -- run into the limits of static typing and contain a set of workarounds, using void* or linguistic equivalent. That's code a dynamic language doesn't need.

The only code you can be sure isn't buggy is code that doesn't exist.

void* is usually not a symptom of limits of static typing, but limits of the [type system] design or human brain. You can think of it as "ok, I give up. Anything can be passed here, proceed at your own risk, compiler will not save you here, errors will show up at runtime". Even the memory safe Rust does not do without such unsafe blocks. In dynamically typed languages that is everywhere, though. I have said this before: safety benefits of static typing show up when you are working with at least data structures, not simple variables. Imagine you have an external endpoint or library call that is specified to return a single object and does exactly that. At some time after release you are the maintenance programmer responsible for implementing spec changes:

  * The object returned no longer has member/property x, it is obtained by other means;
  * The endpoint returns list of such objects.

How sure are you that tests in dynamic language cover these cases? My experience shows that tests very rarely get designed to anticipate data changes, because data is driving test design. Which is more likely for a test: a) to test whether object returned contains keys x, y and z; b) to check if the object returned is_list() (see appendix)? Static typing covers such cases. Static typing is not something that magically saves oneself from shooting them in the foot, but is nevertheless a safety tool that CAN be used. It is of course a burden if one does not intend to use it and that is the core of the debate.

Fun thing: in the second case if your code manages to convert input list to a map and assign one returned object to a key that coincides with the removed property and map access looks syntactically the same as property access (a very specific set of assumptions, though), the bug can butterfly quite deep into the code before manifesting :)

How is it dogmatic? Sure, there's a lot of dogma around which one is better, but simply explaining what each one is and what's objectively different about them isn't remotely dogmatic.

OK, ask me that question about defining the difference and I'll argue with the question, and back up my argument with examples of how type systems are far more of a spectrum of different cases than a stark static/dynamic binary.

And then your non-engineer phone screener who's expecting the answer to match the scripted sheet will conclude that I don't know this "fundamental" thing and thus am unqualified.

Which would be true, or rather: over-qualified.

This isn't a question a non-engineer phone screener can ask. Coming up with first pass filters that don't require an engineer to interpret is harder.

This is proposed as a question that an engineer would ask, not some base-level screener.

> It would be like an accountant not knowing what the number 4 is.

It's a hypothetical no-go! Every person, even the fourth grader knows the number 4. So why ask a question that measures their ability to remember 4, say 4 or show that they know 4.

> I don't see how a programmer could be remotely competent without having been exposed…

Share this link with them:

http://stackoverflow.com/questions/1517582/what-is-the-diffe...

Invest in people and people will invest back in your business. Interview process that I follow at my workplace has just one goal to assess: whether or not it'd be great to work with this person and spend over ~50 hours per week with them.

Are you hiring fun people who know nothing about computers? Or are there actually more criteria than you let on here?

> hiring fun people…

Absolutely! This is super super important. Fun to work with, not annoying to waste time with.

> know nothing about computers

It's sad that you think this way of people who couldn't answer your questions at the expected level.

> Or are there actually more criteria than you let on here?

Yes! One way to know if they're any good or not suitable is by giving them a problem statement like so:

'Design X, feel free to choose a language that's suitable for this problem', and then may be proceed to hint with: 'You might want to look at advantages of Static versus dynamic typing'… and then let them ask whatever questions they want to ask or read up or search or start implementing whatever.

Observe what they do -- and how fast can they get to the decision of what language and why. And how to make X (break down of steps) or if they can dive and start making X there itself. Note, if they had theoretical knowledge of what you seek during an interview it will work to their advantage naturally. Or sometimes not.

Of course, this process may not work for you as it does for us -- therefore seeking direct answers about static vs dynamic language may not be such a bad question after all (I get it), but expecting people to accurately remember what an http request or its response looks like may not be fruitful at all. It can throw good people off guard and ruin the rest of the interview for them.

Well, following Netflix's mantra - it is a team and not family that you are hiring for. Anyone can Google and find answers, doesn't mean you would hire everyone, would it?

There are a number of basic items that a competent programmer needs to know off the top of his head. If they had to google for every single item, then their productivity goes down the drain and so does the entire team's productivity. You should fix your hiring.

That's a preposterous attitude. Just imagine if we took a similar approach to hiring for other kinds of jobs:

"OK, so you'd like to work here as a mechanic. What's the difference between automatic and manual transmission?"

"It's not fair to expect me to know that off the top of my head. If I need to know, I'll just do a Google search."

That's a crap comparison.

You're gonna have a hard time drawing a comparison between a line of work where you build things and one where you fix things.

Ok, how about "What is the firing order on a Chevy LS1?" ?

"OK, so you'd like to work here as a mechanic. What's the difference between automatic and manual transmission?"

Nope, more like "can you write out on the board what types of connectors are used in the car cooling system and in what order".

I would not want to work for or with him, if he asked me that in an interview, I'd walk out.... if he think thats what good computer scientist should know...

Reply on news.ycombinator.com