steven777400

I don't know much about this case but depending on the level of concern, even just plugging the device into a safe, isolated machine and performing an image may be insufficient.

You could imagine a USB device that presented as a harmless file store unless certain conditions were detected, in which case the device could re-present as a keyboard (providing pre-programmed keystrokes) or potentially a bluetooth or wireless network receiver that could log or analyze traffic to a hidden partition.

I think the question of how to safely analyze suspect USB devices, at the level of potential nation-state actors, needs a lot more consideration and probably some custom tooling.

I appreciate the increasing trend toward openness. I think it benefits everyone to see what's out there.

My journey All USD $ are gross annualized and approximate. No bonuses/stock. Doesn't include employer-paid health or retirement.

2006, Tenured professor at a community college, $43K to $65K

2011, Developer at a state agency, $84K

2013, Development Team Lead, $90K

2017, IT Manager, $100K

I'll agree with you that modern HTML and CSS for presentation is best-of-breed. I'll accept that the DOM API is sufficient.

But neither of those necessitate JavaScript; JS is just a language that happens to run in the browser and has DOM API bindings (and the other browser APIs too). There's no reason those identical bindings couldn't be provided in any other language.

I have to encourage you not to give up on all tech interviews. (By that I think you mean "hands-on"/"practical" type tests).

I do hiring for our agency, which consists entirely of non-rock-stars, at non-rock-star pay, solving non-rock-star problems, in non-rock-star time. We still do practical tests for all interviews. Some people, actually, do just get up and walk out. I wish they'd at least look.

We do problems on the level of "fizz-buzz" or similar. Quick 10-20 minute problems. We don't make full completion a binary success/failure metric. We just want to hear you discuss your thought process and see that you're aware of variables, if statements, and for loops. Because, yeah, turns out some candidates who claim years of programming experience ... aren't.

But no tricks. And we also make sure the request is suitable to the resume (think about it as resume validation). So we wouldn't say "Python person, write a method for us in C#" or vice-versa. Smart people can easily cross-train themselves once the job starts. It's more about finding someone who has the fundamentals and can apply them.

In conclusion, I would defend the hands-on "tech" interview as necessary and not even evil.

Related question: what online sites, if any, are better to purchase items to avoid counterfeit?

I've been thinking of using B&H instead of Amazon for electronic stuff, assuming that their reputation means they are less likely to enable counterfeit sellers, but I don't know that for sure. I also don't know if other online sites (jet.com?) have or don't have the counterfeit issue.

I found very interesting that the sample meal shown was very, very heavily pure meat. Today's meals tend to include substantial "bread"/starch component for each meat: whether a bun, breaded chicken, potatoes. That appears absent or much reduced on this menu.

What I really want is to the ability to optionally select the shipper... UPS, FedEx, USPS, OnTrac, with different prices as needed. I think a lot of people who have trouble with one particular shipping company in their area (which one varies by area) would enjoy the ability to choose the one that is more reliable, and be willing to pay for it.

Sometimes you can catch this in an interview, too, when you ask what happened to the previous person in the position (I always ask this question).

Usually it's simple like "they moved on" or "they were promoted". One time I got an angry, "Well they just couldn't handle it here!" Huge red flag

I agree. Of course, there is a "spin-up" time and we prefer to select the competent candidate with skill in our tools vs the competent candidate with skill in a different tool; but absolutely a competent developer should be able to adapt to any environment.

Interviews can help accommodate this by allowing the candidate to solve a coding test in a language of their choice, while also inquiring about the candidate's learning plans. (Want to make sure they are willing to adapt to the team's tools and not try to force the team to adapt to them!)

I took a job once where the code base was in a FORTRAN-derivative language. I had never used FORTRAN or anything like it. Not a problem. I studied the code. I studied the docs. I figured it out and did the work. I would expect nothing less of any other competent developer.

Another job had a toolchain based on NodeJS on the server-side. Never used NodeJS. Not a problem. Studied the code. Studied the docs. You know the story.

The key skill is a developer's willingness and ability to learn the tools that are desired for the job at hand, and to accept and learn new tools when the time is right.

This is an oversimplification. The average household has several kinds of debt, and generally debt should be paid down in descending order of interest rate.

More significantly, investment income opportunities need to have their interest rate (or equivalent) assessed. For example, in the past 12 months, the DIA has risen 18%. Thus, if 12 months ago I had money to spare, it would have been better to put the money into DIA rather than make an extra principal payment on the mortgage, unless my mortgage is 18% or more.

With the exception of bonds and CDs, it's not possible to know the investment growth in advance, so that creates some risk of course.

Although it could have been coincidence, it does seem like Google is making a statement with the temporary suspension of Peterson's account that these initiatives are clearly targeted at users posted politically incorrect content.

It's possible that a new version could have a breaking policy change. For example, all our intranet apps are served over HTTP. At some point, that's going to become untenable due to the changes for browser security requirements.

In general, there's no momentum to make a change that the agency doesn't "have" to make, and when the browser finally refuses to transmit forms over HTTP then we want to know about it before the change is deployed to all the users.

The login problem was attempted to be solved by Mozilla's "persona", now deprecated. I like the general idea that I strongly authenticate to my browser, which can then "vouch" for me to various sites using cryptographic tokens that are otherwise useless (so no cracking/stealing passwords, etc). The devil of course would be in the details.