Little bit of everything!

Avid Swiftie (come join us at [email protected] )

Gaming (Mass Effect, Witcher, and too much Satisfactory)

Sci-fi

I live for 90s TV sitcoms

  • 56 Posts
  • 2.47K Comments
Joined 2 years ago
cake
Cake day: June 2nd, 2023

help-circle











  • Scrubbles@poptalk.scrubbles.techtoAsk Lemmy@lemmy.worldDid I get a job?
    link
    fedilink
    English
    arrow-up
    17
    arrow-down
    3
    ·
    edit-2
    6 days ago

    This will be the main interview. Welcome to software development interviews, where you can have 6 interviews and a take home exam and they still aren’t sure if you’re worth hiring.

    This is what we call the “Loop”. I have done too many of these. I did one just yesterday actually! Probably… 15-20 under my belt now throughout my career.

    There will be 4 1-hour interviews you will go through. Usually there will be some combination of the following. This is how most of mine go (my mid-tier ones and now my senior ones). They may mix and match them, you may get 2 technicals instead of a system design, maybe they don’t do the last one, who knows, but this is to help you prep a bit.

    Technical - 1 hour with a sample problem. Chill companies will give you something like “Solve a wordsearch”. Maybe they have something premade like “Add some functionality to this”. Companies like Amazon will do a more intense leet-code style question. The number one advice I have to you is never stop talking. Be talking the entire time. Every thought you have, verbalize it. The interviewer is not a mind reader, they will be trying to figure out what you’re doing, and if you tell them they honestly will probably help you. Just describe everything you’re doing. “I’ll make a method here because I think it’ll be easier to reuse - well… maybe I won’t. Actually I’ll keep it and we can use it later, so yeah that’ll be what we use to do X functionality”. Even if you think you sound silly, it’ll really help your chances. Do this for the System Design below too. Worst thing a candidate can do is clam up and not talk in their interview, leaving the interviewer at the end trying to guess if they understood the problem or not.

    Culture Fit - Talk about projects you did, since you’re coming out of entry level, focus on results. Outcomes. A lot of people ramble in these. Prepare for this interview. Look at your history, find projects, and learn the STAR Method for behavioral. It honestly is a clean way to tell your own history.

    System Design - This will heavily change based on your level, and that’s okay. Usually it’s a question like “Design WhatsApp” or some vague thing like this. They won’t expect you to have a perfect answer. Instead, they’re looking for you to ask questions and how you think. I strongly recommend watching This video - again they lay out how to organize the interview. Most interviewees just start throwing stuff on a whiteboard - watch the video and learn how to lay out things in an ordered way. Even if you don’t know the answer, it shows how you think, which is much more valuable in the interview.

    VP/Executive Chat - This will be a fairly informal chat with someone higher up at the company. They are mostly going to lean on the others to decide if you should be hired - but they want to know if you’re “excited” to work there. Show an interest in the company. Ask questions about something you heard they were working on. Are they smaller? Are they pushing towards IPO or something else? Show an interest in the business side. Talk about how you want to uplevel your skills and you think X company is the right place.

    Bonus - The “Bar Raiser” - This is more of a “style” of interviewing that can happen in any of the mentioned ones above. I was caught off guard the first time I encountered one of these. The Bar Raiser is essentially they’re going to push you to see if you “raise the bar” for them, if you go above what a normal employee will do. You’ll notice this if you find they are asking a lot of questions, maybe even to the point of offending your or annoying you. This is essentially what they want, how do you do under pressure? How do you do when people are second guessing you? Don’t let it get to you, and don’t start bullshitting. Admit when you don’t know things. Stick to your guns on things you believe in, but admit when you don’t know things. Software engineers need to know when they don’t know something. When I was younger I insisted that a SQL database would be the best database for a system design. They asked why - and I didn’t have an answer. It’s just what I had used. What I should have said was “It’s what I’m most familiar with, but there are some others I would want to look at first to really make a decision”. Since I insisted that it was best, they asked how I would scale it? How would I make sure it wouldn’t go down. I quickly realized it wasn’t the best choice, and I worked myself into a corner.

    Important Notes

    • Ask for a break - you deserve a break between these. If you need to go to the bathroom, make sure there is time for it. You’re looking at 4 hours of interviews, most will offer between “Do you need anything” - don’t think it’s impolite. Just go to the bathroom if you need it.
    • Accept the drink - They’ll offer you coffee or water. Just accept it. Again, 4 hours of interviews. You’ll need some water. You’ll get dry mouth, just trust me.
    • Think about food - Most good ones will provide a lunch… but I’m seeing this less and less. Eat right before going in, nothing heavy or you’ll be sleepy, but have a good solid breakfast and eat before you go into the meeting. (Even if they provide lunch then you don’t look like a pig on their dime). Pack a snack with you if you can, after one loop I was shaking with hunger and went to the mcdonalds immediately after right next door because I was so hungry.
    • Get a good night’s sleep before hand. You’ll have to be on the whole time, it’s just going to be tiring, physically and mentally.

    Alright padawan, that’s my advice for you. I wish you all the luck in the world, take what I’ve learned about these and may my knowledge help you. We’re all rooting for you!







  • Agreed on all points, and also would like to point out most of the people who want to “go back” are not the ones who were oppressed during that time. It’s no surprise that the people who want to go back are mostly those who grew up in the white suburbs and small towns, where it was simple and easy.

    The oppressed are conveniently left out of those conversations. Where were the black people, or the gay people during those times? They existed, but in a very simple worldview it’s easy to forget that.


  • I’ll post more later (reply here to remind me), but I have your exact setup. It’s a great way to learn k8s and yes, it’s going to be an uphill battle for learning - but the payoff is worth it. Both for your professional career and your homelab. It’s the big leagues.

    For your questions, no to all of them. Once you learn some of it the rest kinda falls together.

    I’m going into a meeting, but I’ll post here with how I do it later. In the mean time, pick one and only one container you want to get started with. Stateless is easier to start with compared to something that needs volumes. Piece by piece brick by brick you will add more to your knowledge and understanding. Don’t try to take it all on day one. First just get a container running. Then access via a port and http. Then proxy. Then certs. Piece by piece, brick by brick. Take small victories, if you try to say “tomorrow everything will be on k8s” you’re setting yourself up for anger and frustration.

    @[email protected] Edit: To help out I would do these things in these steps, note that steps are not equal in length, and they are not complete - but rather to help you get started without burning out on your journey. I recommend just taking each one, and when you get it working rather than jumping to the next one, instead taking a break, having a drink, and celebrating that you got it up and running.

    1. Start documenting everything you do. The great thing about kubernetes is that you can restart from scratch if you have written everything down. I would start a new git repository with a README that contains every command you ran, what it did, and why you did it. Assume that you will be tearing down your cluster and rebuilding it - in fact I would even recommend that. Treat this first cluster as your testing grounds, and then you won’t feel crappy spinning up temporary resources. Then, you can rebuild it and know that you did a great job - and you’ll feel confident in rebuilding in case of hardware failure.

    2. Get the sample nginx pod up and running with a service and deployment. Simply so you can curl the IP of your main node and port, and see the response. This I assume you have played with already.

    3. Point DNS to your main node, get the nginx pod with http://your.dns.tld:PORT. This should be the same as anything you’ve done with docker before.

    4. Convert the yaml to a helm chart as other have said, but don’t worry about “templating” yet, get comfortable with helm install, helm upgrade -i, and helm uninstall. Understand what each one does and how they operate. Then go back and template, upgrade-ing after each change to understand how it works. It’s pretty standard to template the image and tag for example so it’s easy to upgrade them. There’s a million examples online, but don’t go overboard, just do the basics. My (template values.yaml) usually looks like:

    <<servicename>>
      name: <<servicename>>
      image:
        repository: path/to/image
        tag: v1.1.1
        network:
         port: 8888
    

    Just keep it simple for now.

    1. Decide on your proxy service. Traefik as you see comes out of the box. I personally use istio. I can go into more details why later, but I like that I can create a “VirtualService” for "$appname.my.custom.tld` and it will point to it.
    2. Implement your proxy service, and get the (http only still) app set up. Set up something like nginx.your.tld and be able to curl http://nginx.your.tld and see that it routes properly to your sample nginx service. Congrats, this is a huge one.
    3. Add the CertManager chart. This will set it up so you can create Certificate types in k8s. You’ll need to use the proxy in the previous step to route the /.well-known endpoints on the http port from the open web to cert-manager, for Istio this was another virtual service on the gateway - I assume Traefic would have something similar to “route all traffic on port 80 that starts with /.well-known to this service”. Then, in your nginx helm chart, add in a Certificate type for your nginx endpoint, nginx.your.tld, and wait for it to be successfully granted. With Istio, this is all I need now to finally curl https://nginx.your.tld!

    At this point you have routing, ports, and https set up. Have 2 drinks after this one. You can officially deploy any stateless service at this point.

    Now, the big one, stateful. Longhorn is a bear, there are a thousand caveats to it.

    Step one is where are your backups going to go. This can be a simple NFS/SMB share on a local server, it can be an s3 endpoint, but seriously this is step 1. Backups are critical with longhorn. You will fuck up Longhorn - multiple times. Losing these backups means losing all configs to all of your pods, so step one is to decide on your stable backup location.

    Now, read the Longhorn install guide: https://longhorn.io/docs/1.9.0/deploy/install/. Do not skip reading the install guide. There are incredibly important things in there that I regretted glossing over that would have saved me. (Like setting up backups first).

    The way I use longhorn is to create a PV in longhorn, and then the PVC (you can look up what both of these are later). Then I use Helm to set what the PVC name is to attach it to my pod. Try and do this with another sample pod. You are still not ready to move production things over yet, so just attach it to nginx. exec into it, write some data into the pvc. Helm uninstall. See what happens in longhorn. Helm install. Does your PVC reattach? Exec in, is your data still there? Learn how it works. I fully expect you to ping me with questions at this point, don’t worry, I’ll be here.

    Longhorn will take time in learning, give yourself grace. Also after you feel comfortable with it, you’ll need to start moving data from your old docker setup to Longhorn, and that too will be a process. You’ll get there though. Just start with some of your lower priority projects, and migrate them one by one.

    After all of this, there is still more. You can automount smb/nfs shares directly into pods for media or anything. You can pass in GPUs - or I even pass in some USB devices. You can encrypt your longhorn things, you can manage secrets with your favorite secret manager. There’s thousands of things you’ll be able to do. I wish you luck, and feel free to ping me here or on Matrix (@[email protected]) if you ever need an ear. Good luck!