These need to be both true and not just the same boring stuff everyone knows. Of course, everything mentioned here will be verified.

We'll be checking their actual competence against their perceived/claimed competence.

Whether it's work-related, a side project, or even something from school, everyone should have something impressive to say here. Unfortunately, very few do. A lot of them will just start telling you about participating in a cool project, but we don't care about the amazing people they worked for/with. We want to know what they themselves did. Working at NASA or Google means nothing if you were just a code monkey.

Binary tree, B tree, B+ tree, red/black tree, finger tree, etc., with appropriate details.

Static: type checking performed during compile-time; Dynamic: type checking at run-time.

A graph with weighted edges. A matrix would also work, but be considerably less efficient and complicate the shortest path algorithm needlessly.

This allows for recursive functions that would otherwise fill up the call stack to be optimized by the compiler or interpreter in a way that only uses the space of an iterative solution.

The linked list, since inserts are considerably less expensive.

Functions defined over a range of types, acting the same for each type. Examples include map, generics with type parameters, fold, etc.

A nondeterministic finite state machine.

All of lambda calculus can be reduced to compositions of S and K combinators (I is optional).

Ensure that all functions in a program are referentially transparent and thereby purely functional. Several methods exist to then manage non-local state transformation, the most obvious being structures like monads, but there are other methods, such as those from type theory, like uniqueness types.

In most mainstream languages, this isn't possible to do in one function. One could almost do it in any language it was possible to create a quine in, but in something like C, for example, this would mean compiling the output of it before you could run it. We get closer to the desired result in interpreted languages that provided some kind of eval function. However, it is completely possible in any language that has the ability to treat its own code as data. Really CompSci-literate types will be able to list several possibilities along these lines.

In trivial programs only capable of taking limited input, this is obvious, and can be done by ad hoc methods that enumerate all input values. One method to do this for complex programs is to first define the program's "formal specification." There exists a field of computer science known as formal methods, where at the highest level of formal verification, the program semantics can be machine-checked by a theorem prover against this specification using various forms of logical calculi and type systems.

Simplest answer is to just create a hashmap with the letter being the key and the value being the count, but there's other solutions that are okay, provided they don't require a lot of extra looping or are otherwise greater than O(n) or have a ton of constant time operations.

High computational complexity, high recursive depth, repetition of computation.

Tail recursion, population of matrices/lookup tables, memoization, iterative population of an infinite sequence, etc.

Its runtime is O(log n).

Unknown. All that is given here is the upper bound.

Abstraction, encapsulation, subtype polymorphism, inheritance, message passing, etc.

Anything that shows they think of programming languages in a formal way, and not just a finite bag of tricks they can use.

This is probably a better version of the previous question.

Compiler: generates executable binary; Interpreter: translates and immediately executes source.

Procedural, declarative, functional, logical, stack, etc.

Alternatively, one could say there are really only three paradigms: imperative, functional, and logical.

Hopefully they at least know what they are. Really smart candidates will not only have opinions on when to use them, but maybe mention their misuse, anti-patterns, or have some fundamental criticisms of the concept.

They should at least be able to describe one or two of them, with implementation details.

There's a lot of common misconceptions about unit tests. A lot of people think they understand the concept, but due to never actually writing any, say incorrect things about them. They should at least mention edge cases and code coverage. Some thought about the goals and trade-offs of unit tests are also a good sign. On the other hand, be wary of True Believers regarding some aspects of testing, particularly TDD.

Foremost here is generative (or property-based) testing, popular in FPLs. There are also more SE-centric methods, like integration and simulation testing.

This is a pretty straight-forward problem of medium interview difficulty. Here's an acceptable solution using infinite sequences:

(defn identity-matrix
  "Create an identity matrix, of size n x n." [n]
  (->> (concat [1] (repeat n 0))
       (repeat)
       (apply concat)
       (partition n)
       (take n)))

First make them think of how they're going to model their hashmap before proposing an implementation. If using the proposed nested vectors, here's the naïve solution:

(defn my-get
  "Retrieve element `e` from map `m`." [m e]
  (second (first (filter #(= e (first %)) m))))

(defn my-put
  "Put key-value pair, `k` and `v`, into map `m`.  Overwrite current value at
  key `k` if it already exists." [m k v]
  (cond (empty? m) [[k v]]
        (= k (ffirst m)) (concat [[k v]] (rest m))
        :else (concat [(first m)] (my-put (rest m) k v))))

This is a good question for a follow-up discussion on efficiency and implementation trade-offs.

A good question for former CL programmers claiming to have made the transition. One of the differences with Clojure is macros in practice. These should be avoided in use for syntactic abstraction, and generally only used when controlling evaluation or creating APIs and (e)DSLs. Outside of these use cases, macros should only be used when data structures and functions won't suffice (which is very rare).

A sequence that when evaluated only realizes values and caches up to the point evaluation ends. These are super useful and appear everywhere in Clojure. For one, they're efficient when not all elements of a sequence are known to be needed. Another use for them is creating iterative versions of algorithms commonly implemented recursively.

This is an opinion-solicitation. A good answer here demonstrates intermediate-level understanding of program design in Clojure, at least as it relates to internal program data modeling. There are some wrong answers, the most obvious being suggesting that you should always use one or the other.

Clojure dynamic-typing has mostly the same drawbacks as in other languages. Some mechanisms available to reduce the negatives are pre-conditional asserts on functions, a strong testing story, naming parameters appropriately, unification of program control data structures that are passed around, constraint-based design, and optional typing libraries (though the latter comes with its own downsides).

This is a pretty straight-forward problem of medium interview difficulty. Unlike with the Clojure solution for this same question above, there's a larger number of more elegant solutions for this. Here's an acceptable solution using infinite sequences:

split :: Int -> [a] -> [[a]]
split n [] = []
split n xs = w : split n ws
  where (w, ws) = splitAt n xs

idMatrix :: Int -> [[Int]]
idMatrix n = split n $ take (n*n) $ cycle $ 1 : (take n $ cycle [0])

For languages, hopefully they'll at least know C#, VB.Net, or C++/CLI. Extra points if they've spent time on F# or some of the many ported languages. For components, they should be able to rattle off a few they're fond of, like LINQ, WPF, WCF, etc. With the .Net ecology so massive, this gives you a starting point of stuff to verify competence in.

A delegate is a type that references a method, allowing it to be passed around, such as in an argument list. A multi-cast delegate is a delegate that can have multiple elements in its invocation list, typically used for event handlers.

Allows run-time retrieval of information about an object, such as its type.

^ is a managed pointer, gcnew instantiates .Net reference types.

Language Integrated Query, a library added to the .Net framework in 3.5 and recently extended with PLINQ. It allows for query operations to be performed natively within the language itself. The main great thing about it is that it allows for compile time checking of query operations, but there's several other pluses.

Native to the .Net framework, just SQL Server databases, DataSets, XML, and objects that implement IEnumerable.

Should probably mention something about SOA, the concept of providing/consuming services, service/data contracts, etc.

An anonymous (unnamed) method, declared inline, applied against a collection, such as a list.

Even if they didn't know what IComparer was, it should be obvious that this means you'll need to create a class implementing IComparer that defines some method that would implement comparison logic.

Using threads, you could manage them yourself using various lock and signal synchronization methods. You could also just use a ThreadPool if it makes sense for your problem (like if the operations are asynchronous). There's also the Task Parallel Library.

No, since static methods don't require an instance of the object.

A variable local to a class where only one instance of it exists for all instances of the class.

Anyone who's programmed in JavaScript some will have plenty of very specific complaints about it, but most likely also a few things they really like. JavaScript is a common filler item on resumes, so this is a good question to ask first.

Not a Number. This is returned when a numeric operation is performed on a non-numeric type and type coercion cannot extract a valid number. NaN is actually of type "number".

Some non-erroneous info about React, AngularJS, Vue.js, etc. Most front-end developers have one of these as their primary framework, so maybe deep-dive on it a bit to see how much that is the case.

Allows the client side to retrieve data from the server asynchronously with a request in the background.

JavaScript Object Notation. A data representation standard that is typically used for serializing and transmitting structured data. It has a few benefits over XML like being easier to read and being legal JavaScript code.

The former allows JavaScript to type coerce prior to checking the equality, the latter does not.

Modifying element.innerHTML is the preferred method in pretty much every scenario. document.write can work, but has potential pitfalls.

Loose/weak, dynamic.

Something like:

if (typeof someVar !== 'undefined' && someVar !== null) {
  // ...
}

Functions can be passed around like any other object in JavaScript, e.g. they can be passed as arguments or returned from other functions.

Function scope, but not block scope.

It would immediately append that method to all objects covered by that type, even those declared prior to this augment.

By reference.

Executes a string of JavaScript code, with direct access to the JavaScript compiler. You should almost never use eval(), as there are almost always better ways of doing things.

This loops through all properties of an object (including all members from prototypal inheritance.)

The ability of a function to have access to the scope within which it was declared, despite possibly no longer being in that scope.

JavaScript try...catch blocks don't support exception type checking as part of the language. You would have to do this manually within a single catch block.

An object that represents a value that may be available now or in the future. They are often used in asynchronous computation.

Yes. Something like this will do it:

var stuff = function () {
  var secret = 0;
  return {
    get_secret: function () {
      return secret;
    }
  };
};

There's two answers to this. The more obvious one is to sum up all numbers from 1 to n (there's also a formula for this which can save time), then remove each integer from the set and subtract it from the sum. The remaining amount will be the missing integer. The other solution is to simply XOR all of the integers.

Here's an acceptable implementation. The point is to give the candidate the chance to use some FP functions. The non-FP solution isn't as nice to look at.

def sum_adult_ages(lst):
    adults = filter(lambda p: p['age'] >= 18, lst)
    return reduce(lambda x, y: x + y['age'], adults, 0)

Higher normal forms guarantee lower vulnerability to data inconsistency, reduce data duplication, and reduce the of the number of unused columns.

It's amazing how many people screw this up. The result set would be:

A1, 1, B1, 1
A2, 2, B2, 2

Junction table.

Lots of good answers here, but probably should mention indexes, denormalization, star/snowflake schemas, fact tables, data marts/warehousing, materialized views (indexed views in SQL Server), or maybe even NoSQL solutions.

A critical question if you want a quality candidate. Almost everyone that's any good at programming will be genuinely interested in it enough to do stuff on their own time or have some areas that they're especially fond of. If this is the case, you can get them to tell you about it with obvious enthusiasm.

This is where they can tell you how they're a genius in some obscure field of math, science, or engineering.

Most people do. If not, no big deal.

When the candidate get his hand around it, he won't be able to pull it out. Tell him to keep trying.