Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
  • Post
  • Reply
Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Anyone here worked in the manufacturing industry as a developer?

Adbot
ADBOT LOVES YOU

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

New Yorp New Yorp posted:

I spent my first 3-4 years post-college working on ERP systems and a staggering number of engineer-developed spreadsheets for a chemical manufacturer. It wasn't a great experience, but I was also very inexperienced and had no good technical mentorship. The person I was hired under didn't even believe in source control, so we just... didn't. I set up SVN for myself.

I just picked up my first full time job out of college and its in the materials manufacturing industry. The guy I'm working under also doesn't believe in source control (too complicated and what if other engineers need to use it), there is no sense of separation between development and production environments (just make a backup before you change something), and yeah no potential for actual technical mentorship. The pay is fantastic and I have enjoyable work to do.

Would you mind elaborating on what the rest of your experience was like in that environment? We've had some chats about modernizing stuff and it seems like they're intending to hire more CS people, but I'm feeling stuck between wanting to push for doing things better at the risk of dealing with the fallout or just staying status quo until I can find somewhere else to go work. I'm worried that if I do the later then I'll be missing out on opportunities to expand my resume while I'm here though.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

leper khan posted:

Changing that environment is not something you're going to be able to do unless you spend a very long time in that job.

You're right. This industry has the expectation that new hires will be there for 20+ years and they're already acting like I'm going to be long term without asking me what my plans are. We have plans of expanding out the department with a few more CS guys though. Ethically, I feel like initiating new stuff if I don't intend to be around for a long time is kinda weird, but I know they're asking me to do it at the same time. I'm fresh out of college and in a weird loving position.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

lifg posted:

Really?? Do they have an individual contributor career track that goes all the way up?

Honestly I'm not too sure what career progression looks like. It's a very old, very big (num employees and net worth) company in the metal industry. Everyone here (hyperbole a bit but not much) has been here for 20+, and there is a lot of company loyalty/family ideology that just doesn't resonate with me - just a generational thing I guess. There is awareness on some levels I've run into that they need to start modernizing, but it doesn't exist on my level yet in any real way.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Che Delilas posted:

I'd put my money on any career progression there involving a transition into management, that is a theme that I see among older, non-technical people. I regularly get allegedly wise words from my parents' generation that I'll eventually stop wanting to solve engineering challenges and want to start solving interpersonal ones instead. None of them are or were engineers though, and I've worked with people in their late 60s who are utterly uninterested in moving from engineering to anything else.

I think it's partly generational and partly the nature of our field. Earlier generations had the possibility of a pension and job security, and more recent generations bought into that too, but when people my age see a few family members get forced out early and end up with half or a quarter of the money they planned on having for retirement, and don't even have the illusion of a pension on the table, we wise up and treat the jobs like the temporary business relationships they tend to be. We also have a transferable, in-demand skill with basically no ceiling (more to learn than we ever will), compared to the lifers who are only valuable at a given company because they know that company intimately. There's just no advantage in sticking around unless they do what the big four do: slap on enormous golden handcuffs.

That makes sense and is probably true for the most part company wide, but our department is a R&D department that's composed of engineers, scientists, and lab techs. We have one manager and everything else is flat. Most of the senior researchers are all lifers. I do know that there is a lot of lateral movement throughout the company. Moving from production to research to systems etc...

Either way, I know I'm not gonna be a lifer so it's a weird boat to be in.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

So I got hired a few months back into a oldie manufacturing company who is slowly but (at least from our departmental view) desperately wanting to move into the 21st century. My day to day tasks have been about 50% self initiated following general guidance regarding the kinds of things my boss wants us to be doing. The development I've been doing has mostly been working on their legacy applications that interact with their production systems on request and some data warehousing and automation of data collection from sensors and whatnot. We're in the research department so I'm mostly in a support capacity for the researchers on that end.

Their production systems guys have been developing code in house for the last 10+ years and are pretty dependent on it, but it's a mess. On my own initiative I've rolled out a demonstration development server with a source control/CI workflow, have been creating upgraded versions of current applications to run side by side to introduce them to some potential areas we can improve on, and have been slowly cataloging all of the crippling issues regarding our network. The people who matter have received the idea of it with a lot of enthusiasm and healthy bits of caution (I can't be the only one capable of interacting with the system, we need to develop more talent, etc..).

Without getting to into the weeds about how this came about, there apparently was an internal feud a while back with the net result being that their IT department (under the CFO) said "gently caress it we're not touching it" to their entire production network years ago and gave full control (everything but domain admin) of it over to their systems engineers. So obviously there are dozens of web facing servers running every different type of MS Server you could imagine that haven't been patched in years and heaps of vulnerabilities everywhere. Everyone's known about this but they've just treated it as a sort of non issue because no one has the time to do anything about it, but they don't want IT all in their stuff "slowing things down."

Like an idiot I decided to write up a summary threat analysis of their production servers and had a conversation with my boss about it. The reaction I got was actually really positive and mostly just "well seeing it all in one place like that makes me feel pretty dumb about ignoring this for 10 years. This is a full time job isn't it?" So now the idea of creating a production sysadmin/devops/security full time position is on the table. If they decide to go ahead on it I'm thinking of asking them to pay for me to train up on the standard networking certs (I've got funding for training on the books) and pivoting into that role and having them backfill my position instead. So given an ample supply of corporate funding what would be the ideal way for someone with a standard BS C.S. background to train up in that area?

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

necrobobsledder posted:

Most people with CS degrees fundamentally want to do some form of development that involves coding. The scenario you're describing is somewhat uncommon in that normally nobody hands over IT duties to developers of any kind because the day-to-day work of sysadmin / operations is pretty much nothing like development.

You really just need a solidly competent sysadmin or two that isn't afraid to dig into badly maintained systems, a CS degree may actually be a handicap in some respects because a lot of sysadmin stuff is really nothing you'll learn in any school. You can learn algorithms and approaches to problem solving galore that can help, but that won't matter much when getting down to the nuts and bolts of deploying GPO policies to a fleet of servers or using SCCM to keep servers patched without causing production outages (oftentimes because a patch can interact poorly with a lot of badly designed software that's hacked together to just get it working). However, where you can spin things in recruitment is that you can give someone an opportunity to fix the problems that a lot of places would not have budget to do - this should appeal a lot to admins that have been constantly denied budget throughout their careers. You should have a budget laid out over the course of a couple years to fix the problems and make sure that developers are onboard with any software fixes that will be necessary.

If patching a Windows server is ever thought to mean it'll "slow you down" then you've got a software architecture or design problem. Taking out one server shouldn't mean anything whatsoever in modern systems, and even maintenance windows shouldn't exist anymore with software that can be deployed continuously (most programmers do not write anything that can be deployed frequently).
Section 83B allows you to pay the tax up-front, but the alternative is that you'd pay tax as ordinary income on the day that the grants vest. Nothing in tax law will protect you anywhere from stock prices going down 100% unless you have a short position on the stock, but that's not a possible position in most privately traded companies (although I do wonder about a shadow market only among VCs). You're right that a tax deduction of, say, $3000 annually for 6 years is not going to offset you having paid $18k if you were to file a Section 83B. This is part of why I didn't file a Section 83B when given ISOs before - I expected the stock value to go down substantially because I thought the company that bought us was total crap and their stock dropped 60%+ within a year or so after they bought us. My primary regret is that I didn't buy a bunch of short positions on the stock and stop loss orders. I bought Tesla shares as soon as I had vested and the rear end in a top hat broker that was incentivized by my company delayed my sale and purchase by like 3 days.

Yeah I'm aware that my CS background doesn't translate to doing sysadmin stuff. I've been interested in infosec stuff for years and have a decent nonprofessional understanding of networking fundamentals from that perspective, but I really don't know the first thing about running a network. I guess I'm looking at this as a potential to explore a career path I'm potentially interested in and in the mean time help clean up the low hanging fruit. If I expressed interest in taking over this role I'm pretty confident they'd be willing to invest in me the resources to get it done. When things are as bad as they are any progress makes me look good so it's not like I'd need to become a first class sysadmin over night. I guess on the flip side if we brought someone who is already competent in to fill the role I'd have someone to learn from.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Bruegels Fuckbooks posted:

I don't think you're in the right thread, but I'll answer anyway - It really depends on "do you want to do sysadmin or do you want to develop?" That situation honestly sounds real hosed up - if you wanted to learn how to sysadmin, you'd probably be better off working at a place where things are semi-functional. It depends on your role now though - if you're just some random intern at the company and trying to score a full-time gig, it might be worth a shot, but if you're a software engineer already, that seems like a terrible transition to make..

I graduated a few months ago and got the job out of school. I hired in as essentially a software engineer. Still trying to figure out what I want to focus on career-wise I guess.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Good Will Hrunting posted:

My bad - should have read more carefully. Too busy being my own product manager making Jira tickets for myself. Speaking of which, have you folks ever worked somewhere with 0 "scrum" or "scrum like" practices? Like, we just have a giant board of tickets. We do no planning, grooming, discussion or anything and frequently make our own tickets. There are no sprints or points assigned because my boss things it's a "waste" but myself and peers think it's to reduce transparency. Our new team lead is all for doing a bi-weekly retro and planning, which I like.

We have a no project management process at all kind of thing. I get told "here's the general idea of what we want you to do" and then I go collect requirements and do the project. The process is up to me. It's probably a terrible way to do things. I'm trying to leave.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Jaded Burnout posted:

Do I need to know "algorithms".

For interviews? Yes.

Everyone is going to tell you to read Cracking Coding Interview and do practice problems on hacker rank.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Jose Valasquez posted:

I certainly don't think it is normal in most markets and industries, but within tech companies/startups with HQs in the Bay Area, NYC, and a few other expensive markets it is completely normal

We should just make a rule that if you're going to discuss your +150k salary you should also be required to postfix in brackets the amount you pay in rent/mortgage.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Che Delilas posted:

Well, yeah. And that sort of thing is not the kind of hill I generally chose to die on anyway, since it's just one stupid hoop to jump through that I can then completely ignore once I actually start working.

Our personality test has determined that you'd be a great lead for our weekly Lean Office/5S meetings. We look forward to seeing your SWOT matrix.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Pollyanna posted:

This would be my go-to strategy if I had the magnitude of knowledge that recruiters do about what tech companies are in my area, what they do, which of them are hiring, and if they're hiring for someone with my skill level and skillset. Unfortunately, I can't really compete with an entire company dedicated to that task.

indeed.com got you covered bro

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Pollyanna posted:

I dont really want to learn everything, though. I recognize the usefulness of a lot of things but also realize that theres a lot of investment that goes into it, both time and effort. Im also naturally uncurious about things I dont immediately have to deal with, too...which is why stuff like how does SSH work and explain graph theory to me just sounds like minutiae, cause Ive never had to care before. I care about embarrassing myself by not knowing the answers, though...

This is why I wouldnt do another degree unless theres something I like and want to work in AND require a degree in.

For what it's worth, there isn't even any certainty that you'd actually be able to answer "how does SSH work" or "explain graph theory to me" just by obtaining a CS degree. Most CS programs don't even get into graph theory outside of 1-2 weeks in a discrete structures course, and unless you take a course on networking you won't learn jack about SSH other than maybe how to use it. Four year degrees give you very broad and very shallow formal understanding of a lot of critical things, but you essentially come out a blank slate not really knowing much when it comes down to it other than how to go about learning the things you need to.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Skandranon posted:

Bahahaha no, the value of getting a degree is plummeting daily and is never going to go back up. It will be a waste of time that you could have invested better.

This probably needs a huge caveat *if you are the type of person who is generally successful self teaching.* There's no loving way I could have made it into this field without someone holding my hand through college to pound into me the fundamentals I needed to be successful. Now that I'm on the other side I don't need that structure, but the value was actually in the education that allowed me to get the first job.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Good Will Hrunting posted:

I bet if you had been giving reading + assignments and tried on your own, posting any questions in the respectable threads on SA you would have gotten as much help here as you would have from a professor if not more. Now, in the advent of poo poo like Coursera, this is even more true. I enjoy learning and I am perfectly capable of doing it on my own, I just struggle to find the time these days. A formal education provided me the focus and time to do so.

I'm not going to argue this any further, but no I don't think I would have been as successful. There is something to be said about the formal structure of academic institutes.

Is it necessary for everyone? No. Does it work for lots of people? Yes.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Skandranon posted:

There is no need to be there to learn anything CS related. You have a lovely laptop & internet, you have all the tools necessary to learn what a 4 year degree purports to teach, and probably in less time.

You're obviously just significantly smarter and more driven than most of the population.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

B-Nasty posted:

Just trying to provide a little perspective. There are many, many people that would trade their truly miserable jobs (with objectively bad aspects) for ours if they had the ability.

This perspective isn't ever helpful though. It's like telling a homeless man that his hunger doesn't matter because his belly isn't distended like "KIDS IN AFRICA" yet.

If you aren't happy you aren't happy end of story. The floor of potential human misery isn't really relative at that point.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Pollyanna posted:

The thing that bugs me the most about the industry is how touch-and-go it is. Most jobs seem to last 2-3 years, and there isn't much potential for nice, long-term employment where I don't have to go job hunting three or four times a decade. Plus, the jobs that do exist are in an industry that has taken "fire fast" to a bizarre degree, to the point where it's difficult to trust that a company genuinely understands its needs and won't just change its mind out of nowhere after hiring you. Then there's companies that depend on the whims of VC funding, depend on a customer base and product that don't even exist yet, depend on a pre-existing market that would result in major losses if it left...it's like it's held up with sticks and stones.

There's a level of trust necessary between an employee and their employer to make that Maslow tradeoff work, and in my current job search at least I've come across a lot of employers that haven't proven themselves to be stable enough to keep that trust up. Maybe I just come from a world that's based entirely around going through long educational periods, then finding one job to stick to for 40+ years (medicine), but it's hard to see myself doing this when I'm 30 or 40 and feeling like I've really made it somewhere in life.


fully-automated gay luxury space communism or fuckin bust, and i am only half joking about that

Come work as a developer in the manufacturing industry. There are a ton of jobs since the industry is moving in to what they're terming "Smart Factory 3.0. (help we need in house software developers)." The pay and benefits are pretty good, everyone will assume that you will be staying in your position for a minimum of 10 years (only silly gen-xers move around). You can wow people by just understanding that OOP didn't end after smalltalk, and that Visual Basic isn't the end all be all of easy to throw together CRUD apps. You won't be working with cutting edge stuff, but if you swing it right you can easily get the opportunity to pick your own tech stack to work with as long as you're willing to support it. Everyone I work with has been at our company for 20+ years or has been hired within the last 5 and has no intentions of leaving. They never flat out asked me if I was in it for the long run, but I've had people tell me "we wouldn't even bother hiring someone if they have a history of jumping around jobs every few years."

Oh also they're all conservative Republicans so that's a thing...

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

I actually work in a research lab and I haven't even thought about writing a white paper. It's not a measure of success its an artifact of coming across something in your line of work that warrants publishing it (assuming your employer allows you to publicly publish things). If your goal is to write a white paper in order to be successful, then you're going to end up finding something to write about regardless of its merit. What about like getting paid or just enjoying your job and the people you work with?

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

hendersa posted:

This is a bit tough to answer with specifics, as the implementation of device drivers varies a lot depending upon the environment that you're running in (bare metal, specific OS, SoC/microcontroller/etc.). However, there are some common aspects that will be a part of all hardware interfacing. I'd concentrate on these aspects when preparing for your interview (they're what I'd ask a candidate about, anyway):

1. Like csammis mentioned, know your low-level communication methods for speaking with hardware. For sensors and control systems like what you'd see in RC vehicles, these will probably be things like I2C, SPI, GPIOs, and UARTs, as well as PWM and ADC. Knowing what these guys can do and what their limitations are is good. Knowing how a microcontroller, SoC, or BIOS exposes memory-mapped I/O control registers for these guys is good. Those MMIO registers are how you're going to be interacting with hardware, so show that you know the basics on how to do that and where you'd find address/register info ("it's in the 4000-pages of SoC documentation", "I'd go talk to the BIOS guy", "I could probably scrape an address out of a device tree in the Linux kernel and then Google it to find the right docs", etc.).

2. Interrupt-driven design. Top-half and bottom-half interrupt handlers are important to know, though a simple design with lax constraints could get by with immediately servicing interrupts completely without any queuing for later processing. If you have experience with interrupt management with a particular microcontroller or SoC, explaining a concrete example of that is good. Examples of when interrupts might fire (say, data arriving on a UART from a serial-based MAVLink connection) and how you'd service that before returning to the main event loop is good. Comparing/contrasting interrupts to polling and knowing when it is appropriate to use each will most certainly be asked about if your interviewer knows anything about device drivers.

3. DMA will probably not be a concern for you, since your problem domain is concerned with sampling and writing small amounts of data to/from sensors and motors at regular intervals. You're not pushing large blocks of data around, unless you're capturing video data from a camera and transmitting it back or something like that. A cursory knowledge of what DMA is and what it is used for would probably be enough to just check the box on that one, if it even gets mentioned during your interview.

4. State machines, particularly on a bare-metal system without an OS. Show that you understand the main event loop of embedded firmware (deadlines, scheduled polling, etc.) and that you understand more of the big picture of where device drivers fit into the system. Your device driver itself may also contain a rudimentary state machine of some sort (init, shutdown, delay, sample, etc.).

5. Stuff that you should avoid doing in a device driver. Some good examples are avoiding floating point math, variable/large-sized buffers, large stack frames, non-word aligned memory accesses, concurrency/locking (sometimes), and text/data manipulation. Get the data in/out of the hardware quickily and at the correct point in time. Minimize processing of data in the driver itself. Keep memory/resource usage as small as possible. Ironically, avoid blocking/busy-waiting on I/O. On bare-metal, all bets are off on this stuff, but these items are generally best practice.

6. Debugging. The unexpected will happen, and you'll need to show that you have what it takes to figure out why. Have you ever used a logic analyzer, oscilloscope, or JTAG to watch hardware behavior? It isn't a dealbreaker if you haven't, but if you have you can demonstrate some real strength in this area. Also, if you have Arduino, RasPi, BeagleBone, etc. hardware interfacing experience, you can use that as a testbed to shake down hardware interfacing code before moving it back over to the target platform. If you have a serial terminal to push debug output over on the target platform, make sure to explain that, while useful, using it will slow things down, blow your timing budget, etc. Blinking an LED via a GPIO is also a tried-and-true aid to debugging device drivers during their initial development and troubleshooting. Your goal is to show that you won't get stuck because you've run out of debugging techniques to try. Or, at least, that you've got a few good ideas on what to try first. Try to think of a few good ones that you can mention (hell, just use the ones I listed) to give assurances to your interviewer that you can handle this type of debugging.

If I were hiring a device driver developer for something like what you've mentioned, I'd ideally want someone that I could hand a sensor/motor/servo control IC datasheet to and say, "we want to be able to sample/adjust this at 100Hz on a continual basis. We've got some samples, so breadboard this out with an SBC to drive it. See if you can find some sample Arduino or Linux code available for you to start with. Get this chip talking and tell me if there are going to be any problems." I'd then (eventually) get back some C code with best/worst case time when polling and any appropriate interrupt handler info or jitter issues or whatever caveats or dealbreakers turned up.

Once given the green light to proceed after the proof-of-concept, that developer would then lock down the device driver, coordinate to get it integrated into the software build (kernel/bootloader/BIOS/etc. as appropriate), document it, and perform integration testing on the target hardware side-by-side with the hardware team as appropriate. If the system misbehaves down the line, the developer will be able to collect enough information to assist the hardware folks in troubleshooting the issue from the software side, and adjust the software side as needed to address the issue.

Some reference materials that might be of some use:

Linux Device Drivers, 3rd Edition (check out Chapter 10 on interrupt handing):
https://lwn.net/Kernel/LDD3/

ArduPilot firmware libraries:
https://github.com/ArduPilot/ardupi...aster/libraries

Quick overview of SPI, I2C, UART, GPIO (if this material is new to you):
https://tessel.io/blog/108840925797...ation-protocols

Good luck!

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Sitting at a desk for 8 hours straight thinking through logical abstractions is not a normal state for the human brain. You aren't broken if you can't do that.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Assuming a normal distribution, if you aren't average then you have a 50/50 shot of being either really great or really awful. I'm not a big fan of those odds.

Team Average for life baby.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

How about some advice on dealing with increased workload due to other people not pulling their load?

I was having lunch with my TL the other day and we got into a discussion about making sure that I'm not working myself into a corner where I'm the only person who can support what I'm developing which is totally sane advice. The problem is the only other people around who could support this stuff are myself and him.

We have an entire department dedicated to maintenance (we're a large manufacturing company) who have two employees that are supposed to be the guys who maintain the stuff that we (R&D) develop, but neither of them actually have the skillset and so the company just defaulted to making us both the developers and the support.

I didn't even know these two guys were supposed to be responsible for maintaining this stuff until my TL told me this (prefixed by a sort of ssshhh don't tell anyone I told you this), but now I'm pretty loving irritated that they come in all the time asking for help regarding programming other stuff when we're apparently doing their jobs for them because they just can't hack it.

Is this the kind of thing that is not even worth raising up to management? My TL isn't in the management chain, and is just a really "nice guy" so I'm kinda left wondering why the gently caress he wants me to keep it a secret that two of our employees are apparently trash and increasing the workload of our team instead.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

muon posted:

Yes: don't do their work and also don't snitch on them.

The work just comes back around to us in the form of a work request though. So we're already doing the work. I just didn't know we were doing someone elses work until my TL fessed up to it over lunch. So the only way for me not to do their work is to snitch.

Jaded Burnout posted:

Sounds like Politics. You could raise a request with management for, say, two support people, and act dumb that you already have two.

"Oh, I didn't know they worked on our stuff, we've been doing it all"

If it wasn't a secret that we were doing it already this would be nice.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

muon posted:

How about talking to the people who are supposed to be doing the work first instead of going to management? If they can't do the job, are you capable of training them?

They are genuinely incompetent in regards to their position. I found out about this after being told that I spent too much time supporting requests for fixes or changes to our .NET applications by my manager after being told by my TL that requests for fixes or changes to our .NET applications were the highest priority interrupts. Neither of the guys on the maintenance team who should be supporting it even know what .NET is. So my TL constantly tells me that supporting these requests is the most important part of my job and my manger decided to put in writing that I can only alot 5% of my time to supporting these requests and they both laugh when I tell them that the messages I'm getting are conflicting.

I just need a new job probably if I don't want to deal with this.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

BurntCornMuffin posted:

Pick C#, Java, or literally anything that's not some dumb Silicon Valley vanity scripting language of the month for the sake of your replacement and .

Or pick the trendy Silicon Valley language and then spend the rest of your career there acting smug and bitter when no one else has the time to learn it since every other software base is written in the communal normal language and still needs to be maintained and developed on.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Good Will Hrunting posted:

I don't feel like I'm beyond maybe a high-junior, low-mid in the big data ecosystem at the moment. I haven't done much with the Spark Streaming APIs (or Kafka obviously ) and we're stuck in Hadoop batch flows which is just baffling to me in 2018 given our use case is textbook streaming appropriate. I joined this company because we were going to build a streaming pipeline, and then this mess happened.

I'm going to look for mostly back-end stuff but probably more towards API/microservice work instead of big data. If I stumble across something where they're seeking someone with a very elementary understanding of Spark and Hadoop I'll give it a shot, but it's a pretty niche area.

I'm really interested in getting into this stuff and I think I have some decent use cases for it at work, but I'm not 100%. You have any suggestions for good resources? Every time I try to move into doing research regarding data engineering I feel like I'm just swimming in a sea of buzzwords with no definitions.

For some context I work in manufacturing, we have lots of automated equipment that pumps out a ton of real time data via PLCs to data historians that aggregate it into periodic scorecards and I'm being tasked with building a data warehouse to relate all of this data and coming up with a plan for the next generation of our "data driven" manufacturing processes.

I inherited what is basically an ETL process composed of about 2000 python26 scripts and about 100 MSSQL tables with more trash in them than good data.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

BurntCornMuffin posted:

Make sure a quality tracking and alerting process is an intrinsic part of your design, not an afterthought. If a consumer sees numbers they don't like, they will try to blame you first, and this will give you the evidence to say "no, you're just wrong" or "yes, because our source hosed up" quickly.

Can you expand on these a little? It seems self evident that this should be important, but other than validating that the incoming values are reasonable (ie. not negative length measurements or air speed sensor measurements indicating the end of the world) what other types of tracking are standard when monitoring data streams when you don't have control over the input data?

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

BurntCornMuffin posted:

All I that I stated came from being on the grapevine, and running into these problems. I actually don't feel like much of an expert, there's a lot I don't know. At the same time, being able to write that definitely makes me feel like maybe I'm better than I give myself credit for.

Maybe I should start blogging and writing. Perhaps it'll help make me more compelling as a potential hire, too, especially since I have a few interests that are outside of what I've proven to be capable of in my career, would love to pivot my career towards, and I need something to prove some skill in those interests.

I'd click your ads. The internet is still pretty barren in regards to consolidated information about how to initiate this stuff in the real world. Sounds like a good opportunity to make some cash if you can get the word out.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

What is your favorite/least favorite language to work with and why?

You need to build X product, what technology would you choose to build it with and why?


Basically looking to screen out the "X is better than Y because " type thinkers.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Anyone have any experience with companies that have actual data governance roles? I'm looking into switching jobs from a more traditional role into a position with that title. Had a decent first interview where they said it's about 25% technical / 75% policy/requirements gathering etc...

On one hand I feel like the fact that this company allows that role to exist and doesn't just make it a auxiliary duty of the data engineers or DBAs means they understand the complexity of managing large sets of data which could make it a good job. On the other hand I'm kind of on the fence about moving into a less technical role. Where do you go from that type of position?

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Cancelbot posted:

It's completely illogical and I'm just venting, but I think kids really change your career priorities; my interview questions have shifted from "what tech do you use?" to "can I choose my hours?"

It's not illogical at all. When you have more than yourself to worry about, switching careers effects more than just you.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Volguus posted:

So, don't go there.

You went there.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Good Will Hrunting posted:

Trip report #2: Slightly modified trie algo question. I got and explained my preferred solution (after pointing out the brute force) and coded it up. It compiled and passed the tests but I did need a little assistance at a few points during and it took too long. Overall not terribly hard but I don't expect a call back.

The hardest thing about this one was they were very insistent on prodding me along with the code and pair-ish-programming instead of giving me a sec to write the algo out on paper and draw my trie so I could go from visual -> code.

What kind of positions are you applying for? I've never even heard of a trie.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

asur posted:

It's far more likely that you're working with people who have good CS fundamentals. It's pretty obvious if someone has memorized a solution versus understanding it and that tends to get you rejected. My personal experience, based on two companies who had tribal questions and two companies with algorithm based questions, is that it weeds out the people who can't code, bottom 50, and leaves you with an above average workforce which leads to a much more productive work environment.

Also everyone focuses on the odd questions, about tries, red black trees, whatever, but you're far more likely to get questions around hashmaps, graphs, and generic or binary search trees.

I don't disagree with this outright, but if I went to an interview and you asked me to do something with a trie I'd probably end up saying something stupid like "try what." We wouldn't even be able to advance to the problem solving portion until you drew out the structure for me and told me how it worked. I don't see how using rarely known data structures is anything but a filter for elitists.

I think it's worth focusing on the odd questions because apparently people are asking them.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Good Will Hrunting posted:

It was a word problem just FYI. I deduced that the best way to solve it would be a trie-like structure. Nobody ever said "trie".

Fair enough.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Doctor w-rw-rw- posted:

Huh. I encountered tries in high school, college, open-source, interviews, and at work. I'm finding it hard to digest that they'd be considered esoteric. If I were interviewing, I'd consider not knowing that tries exist a major negative signal, though I'd understand people not recalling them exactly since it wouldn't be terribly rare to not encounter them at work/open-source/interviews. Just learn tries. If you have a mostly-static set of data you want to search through, you can frontload the computation and make searching pretty fast, or even ship the trie from a server to a phone as a sort of search index (depending on the size of the dataset of course).

This is the wrong answer and is exactly what's wrong with interviewing in this field. Good generalized questions need to come from more than your own personal experience. A trie is not in the subset of data structures that the majority of our community has agreed represents basic foundational knowledge. If you don't know this you are a part of the problem. Specifically if you think not knowing what a trie is is a negative signal.

Adbot
ADBOT LOVES YOU

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

Munkeymon posted:

Have the people who've never heard of a Trie heard of a directed acyclic word graph?

A DAG yes.

A directed acyclic word graph, no.


This is a great example of what a generalized concept vs. a specific application looks like in practice though. Graphs are in most/probably all CS curriculum. Every single application of their use are not.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply