I have to agree with parent comment. Leet code interviews, while sometimes obnoxious, are still good exercises. I have learned a lot of nuanced takes from a leet code interview with an interesting question.
Right now, I'm working on a data parser for a backend API that fetches a JSON response, using the built-in NSURLSession stuff, turns it into a Swift Dictionary, then I sort through that Dictionary, and emit a bunch of Swift struct instances for use by the API consumer.
The reason for this, is because the API that I wrote about seven years ago, is giving us performance problems. I wrote about that in this comment[0].
The NSURL stuff has all the sockets and whatnot, as well as all the transport stuff. I've written that stuff before, but I guarantee that the deep geeks that wrote the system have done a far better job of optimizing that stuff, than I ever will.
The JSON parser (built into the OS, but I may think about maybe licensing another one, if this doesn't do what I want) has all the recursive-descent, tree-crawling stuff in it, so I don't need to worry about that. Since this is a multi-threaded system, almost every school algorithm is worthless, but I guarantee that the deep geeks that wrote the system have done a far better job of optimizing that stuff, than I ever will.
I want to get the hell out of this API, as soon as possible, and return to writing the UI stuff that will make my app sing.
The API is being developed as a standalone SPM package that will work on all the Apple systems (iOS, iPadOS, MacOS, WatchOS, and TVOS). The one that it's replacing only worked on iOS. No excuse. I know better, now. I'll also be structuring this to be a lot "swiftier," and more "reactive" than the original API.
The app is a native Swift UIKit app. It's a big mofo. At its peak, it was over 40 screens, but I'm trying to get it down to half that. I've been working on it for a couple of years. It's had a couple of pretty massive pivots, in that time.
UIKit is a big framework. It takes years to learn. I'm looking forward to SwiftUI, but SwiftUI is not at the point, where I'm comfortable committing to a project of this scope.
I've been working with UIKit since 2012. I barely understand it, and they keep adding new stuff, as fast as I can learn it.
Swift is an excellent language. Like every language, you can get the basics down in a few weeks, but it takes years to get the advanced stuff down.
I've been working with Swift since 2014 (the day it was announced). I speak it without an accent.
The project I'm working on has been a wonderful masterclass in Apple iOS development. I also wrote a fairly massive PHP backend, but that was years ago, and it is, I guarantee, not as cool as a really good PHPista could do. That said, it works great, is maintainable, secure as hell, and fairly well-structured for scaling and extension.
The app is gonna be great. Its approaching ship (still a ways off, but we can see the harbor lights, from here). I've been releasing it on TestFlight since it was a month old. By now, I've probably made over 800 TestFlight releases to the team. That's how come we can be so confident in the UI and the Quality. It gets banged on a lot.
But maybe I'm doing it all wrong, and I should stop working on this to practice leetcode.
It’s just that when interviewing, it can few easier to evaluate some algorithm puzzle than to figure out what it means and whether it’s true that “the app is gonna be great.”
I used to hire pretty senior-level engineers. They would be writing C++ image processing pipeline code, to some insanely exacting standards.
My technique was usually to get them relaxed and comfortable, then start asking them for stories about the projects they've worked on. It was always a joy, when I could get them to start chattering, like the post above. I would look at the enthusiasm, and the passion, as much as the technical detail. I'd love hearing them talk about discovering problems, and how they addressed them.
I love this, and I’m stealing it. it’s a perfect description of competency in a language, imo.
I absolutely understand the emphasis on shipping, and i actually have recently come to lament some of my unshipped projects lately (I’m in a phase of finishing instead of starting projects myself, and sometimes have felt like I haven’t gotten to ship anything in my software career, but that’s another story for another day) but part of the core skills I attribute to allowing me to finish are the same ones leet code interviews helped me polish. how one works on a low-level data structure is one of the core aspects of software engineering i examine in a new hire.
What I think I’m trying to say is, I don’t mean to stop working on shipping a project to focus on leet code toy problems, but rather that a lot of leet code interview problems have given me better insights on how to focus and solve problems im trying to ship. I have found great value in going back and rehashing leet code interview problems and turning them into tiny libraries after i was given them. So much so that I’ve turned it into an exercise. I’ll have to write a full post about it sometime, but writing tiny libraries has been one of the best things I’ve done for my technical skills.
I'd read that.
> but writing tiny libraries has been one of the best things I’ve done for my technical skills.
I do that all the time. When I get to a bunch of code that I think has reuse potential (like, say, a backend connection SDK), I break it into a standalone GitHub repo, set it up as an SPM package, and give it The Full Monty for testing and documentation. The testing code usually dwarfs the implementation code, and the documentation is...well, you can see for yourself. Here's a few of the packages that I've written: https://riftvalleysoftware.com/work/open-source-projects/
I usually take a few days off the main project, write, test, document, and release the subproject, then re-absorb it into the main project.
There's a lot of similarity between that, and UI work.
I trained as an artist, way back in the Paleozoic Era, and that gives me "airs" about things like graphic design, and data presentation. I've spent a good part of my career, unlearning that crap. I'm usually best off, leaving the defaults in place, if possible. I write about that here[0].
I think that UI needs to be treated as seriously as possible. It should not be an "also" thing. I think it needs to be the starting place for the work, and I tend to develop UI pretty quickly, in my work.
I feel like SwiftUI still needs a lot of fine-grit sandpaper. I have every confidence that it will get there, but I don't feel confident in committing any project at scale to it.
[0] https://littlegreenviper.com/miscellany/the-road-most-travel...
Junior here and not as experienced as you are but I resonate with a lot of what you have written so far. I'm more of let my work and projects speak for itself. I also hate leetcode or code challenge kinda interviews. So far I haven't have to take any to get a job and I plan on never taking or doing any. If I see that an interview involves such I will reject it. I can accept a decent take home assignment or technical questions in areas that I will likely encounter on the job.
[1] https://blog.pragmaticengineer.com/software-engineering-sala...
Obligatory ask, bullet list of "the advanced stuff", please?
There’s an excellent book[1], called “Advanced Swift,” by Olle Begemann, and Chris Eidhoff, that gives a far better breakdown of the more intricate parts of Swift than a simple bullet list.
Like many languages, Swift is a deep rabbithole. Heck, you can get lost, just in the way it handles strings[2].
[0] https://littlegreenviper.com/series/swiftwater/
You're not "wrong" per se. If you want a pure Swift job it would be very reasonable if the hiring company tested you on your very broad and deep Swift knowledge. However, if you ever wanted to do anything else job wise you'd be screwed. Leetcode gives you a chance to become a Java/PHP/C++ dev somewhere. That's the only plus for me. I'm mostly a Ruby/Rails dev experience wise and I get a real chance at different stacks because their hiring process is Leetcode (or something of the sort) and general design questions. So sure I'll never know as much about Swift as you but I do think that a hard working engineer who takes his craft seriously can pick it up and become productive in a couple of months. Not an expert, productive. I can join your company/team and then someone like you can make sure my code doesn't suck. For many companies that's good enough. Others can't or don't want to mentor anyone for more than a week or two so they only accept someone who fills all the requirements of their stack. Mostly startups, and in general not my cup of tea.