Marina-

Flea++ wrote:


Did you go to the University of Washington or somewhere else?

No, I went to schools in the Midwest (of comparable size).  

Flea++ wrote:


 What were you favorite computer science classes and why?

For me, enjoyment of specific courses was highly dependent on the quality of the professor, and the lack of professor's attachment to giving busy work.  My favorite general topics in CS were: Theory of Computation, Cryptography, Databases, and all of the Compiler/Programming Languages courses.

Minh wrote:

I'd never thought about what it would take to QA a compiler before. QA in my previous companies haven't been at all technical. What they were good at is trying weird stuff on the UI to try to break stuff.

So, to QA a particular feature in the compiler, you must know that feature really well, right? Or knowing it well is actually a hinderance -- because you sorta gotta buy into that usage pattern.

In the case of C++, solid testing of scenarios enabled by a new feature definitely requires knowing it well, in my opinion (even tests for simple scenarios can always break as the compiler evolves, which is one motivation to have tests at all levels of complexity in place).  If you're referring to the implementation itself, I think knowing the specifics of implementation details can sometimes  be helpful in coming up with a nice breaking test case, but may not be the most productive way to write thorough tests on the whole.

In my experience, the ability to break the compiler usually comes from using a feature in conjunction with other elements of C++ (including itself)  in an atypical way (e.g.: testing A<5> vs. A<B<7>::value> where B<T> inherits from A<T>...).