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?
That is one way to “remove a commit” and I agree with your analysis for that case.
The method I had in mind is an interactive rebase. Assume there are n > 5 commits on my branch, choosing 5 arbitrarily. If I run “git rebase -i HEAD~5” then use the “drop” command on the third-most-recent commit, I do end up with a different DAG. The change is subtractive and not just the removal of the current HEAD.
This kind of history change is definitely a bit less common but not obscure by any means. I’ve rebased to drop commits on my own feature branches many times.
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.
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?
>He thinks that Apollo is threatening to blast them on social media?
Threaten him with pretty much what he did. We'll go quietly instead of making a large amount of noise and complaining and getting the generally hostile Reddit user base riled up.
Except thats not at all what he said. The noise referred to the amount of API "noise" he generates. Which reddit likes to pretend is costing them millions.
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.
I don’t think it’s fair to dock points for asking if the list is sorted. It might feel like a stupid question but clarifying requirements rather than making assumptions is one of the key differentiators between a junior and senior engineer.
>this barely qualifies as a clarifying question in my opinion [...] It is almost irrelevant to the prompt
One of my first internships was punching in 10 meter reams of dot matrix printed numbers.
After several days, during lunch, I casually mentioned how much easier it would have been if the list was electronic.
They said that it was electronic, they just printed it out "for my convenience" so I wouldn't have to constantly keep switching between two apps.
They gave it to me on a floppy, and with the help of an Excel macro I finished two weeks worth of work by the end of the day.
While these whiteboard questions obviously aren't designed to have wider context, I now always appreciate when candidates question the question itself.
Asking if the list is sorted was also the very first question that popped up in my head, because it makes the difference between a linear and a quadratic algorithm. Contrary to, for example, having the choice between an n log n algorithm and a linear algorithm, when given the choice between a quadratic and a linear algorithm, it is very rare that the right choice is the quadratic algorithm. (Semi-related: [1])
(EDIT: after thinking about this more than two seconds, the quadratic algorithm for unsorted input can become n log n by sorting the list, though that takes linear space. This would certainly be a clarifying question.)
The other questions would be less obvious to me, though I'd encounter them while thinking more than 2 seconds about the problem, I suppose.
Or maybe this just outs me as an ex-amateur competitive programmer :)
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).
Clarifying questions may help or not depending on the interviewer. Some want you to clarify, others expect you mostly not to; they'll call that "taking initiative" in that you 'take ownership of the problem' and get something done. Otherwise they'll take that as a request to "spoonfeed you" which is a no-no. You can't tell in advance what they want, and I don't know which attitude is better.
> > given a list of numbers, return two numbers such that one times the other results in 220
> > is the list sorted?
> this barely qualifies as a clarifying question in my opinion.
Maybe I'm being too charitable but whether or not the list is sorted is very relevant to the first solution that came to my mind as I read the problem.
for i from 1 to n:
for j from i+1 to n:
prod = a[i] * a[j]
if prod == 220:
# found it
if prod > 220:
break
# don't waste time, assumes sorted
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.
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.
> Almost all of these examples I'd argue would be better suited for something like .map()
Roughly half of his examples take an array and return either a differently-sized array, or a different data structure altogether. I can’t imagine how one could argue for a map in these cases.
Use the right tool for the job. Array to potentially different sized array? Use flatMap (which he implements in his example, albeit not it an optimal way). Array to single object or value? Use reduce.
I think the intent was simply to teach. Obviously if something can be done with map() instead of reduce(), it'll be more readable as map(). But seeing how the other list functions can be made out of reduce() helps you understand how it works.
That's also my minor nitpick, I feel like the syntax : `list.filter(myFilter).map(transform)` is clear about what I do and, each functions has a clear goal.
Unfortunately not in a way that can optimize these methods. This is one reason the Java Streams API, which has a similar purpose (e.g. map, filter, flatMap, reduce, etc.), is a better design IMO because you can chain together method calls without creating (and iterating) the full array at each step.
