Home > Reflections | ⏮️ ⏭️

# 2024-06-04

## 🏋️ Practice

### Problem statement

A peak element is an element that is strictly greater than its neighbors.

Given a

0-indexedinteger array`nums`

, find a peak element, and return its index. If the array contains multiple peaks, return the index toany of the peaks.You may imagine that

`nums[-1] = nums[n] = -∞`

. In other words, an element is always considered to be strictly greater than a neighbor that is outside the array.You must write an algorithm that runs in

`O(log n)`

time.

### 🪞 Reflections

- I’m not happy with the solution below
- More importantly, I think there’s a strategic error here
- When planning, I didn’t really settle on a solution that I had much confidence in
- I decided to try implementing it and just hope for the best
- But it turned out poorly, as I’d expected it would
- In general, I don’t think it’s a good strategy to attempt to implement a fuzzy plan that I’m not confident in

1. It seems like when I do, it doesn’t turn out well. This is more of a trend than an isolated incident.

2. But what to do instead?

3. Why is it fuzzy?

4. How can I make it less fuzzy without implementing it?

5. In this case, I had a hunch that it wouldn’t work, and eventually found a test case to confirm that hunch.- That’s better than not finding the bug, and allowed me to find a hacky workaround, but it wasted a lot of time.

6. If I caught the bug during a test case, maybe I can try testing the “fuzzy” algorithm “manually” before implementing it in code. - This would at least save the time required to implement a wrong solution
- And it may be more difficult to modify a wrong solution than it is to implement a correct solution from scratch

- That’s better than not finding the bug, and allowed me to find a hacky workaround, but it wasted a lot of time.
- In an interview context, if I’m not confident in my plan, I should probably engage with the interviewer rather than attempt to implement and hope for the best.

1. At least this way I may get a hint and some help constructing a better plan. - Even without a hint, testing the algorithm manually before implementing the code seems like an improvement.
- But maybe there’s something even better.

1. I’m not quite sure what that is, but there’s an idea that makes me think there’s a better way:

2. In general, testing is not a good strategy for improving quality.

3. We can, of course, test the output of a process and discard the results that don’t meet our quality bar.

4. But a better approach is to improve the process in order to reduce the variation in the outputs.

5. Note: This idea comes from my understanding of W Edwards Deming’s writing.

6. So in this case, rather than test a fuzzy algorithm and then reject it when it doesn’t work, how can I improve the process of generating an algorithm in the first place?- Note: if I test the algorithm and find that it doesn’t work, I’m going to have to do this anyway, so we may as well save some time and skip the testing step until we have an algorithm we’re confident in.

7. So this is my new challenge:

- Note: if I test the algorithm and find that it doesn’t work, I’m going to have to do this anyway, so we may as well save some time and skip the testing step until we have an algorithm we’re confident in.

### 🤔 How can I generate higher quality algorithms without relying on testing?

To be continued…

### My first solution

### Round 2

I took a break, then came back and thought about the problem for a while, sketching some ideas with paper and pen.

I eventually convinced myself of an algorithm, then sat down to solve the problem again.

Here are the results: