In general I try to use exceptions pretty sparingly. There's no reason to throw and catch your own exception. You can just use regular if/else control flow.

In this case I would probably just return 3 states - not a directory, no .txt files found, or success after processing the file list.

I definitely wouldn't worry if they feed more than 1 argument unless there's some legitimate reason that you need to worry about that.

Anything else that causes the app to blow up, just let it blow up.

Messed around with it for a bit. How does this look? Used try-catch only in places where the program would actually throw an error (not sure about the last two catch blocks though) and if-else for program flow.

so, the company I work for(large multinational company) has just announced that there will be layoffs in the next few month. having never been through this before, I was wondering if there are anything that I can do to increase my chances of survival?

But do you even need to catch an exception? The Java container will catch uncaught exceptions and basically spit it out in the console the same way you're doing.

I'm a code minimalist so I'd do this:

Is this app just validating that there are some .txt files and all each of them contain is integers or white space? If so maybe zero .txt files is still a valid state and you could just return number of files validated or something? Like maybe return an object that's num files processed and total sum of contents?

If files not containing integers is a normal part of operations you shouldn't use exceptions to handle that flow - it's just app logic. Exceptions are for stuff like your db server is down, or bad input.

Otherwise, imo just let the system do the work and spit out the exceptions. You're exiting with status code 1, which is exactly what Java is going to do anyway on an uncaught exception (I think).

Maybe once you see an exception and decide it's too cryptic, you can decide to catch it and be more specific. In that case wrap everything in one big try/catch block and look for specific exceptions by type. But that's a lot of cruft just to make your exit a little prettier.

The whole idea with exceptions is they're supposed to just bubble up to the appropriate level - which is determined by the app. You shouldn't be trying to catch and deal with them at every level. You don't want to clutter the code with a bunch of defensive coding for things that shouldn't happen anyway.

Exceptions to this might be if you're writing some app to be consumed by other 3rd party apps - so you need it to be super defensive and explicit. But normally you should just let natural behavior take over unless you have very good reason to do otherwise.

slender,

I agree with suzzer's assessment. I'd probably still null-check and length-check the args, but that's not a big deal.

There's not really any sense in catching exceptions if you can't do something useful with the information--let some other layer (possibly the user themselves) react to it.

Note that sometimes you can do something useful, but not completely handle the problem. An example of this might be some layer logging that an exception happened but re-throwing it. At least the guts of the problem are captured, and it's up to the rest of the application to decide what to do about that.

cybershark,

I rather suspect it's too late. if they're announcing layoffs, they probably already have a good idea of who's going. You probably wouldn't have time to resposition yourself into a non-losable role.

The best thing might be to get your resume up-to-date and see what's out there. Who knows, you might come into something better than "large multinational" and decide to leave anyway.

Make sure they know you want to stay is I think about the best you can do. The last thing your boss wants to do is save you over someone else, then you quit a month later.

If they know you want to stay and still let you go, then you probably didn't have much future there anyway. In that case you may be better off getting thrown back into the job market now - while at least some companies are still hiring.

My company did some layoffs as well. They announced it and alerted everyone within a couple hours but man is that a jarring process.

Sometimes change isn't a bad thing

I spent the last year or so at a startup as a technical co-founder/cto. We were in the applicant tracking space. Things were looking good until covid hit. Once it hit all of our customers and investors dried up. I ended up signing up at toptal to get some temp contract work to tie me over till covid blows over and people start getting hired again.

I end up getting a gig as a data engineer for a company that does marketing/TV ratings data. I start on Monday, Tuesday the VP of engineering (guy who was my boss) quits, Wednesday I'm promoted to Interm VP of engineering. Turns out he had wanted to quit for a while because of family issues, and once we talked for a few days figured they were in good hands with me leading the engineering group so he quit and told them they should promote me.

Place is a pretty big **** show, very little process and tons of data ETL work with very little automation. Absolutely no one of staff with a iota of web experience so instead of building web pages to manage or run things everything was in trello, spreadsheets or run on postman or command line.

So in the last 6 weeks I've hired 2 people, installed, set up and automated Jira, built our first web based user interface so ops people don't have to bother us with simple questions about counts in the database, built a system to track problems, built multiple dashboards for execs to view what ops are doing, pushed out one larger project and about to push out another.

I don't think anyone had worked at a software company before, the place was run as a data consultant more that a software shop, with duct tape and bailing wire all over the place. So I come in, and even though I'm not the greatest software engineer in the world, I look like some sort of savant.

They think I'm the greatest thing since sliced bread and are figuring out how to get me off toptal and just make me a permanent employee and take the interm tag off my title. I have been leading teams of 5-20 people most of the last 10 years so it's not like it's a complete dilbert situation of failing up, but damn it's nice to be on the lucky side of taking a programming job and getting an opportunity to move back to a leadership role and shine.

Suzzer;

I think you are right about the multiple instances of the database. I decided to blow out the entire thing and start over.

I have a file for creating the database and adding the seed data. The table successfully builds and the data is inserted. When I call from the file level, I can retrieve the data; when I call from the route, I get an error saying the table doesn't exist.

Okay, after looking at it more, I saw that the .db file was being built in the models directory after I ran the build scripts, which I wanted.

When I called models/crud.js from routes/index.js a new database file was being created in the root directory, which would be empty. This is obviously not what I wanted.

So, I had to force the system to call the file in the correct directory, and now this is conn.js:

StackOverflow saves the day again: https://stackoverflow.com/questions/...s-with-node-js

Now that you finally having it working, keep in mind that you really shouldn't start the express server until after your db is initialized.

It's just not a good practice to potentially serve requests before your DB is initialized. Especially since crashing and restarting is how node deals with uncaught exceptions and errors.

Heard some update from my manager, it seems like most of the layoffs are going to come from sales and support staff, so we are quite safe.

It’s kinda scary that most of the time you think you are doing quite well, but when you have to think about potientially losing your regular income you realise how screwed you are


Sent from my iPhone using Tapatalk

Its nice to hear a feel-good story. Sometimes it takes a new/outside person to affect change and sometimes there's too much politics with existing people to get things done.

I lost my job and changed to a completely different role (from a pseudo management role to devops) within 6 weeks of being laid off - I think we have a pretty good profession to survive layoffs.

Caveat - I’m talking about california job market. It could be horrible elsewhere.

My understanding from recruiter friends is this market is actually a gold mine for experienced software employees. Lots and lots of senior hiring going on. Absolute abysmal for more junior people.

So I'm applying for a job which first had a take-home assignment and I've made it to the interview round. When I was contacted by their talent acquisition, the person told me that part of the interview will be a discussion about my solution to the assignment. In order for me not to be blindsided, they also sent me the feedback written by the person who reviewed my solution. Most of it I agree with, but there are some parts about that aren't completely black and white and could be argued about. As a random example, it's generally best practice not to use globals/static variables, but at the same time there exist cases where the usage can be justified. These kind of things.

These points of the feedback will undoubtedly come up during the interview and I am wondering how I should conduct myself when clarifying my thoughts on the matter. I don't think coming off as argumentative would help me, but at the other end of the spectrum, instantly giving in and disowning my own approach would give off a pretty insecure vibe.

Those who have been in the same situation, how did you deal with it? Those who have experience in interviewing, how would you expect/prefer the discussion go when it comes to such "grey areas"?

not an engineer (pm) but this seems a lot like how my old company recruited engineers

the idea was there's many ways to skin a cat so it was less about finding an ideal method but more interested in finding out how the candidate communicates and deals with pressure ie don't hire douchebags

they saw your work and regardless of any critiques they may have, in the end they liked it enough to spend time considering you further so i'd lean more towards it being "let's see how he deals with this"

definitely come armed with evidence supporting your position but if they resist keep it super friendly, they'd rather hire someone who will do it the wrong way that they happen to do it - elon musk was removed as ceo of paypal because he disagreed over what frameworks to use - he may have been right, but there's many ways to skin a cat and they want pleasant people who can all operate on the same page

good luck

I'd say not defending your approach, but letting them understand your thought process.

Also, make sure to ask them about their approach, and show interest into getting into the details of why they like that approach better.

In other words, neither that either side is right, but "let's discuss the pros and cons of either way."

Maybe it demonstrably is, and you'll learn something new. Maybe they're horrid idiots who hard-code things, and you'll learn that you don't want to work with them.

gd phrased it much better than I

I've never had success convincing an interviewer that my way was better than the one they had in mind. Not once. I failed every interview where I tried that. I don't do it anymore. When it's clear from their body language that they have another approach in mind, I change gears immediately.

I interviewed for a Technical Account Manager at AWS. I've been running servers for 20 years and worked on some of the biggest websites in the country as well as have multiple years being a CTO and running large teams. I was overqualified for the job and they needed to hire a few thousand TAMs at that time.

I was interviewed from 8am to 6pm and even lunch was an interview.
I was beat by the time the 5pm one started. He was the TAM manager in Dallas, so while I wouldn't be working for him, he'd be my boss if my boss was on vacation.

All of the other interviews were in person, and this one was on a video chat and I was having a hard time understanding him.

He asked me for an example where I stood up to authority. Luckily for me I had a buddy that worked at amazon and gave me the list of questions and I had stories ready for them so I told him a story. He said that wasn't good enough, tell me a better story, so I tell my second story. He says now tell me a better one.

So I tell him the story of a few companies and a few years ago where I was the CTO and our CEO and board continuously asked me why we weren't on AWS. I explained we had already bought servers and the rack was $2000 a month where AWS was going to be $20,000 a month. In addition we had done a ton of testing and were not able to get AWS to be as fast as the servers we had, mainly due to being able to put our entire database in memory on iron where we could not at that time due to AWS having a memory limit below our database size.

The guy goes ****ing nuts. "IT'S IMPOSSIBLE FOR IRON TO BE FASTER THAN AWS, YOU GUYS ARE IDIOTS AND DIDN'T KNOW WHAT YOU WERE DOING"

I replied that yes for scaling and having lots of users AWS will probably always be better than iron, but for a company with less than 1000 users, who's users are doing large queries over a large database that we could get into mysql cluster on iron that was not possible to get into AWS at that time, iron is faster"

Him: "YOU DON'T KNOW WHAT YOU'RE TALKING ABOUT. AWS IS ALWAYS FASTER THAN IRON"

Me: "So 10 years ago when I bought a server for $20k that ran at 3Ghz and had 64Gb of memory and was pretty much the fastest server available at the time and the fastest EC2 box at AWS was around 2Ghz and 32Gb of memory and has a hypervisor on top of the OS and other customers running on it as well, that server is going to be faster than the one I have that is dedicated to me?"

Him: "Yes, it is impossible for an iron server to be faster than AWS"

I just bit my tongue at that point, realizing I probably shouldn't work at a place like that, which is funny because at amazon you're supposed to question everything, but I guess you can't question AWS server speed.

I ended up not getting an offer and later found out I got 8 high ratings and one low rating/blackball on the interview team. Everyone thought I was great except the last guy.

A year later I got an email saying "we ****ed up the interview process and would like to make you an offer to be a TAM" and I never replied

Showed the email to my boss and got a promotion and raise the following week. So my advice, there are some things you probably don't want to argue about at an interview. Pick your battles wisely.

I had a similar thing happen at Micron where every person gave me the highest ratings and one person rated me "do not hire." That one person was a miserable SOB that had no idea wtf he was talking about and I (tactfully, at least I thought) let him know he was wrong about several things.

IMO needing unanimous approval in order to hire is flawed, at least in some situations.

This one person also asked me to draw the HW block diagram for the product I was working on (for a direct competitor no less) on the whiteboard during the interview. I laughed in his face. I guess I should have reported it to his manager.

Thanks for the substantive replies. Discussing my rationale while conceding that theirs is also viable seems like the way to go. Since I will be interviewed by three leads, there's definitely an aspect of me feeling somewhat inadequate compared to them and therefore thinking that maybe I should just agree with them.

I posted this in the “Things that shouldn't piss you off, but do.” Thread in OTT, but it may be appreciated here.

Phoned up to report a problem with a delivery. Going through phone menus the recorded message said “Press 1 for yes or ....”
I immediately pressed “0” for “No”, and got the response “Invalid reply, press 1 for yes or 2 for no”

What kind of ****ed up Boolean algebra were these people taught?

It's actually an excellent kind of ****ed up Boolean algebra.

Computers talk to each other through a bunch of 1s & 0s. Among these 1s & 0s are check numbers that let the receiver know something ain't right, namely that there are flipped bits. When something ain't right in the stream of bits, it is either fixed or rejected by the receiver.

Well, you may ask, why doesn't the sender, receiver, and the entire infrastructure do a better job of sending these 1s & 0s? They do the best they can, but there is this pesky thing called "The Laws of Physics."