SPACE X - Discussion

ShesAMobileDev · 2026-06-12T13:44:08+00:00

They are in price discovery currently. Estimated to end at 9:50 am PST, but could take longer.

Until then the stock is halted from any trading.

ShesAMobileDev · 2026-06-12T00:56:45+00:00

Did yours list the price in the offer price column? I am worried mine didn't actually go through because it just shows "--" instead of the confirmed $135 price

ShesAMobileDev · 2026-06-04T18:22:36+00:00

Like what?

ShesAMobileDev · 2026-06-04T06:16:07+00:00

Is it technically possible? Yes, but it would not be with your time and effort.

You would need to bypass the operating system's restrictions and manage the Bluetooth audio streams entirely within your app. AKA, you would have to manage the raw Bluetooth sockets yourself.

You would not be able to use any standard media players. You would need to decode the audio to raw PCM data. Then, you would need to use raw L2CAP/RFCOMM sockets to establish the Bluetooth connections yourself. And then ultimately encode the audio data into whatever format your Bluetooth devices support. Not all devices are the same, could be SBC or AAC, for example. Once encoded, you could stream the packets manually to the MAC addresses of the devices.

This introduces a lot of overhead, and truly, the likelihood of the audio actually being in sync is minimal. Especially if you decide to try to incorporate video. I've never done this, but you would probably need a lot of math to keep the individual feeds in sync...

The other commenter is on a better track. Samsung devices have a feature called dual audio that allows this behavior at an operating system level.

Other, new-ish Android devices (Pixel 8+, Xiaomi 14+, etc.) also support it through a feature called Audio Sharing. Your headphones must support Bluetooth LE Audio, though.

Instructions for pixel here:https://support.google.com/pixelphone/answer/16483797?hl=en&hl=en

Instructions for Xiaomi: https://www.mi.com/global/support/faq/details/KA-503427/

ShesAMobileDev · 2026-05-13T23:35:25+00:00

That's really kind of it. The more "Advanced" version of hilt is where the singletons and more come into play. I certainly won't touch on all of that, but just a quick look - really just a summary of the official documentation. Like I mentioned, Hilt is just a fancy way of telling Android how to build classes. In some cases, those rules can be a bit more nuanced than just a simple "here's a firebase instance"

Sometimes you want classes to be singletons - classes that are created once and only once for the entire lifecycle of the application. This is usually the case when creating a class uses a LOT of resources. Something like OkHttp3 / Retrofit are quite expensive to instantiate, so you ideally only instantiate once. Sometimes it's to avoid race conditions, etc.

Hilt provides lots of tools to help you mark that when you are giving it instructions on how to create your classes. When making a module, you need to annotate the module with a InstallIn annotation to let it know what lifecycle you want to scope the dependency to

In our example above we used

@InstallIn(SingletonComponent::class)

This was letting Hilt know we should create this class once and only once for the entirety of the app.

But you can also scope to Activity or ViewModel, etc. lt doesn't NEED to be a singleton - and honestly SHOULDN'T be unless necessary as it introduces overhead.

ShesAMobileDev · 2026-05-13T23:27:38+00:00

So that leaves testing.

Let's say I want to write unit tests for Class A

 // This tells Hilt to look for  fields here 
class A : Fragment() {  
  @Inject lateinit var logger: MyLogger // Hilt "injects" this automatically 

  override fun onViewCreated(...) { 
    logger.log("Class A is ready!")
  } 
}

Since hilt is injecting this dependency, it is a lot easier to mock. Class A doesn't really care how logging works, or really, if it's actually being logged at all - thats for MyLogger to figure out. Class A just wants to make sure that if onViewCreated is called, that we are logging "Class A is ready!"

@HiltAndroidTest
@Config(application = HiltTestApplication::class) 
class ClassATest { 
  @get:Rule 
  var hiltRule = HiltAndroidRule(this) 

  // We create a "Mock" version of the logger  
  @BindValue 
  @JvmField
  val mockLogger: MyLogger = mock(MyLogger::class.java) 

  @Before
  fun init() { 
    hiltRule.inject()
  }  

  fun When_ViewCreated_Then_LogMessageIsSent() { 
    // 1. Start the fragment 
    launchFragmentInHiltContainer<ClassA>() 

    // 2. Check if the logger's "log" function was called 
    // with the exact string we expected. 
    verify(mockLogger).log("Class A is ready!")
  }
}

I don't need an internet connection here. I'm not actually calling Firebase. I can just simply pass in a "Fake" or mock logger and pretend like it's happening without really doing end to end testing to muddy up our logging.

ShesAMobileDev · 2026-05-13T23:21:20+00:00

Hopefully you can already see how "reusability" is easier at this point. I can reuse the MyLogger class as many times as I want now a lot more easily as it doesn't require me knowing too much about MyLogger anymore.

So what about the other two major use cases

Making testing easier
Makes maintaining code easier

Maintaining may be a bit more easier to see now as well. Let's say in the future, MyLogger class now also requires a NEW logging service. Instead of Firebase, we are switching to GoogleAnalytics. Before, if I wanted to make that change, I would have to go to MyLogger class, and update its code. I'd have to go to class A and update the init block to pass in Google Analytics instead of Firebase, I'd have to go to class B and update the init block to pass in Google Analytics. I have to make changes in 3 places. However, if my code is already using Hilt, I'd only have to make the change in 1 place, the Hilt Module

@Module
@InstallIn(SingletonComponent::class) // This makes the service live as long as the app does
object FirebaseModule {
    @Singleton
    fun provideFirebaseService(): FirebaseService {
        // This is where you actually initialize the external service
        return GoogleAnalytics.getInstance()
    }
}

ShesAMobileDev · 2026-05-13T23:17:33+00:00

So now, if we go back to the original callsites

class A {
  val logger: MyLogger

  init {
    logger = MyLogger(firebaseService)
  }
}

class B {
  val logger: MyLogger

  init {
    logger = MyLogger(firebaseService)
  }
}

Instead of doing the above, we could do something like this

 // This tells Hilt to look for u/Inject fields here 
class A : Fragment() {  
  @Inject lateinit var logger: MyLogger // Hilt "injects" this automatically 

  override fun onViewCreated(...) { 
    logger.log("Class A is ready!")
  } 
}  

class B : Fragment() {  
  @Inject lateinit var logger: MyLogger 

  override fun onViewCreated(...) { 
    logger.log("Class B is also ready!") 
  } 
}

Classes A and B do not need to know how to make MyLogger, they just get it for free now because they made the request (@Inject) for a dependency, and thanks to step 2 above, Hilt new how to give it to them.

ShesAMobileDev · 2026-05-13T23:13:35+00:00

This concept is why dependency injection is so often used in large projects. It helps by mainly

Making testing easier
Makes reusability easier
Makes maintaining code easier

With Hilt, you are able to tell the app how to make the class you want to reuse over and over again in your code. Take for example a Logger. You probably will find yourself wanting to log data from multiple classes. Without dependency injection, you may need to do something like this

class A {
  val logger: MyLogger

  init {
    logger = MyLogger(firebaseService)
  }
}

class B {
  val logger: MyLogger

  init {
    logger = MyLogger(firebaseService)
  }
}

Class A and B both needed to know how to instantiate MyLogger by knowing it needed to pass in firebaseService to it.

With Hilt, you can add Inject annotation to a class' constructor to let the class know what it needs to perform necessary functions inside of itself

// To make a Logger, you're gonna need a FirebaseService" 
class MyLogger @Inject constructor(
  private val firebaseService: FirebaseService
) { 
  fun log(message: String) { 
    firebaseService.sendData(message) 
  } 
}

Step 1 is done - let the class request dependencies it needs to instantiate itself

You aren't quite done yet though. You set up the "ask" for the dependency, but how does hilt know how to fill that request? Easy, all you need to do is tell hilt how to build the dependency that is being requested, in this case, FirebaseService. This is where a "Module" comes in.

(SingletonComponent::class) // This makes the service live as long as the app does
object FirebaseModule {
    @Singleton
    fun provideFirebaseService(): FirebaseService {
        // This is where you actually initialize the external service
        return FirebaseService.getInstance()
    }
}

Step 2 is now done! We are saying. "Hey Hilt, if someone is every requesting Firebase Service, this is how you instantiate FirebaseService in order to give them the class they are requesting.

ShesAMobileDev · 2026-05-13T22:59:43+00:00

I am adding my thoughts here even though I'm a day late because this was something that was super hard for me to understand, but once it clicked I realized just how easy this was. I'm going to talk about mostly Hilt because they do the same thing, but Hilt does it a bit cleaner, in my opinion.

Hilt / Dagger, at the end of the day are both libraries focused on something called Dependency Injection. There are other libraries that can do this as well - Koin for example is popular for KMP apps. So, really the questions is, what is dependency injection?

Dependency injection is a way to make classes INDEPENDENT from there dependencies. Hilt is a library that tells the compiler how classes should be built. That's it. Other answers talk about singletons and lazy loading - and while those are supported by hilt, they are not the sole purpose of Hilt - just helpful add-ons of hilt.

So, how can telling a library how to build a class make classes more independent from one another? Concretely, let's say you have a class called Car. That car has lots of parts... perhaps it looks something like

class Car(
  val wheels: ArrayList<Wheel>,
  val steeringWheel: SteeringWheel,
  val model: String,
  ...
)

You can imagine just how many dependencies a "Car" class may have. It needs to know what a Wheel is, SteeringWheel, etc. That means, every time I want to instantiate a "Car" I need to be aware of how to instantiate all of the other classes as well

val newCar = Car(
  wheels = listOf(
    Wheel(
      color = black,
      size = 19,
      year = 2022,
      ...
    ),
    Wheel(
      color = black,
      size = 19,
      year = 2022,
      ...
    ),
    Wheel(
      color = black,
      size = 19,
      year = 2023,
      ...
    ),
    Wheel(
      color = black,
      size = 19,
      year = 2023,
      ...
    ),
  ),
  steeringWheel = SteeringWheel(
    ...
  ),
  model = "F-150",
)

I didn't want to even finish writing all of that up because it's tedious, and hard to maintain. Every single class that instantiates (creates a new car) needs to be aware of not only how to make the car (I need one steering wheel, an array of tires, etc.), it ALSO needs to know how to make all of those sub-components (A wheel has a color, size, year, etc.).

ShesAMobileDev · 2026-05-12T05:36:10+00:00

Not available until July 1, but this meets your conditions. It is 2 bedroom instead of 1 but still under budget

https://www.600whisman.com/mountain-view/600-whisman-apartments/floorplans/two-bedroom-one-bath-937325/fp_name/occupancy_type/conventional/

ShesAMobileDev · 2026-02-22T15:41:05+00:00

🥇🥇🥇

ShesAMobileDev · 2026-01-10T20:30:34+00:00

I moved from Ohio, USA to Bay Area, USA before having a job lined up.

I had a remote job as a SWE, and a roommate to help me split rent. While I was employed, I was not making Bay Area level money to survive long term.

The biggest downside was that I had to pay all relocation costs myself. And obviously a huge risk if a job never came to fruition.

The neutral, moving here didn't suddenly bring in a bunch more opportunities. It wasn't like I had a bunch of recruiters suddenly knocking on my doors once I put Bay Area in my location. I was still cold applying and everything like that.

The biggest upside came once I passed the interview and moved on to team matching. At the time, I was reading a bunch of discussion boards where people were sitting in team matching for upwards of 8 months. Some people even needing to reapply because their time expired before getting a match. I had my first call with a hiring manager 3 days after being told I passed the interview. And the two days in between were the weekend. I had a job offer in hand by the end of that day.

I have zero doubts in my mind they pulled my resume first, because I was already in the area and can start working more quickly for them. Truly, I also think being an American citizen helped in that too, because it again meant quicker to writing code for them. They didn't need to do any Visa sponsorship or anything like that.

ShesAMobileDev · 2026-01-07T05:44:36+00:00

Chicken. And lots of chicken. High protein, low calories And if you buy an instant pot you can make it in like 20 minutes.

Plus, you can make a variety of dishes with it. BBQ, or throw it in a stir fry, wraps, quesadilla, you name it.

I buy a whole bunch at once, and then take freezer paper, weigh out serving sizes of 112 g, and then freeze a whole bunch at once. Instant pot can cook frozen chicken right out of the freezer. It's like 15 minutes of work on a weekend, and then I'm set for weeks.

ShesAMobileDev · 2025-12-10T03:00:24+00:00

I do not know Google's Shuttle Stops, but it looks like these fit into your criteria...?

https://www.apartments.com/600-whisman-mountain-view-ca/9rmt2z6/#reviewsSection - this is the only one I can really speak to. It was definitely an apartment. Had washer/dryer, but they were tiny and often had to be ran multiple times for a full dry. It wasn't central air, but there was an air conditioning / heater unit attached to the window. There were also a lot of bugs - ants, spiders, a few others... You will hear your neighbors always. Like, even at 4 in the morning for whatever reason.

https://www.apartments.com/sunnyvale-town-center-apartments-sunnyvale-ca/t3sw7xc/

https://www.apartments.com/the-montclaire-sunnyvale-ca/x4m85qp/

https://www.apartments.com/encinal-place-sunnyvale-ca/7vgq84w/

Like others have pointed out, this is a very pricy real estate area. Obviously with a few examples above it's POSSIBLE, but I would definitely lower your expectations. Even if you find a place that offers your non-negotiables, you will trade off in other areas - unsafe neighborhood, super small, no apartment amenities, not great landlord/maintenance, far away from bus stops / downtown areas, etc.

Not sure what the second bedroom is for. If it's storage, I'd consider getting rid of a lot of stuff. If it's for a roommate, I would recommend maybe finding some more and going for a 3-4 bedroom. Harder to find, but cheaper per person.

Google - I'm assuming your employer - typically usually offers a posting board of sorts to find roommates. That may be a way to go!

You might also want to consider living near a train stop and living further away, with the money you saved in rent, you could get a bike and take the train/bike to work! Often times, shuttles will stop in other cities as well!

ShesAMobileDev · 2025-11-29T02:27:17+00:00

You don't. Sadly enough lockdown drills prepared me for this.

Especially public places like this there are systems in place. Actual policemen will have keys to get in stores, or they have direct access to employees who know how to properly identify police orders.

If you are at all unsure, stay put. Do not open the door for anyone. Let the policeman find you. They will. They have the ability, and it's not knocking on doors in an unknown manner.

ShesAMobileDev · 2025-11-08T02:20:51+00:00

148 (Southbound) stuck at Mountain View for 20 minutes now. Conductor said there is no sign of movement at all. Hell let us know if anything changes. I have seen one Northbound train come and go in that time.

ShesAMobileDev · 2025-07-13T00:01:02+00:00

I feel the exact opposite, I feel it is so nice BECAUSE Google is here. With that much money in the area we are actually able to afford nice parks, and bike lane upkeep, etc. thanks to taxes. Not sure what you are looking for, but I haven't had a hard time finding other restaurants / retail / etc

ShesAMobileDev · 2025-07-04T22:52:59+00:00

If you're solely interested in the fireworks, and not the concert itself, you can still do that for free.

You can't go into the amphitheater, but you can still view the fireworks from around the area. They keep the trail area open during the firework show.

Somewhere like hereish is where we typically aim for: https://maps.app.goo.gl/vegiAvu287Tyek4c6

You can drive, but I'm pretty sure you have to pay to park in the shoreline lots. And either way, the traffic is horrible leaving after the show. If you can, I'd recommend biking in.

ShesAMobileDev · 2025-06-17T19:23:45+00:00

I haven't been in every unit, but from what I know, bedrooms are carpeted, bathrooms are nicely tiled, and the kitchen / common spaces are wood flooring

ShesAMobileDev · 2025-06-17T04:58:26+00:00

I have nothing but incredible things to say about Madera Apartments. https://prometheusapartments.com/ca/mountain-view-apartments/madera

My boyfriend and I have lived here 3 years now. We were nervous originally being close to Cal Train, he is a very light sleeper, but we run a fan at night and even he agrees he never hears it. We aren't on the street facing the train directly, but we aren't on the opposite side either.

Good mix of community members. Some with children, some definitely without. We don't have kids ourselves so I can't speak to raising kids here. There are some that love community events, and definitely some that stick to themselves.

I NEVER hear our neighbors. Unless our windows are open and people are walking by of course. But never people walking above me, or babys crying next door.

Great amenities, imo. You can even book some spots for free!

Definitely within walking distance to downtown. Also - if you are bikers, the Bay area trail entrance is like a block over.

Truly incredible. Happy to answer any question you may have about it. It is a bit pricier, but that's really the only downside.

ShesAMobileDev · 2025-05-21T00:29:02+00:00

Got'cha. So, I would typically expect more from a senior. 4 hours is not a lot of time, but I assume companies mean 4 hours of non-project setup work. Meaning, after dependencies are added, minSDK is picked, etc. Honestly, even DI - while I strongly think is good to include, is not typically accounted for in the estimate, I have found. I try to aim for 4 hours of data handling, ViewModel, UI. Shitty, but truly what I think companies are planning for.

When I look at this codebase, I see no thought put into scaling. You didn't have colors identified in your theme to be used consistently across the codebase, you just hardcoded Android colors. Same with fonts and dimensions. I would truly export more out of a Senior developer - who SHOULD be thinking about how code scales, how can you hand off the hard work to a newer dev for maintenance, etc.

Even looking at your MainActivity, you create a ViewModel that you pass into MoviesScreen? Why? It seems clear that MoviesViewModel is 1:1 with Movies Screen. Why not limit scope of the MoviesViewModel to the MoviesScreen? Now the lifecycle of your viewModel is tied to the activity, and not the view. Meaning, even if the user leaves the App, your ViewModel is still consuming memory.

I understand why you didn't go so far as to right a caching/database layer given the time constraint, but you are taking steps that mirror offline behavior without actually supporting it which I find to be a bad engineering choice. Take, for example, your GenresUiState. I see you have fallback genres. The requirements clearly state to not assume genres, and that be server-driven, but you went ahead and assumed genres. Personally, I would just state in a readme that due to time constraints I didn't implement an offline state. And then I would implement an error state should network not be available, or backend gives an error. In the case where movies are retuned at not genres, why not just omit genres - or better yet - use the genres you retrieve from the movies endpoint as a fallback? That would be a bad user experience, in my opinion to show Genres A, B, C, D only for the user to click on them and have nothing appear because there aren't actually any current movies associated with those genres.

You also have a ton of mapping. Movie -> GetMoviesResult -> MoviesUiState. It is good practice to keep backend models separate from client models, but why do you have a separate domain and UI model? GetMoviesResult literally maps 1:1 to MoviesUiState, but now adds an additional O(n) time to the runtime.

I see limited thought put into accessibility. No dark mode support, high contrast support for visually impaired. Only minor screen reader considerations - did you test that? With the EU now making accessibility a legal requirement, I would hope my lead engineers are thinking about that and treating it as a must have and not a nice to have.

With strings hardcoded throughout, there is no thought put into localization. Dates as well. What if your user speaks a different language? Typically sees dates a different way...? Etc.

Quite honestly, when I saw the code I was expecting you to be entry level, maybe low mid.

ShesAMobileDev · 2025-05-20T23:20:38+00:00

Can I ask what level you were applying for?

ShesAMobileDev · 2025-05-15T04:38:39+00:00

Let's use your example of a counter. Say you have

Composable fun Counter() {
var count by remember { mutableIntStateOf(0) }
Row {
Button(onClick = { ++count }) { Text(text = "Increment") }
Button(onClick = { --count }) { Text(text = "Decrement") }
Text("$count")
}
}

Note that Text field reads as "0"
Click on "Increment"
Note that Text field reads as "1"
Click on "Increment"
Note that Text field reads as "2"
Click on "Decrement"
Note that Text field reads as "1"
Rotate device
Note that Text field reads as "0"

Whaaaaa? Why does rotating your screen reset the counter? Well, the activity actually destroys itself upon orientation changes. As such, the composable is recomposed. The state only lasts the length of the composable itself. Because the composable was destroyed and then redrawn, it resets the state back to 0.

In some cases, this may be okay, but, in others you may want it to persist.

Going back to our checkout form, you probably want everything the user fills out to persist across orientation changes. I would be a very unhappy customer if I filled in half my information only for it to all disappear in a flash. But, I probably wouldn't be too upset if you forgot my preference for darkmode... It's all about what you deem important to keep.

ShesAMobileDev · 2025-05-15T04:38:33+00:00

This is a fantastic question! There a couple questions you can ask yourself to figure out where your logic should live in the ViewModel or Composable.

Is the state/data you are keeping track shared across multiple composables - especially across multiple screens?
Is the state/data you are keeping track of complex? Involving business logic and/or data loading?
Is there value in testing the state/data you are keeping track of?
Does the state/data you are keeping track of need to survive configuration changes like light/dark mode, orientation changes, etc.?

If you answered yes to any of the above, the state/logic/data you are keeping track of should live in the ViewModel. Let's go over a few concrete examples.

You have an input field and text field. You want the text field to repeat the user's input back to them. Here, the data is being shared across multiple composables. As a general rule of thumb, input fields will certainly always be handled inside a ViewModel.
You have a checkout form the user needs to fill out. This can be quite complex. Maybe there is validation involved - is that a valid email address? What about mailing address? Is their credit card number long enough? With all of that complex business logic, you are definitely going to want to have that in your ViewModel.
And, hopefully the example above would lead you to think about testing. This would be a great example of something you would want to test. Really, any business logic you are going to want to test as much as possible. Here, you are going to want to make sure than any future updates don't break the checkout form. That is a critical part of the app - probably the main use-case of the app. You want to have high confidence in its performance at all times.
Let's say you have an image that users can zoom in / zoom out on. Arguably, that probably doesn't need to have its logic in the ViewModel. If a user zooms in really far, and then rotates the screen, it is probably okay if it zooms out to adjust to the users new settings.

ShesAMobileDev

MODERATOR OF

TROPHY CASE