I think it's less about the notation, and more about thinking around computational complexity. You should know when to use a set vs a hash vs a list vs an array. You should know what different sorting algorithms do, and why you might use one over another. In some cases having exposure to more esoteric data structures like persistable tries, minimal spanning trees, red/black tries, bloom filters, etc can come in handy. Knowing why things like that are useful is worth knowing. But I agree with you, judging a bootcamp graduate on skills that can be taught with experience and continual study is probably not the best way to go about hiring people.

I think it's more about simply having an awareness of algorithmic complexity. I'm talking about writing a doubly nested 'for' loop and being able to realise that you've just written an O(N^2) algorithm if you're iterating over the original collection again. This sort of stuff is blindingly obvious to experienced programmers but for bootcamp grads who haven't built up that intuition, a short course on Big O notation exposes them to it.

Or, since you're hiring Junior devs, someone could like, take 10 minutes to explain why what they did is wrong and point them towards some resource to help them get on the right track.

This whole thing is part of the circular logic problem with hiring: you have people making these hiring decisions that aren't trained in hiring, so they just go with "what makes sense to them" or hiring a younger version of someone who looks exactly like them for a junior role. It's fine, it works for the company, but it's why people will miss long term talent.

Do you have any resources would you recommend for becoming better at hiring? It's an area I think I definitely have room for improvement in

Damn straight. 100% of stupid whiteboard coding questions could easily be solved with taking 10 minutes to google / explain the solution. So why are these stupidities even asked? In other words, the author is incompetent and shouldn't be in charge of hiring. He won't hire someone because he won't take 10 fucking minutes to explain to them something beyond simple (although if you explain it in big O terms, it's not simple). That's a manager who is in the wrong job.

I think your experience is largely true for professional web developers, but with the advent of things like Node that brought JS into back-end land, there are a lot of traditionally front-end people spilling over into back-end and "full stack" roles, which often do require some basic level of competence with complexity analysis.

When you make the switch from writing code to support UI elements to writing code to handle data processing, for example, you're going a bit beyond the standard coding bootcamp's toolkit. I think this is the author's point, and why he recommends that bootcamp grads (who may end up in situations like these) take extra steps to be prepared for whatever curveballs come their way in their careers.

I agree and I don't. For the record, I'm a (2014) bootcamp grad. I don't use Big O directly, and still struggle routinely to talk in those terms, but also consider considering performance one of the most important parts of my job.

I think it's important that bootcamps teach about complexity, and that they don't do a great job of it. I also think asking anyone to speak in terms of big o may or may not be the most comfortable way for the candidate to talk about it.

I do a lot of interviewing now, and prefer to check to make sure that they understand how to optimize their solutions in a coding context, rather than asking about the "description" of that optimization, personally.