I just already had a graphql backend, which uses the gql schema to codegen the networking layer.
Probably not much different from an open-api schema + codegen, I just had it set up so it was an easy choice for me shrug
325 karma · joined December 27, 2015
https://envelopebudgeting.com
Former iOS Engineer @ Robinhood, Twitter, Tesla
Probably not much different from an open-api schema + codegen, I just had it set up so it was an easy choice for me shrug
You're totally right, you're at the mercy of these KMM libraries and their knowledge of platform specific optimizations.
KMM is an alternative to cross platform mobile libraries like Flutter, React Native, etc. The idea is that we could write all of our mobile app's business logic, networking layer, and caching layer in Kotlin, and KMM will codgen the matching iOS code. "We only need to write it once!" is the selling point. Then we get a blank canvas to build our UI using 100% native SwiftUI & Jetpack.
In reality, the codegened iOS code gets you 90% of the way there, the but extra 10% is extremely frustrating to work with. Enums (Sealed Classes in Kotlin) get mangled in translation and you lose exhaustive switch statements. Basic data types like Bool and Int get wrapped so you can only access them using additional .boolValue or Int64(..) constructors. Entire companies are being built around solving the pain point of this last 10%: https://touchlab.co
In my opinion, the fatal mistake the KMM team made was designing it to support Objective-C, instead of just Swift. So you're using a Kotlin layer -> mangled through Objective-C -> accessed from Swift. It's a confusing decision, as the only iOS teams still actively using Objective-C are legacy apps (like the Twitter app), which seems like the opposite target market for new mobile tech like KMM. Kotlin and Swift are both modern languages, and my gut says the interop between the two would be much better without Objective-C in the middle.
Further discussion from Droidcon if you're interested: https://www.droidcon.com/2022/08/01/sdk-design-and-publishin...
> As you progress beyond "POC" to integrating and shipping real production code, the design of the "SDK surface" becomes more complicated and nuanced (or, possibly, problematic)... An Android consumer can see all the richness of the Kotlin language, but the iOS side gets filtered through Objctive-C into Swift. Much can get lost along the way.
P.S. I'm replacing KMM with the Apollo Kotlin and Apollo iOS SDKs, which codegen your app's entire networking/caching layers. So it solves the same pain point (aside from business logic), but in a much cleaner way!
Love Factually - Duana Welch, PhD
It talks a lot about playing hard to get. The book basically frames it in the same “more in demand” that this linked article talks about.
And also adds something I’ve always remembered.
We see hard-to-get as attractive because we know, for others, they will be impossible-to-get once they’re our partner.
(I’m paraphrasing)
So hard to get only works as long as we perceive they’re hard to get for others also.
Anyways, that book was definitely a life changer for me so if you’re interested in this kind of stuff or trying to understand the confusing world of finding a partner I highly recommend it.
You open up your laptop and type in your name and hit enter. You get an error message though, saying that you need to install Adobe Flash Player first.
> burn my laptop
You decide not to bother with installing Flash Player and instead just burn your laptop. When you turn it on you get an error message again telling you that you need to install Flash Player. This time you choose to ignore it and proceed with burning your laptop
Sounds pretty accurate!
I’m sure Google or someone would pay a TON of money to have them all sent down to Mountain View for the day to do a huge round of interviewing. The same way they do for smaller-scale startup acqui-hires.
Employees are also not usually invited to the investor meetings where these types of negotiations would take place. They would probably need the founders to vouch for them to make this happen.
Morale went way up once we released the game because everyone was so sick of working on it and knew the game was terrible. It was a product of having a low budget and tight deadlines. Sounds like my experience lines up with most of this Reddit discussion.
I think it may be different if, for some reason, the team is convinced their game is amazing before shipping. But in my experience game developers usually know if their game sucks.
They have 30+ levels where you ssh into a server and attempt to find some type of vulnerability. They start out very easy and get tough quick. It’s very eye opening to see the types of exploits that exist.
They also have a set of challenges aimed at serverside web security. http://overthewire.org/wargames/natas/ I went through the web challenges last year and they helped a ton in my web dev roles.
My question for HN is do you feel that the content you are working on makes a difference in your career satisfaction? Or do you just need to know that _someone_ out there is being benefited?
Is it just as fulfilling to work on a video game that flops (but maybe a few people still enjoy it) as it is to work on Fortnite where your code changes are used by millions?
Is it more satisfying to work on consumer facing iPhone apps like Apple Fitness where you are enabling millions of people to be healthier compared to working on a high frequency trading algorithm that makes a few people lots of money?
https://www.apple.com/shop/product/HLZ42/belkin-boost-up-spe...
So, although I've never used one myself, clearly these chargers are feasible and the overheating challenges the article lists are solvable. I know the Belkin one looks more simple (1 device instead of 3), but why doesn't Apple enter the market with a similar product? The article doesn't really answer the question for me of why Belkin is creating one but Apple is not.
Edit: Not sure why I'm getting downvoted. This is a genuine question and it's getting a lot of informative responses.
Source: I worked on a fall detection app for the Apple Watch last year.
Source: I worked on a fall detection app for the Apple Watch last year.
My mind jumped to pronouncing it as Name-Genie, thinking it was a reference to a genie in a bottle that would spit out a startup name for you.
Yeah I've been through this many rejections total, and some of them have been pretty tough emotionally, but it only takes 25-50 before landing another really cool job I've been excited about. 200 rejections is pretty soul wrenching, but getting the other big companies on the resume makes it more than worth it.
A lot of companies will list the same roles across different teams. Applying to (or interviewing with) all the different teams helps your chances. I'm at Tesla right now and I applied for 15 different roles over the span of 3 years before they gave me an offer.
First off, you are not a bad engineer for failing a technical interview. Over the past 3 years, I've applied for hundreds of roles across dozens of companies. I've been through dozens of interviews and I've got offers from (or worked at) Uber, Twitter, Microsoft, Tesla, etc. The side of the story I don't focus on is that I've had over 200+ rejections. Some after first rounds, some just after they look at my resume. Rejection is part of the game but you just need to push through it. Here's my advice.
- As other comments have said, it's definitely a numbers game. Some days you just don't mesh with your interviewer, others you know the answer to their coding question before they've even finished asking it. Just apply over and over if you want the best odds. You can't get too emotionally attached to any single interview opportunity. I've had to apply for ~50 roles for each offer I get. That's just the way it works.
- Practice a ton. It sounds like you are more worried about coding under pressure and thinking through the answer while you are in the middle of trying to explain your thought process to the person interviewing you. I recommend pramp.com You interview someone for 30 minutes over the webcam and then they interview you for 30 minutes. It's super convenient and gets you very comfortable thinking through problems on spot with someone else watching you. I normally do ~10 pramp.com interviews while I'm preparing for an upcoming interview. In person interviews with friends is good too but less convenient than just signing up online for a time slot.
Just remember that bad interviews don't make you a bad engineer. At the end of the day, no one will remember dozens of rejections, but they will remember the job you eventually land. Keep interviewing till you get an offer that you're excited about. Good luck!
I read the HN article last week about charging these (where they pay you to collect scooters and you charge them over night), so I recently signed up to become a charger for Bird scooters. When I first opened up the app to search for ones to charge it showed dozens of these things[1] that had gone missing in the Tenderloin. I went searching for some yesterday and after being unable to locate about 5 in a row, I saw two homeless guys dissecting one. The electronics were hanging out and they had screw drivers in hand.
Of course I didn't confront them, and I went home empty handed.
[1] Yesterday I counted ~33 that had gone missing in the Tenderloin within the past two weeks. To put this in perspective, there are only about 75 - 100 of them in the entirety of SF right now if you open up the Bird app.
This one looks like R2-D2 with giant Coca-Cola sticker slapped across the front. http://www.theoldrobots.com/cobol.html
I don't think you need to worry about this. A simple search for "binary search" shows 20 different questions. If you can't do the 1st bst problem and you look at the solution then that's okay! You have 19 more to try it on. Even if you do all 20 then come back in a month and try them again. There's no way you're going to be able to memorize that many variants. And that's just 2% of their entire set of questions.
To really answer your question, I prefer to just hit the "random problem" button and see if I can solve it in 15 minutes with an optimal solution. If I struggle, then I just go read the solution (to understand how I should have solved it) and try a couple related problems to make sure I'm not just memorizing it and I actually understand the methodology behind solving it.
Good luck!
https://www.pramp.com - 1 hr online interviews where you interview someone and they interview you back. Go through ~20 of these to get really comfortable solving problems while talking through them. They also give you the optimal solution at the end. This will prepare you really well for the initial technical phone screenings.
https://leetcode.com/ - collection of 700+ interview coding challenges. You should be able to solve any random medium difficulty question within 15 minutes if you want a shot at the companies you listed. Keep doing a couple of these per day till you get really good.
"Elements of Programming Interviews" or "Cracking the Coding Interview" - Read through either one of these to get an overview of the interview process and what companies expect.
Polish your resume - This is only important to get the interview. Once you are interviewing onsite the resume doesn't matter much. Here is mine to give you an example. http://joshcockrell.com/joshua_cockrell_resume.pdf Feel free to send me yours if you want some feedback.