5 ms·

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 lee

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.

ChrisMarshallNY 4y ago
OK, fair 'nuff. 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. [0] https://news.ycombinator.com/item?id=32921823 https://news.ycombinator.com/item?id=32921823
- throwyuno 4y ago
  If you’re looking to get hired as an individual contributor somewhere else, maybe you should. But judging from this and other posts of yours, you’re not, so you’re probably not doing it wrong. 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.”
  - ChrisMarshallNY 4y ago
    Well, that screed I wrote, is a fairly typical "geeky conversation" that can be invaluable, in an interview. 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.
- shakezula 4y ago
  > I speak it without an accent 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.

ChrisMarshallNY 4y ago

OK, fair 'nuff. 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. [0] https://news.ycombinator.com/item?id=32921823 https://news.ycombinator.com/item?id=32921823

throwyuno 4y ago
If you’re looking to get hired as an individual contributor somewhere else, maybe you should. But judging from this and other posts of yours, you’re not, so you’re probably not doing it wrong. 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.”
- ChrisMarshallNY 4y ago
  Well, that screed I wrote, is a fairly typical "geeky conversation" that can be invaluable, in an interview. 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.
shakezula 4y ago
> I speak it without an accent 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.