raze2012

Always accuse the other side of that which you are guilty.

You don’t care about justice, you only care about what makes you feel better and that’s wrong.

well if the boot fits…

fediverse is still new, and this was on Hot. How is it surprising that someone wants to comment on an actually active topic?

Prisons are pitched to us as places of rehabilitation - somewhere to pay penance and right wrongs before returning to the community, better for having served the time

In America? many states don’t even pretend with that pitch. They want to be “hard on crime” and “give justice to victims”. And voters vote for that.

in rough order of important:

• experience
• personal projects or project you contribute to (e.g. a decent sized code base in Github). if you’re early on, this can be school projects.
• ability to answer programming concepts in an interview settings
• school/grade prestige.

I have no idea what I would say in an interview.

if you have no previous job, then yea. It’s rough. The first job is always rough, and even in software that’s no exception. You will want to talk about decisions and features you worked on in personal projects for that stuff. And of course, really nail down your fundamentals; they really drill you with those interview questions as a junior.

If you have a job, then talk about that. Maybe there’s some NDA, but you can talk about some problem in general terms and what you needed to do to solve it. You’re not expected to do anything crazy as a junior, so your answer relies more on you knowing how to work in a team than novel architectual decisions.

Personal example: my first job was at a small game studio and my non-BS answer would be that I simply did bug fixes for a game. Nothing fancy, probably something an intern can do.

But interview spin: doing those bug fixes

• helped me learn about Unity’s UI system, I can talk about specific details if the interviewer cares (and don’t feel too bad if they don’t. Even a super experienced engineer won’t be able to talk about every sub-topic of an industry)
• I talk about where I encountered decisions and when I talked to my lead about what to do. e.g. One bug ended up coming from code that another studio owned. While it was a one line fix, I reported it to a lead who would then create an issue to pass on to that studio. Frustrating, but it shows you understand the business politics of the job, something school can’t teach.
• I never did it at that first job, but there were moments where deadlines get moved forward, and you think of a compromise for a feature due to the lack of time . That shows your ability to identify the Minimum Viable Product and to understand the problem, both the bad and good ways to solve something (sadly. in games you may have to hack solutions quite often)

Best of luck

We’re talking here about engineering role after all.

where? seemed like general advice.

Even then, thee aren’t mutually exclusive. your competence will affect how people see you on a personal level, at least at work. And your competence affects your ability to be given problems to own. You’re not gonna give the nice but still inexperienced employee to own an important problem domain. they might be able to work under the owner and gain experience, though.

Documentation and presentation are highly undervalued, and your ability to understand and spread that knowledge can overcome that lack of experience to actually handle the task yourself.