Is my technical interviewer being nit-picky or did I really screw this up?

I would suggest you to stop defending yourself and accept the feedback you've been provided here and learn from it.

From my point of view the most important issue with your code is complete lack of code organisation and separation of concerns. IMHO, not knowing these things are not acceptable even for Jr Dev position.

Another nitpick, but hopefully worth mentioning...

On the second line of the func, you're using cell?.textSpace... which communicates that a cell might not be returned, but in the next line you're returning cell! which says you're absolutely definitely sure that it does; your code contradicts itself.

It still works, and here the next line makes it clear it's just a mistake, but in general, code that isn't clear and consistent about enforcing what it believes to be the 'truth' is a massive source of cognitive load during maintenance, and hence bugs.

2 Likes

That job advert states they're looking for an already iOS Engineer with all of those qualifications listed below, so I guess it was way over your head there. You should start searching for some internship positions right now.

I'm just curious, where/how in your career path did you learn about code organization and separation of concerns?

From books. One of them is "Code Complete" by Steve McConnell. I read a bunch of books before my first production code.

Also, "Clean Code" by Uncle Bob. You can probably find a pdf online.

2 Likes

Pro tip: a lot of CS books/text books are readily available online. Add filetype: pdf to your google search query, and enjoy.

Can’t say I can recommend this one.

7 Likes

It's very Java-centric. The first half of the book has a lot of good ideas. The reason nobody writes comments anymore is because of that book. I like to write small methods with descriptive names that do a single task. The descriptive names were supposed to replace comments. Anyway, I learned some things from that pdf.

It is quite dated, and I don't fully agree on a lot of things in the book (even back in my Java time).

Still, I gotta admit that it makes you aware of a lot of things about code organization whether you adopt it or not, which is at least workable as an introduction to code organization. So my recommendation when reading it would be not to accept the content all too religiously (not that you should on anything anyway).

On the subject of recommendations, this clean-code course is fantastic: Clean Code Course: Writing for Humans | Pluralsight

It changed the way I think about, for example, variable naming and code organization.

My guess was that listId is an arbitrary number, and you would need to keep it around.

I do keep them around inside Items.