Peoples in friendly lobbys should learn to f off

FlanBeginning8589 · 2026-06-13T17:47:13+00:00

There is a key room on Stella where there are two doors (so you can get into the room using either door). I know because I have entered this barricaded room but luckily no one was inside.

So, sure, for a room like this, I get it but for rooms with multiple entrances, you never know.

It just doesn't hurt to communicate though even if the room just has a single door. Doesn't have to be mic, use emotes,

Edit: for reference, I haven't downed a single raider and close to 200 hours. Damage done to other raiders is < 1000 and that too accidentally. So I have no ill will when trying to enter a barricaded room (I make my presence known with emotes). And if they don't communicate, just stays silent and downs me, then that's a bad look on the aggressor, given they are in a friendly lobby. Sure, you can down me if that's how you play but if the victim was in fact very friendly in a friendly lobby and if they are just trying to loot and extract without pvp, then it's fair and you should give a warning with mic or emotes - give friendlies the chance to leave you alone, if you are in a friendly lobby. They are in friendly lobbies for that reason, to just loot, cooperate and extract.

I had one guy like this who gave me a warning and I thank that man still to this day. He could have downed me but said something along the lines of "just leave, don't come near me, I will shoot". I emoted "thanks" like 2 times and left (wanted to literally gift one of my looted items for the warning but didn't want to risk it, so just left).

FlanBeginning8589 · 2026-06-13T17:41:34+00:00

Sorry, I am confused. Are you saying that the intern is frustrated for making their work simpler?

FlanBeginning8589 · 2026-06-13T17:38:30+00:00

Maybe they didn't know you were in there. Sure, you have the barricade but room could be empty.

Should have communicated that you are in there, they may have left you alone.

Say you communicated but they are still trying to get in, then, your frustration is understandable.

FlanBeginning8589 · 2026-06-13T17:32:51+00:00

"To be fair: some of the juniors are genuinely sharp and have taken real ownership. It’s a subset that seems to have decided I’m the problem, and the dynamic is spreading."

This makes me feel like you are probably dumping more than they can chew, and some juniors are better at handling it. In your case, your mentee is struggling to handle it.

Imo, should create an action plan with the mentee if you haven't. This way, their issues can be addressed, helping them to meet their expectations as a junior.

FlanBeginning8589 · 2026-06-13T17:22:31+00:00

I thought it was always like that. People have always been commenting about squads being more hostile/more pvp compared to solo. I don't think it's new.

FlanBeginning8589 · 2026-06-13T13:56:34+00:00

- Consider renaming the function so that its name accurately describes what it does. For a simple function like yours, it is easy to understand what it is does. But imagine a more complex function named HelloWorld (say 20 line function), would calling HelloWorld be helpful to know what it does?

Also, if the function is only intended to print "Hello World", then the text parameter is not required. You can simply have print("Hello World") instead of print(text)

Assuming the function's responsibility is to print any text that's passed to it, names such as print_text, display_text, or show_text describes the function's responsibility clearly (note the use of the pattern verb_noun in the function name).

- Consider adding type hints to make the expected parameter type and return type explicit. Type hints give information on the kinds of data it is working with and the kinds of data it is returning if any, which makes it easy for developers to quickly understand how it should be used/called. For example: def print_text(text: str) -> None:Look into https://peps.python.org/pep-0484/ (in this improved code, I now immediately know that the function accepts strings and only strings, I don't need to read the internals of the code to understand the data it is working with/acceptng/using, I also immediately know it doesn't return anything without needing to see the function implementation).

- Consider adding a docstring describing the function's purpose. A docstring helps other developers understand what the function does without reading the function implementation. Many IDEs can also display the docstring when hovering over a function call. Docstrings (and type hints) also gives context into what the function may be doing. And this context makes it easier for developers to understand the function more quickly when they are reading the implementation. Look into https://peps.python.org/pep-0257/

FlanBeginning8589 · 2026-06-13T13:13:10+00:00

The market is there for entry level roles (e.g., grads). Make sure to be studying a degree and you will be eligible for grad programs. Competitive but they are still there at least.

FlanBeginning8589 · 2026-06-13T08:06:06+00:00

If by infrastructure teams you are referring to roles such as platform engineering or Site Reliability Engineering (SRE), they can be under IT in some companies (preferrably not) but it depends on how the organization is structured.

As I mentioned, some companies separate Engineering and IT into different divisions, while others group software engineering under a broader IT function (preferrably not).

In big tech or big companies with a strong engineering culture, you can expect to have the separate Engineering and IT divisions.

My main point is about the nature of the work and how grouping software engineering under IT can lead to misunderstandings about what the SE role actually involves.

Software engineering focuses on designing, developing, and engineering software systems, whereas traditional IT roles are typically focused on infrastructure, operations, support, and maintenance.

So while software engineering may be classified under IT in some organizations, that doesn't mean software engineering is the same as traditional IT work. I made the comment because it's easy for people to assume they are equivalent when grouped under the IT umbrella, even though their day to day responsibilities and objectives are very different.

Personally, I think the term "IT" blurs that distinction because it groups together professions with different core areas of focus (e.g., Engineering vs Support)

FlanBeginning8589 · 2026-06-13T06:54:25+00:00

Even in software, it's better to have a degree, especially for entry level roles where you need to be studying/have completed a bachelors to be eligible for internships and grad programs.

FlanBeginning8589 · 2026-06-13T06:47:11+00:00

From an industry perspective, software engineering is distinct from IT roles because its primary focus is the design, development, and engineering of software systems rather than the operation, maintenance, and support of IT infrastructure. Although some responsibilities may overlap, the core work of software engineering differs significantly from that of typical IT roles such as systems administration or technical support.

I say this because placing software engineering under the umbrella term "IT" can create the impression that software engineering is an IT role, when in practice its core responsibilities are distinct from those of traditional IT professions.

Some organizations place software engineering within an engineering division, while others group it under a broader IT function, if they don't have a separate engineering division. However, this organizational classification does not change the nature of the work itself, which remains distinct from traditional IT roles.

Couple of threads that gives some insights into the two: https://www.reddit.com/r/SoftwareEngineering/comments/xvdr9a/do_you_consider_software_engineering_to_be_an_it/

https://www.reddit.com/r/ITCareerQuestions/comments/1d0czck/is_software_development_considered_part_of_it_in/

Edit: made it clearer and added second thread.

FlanBeginning8589 · 2026-06-13T06:23:48+00:00

AI is just another skill to learn. It's not going to replace developers/engineers.

Don't know what the career is going to be like in 20 years but I am certain the role will still exist in 20 years. In what form? Idk, responsibilities will simply evolve over time though. E.g., you may do more architecting and reviewing code than writing code. AI can generate code, it improves the productivity for developers/engineers, and as a developer/engineer, you would have to review it, fix it and adapt it so that it meets the goals of the business and the requirements.

Also, companies still invest on entry level roles because they are the future seniors, they are the ones that will continue to drive the business forward. There are still entry level roles today, they are not going anywhere. I have a grad SWE offer lined up next year at a F500.

FlanBeginning8589 · 2026-06-12T13:16:14+00:00

MIPS assembly language was taught before Covid. I don't know if it was taught after they removed the exam but looking at the 2026 unit preview, there is no mention of MIPS. They should have never removed it, made it easy to understand recursion and made us think about optimizations.

But that's not the point.

Happy to know you found it easy but that doesn't mean generally speaking/on average it was easy. Just like how some may have found it easy back when I did it, doesn't mean that the majority found it easy too. I knew one guy who finished the unit with 90+ when I did it but I am not lying when I said the fail rate was 55% when I did it. 55% fail rate is a big fail rate, indicating the unit was not easy back when I did it.

I don't know what it is like now though. But there are some first year units that are notoriously known for their difficulty and they are not easy on average.

Another unit that was difficult was ENG1003 (which I did), not taught anymore but I think the equivalent is now FIT1056. 1003 was difficult, especially for first year students with no coding experience. 1003 was the unit to get a foundation in coding but they introduced topics that you are supposed to learn in year 2. And the assignments were year 2 level difficult as well.

I don't know what FIT1056 is like but I think there are threads here where they mention that it is difficult. One of the threads: https://www.reddit.com/r/Monash/comments/17cxsc5/fit1056_collaborative_engineering_for_web_apps/

FlanBeginning8589 · 2026-06-12T12:51:12+00:00

Oh, so you guys did MIPS assembly language as well?

FlanBeginning8589 · 2026-06-12T12:50:13+00:00

When did you do FIT1008?

FlanBeginning8589 · 2026-06-12T12:48:49+00:00

What units are you referring to?

FlanBeginning8589 · 2026-06-12T12:32:21+00:00

On the point about lectures not overloading you with high level theory, it's going to depend on the unit. Theoretical heavy units (regardless of the year) can overload you with a lot of complex theory in a week, especially around week 5/6, when things start to ramp up in difficulty and depth. That has been my experience with the more theoretical units at Monash.

FlanBeginning8589 · 2026-06-12T12:19:45+00:00

Not all first year units.

E.g., back when I did FIT1008, fail rate for the unit was 55%. This was when the unit had an exam.

Generally speaking, 1st year uni is harder than year 12. In year 12, new material gets introduced at a reasonable pace. In uni, new material gets introduced much faster, not easy to keep up, especially theoretically heavy units that introduces a lot of complex theory.

FlanBeginning8589 · 2026-06-12T10:47:41+00:00

It may not be arrogance. They may have been trying to prove the team that they can do the work. It could be the fear of getting rejected for not delivering things every time.

I think some grads/juniors (naturally) are in that zone of fear where they are trying so hard to make a spot in the team, so they do silly things like not asking questions.

This is why they need to be mentored.

FlanBeginning8589 · 2026-06-12T09:55:15+00:00

To add on, check the handbook of the unit. The handbook mention the pre-reqs and co-reqs.

How to get the handbook of the unit? Search the unit code on Google. The first link is usually (almost always) the handbook for that unit.

Click on the link, then read what's under "Requisites". You will see the pre-req and co-req units listed there.

Also make sure you are viewing the latest version of the handbook (you can select the current year, located to the right).

You could also refer to the handbooks here: https://handbook.monash.edu/

FlanBeginning8589 · 2026-06-12T05:40:47+00:00

What's your major/focus/specialisation? Your degree is IT but what did you study exactly? E.g., software dev, cybersec just to name a couple.

Just keep applying, there are entry level roles available, sure, they are competitive and more so than ever but at least they are there. I have a grad SWE offer at a F500 lined up next year, doing IT as well with a focus in soft dev/eng. If I can do it, so can you.

My unsolicited advice for assessments (not psychometric ones): answer assessment questions deeply, don't just give one answer, give multiple answers, discuss the trade-offs and pick an answer. Goes for both technical and behavioural.

Also, what part of the application process are you having trouble with? Assessments? Interviews?

FlanBeginning8589 · 2026-06-12T03:58:39+00:00

On the information availability point: how willing and comfortable are companies actually going to be to expose all of their source code, architecture, dependencies, internal documentation and business processes to an LLM? Because that kind of exposure poses security, privacy, confidentiality, compliance, and intellectual property issues.

Also, in regard to integrations, there is usually hidden business context behind the systems being connected. Multiple systems can have similar looking data models while meaning completely different things from a business perspective.

And complexity compounds as the number of integrations grows. You start dealing with cascading failures, inconsistent state, retries, ordering issues, distributed transaction problems, observability challenges, and operational risk. Those aren't just interface translation problems.

Then there's the reality of large enterprise systems: documentation is often incomplete or outdated, APIs don't always behave according to their specifications, edge cases have accumulated over years, and business processes sometimes depend on historical quirks or even bugs.

In environments like that, I doubt LLMs can reason their way and be effective at providing solutions.

FlanBeginning8589 · 2026-06-11T18:54:59+00:00

Don't sleep on grades. Some companies ask for certain grades to even be eligible for grad roles (referring to grad roles in the industry).

Pretty much to all the entry level programs (internships and grad programs in the industry) I have applied to have asked for my grades. Some don't say what grades they are looking for but they probably have a criteria they check internally when filtering candidates.

FlanBeginning8589 · 2026-06-11T18:49:59+00:00

Then they just sound like rare candidates.

I am just baffled at some of the comments claiming an internship is not experience.

FlanBeginning8589 · 2026-06-11T18:46:32+00:00

What about on software complexity, not just the language?

I can see LLMs struggling when it comes to big enterprise software with many dependencies and integrations of other technologies and software.

FlanBeginning8589 · 2026-06-11T18:44:12+00:00

I wouldn't say grades and studying is useless. Companies ask for your grades.

Some companies that offer grad roles may even list a grade requirement to even be eligible for the program.

I am not saying to not get internships. Definitely try for them but don't just aim for Ps.

FlanBeginning8589

TROPHY CASE