xyrouter

I said, "Given two candidates with all things equal except ..."

I mean if there are two candidates who are equally motivated and are more or less equal in all things except that one is strong at CS fundamentals and another isn't, is there a good reason to reject the candidate who is good at CS fundamentals.

In many hiring decisions, I am faced with a similar choice, and I go for the person who is good at CS fundamentals. If two candidates are good in all other ways, then the understanding of CS fundamentals becomes a tie breaker. I see no rationale for selecting the guy who does not demonstrate his strength in CS fundamentals.

> though in this case the easy and correct thing for the interviewer to do is to say "OK, how is Collections.shuffle implemented?"

And very likely that's what really happened. I have been in such interviews and it is sometimes hard to guess whether the interviewer wants the practical answer (calling a library function) from engineering standpoint or the conceptual answer (demonstrating that I can implement the inner workings of the function) from CS standpoint. Often I would just ask a follow up question to clarify exactly at which level of abstraction does the interviewer want my solution to be in?

In situations where I offer a solution that does not match the interviewer's expectation, they clarify the expectations.

I think it's stupid to assume that a decision regarding time complexity would never come up at their job. Where I work right now, and especially in Google (not where I work right now), it is important that one understands time and space complexity issues well. The data sizes are huge and optimization skills are highly valued.

Sure I can teach constant vs. linear time. But what incentive or reason do I have to spend time teaching these fundamental concepts when I can just hire an engineer who demonstrates the understanding of basic CS at the interview time itself?

Given two candidates with all things equal except that one demonstrates the understanding of CS fundamentals and other does not, why would I want to hire the second person and spend our time teaching him those concepts?

I come across candidate A who shows up on time, with a good attitude, takes heat and shares credit, builds people up, isn't afraid to speak their mind and offers a smart-ass answer to a problem designed to evaluate whether the candidate understands the underlying concepts.

Then I come across candidate B who shosw up on time, with a good attitude, takes heat and shares credit, builds people up, isn't afraid to speak their mind and offers a genuine and insightful answer to a problem designed to evaluate whether the candidate understands the underlying concepts.

I am definitely going to hire candidate B.

Ah! That makes a lot of sense. If Python 3 is the default, it does make sense 'pip' to be the Python 3 pip. That way 'pip' always refers to the default version.

Unfortunately in the Ubuntu and Mac world 'python' is still Python 2.7 and 'pip' refers to the Python 2 pip. Python 3 is available as 'python3' along with 'pip3'.

I am aware of that. So has been many other distributions like Debian, Ubuntu, etc.

My point was: Which command do you normally use to install packages in Python 3? pip3 or pip?

I thought it was pip3 but the article seems to imply that using the pip command to install packages in Python 3 is common too. If this is true, which distribution ships Python 3 with pip instead of pip3 for installing packages in Python 3? Does it not conflict with pip of Python 2?

> On some Python 3 distributions, you may need to replace pip with pip3 in the command above.

Are there any distributions where the command pip just works with Python 3?

In every Python 3 installation I have used, I had to invoke it as pip3. So it seems to me that pip3 is the commonly used command and one may need to replace pip3 with pip only on some distributions.

> ability to read code and locally easily reason about types only gets more critical as the application gets more architecture or performance dependent

Exactly! And using auto for variables with very limited scope where the type is obvious effortlessly does not negatively affect the ability to read code and in my opinion improves the ability to read code.

> Absence of explicit type info is an inherently bad thing.

Let me reiterate: It is your opinion which many people here do not agree with in the context of types obvious from context. Your opinion is definitely not a popular coding standard and definitely not a fact. Most of the coding standards are in favor of using auto for simple code where the type is immediately obvious from the context.

The auto keyword is available to help people who do not share your opinion. The auto keyword is present for teams which agree that absence of explicit type info is a good thing for simple code with obvious types (obvious from the context).

Teams that believe that absence of explicit type info is an inherently bad thing don't have to use the auto keyword. But that belief does not become a fact no matter how many times you reiterate that belief.

> paying the penalty of giving up valuable explicit info

That's your opinion. My opinion which many coding standards agree with: There is no penalty in giving up explicit type info in a local loop variable. The typo info is not valuable in that case.

> There’s absolutely no sense in which less explicit information is somehow better for code readers.

This is patently false. It has been demonstrated more than once in this thread that there clearly are cases where the types can be deduced effortlessly and avoiding explicit information leads to cleaner code.

Your claim is only your subjective opinion/belief and definitely not a fact.

We might just have to agree to disagree, but I would disagree with your claim here in the strongest possible terms. Constantly pretending as if your subjective beliefs comes off as obtuse and is in poor taste. There is one size fits all standard for coding. You are free to follow your coding standards and so is everyone else. What looks like an obvious argument to you may appear absurd to another. Like I said, the world of software development is far more heterogenous that you seem to believe it is.

> this kind of system that relies on the whole codebase having no localized type annotations (so you can’t reason locally about code when you go to refactor or change types, etc.), is so egregiously bad.

Nobody said that either. The parent comment specifically said that they have alternate types to provide different performance characteristics and behavior. Such code bases do exist contrary to what you believe.

Don't think of it as an Apple type suddenly replaced with an Orange type on one fine day and your head begins to spin when you try to understand what the code does.

Think of it more like int32_t being replaced with int_fast32_t because you realize you want to port the code to a new architecture due to which int_fast32_t makes more sense now. Now the argument should not appear as "egregiously bad" as you make it look like.

The world of software development is far more heterogeneous than what your experience might have led you to believe.

> In most cases it won’t be anywhere near this easy anyway

Then don't use auto in such cases -- is the point of the discussion here.

Use auto anywhere it is indeed nearly this easy.

When the situation is simple, auto clearly provides an advantage of automatically deducing types that are very obvious to humans and the compiler. The argument here is that not having explicit types here is better.

Your cannot use the word "strictly" here in the mathematical sense at all since you have not mathematically established that explicit types for simple cases are better. It is only your subjective opinion that explicit types are better even in simple cases and such an opinion is far from the exactness and axiomatic nature of mathematics.

You pretend as if the proposition that "explicit types are better" is an axiom. It is not. To many of us such proposition is neither self-evident nor obvious because many of us believe removing explicit types for simple cases is better. As such, the usage of "strictly" here is merely a weasel word.