lol I'm sorry but weren't you painting yourself as some kind of machine learning expert in this thread?

What do you guys think about working remotely for your first programming job? It would be on a 4-5 person team at a financial company that is worth $1b that does not focus solely on tech. The interview process was very simple. Someone you spoke with briefly is a consultant and passed your names to these guys. They did not give you any homework assignment or code challenge. They seem pretty chill and generally uninterested in a traditional hiring process. They do know that you had multiple offers at other companies. They matched the offer and it is definitely above market for your physical location.

You've been applying to tons of remote jobs and the hiring process has generally been way different than this company, those other companies are looking for experienced devs and have a boat load of hoops for you to jump through.

It's hard to say without further details, but in general, remote work can run the gammit of working with an attentive team on Slack to being totally isolated and emailing an invoice once a week.

It also depends on what the team configuration is. Are you going to be working with other devs? What is their background? What is the role you are expected to do?

For example, if you are working with non-techs, they are more likely going to expect magic to happen in 1 day. A bug needs to be killed now, and it doesn't matter one iota to them if the codebase is a polyglot COBOL / Smalltallk system written by a meth addict.

IME, it's a sliding scale. If you are working with non-techs, the difficult work will be more immediate, often, and ever-changing. If you are working with a tech, they are more able to block the fires from you.

I think it really comes down to this with remote work: If you are looking long-term, join a team working on a project that sounds interesting to you. Join a team that has a relatively high collective IQ. Take on something that challenges you. There is going to be no one forcing you to show up and work, so you need to be motivated to wake up and do it.

A short-term contract is whatever to me. A few week so spelunking code and throwing my mouse against the wall is doable. A short-term job doing stuff I absolutely would never do full-time is no big deal.

As a first programming job working remote? I have to disagree strongly. Communication is difficult remotely and for someone junior, you'll need a lot of hand-holding to get ramped up.

There's so much you are missing out by working remotely, it will hamper your growth as someone starting out. You'll miss out on things like pair-programming and asking simple 1 off questions.

I agree with you. I'm not really sure here OmgGlutten! lives, but if he's in the middle of nowhere, there isn't many options for him if he isn't willing to move.

If given the option between working in-office or remote, I'd take in-office any day of the week and it's not even close. You get to meet people (networking is more important than talent), you can get free coffee / food, and you get that requirement to show up / motivation. I think motivation is the hardest thing for a lot of people.

I'm also not sure if this remote position is contract or employee. There are huge differences between the two. My computer took a dive this past weekend. As an employee, that's no big deal because the company is required to send you a new one. If you are a contractor, you're out of work.

Yeah I wouldn't recommend it for a first job.

Even with some experience, you will have to work much harder to communicate. It's harder to be heard (and to hear) in meetings, because you're on the phone. You won't be present for some decisions that get made. If you don't make frequent visits to the office you won't really be seen as an actual person, just sort of an Abstract Programming Unit.

I don't think so. Never claimed to be. I know the basics. I am excited by this new technology. If anyone is trying to pretend to be an expert though, it's Elon Musk with the constant barrage of hyperbole and apocalyptic doom. I at least understand big picture what this technology can do. I study all the time and work hard at it.

Welcome to the programming forum. Interesting first post.

Yeah I don't think anyone with < 10 years experience should take a remote job because it's going to slow your learning and growth opportunities too much.

Agree with the comments so far on remote work. Even for more experienced folks it's fraught with challenges that can be difficult to overcome.

I'd add that this place doesn't sound like an ideal first programming job even if it didn't have the challenges of being remote. Non-technical company with an easy and not technically focused hiring process? Sounds like you're likely to be working with people that won't be helpful in developing you too your potential and I'd guess you'll be working with weak devs

I have less than 10 years experience.

Agree with blackize5 on the non-tech issue. Non-technical people have many challenges you may not be prepared to deal with. You can't ask them a stupid question and expect to get an answer, whereas with a technical person, you can ask a dumb question and they can at least Google it for you.

The worst clients I've had are those that are somewhat technical. Like they know *some* HTML or SQL but don't know anything else. If you get the sense they are these types, stay very far away.

As a mostly remote worker, I find a good way to network is to be so ****ing awesome that people talk about how ****ing awesome you are.

It?s worked well for me so far.

Unrelated, does anyone know some good SEO gurus who take on side work?

Here's my PM reply to OmgGlutten's job situation. I told him to post it here as well. Agree with all posts so far.

I actually don't mind this at all. Just give me a task and let me gogogo. There's already a hundred decisions to make on the small scope. I care about the big picture only as a general target. 9 chefs don't bake a better cake.

This job, as described, doesn't sound ideal. It wouldn't be ideal in an office either, I think. As a solo tech person, you create the implication that you're an expert. Any rust on that image will not bode well for you.

Doing remote work and contracting without experience works out for me because I already built very large systems alone, made a ton of hard mistakes, and learned how to really debug and modify code... both my own and other open source things. The balance is understanding my own limitations and knowing when to say no.

ya I agree with Barrin. even after 1.5 yrs I still need to ask a lot of questions. and its not really any questions about actual coding, such as how to filter something out of a list of objects, or even how to set up an API that returns something.

its more about environment questions. like, how do I set my computer up to run this bit of code locally so I can debug? or, why am I getting an error when I try to run this code locally? why am I getting an error when I try to access this database?

theres also the problem of just knowing who to ask for help on certain issues.

that may be greatly mitigated at a small company tho.

and bolded indicates you are looking for a remote job primarily so maybe you are on a higher level than most beginner or jr devs.

Yea that stuff seems to go way better in person.

Our various backends have fairly involved steps to set up locally, and one of our most senior people showed me how they are all essentially set up when I started.

We had a senior engineer start recently and for a couple days she was stuck on slack getting her local environment set up.

One morning this week she seemed to be getting really frustrated so I walked over to her desk to offer help. She was at the point where she immediately stood up and said "please try anything you can". I really didn't do much more than rm a couple .war files, reset apache and then run the build scripts off the readme, but we had her local built and ready to roll in 5 mins.

Yeah, the local setup can be a PITA when working remotely. Many times, I have zero guidance and I have to hope for the best. The positive is that I can use my own passwords for many things like the database.

The recent contract has a rather complex polyglot setup. It was easy for the first few steps, then I ran into a whole slew of problems. Of course, since everything works on their machine, I can't say "well, just help me, yo!" I have to send over a useful error message. Granted, it's not hard to look at a bunch of stdout and logs, but those can be overwhelming if you don't know what line to look for in a 500 line dump.

Not to mention having literally no idea what the error means because its a general error catch that corresponds to many things. But the most common 1-2 are usually it.

Knowing what errors to check for in situations like that seems so valuable.

I just see it as do or die.

I only had to bow out of one contract over my inability to set it up, but it was probably for the best.

I once turned down a contract because they couldn't set up their machine. They wanted me to remote control their box, and they kept sending me emails because they kept getting stuck. After 3 days of that, I told them I wasn't interested.

To be a great contractor is to take over in a situation like that and become incredibly valuable right away.

Nah, there were other indicators that it was going to go bad for me. It was just the last straw. I won't talk about it publicly.

One of my fellow bootcamp grads (we've been working just over 2 years) told me about feeling embarrassed at work for not having a full understanding of what .bashrc is (I barely know what it is as well and just use what's either standard at my company and/or copied from others when I first started). This is something that most CS grads know. For CS grads - where did you learn that? How would you recommend a non-CS grad learn it?

Of course we can look it up and just get the answer that way and have an idea of what it is, but I'm assuming that in some CS class[es] you drilled down deep and have a strong understanding of shell scripts, Bash, Unix, etc. (Or maybe that's an erroneous assumption.)

.bashrc is an awful thing and you should hope you never have to deal with it. It's "magic" that executes off in some hinterland that most devs aren't even aware of. It can't be checked into a git repo. Avoid.

The last thing on earth I want as a dev lead is devs with different .bashrc-s. Not to mention all our offshore devs are on PCs, so **** that.

Seriously. I don't have a CS degree either. But I remember the first time I learned that weird **** was happening in a .bashrc file, I was like - this is not a good model at all for shared dev environments.

Idk about "most CS grads know". More like "huge Linux command line aficionados know". Although, at a certain point probably bash is terrible / for n00bs and ksh ftw or some such...

I mean, everyone with an interest in Linux should know "it's probably the config file for bash shell, the "normal" shell on a Linux terminal". If this is news to you and you are learning Linux, know that ".*rc" is a startup script / setup configuration for *. See also .vimrc (for the text editor Vim, ldo), or the system V init scripts in /etc/rc.d (system boot up) and so on. Some say it stands for "runtime config".

Imo you've gotta be fairly into it to actually know much about it though / write your own from scratch without just copy/pasting useful snippets off the internet. I've used Linux for maybe 18 years and never once messed with it lol.

like learning anything these days, just google and read / watch. man bash if you're stuck in a terminal without internet

Lol wut??? There's no reason to worry about your devs having different bashrc's. It's a plain text script that sits in the users home directory and runs startup stuff when they open an interactive terminal session. It can be as simple as you want and it doesn't affect anyone that's not using your machine. A normal user will never touch it or just add his personal aliases to it (e.g. alias ll="ls -l")

Baltimore Jones,
If you want to learn more about anything linux related, I recommend the arch wiki. Just google e.g. "arch bash" and you will find very good documentation, albeit a little verbose.