Make sure? Well, aside from keeping sh feature subset in my head, I usually run them like "sh myscript.sh" on target or limited environment (they have #!/bin/sh shebang) for testing. Other people here probable have better suggestions though. )
I see AWK as a general-purpose output filter and aggregator, something like a programmable grep. You read another program's output line by line, and output it filtered and/or summarised. Works nice when the format is known, but in case it isn't, error handling and recovery is not something I would enjoy doing in AWK.
Isn't awk that thing that has different versions with entirely different features and syntaxes? I think one of them ships with mac and the other with, uh, everything I've ever used anyway (maybe not *bsd or something). Or was that sed?
I only ever use it on my own systems so awk works fine for me and I use it regularly, but iirc it's not true that you don't have to worry about versions.
Python is where I don't worry about versions. Everyone's got python3 by now (word got round) and most basics, like print(), works just fine in 2.7 (the main py2 backwards compatibility thing I run into is bytes vs unicode strings; if the script needs to work with raw bytes, you'll just need any python3 version). The issue I run into is with Windows people not having python installed, and (worse) not being able to install it in 30 seconds with one command, but that would be the same with awk.
> I've also found that interviews don't tell you much about reality.
Always ask to see code and talk to engineers about what their days look like. I believe there are very few legitimate reasons they won't show you their code, but more likely if they're refusing, it's because they're hiding something. When talking to an engineer, ask them how their code goes from idea to production and have it explained in detail. This will tell you what type of management they have, what testing/review/deployment practices, etc.. As a bonus, I also like to ask my future peers what they don't like about their job or what they'd like to change.
I agree most jobs are some form of shite, but there are good ones. Being more picky during the interview phase should hopefully allow you to find some of those while weeding out the bad quicker.
I don't recall hearing of (non-opensource) proprietary code being shown in an interview. Is that common in some circles?
In a startup, I think I'd have to get an NDA from everyone, even if the code was mindless bulk glue code -- if only to avoid having to later mention that practice to investors who are checking our IP diligence.
Would the following alternative work for you?
In a great engineering environment, people will give sincere answers to questions, or tell you when they can't tell you (because they don't know, or because of business-related conflicts). What about just asking them what their code is like, and see whether their answer sounds like they know what they're talking about, such that that they could give you an accurate answer.
Variation: if they know what they're talking about, but they misrepresented it intentionally, that's a really bad sign from an engineer. And hiring engineers under false pretenses would be a bad idea, as would setting precedent for engineers in that organization intentionally misrepresenting technical information to each other. (That doesn't mean that a dumb organization wouldn't establish an internal culture of dishonesty anyway, but you'll have to filter out the self-destructive and the scammers some other way.)
No, it isn't common. As an engineer you know it doesn't matter if you're shown some code (what are you going to do? memorize it?) and signing an NDA should be a thing anyway if they are concerned about secrets, so what's the worry?
But, if you have any real experience in the industry (rather than making up fake advice which sounds good on the surface) you'll know that few companies will show their code, because there is little to no benefit to them doing so.
I can also argue that is is almost impossible to show code to you for very simple reason: showing couple of files won't make any difference for you anyway and you can't just transfer your codebase to a person. The only thing you can do is to sit candidate to a laptop with the codebase for couple of hours, but I doubt anyone will go that far.
I'd argue that this will absolutely help filter out abysmal codebases made by people who have no idea how to code. I've seen companies like that, I've seen people who don't know how to format code, how to write proper function names in English, hell, I've seen people making Polish comments in an English codebase with grammar errors in their native language. But I agree with other comments, doubt anyone would actually show you code during an interview due to legal reasons.
I haven't seen NDA on interview from many startups in the Boston area. (Which is good, because I minimize the number of NDAs that I sign, and just try to be professional and collegial.)
The first NDA for an interview that I recall was from a big tech company, and most of it could be paraphrased as something like "Everything we tell you is under strict NDA; anything you tell us, we will treat as public domain" (or maybe it was more like nonexclusive license to use; I forget for certain which that particular company said, since I've also seen the latter since).
Later, I think that company reworked it to be more like "Don't tell us anything that could be proprietary to someone else!"
I don't think the company was trying to be malicious; the double-standard is because they don't want you in a position where you violate an NDA, AND they want to make it clear to their staff (the person interviewing you) not to press you for details.
Agree that their later wording is better, but I suspect good intentions from the start
I've signed NDAs for almost all large company I've interviewed at. But for most smaller startups, haven't had this requirement, as the interviews are more casual conversations. (Also, Boston area.)
Depends on your definition of normal. I've interviewed with 10 companies or so over the last 6 months, ranging from FAANG to series B startups, all US based.
One company asked me to sign an NDA, they're a well known public but non-FAANG Boston based company. I didn't have a problem signing it but I also don't really see the point.
I'm sure it depends on industry, but in my industry there is no way showing someone code during an interview would fly. Zero chance.
A programmer who decided on their own to show our code to someone without nda and a confidentiality agreement would be at best severely chastised and no longer trusted with anything important or dismissed.
But, your mileage may vary - every place is different.
Yeah at my firm an interviewer getting access to and sharing code would go further than dismissal and result in unlocking the cages of the attack lawyers. They may or may not be turned loose but that’s def a DEFCON 2 event.
> Always ask to see code and talk to engineers about what their days look like. I believe there are very few legitimate reasons they won't show you their code, but more likely if they're refusing, it's because they're hiding something. When talking to an engineer, ask them how their code goes from idea to production and have it explained in detail.
In an ideal world it makes sense to have a look at the code and understand how the company works from a holistic standpoint. However in reality I doubt that many companies would allow that to happen at interview stage…
I've asked to peruse source code in interviews and some companies have complied. Never hurts to ask.
I usually just throw out the idea to let my interviewer share their screen and navigate the codebase while I ask questions. This way, we don't have to fiddle with repository access and I can get a glimpse of their organizational culture.
Does it really happened like that in the US ? It seems like a total different world.
Here in France, if I ask for something during the interview process with the recruiter, I will get a response like this: "Sorry we don't do that in our process, so goodbye" and they move to the next candidate while I'm out for this job.
> Here in France, if I ask for something during the interview process with the recruiter, I will get a response like this: "Sorry we don't do that in our process, so goodbye" and they move to the next candidate while I'm out for this job?
Eastern Europe, the same. I asked a couple of years ago what are the credentials of the business unit manager, of the line manager and the technical team lead. They almost laughed me away from the building.
Nah, this person is delusional. I don't even know why you'd want to see their code.
I'm sure plenty would explain their processes and how they code, but they're not showing you their code unless it's already public which would be a moot point then.
From central european here. The initial interview usually has been done by a HR person + someone from the department that is hiring. If that went well there was an on-site tour of the department in question, talking with engineers, looking at their projects including source code and workflows. The only time someone refused to show code was when it was owned by a customer.
By "something", I mean something different in the process like in the comment.
If you ask to talk to developer or see some code, or meet the team for a day, you will never have a positive answer. Recruiter will say it's not possible and disqualify you.
Wait, an actual developer/engineer is not conducting the interview ?
To see some code is definitely out of the question, though. But asking about the development process et all I find to be the type of mandatory questions I would ask as a candidate (and expect to be asked as an interviewer) even if I already knew the answer, just because not doing it would be strange.
Judging from sibling comments, this is why you deprioritize or flat out refuse to work on closed source and proprietary software. There are plenty of good companies willing to pay you to work on open source.
> use the probationary period for what it's designed
This is probably fine in an environment where the candidate has lots of other options, but think about this scenario: a person applying to multiple companies, possibly rejecting some offers, possibly relocating or otherwise changing their life, accept that one offer, and then be let go in their first weeks. Changing jobs can be emotionally difficult and being let go even more. If you have to restart your job search, because you were let go during the probation period, all the other roles you have applied to might have been filled. On top of this, contrary to when you were looking for a job last time, now you're actually unemployed and potentially under pressure to find something new.
So, in essence I don't think this is good for candidates.
You obviously can't take the above in a vacuum and think it's fine. You could say the same for the advice of "give people work which resembles what the company does" leading to a situation akin to having interns doing minimum wage work for free, putting pressure on others as a result.
But as things stand, nothing is preventing companies from doing the above anyway. If they think you're a bad fit, they will use the probationary period to cut ties with you. This is perfectly viable today. Your example assumes current filtering methods do in fact increase the ratio of true : false positives, and taking some of them out would decrease that ratio. This is not something that has been proven, and I'd even argue it's something that can't be reasonably proven within the next few years. This is even worse when considering a few interview rounds can only filter for the most obvious dummies, but can't decisively tell you the performance of that individual a few weeks down the line.
What your example does show is how much power employers have over employees. It just isn't healthy for individuals to have to carry this amount of risk while corporates continue to reap the benefits.
GitHub Actions are extremely actively developed and from what I can tell quite strategic. However, the action team's acceptance for outside contributions across all their projects (runner, toolkit, actions) seems surprisingly low for a company that runs a "social" coding service.
The way I understand the author is that he would also be someone who would not be willing to buy another (pricey) adapter, because apple decided to drop support for port x.
This is a weird perspective when all newer Apple laptops use a standardized port which is reasonably well supported by third parties and will be for another 10-20 years.
Right now I'd say the third party power options are better than OEM, even for Apple.
Apple maintained the iPhone 30 pin connector for 10+ years. The Lightning port is 10 years old. Apple supported Thunderbolt for its entire life as a standard. Apple was one of the first to use USB-A and supported it for ~20 years until they switched to USB-C (another standard).
Apple does tend to go all in on a bus, but they don't change them often. You won't find 8 different ports on a Mac to satisfy the previous 4 generations of various connector technologies.
Regardless, if you buy a USB-C powered computer, it doesn't matter a bit what Apple does next year. It's USB-C. Whether Apple changes next year or not, you can still buy cheap/ good third party USB-C charges and they are likely only going to get better.
I think apple has this reputation because even if they keep a port for 10 years, that means 20% of the people get their first apple product within 2 years of the port disappearing
This still makes no sense. USB connectors for smartphones have gone through 3-4 different iterations in that same time depending on the make. If you bought Samsung, you likely went through a year or two with that god-awful USB 3.0 "Micro-B" connector.
My first smartphone was a Palm Pre in 2009 that took a micro USB. I recently (this year) got my first smartphone with a USB-C connector and all of the ones in the interim used micro USB.
As far as computers, I have had USB A on all of the laptops I've ever owned, and gone through 2 display connectors (DVI, and HDMI). The laptop I'm currently typing this on has a VGA connector, should I need it. My wife, who uses macs has had a different display connector for every laptop going back to her G4.
For desktops, I wouldn't be surprised to see a PS/2 connector on the back of my computer, though I haven't looked and I know my second most recent one had a PS/2 connector. Heck, my motherboard has a firewire pin-header, which is absurd because that standard had approximately zero popularity on PCs in the first place!
Apple has much more abrupt changes. I don't think there was a single Mac that shipped with both ADB and USB ports, and it was about a year from the first iMac with USB, and the last Mac Pro with ADB shipping.
This abruptness is possible because Apple controls much more of the ecosystem than anybody does in the PC world. I think I had USB ports on my computer for 3-ish years before I ever used the for anything at all (thumb drives weren't really a thing yet, and I had no need to upgrade my mouse or keyboard). For a long time mice would implement both USB and PS/2 and come with an adapter to let them plug into either.
