yankjenets

It's a second semester freshman course for CMU CS undergrads.

Ah ok, understood.

I would argue that is still not a convenient lie of "a branch is a pointer to a commit". Rather, the rebase command is changing what the branch is pointing to, and git tries to make that clear.

After that rebase command, there is a message like `Successfully rebased and updated refs/heads/yourbranch`, showing that the branch named yourbranch is now pointing at something new.

Your original comment:

>Consider the case where I create a new branch B from A then remove a commit. The branch is now more like a "a pointer to a commit on a DAG" where branch B points to a commit on a different DAG than branch A.

My counterpoint taking this to the extreme:

>Consider the case where I create a new branch B from A then run git reset --hard SOMESHA1

In my example, again the new branch is pointing at a completely different commit--because I am repointing the branch.

By "remove a commit" do you mean rebase A to point at its previous commit, HEAD~1?

A commit SHA represents the entire DAG up until that point, not a given changeset. So in your example, branch B is still a pointer to a commit, and branch A is a pointer to a different commit. Where is the convenient lie?

Isn't that an offer, not a threat?

Apollo is fully allowed to make things difficult by complaining on social media that he thinks the pricing is unfair. What is illegal or even unethical about that?

I listened to the audio as well. Can you please explain how you think Spez interpreted the threat? He thinks that Apollo is threatening to blast them on social media? Slander him? Break his legs? Murder him?

Because the answer should be an obvious "no it is not guaranteed to be sorted".

If the answer is yes the input is sorted, then that context should have been given in the original prompt as it is a completely different question.

And if you had a magical oracle that spat out the two numbers if a solution exists, and otherwise told you no solution exists, you would have an O(1) solution.

Just because you can ask a question whose answer makes a drastic difference between the best algorithm involved, doesn't mean it is a good question.

(and note I said "_almost_ make me dock points...". And if the answer to the question was "yes, the list is sorted", I would _certainly_ dock points off of the interviewer/company if I were the interviewee for not giving that context).

My point was more it is just a different problem.

Another "clarifying question" in this vein would be "if there is a valid answer, will they be in index 0 and 1 of the list?"

I'm obviously being somewhat facetious here but there's a difference between clearing up an ambiguous part of the question versus asking something that the interviewer gave no indication would be part of the problem.

> can I multiply a number by itself

This is a great clarifying question. Ambiguous from the prompt.

> what shall I return if there are multiple numbers meeting the criteria

This is a decent clarifying question. I think it is better expressed as a clarifying point instead of question--mention to the interviewer your thinking out loud; something like "if there are multiple options, I'll return an arbitrary pair". Ask if they are okay with that.

> is the list sorted

If I were the interviewer, this question would almost make me dock points off of the interviewee. Maybe not that strong as I do try and ensure people are as comfortable and open as possible in asking clarifying questions, but this barely qualifies as a clarifying question in my opinion. It is almost irrelevant to the prompt; if the lists were sorted and the interviewer failed to mention / there was some "trick" that they expected you to clarify, that would be an awful interview question.

That being said, overall agree with the sentiment and yes you should try and always ask clarifying questions and ensure you understand the problem statement.

Optimize for readability above everything else. Almost all of these examples I'd argue would be better suited for something like .map(). Little point in being overly cute, and if you are working with arrays large enough such that doing multiple passes is that much of a performance hit client-side, you have other issues going on.

There's a phrase for that. "not permanent."