43 lines
2.8 KiB
Markdown
43 lines
2.8 KiB
Markdown
#interview #logos #pair-programming
|
|
|
|
Ricardo sent him the Minesweeper problem.
|
|
|
|
Wasn't early to the meeting. Showed up at 13:02
|
|
|
|
Console application in C#, limited GUI
|
|
|
|
Seems familiar with Visual Studio. Able to explain his basic plan to get going: two models (Cell and Board), one service to calculated neighboring cells.
|
|
|
|
Interesting choice: adding "NeighborCount" on the cell model--should the cell model know about its neighbors?
|
|
|
|
IN progress: ahs not initialized the Board property yet--how will he discover this?
|
|
Got NRE when he ran this. Easily found that he missed initializing the BoardGame property, explained why it threw well. Struggle a little to initialize the multi-dimensional array correctly.
|
|
|
|
Questions:
|
|
1. Can you GridSize everywhere to avoid errors?
|
|
2. Does each Cell really need to know it's neighbor mine count? Or is that something the board knows about?
|
|
3. Instead of a `(Row, Column)` comment, is there another way we could label the values?
|
|
4. Is there a way to calculate the coordinates of the surrounding cells without statically constructing a list of offset pairs?
|
|
5. You iterate through all cells in the board multiple times. Can you extract that logic to reuse wherever needed instead of copying it?
|
|
6. Can he explain why using GridSize at the property initialization level doesn't work? He couldn't explain it--he needed a const or static integer for `GridSize` instead of a readonly class field. Opted to initialize the property at the top of the constructor.
|
|
7. Can he simplify the user input questions (like don't show option for placing a flag if no squares are revealed yet--ie, impossible to know where mine is yet), or does he want to allow a user to place flags without knowing
|
|
|
|
Nits:
|
|
1. Property, field and variable naming not consistent
|
|
2. Not communicating to user if flag cannot be placed because cell is revealed
|
|
3. Unnecessary comments
|
|
|
|
Bad coding habits:
|
|
1. Reaching into the `Board` class to set cell properties directly in the `BoardGame` field instead of letting the `Board` class own manipulating the `BoardGame`
|
|
2.
|
|
|
|
Notes:
|
|
1. Using `Random` to fill 10 mines into the board, knows basics of `Random` API.
|
|
2. Speaks English _very_ well
|
|
3. Did not run the program early to see if there were errors
|
|
4. Found a bug he wrote in column and row check before executing program by thinking about it logically and visualizing the board.
|
|
5. Has a bug using `.Length` of a multi-dimensional array! Will be x * y and not x as he's hoping. He figured it out without any prompting from me and used `GridSize` in the check instead.
|
|
6. He had thoughts about the `Board.BoardGame` field--renmaing it. This is a good sign to me, thinking about clearing naming something that's redundant (against the class name).
|
|
7. How can you communicate to the user better about what's going on (found mine or tried to place flag on revealed square, for example)?
|
|
|