-
Notifications
You must be signed in to change notification settings - Fork 5
/
dev check list.txt
140 lines (127 loc) · 7.25 KB
/
dev check list.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
Coding
1. Loops
2. Recursion
3. Formatted output - "printf"
4. Text-file I/O
#------------------------------------------------------------------------------------
Object Oriented Programming
Terminology
1. class, object (and the difference between the two)
2. instantiation
3. method (as opposed to, say, a C function)
4. virtual method, pure virtual method
5. class/static method
6. static/class initializer
7. constructor
8. destructor/finalizer
9. superclass / base class / generalization
10. subclass / derived class / specialization
11. inheritance
13. multiple inheritance (and give an example)
12. encapsulation
14. delegation/forwarding
15. composition/aggregation
16. abstract class
17. interface/protocol (and difference from abstract class ?????????????)
18. method overriding
19. method overloading (and difference from overriding)
20. polymorphism (without resorting to examples)
21. is-a versus has-a relationships (with examples)
22. method signatures (what's included in one)
23. method visibility (e.g. public/private/other)
x. reflection
x. struct
OO Design
Candidates who've only studied the terminology without ever doing any OOP often don't really get it.
When they go to produce classes or code, they don't understand:
the difference between a static member and an instance member, and they'll use them interchangeably
when to use a subclass versus an attribute or property
that objects are supposed to know how to take care of themselves
They'll create a bunch of classes with nothing but data, getters, and setters (i.e., basically C structs),
and some Manager classes that contain all the logic (i.e., basically C functions),
and voila, they've implemented procedural programming perfectly using classes.
the difference between a char*, an object, and an enum
polymorphism is not the same as inheritance
Or they'll have any number of other fuzzy, weird conceptual errors,
and their designs will be fuzzy and weird as well
For the OO-design weeder question, have them describe:
1. What classes they would define.
2. What methods go in each class ( including signatures).
3. What the class constructors are responsible for.
4. What data structures the class will have to maintain.
5. Whether any Design Patterns are applicable to this problem.
A good OO design question can test coding, design, domain knowledge, OO principles, and so on.
A good weeder question should probably just target whether they know when to use subtypes, attributes, and containment.
#------------------------------------------------------------------------------------
Scripting and Regular Expression
#------------------------------------------------------------------------------------
Data Structures
Fundamentals of "big-O" algorithmic complexity analysis.
algorithms usually fall into the following performance classes:
constant-time, logarithmic, linear, polynomial, exponential, and factorial.
the big-O complexity for the operations of data structures. Example:
finding an element in a hashtable is usually constant-time
finding an element in a balanced binary tree is order log(n)
finding an element in a linked list is order N
finding an element in a sorted array is order log(n)
Similarly for insert/update/delete operations.
And they should be able to explain why each operation falls into a particular complexity class.
No math needed, no proofs, just explanations.
The (concrete) data structures they absolutely must understand are these:
1. arrays
fixed-sized, indexed, contiguous structures
homogeneous elements (same type)
elements can be accessed in constant time given their indices
2. vectors - a.k.a "growable arrays" or ArrayLists
objects that are backed by a fixed-size array
resize themselves as necessary.
3. linked lists
lists made of nodes
contain a data item and a pointer/reference to the next (and possibly previous) node
4. hashtables
amortized constant-time access data structures that map keys to values
backed by a real array in memory
with some form of collision handling for values that hash to the same location
5. trees
consist of nodes with optional data elements and one or more child pointers/references, and possibly parent pointers
representing a hierarchical or ordered set of data elements
6. graphs
represent arbitrary relationships between members of any data set
represented as networks of nodes and edges
Describe, for all the data structures above:
* what you use them for in real-life (examples)
* why you prefer them for those examples
* the operations they typically provide (e.g. insert, delete, find)
* the big-O performance of those operations (e.g. logarithmic, exponential)
* how you traverse them to visit all their elements, and what order they're visited in
* at least one typical implementation for the data structure
Difference between an abstract data type (Stack, Map, List, Set, etc),
and a concrete data structure such as a singly-linked list or a hash table.
For a given abstract data type (e.g. a Queue),
suggest at least two possible concrete implementations
explain the performance trade-offs between the two implementations
#------------------------------------------------------------------------------------
Bits and Bytes
* know what bits and bytes are
* able to count in binary and hexadecimal
* able to convert between the binary, octal, and hex representations of a number
* not stare blankly at you when you ask what 2^16 is. It's a special number. They should know it
* know at least the logical operations AND, OR, NOT, and XOR, and how to express them in their favorite/strongest programming language
* understand the difference between a bitwise-AND and a logical-AND; similarly for the other operations
* know the probable sizes of the primitive data types for a standard 32-bit (e.g. Intel) architecture
* know what the primitive types are (byte, short, int, long, float, double, char, boolean)
and, except for boolean, exactly how much space is allocated for them per the Language specification
* know the difference between signed and unsigned types
what it does to the range of representable values for that type
whether their language supports signed vs. unsigned types
* know the bitwise and logical operators for their language
be able to use them for simple things like setting or testing a specific bit, or set of bits
* know about the bit-shift operators in their language, and should know why you would want to use them
* know about the sizeof operator and how (and why/when) to use it
#------------------------------------------------------------------------------------
Sorting and knowing the differences in complexity between bubble sort, quicksort, and heap sort.
When, why, and how to use common data structures such as lists, queues, dequeues, stacks, heaps, hashes, etc.
The when, why, and how of using of OO design and programming.
How to deal with concurrency between threads and processes, and in distributed systems.
When, why, and how to use common design patterns and architectural structures
e.g. Singletons, Factories, Pools, Iterators, etc., MVC, and common multitiered technology stacks, such as LAMP, MEAN, etc.