On Apollo 11, Armstrong had to flick a switch to activate or deactivate manual control. On later flights, merely moving the hand controller activated manual control, and letting go of it deactivated manual control.

I read that too, but I thought it said that was employed on Apollo 15.
Hmm i'll have to find the source again now!

__________________
N6MAA10816
'Forensic anthropologist! That's why no gun'
Are you a Bright?

They introduced manual LPD redesignation for 12, didn't they? That's during P64 rather than P66 though.

Half-credit. A change was made to the LPD designation process, but it was not to add manual control. The LPD designation was augmented with landing radar data after Apollo 11.

P66 was augmented to treat the ACA manipulation differently. What was the different interpretation of the ACA?

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

At that point in the interview I stand up, shake your hand, and say, "thanks for revealing yourself to be a smart aleck before I made the mistake of working here."

LOL, that's one of about 30 questions I ask, nearly all of the rest of which which are straightforward. And to say it is the "incorrect" answer is a bit strong. The "incorrect" answer, I suppose, would be to say, "Quicksort? What's that?" (Don't laugh; it's happened.) Every question I ask has a series of followups, because the purpose of an interview -- in my mind -- is to determine the limit of the candidate's knowledge and experience, wherever it lies. If it happens to lie beyond my own knowledge, the so much the better. But if not, then I locate it so that I know where it lies. And I state this at the very beginning of the interview, adding that "I don't know" is a noble answer to any question. I also make it clear that I'm looking for "outside the box" thinking on many of the questions.

If someone writes Quicksort on the board, he'd better get it right. My followup in that case is, "Are you sure that's a correct implementation?" or "How would you go about ensuring that's a correct implementation?" whether the implementation is correct or not. This often leads the candidate into considering the answers I think are more appropriate.

But if you had left the interview on that basis, that's a perfectly reasonable action. The interview is bidirectional. If you don't like me as a boss, then an employment relationship is ill-advised in any case.

Life is too short for me to play mind games with an interviewer. If you don't like my choice of books, that's your problem. Not mine.

Nor mine, although I occasionally ask, "What is the airspeed velocity of an unladen swallow?" at some point in the interview. That's more intended to put a nervous candidate at ease.

But if you honestly think that when my job calls for me to sort an array, I'm going to be dumb enough to write the function myself instead of using a standard library, you're insulting me.

The question is intended to discover how a candidate solves a problem, not to discern whether the candidate knows Quicksort. If it takes several followup questions or a conversation to make the intent of the question clearer, then I'm happy to oblige.

"Is the standard C library available?"
"Yes."
"May I use it?"
"Yes."

Part of being a good engineer is knowing what questions to ask and when to ask them.

"Are you asking me to write the Quicksort algorithm?"
"I'm asking you to use the Quicksort algorithm; if you can figure out how to use it without writing it, that's preferable."

If I carefully word a question in order to present the candidate with a specific problem, I have no problem with the candidate trying to "defuse" the wording and get right to the issue. The ability to see through intentional ambiguity translates to the ability to see through accidental ambiguity.

If someone writes the "correct" answer, I'll often say, "That was the answer I expected. How would you solve the problem on an embedded system where the standard C library may not be fully there?"

If you then berate me for showing it to you, well like I said, I'm just glad that I won't be working for you.

Berating is never part of any job interview I conduct.

And besides, there are plenty of people out there who would ask the same question you did in an interview, but say the wrong answer (for an interview) is calling the library function.

You're right; and those people have no business hiring or managing good computer programmers. And good computer programmers won't work for such people for long. If you were interviewing me and disallowed my call to the library function, I would say, "I would consult Knuth or a similar reference to make sure I got the algorithm right." If that answer were disallowed, I would say, "Okay, I'll write Quicksort in C for you, but I make no representations about its correctness. I don't program key algorithms from memory, nor do I consider memorization of algorithm implementations a good guage of a programmer's skill."

Now I would expect any candidate to describe Quicksort and give its strengths and weaknesses. And so my next question would probably be, "When might it be inappropriate to use Quicksort?"

They'll justify it as, "when I give you a specification, I want you fill, I don't want you work around. And the specification I gave you called for *you* to write the function." Whatever.

Yes, whatever. And, like you, I would shun working for such people. As an engineer it's my job to make sure I understand the problem before, during, and after the solution. And that means presuming that no problem is fully specified at the outset -- either in a job or in a job interview. If the interviewer does not offer further specification, then I feel he has no right to restrict my answer post facto.

"Is the standard C library available?"
"Unknown."
"Then I'll call the qsort() function in the standard C library."
"You can't do that."
"Why not?"
"Because I asked you to implement the function."
"Is there any reason why I shouldn't copy it from a standard reference?"
"Well, for the sake of the interview. We want to see whether you know how to implement the algorithm."

Then at least the actual intent of the question is out in the open. If it seems appropriate we can discuss whether the basis of the question constitutes good engineering, but not ever interviewer wants to know that.

Like I said, life it too short to play mind games in an interview.

Agreed, but there is a difference between mind games and discovering how a candidate approaches problems.

I never say, "Bzzt. Wrong answer." If I hear an answer I don't like, I guide the candidate toward the correct answer. In that case, the exercise is in seeing how much conversation is required to get the candidate on the same page as me.

"Can you deliver me a piece of software by Friday?"
"No."
"Why not?"
"Because you didn't tell me what kind of software you wanted."
"That's absolutely right; and that means I can't argue you didn't satisfy the requirements. So if you wrote 'hello world' and gave it to me Friday, you'd have done what I asked for."
"Yes, I suppose so."
"So if I give you no other constraint right now than have it to me by Friday, could you tell me right now that you could do it?"
"Yes."

The follows a conversation about constraints.

"Can you deliver me a piece of software by Friday?"
"I'm not sure; what kind of software is it?"
"I don't know."
"Then I'm not sure I can."
"Why not?"
"Because I'm not sure what needs to be done by then."
"But you're sure it would have to be done by Friday, aren't you?"
"Yes, I suppose so."
"So any other requirements that might be given to you later, such as a feature set or reliability, would have to be balanced against that initial constraint?"
"Sure, I suppose so."
"Then the answer is 'yes'. So if I came to you Thursday and said the software I wanted was a POSIX-compliant operating system with no major bugs, by Friday..."
"No, I can't do that."
"But if I asked for 'hello world'..."
"I could do that by Friday."

Then the conversation about constraints.

or, "The correct answer is 'yes'. I didn't give you any other constraints but the deadline."
"Hey, that's kind of a trick question!"
"Yes, sorry, but it's to bring up a topic I want your opinion on. You realized that the problem I gave you was underconstrained, right?"
"Yes, I suppose so."
"And did you suspect that the software I was asking for probably had some other requirements like a feature set, even though I didn't tell you?"
"Sure."
"But that wasn't part of the problem I gave you, and that made you a bit uncertain."
"Yes."
"That's typical of most of the problems we'll ask you to solve. We know some of the constraints ahead of time, but we don't know all of them before we give you the problem. And so every time we discover something knew about the problem, we have to fit that into what we already know. And we need to revise estimates at every stage to see whether or not we're going to make it -- if I change the problem, you can change your answer: it's that simple. Deadlines are part of those constraints. Features are constraints. Allowed defects are part of the constraints. Does this mode of problem-solving make sense to you?"

So do you still not want to work for me?

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

My question in response would be, why are you using arrays when you have a prefectly good pointer system avalible to you?

__________________
Howling from the Shadows

It must be fun to lead a life completely unburdened by reality. --- JayUtah

You can't reason an irrational person out of an irrational belief. --- Noclevername

Apollo: The History and the Hoax
Enter the World of Athran

Wasn't the guidance computer on Eagle programmed so that when Armstrong wanted to rotate the LM he moved the stick and the LM started to rotate, but when he centered the stick, computer ordered the RCS to fire to the opposite direction stopping the rotation. In the later missions it was changed so that the LM continued rotating when the stick was centered. I'm not sure but I have a recollection of something like this.

Wasn't the guidance computer on Eagle programmed so that when Armstrong wanted to rotate the LM he moved the stick and the LM started to rotate, but when he centered the stick, computer ordered the RCS to fire to the opposite direction stopping the rotation...

Close enough. In Apollo 11 and prior, manual mode inherited its attitude from the autopilot at the instant of changeover. If, for example, you are very slightly rolled to the right, you will begin to drift to the right faster and faster. You must correct the attitude manually and cancel the drift manually. This was likely why Armstrong had so much difficulty nulling drift rates in the last moments before touchdown. Eagle was drifting at more than 2 fps leftward at touchdown.

A mode was added where centering the ACA commanded "null all lateral drift rates."

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

...why are you using arrays when you have a prefectly good pointer system avalible to you?

Arrays are still useful, especially with many of the data sets our customers work with. However, I would invite you to investigate methods of improving the solution by using pointers and expect you discuss their relative merits and pitfalls.

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

Oh, that's what it was? I remembered something about centering the ACA and stopping some motion but I apparently mixed it with Attitude Hold and Pulse Mode. Oh well...

Here's my question:
Where were each Saturn V stage built and by what manufacturer?

Many commanders elected not to use that mode, preferring the "raw" ACA motion to the more heavily "cooked" fly-by-wire mode. This is one major advantage of fly-by-wire: the behavior of the control system can be changed or tuned without re-engineering.

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

I thought of a quiz question, so I'll bump the thread

Where were each Saturn V stage built and by what manufacturer?
Components of the Saturn V stages (e.g. engines or feed lines) were, of course, manufactured by subcontractors at dozens of places around the country (world?) but the stage manufacturer locations are normally given as:

S-IC by Boeing (Michoud) apart from some of the early ones by Marshall
S-II by North American (Seal Beach)
S-IVB by Douglas (Huntington Beach)
S-IU by IBM (Huntsville)

Stages to Saturn, Appendix E contains lists of some of the subcontractors and their locations.

I'd like to give a plug to the fascinating Saturn V quarterly reports on Mark Gray's Saturn V DVD that has footage of the manufacturing processes. The reports blow away the HB ideas that money mysteriously vanished into the contractors' pockets or that you could build a Saturn V in 6 months given some blueprints.

That's the answer I was looking for.
Your turn.