As a college student, 1. is the one that worries the most. Automatic filtering is scary, and there's no way to test how these ATS systems are viewing my resume.
Difficult when you're an immigrant. I moved to Canada for this reason, and though the tech scene is great here (Toronto at least), it sucks how everyone here talks about how "terrible" the tech scene is wants to move to SF instead. Feels like a never ending cycle.
People will always find things to complain about. Toronto isn't SF when it comes to tech (nowhere is), but it still has plenty of opportunity. Don't listen to the complainers. Just focus on becoming a good SWE for now, then worry about maximizing your earnings.
Automatic filtering is annoying, but there are plenty of tools that will scan your resume and tell you what keywords they find. I once spent weeks crafting a catchy looking resume with a fixed width font and ascii art. It didn't get any responses, and I didn't understand why until I put it through one of these scanners and realized that the program I had used to save the PDF had strangely encoded all of the text in reverse, so I wasn't passing any of the automatic filters. The takeaway: test your resume with a scanner!
It sounds like you could have just opened the PDF that was generated to double-check it too. Sending off a derivative file without proofing seems like a big YOLO move to me
A lot of these scanners went down a few months ago when one of the API services (not sure which) stopped working, but if you have a newer link please do send!
There is software out there for optimizing resumes to ATS. It basically is keyword matching. One tool will allow you to paste the Job Description and your Resume. You can give it a URL, and they'll detect ATS type, and give you further recommendations for file formats and things.
In any case, it's like an arm race for SEO. What was once a useful measure will lose meaning as everyone adopts these tools.
If you're a college student, you should be single minded on having at least one (and ideally two, since the first will be lower caliber) internships under your belt. This will get you past every single new grad filter screen. If you can do this and handle junior dev algorithm questions, you will have plenty of new grad offers.
Also, if you are even vaguely talking to a recruiter (e.g. via career fair) then they are not going to screen you using an automated system.
You are still quite young, it doesn't hurt to take 1-2 years to build your experience in this industry before going to top companies. And believe, they are not that picky.
When you are a college student, it is really hard to distinguish yourself from your peers, unless you are truly outstanding, otherwise most resumes look likes clones to each other.
Yes, tech hiring is entirely broken. I’ve had so many interviews and have been turned down a lot. It sucks but you can’t take it personal. You have to realize interviewers are dealing with time shortages, incomplete information and therefore looking for cues you’re a good fit. Most of those boil down to personality.
Whenever I start interviewing, it takes a few fails before I finally realize: my talents are not (at all) what interviewers care about. Talent is just the icing on the cake. Once I remember that, I focus on being personable and start getting multiple offers. It’s always been like that.
Not enough full stack developers with 10 years of experience willing to work for 75k, “possible equity”, and catered lunches on a “fast-paced high-growth” project that just completed a series A. (actually saw this description)
I feel like this is largely a myth propagated by business. If you feel powerless to control things like your pay or work life balance, then they control it by default. I found once I learned to set boundaries in my personal life that doing it at work was easy because I don’t have to care about an employer’s feelings and my income skyrocketed.
I moved from a 2/5 to a 4.5/5. Doesn't mean it was necessarily a satisfying move. There's 6 - great mission and product, which the first one had and the new job is weak in, but it factors for a lot more than the other 5 in attractiveness of the job, at least for me
Yes! But that isn't something that all (or even most?) companies have full control over.
Most people aren't going to be passionate about building, oh, I dunno, software for insurance companies, but it still needs to get done. There might be a handful of "disruptive" companies doing something in the space, but 99% aren't.
There's a lot more "boring" software (even in the startup world) that needs to be built than anything else. The problem is really that these companies don't seem to be self-aware and they don't adjust #1-#5 (especially #1) accordingly.
That's the thing, it is something companies have control over, if they have a dynamic and passionate CEO, and are willing to take on risk. Or at least, if it's a big established company, create pockets where groups are able to work on entirely new initiatives.
This. I never understood The attractiveness of working for Facebook, Twitter, Netflix, etc. other then money. How is the Dev work there helping society at large?
Once, I got approached for a job at Amazon to help "build the next big e-billing system"... What an uninspiring thing to do.
It depends on whether you care about the overall product or just the puzzles involved in the product.
I get my overall high level fix from outside of work activities, so work is enjoyable mostly for the little puzzles it generates every day. I am sure that there are some fascinating considerations for a mega e-billing system, even if it isn't all that interesting in itself.
I care little about what the product/impact is and mostly care about how interesting the work is on a technical level. I am pretty fond of theoretical research even when practical usage is very unlikely and did a math major mostly for fun. One thing the companies you listed share is large amounts of data and as I work in ML having large datasets is really nice to play with. Also large tech companies tend to have better data infrastructure and more time can be spent focused on ml tasks vs data engineering tasks. What the model actually does is of little interest to me and I've worked in a couple different ml areas now.
I do have an eventual interest to do research focused role, but interesting impactful research I think requires either high management (professor leading a large lab/research director) or making your own thing. The first I lack the experience for and the second doing a startup feels too risky to me today. If I was wealthy enough I would probably try making a research themed ai startup.
"""
You should not be testing people’s ability to recall some obscure definition in an interview. You should be testing people’s ability to tackle something they can’t recall off the top of their head. And, you should allow them every tool they have available.
If they’re totally unfamiliar with the problem, and yet they make significant progress in just one hour that should be interpreted as a good sign this person would provide a lot of value to your company
"""
I think this is extremely important. A developer that can make a lot of progress on something they haven't seen before is often times just as good as a developer who can tell you the big-O efficiency of reversing a red-black tree off the top of their head. Although the latter may indicate a very interested systems-level hobbyist, which is also an excellent value in terms of an engineering quality but impossible to tell from a whiteboard interview if they're a hobbyist or if they just studied.
Just as a counter point, developers that have such a knowledge about algorithms and efficiency tend to be able to sort through different possibilities and branches investigation for new problems much quicker than a developer that has to look up everything on the way. Although that's something that can just come from experience too.
I can't tell during my limited time in an interview if a developer has that knowledge because they crammed (and therefore will forget quickly on the job) or if they actually study and understand this stuff.
I can tell during my limited time in an interview if a developer is capable of making logical deductions and not flail when exposed to a problem they may not have seen before. And, better yet, if they do study algos for fun, this will become apparent!
Honest question: just how often do you actually need to worry about algorithms in your day to day work? The vast majority of software dev, even/especially in hot startups and the like, is bog-standard CRUD and 99.9% of the time the correct response to "I need to do something slightly complicated" is "call an existing library function".
I mean, this is the whole point of the dreaded coding whiteboard interview, no? You can't memorize your way out of it, and with any luck the interviewer will be looking at the big picture of how you tackle the problem and what headway you make, instead of sniping at syntax or the names of library calls.
I would also be interested in this, but it's also something simply crammable. It's impossible to know from a limited interview time just from trivia whether or not someone just crams last minute.
I'm more interested in knowing if they can debug something nasty or opaque with patience and using deduction instead of flailing. Chances are the person who can do this might also be able to explain why a red-black tree inversion is a certain O-notation, but its not strictly necessary.
But I have a story myself: A certain company that is probably in the top100 biggest of the world, one time attempted to hire me, but their hiring process was a mess and they forgot me in the middle.
Then I noticed they kept complaining on media about not finding anyone for that job. 2 YEARS later, after they posted another complaint, I decided to apply again, and even mentioned the previous hiring process.
The HR department said they were sorry, explained that the previous time it was a contractor and they were bad at their job and got fired. So I thought this time I would get hired.
Went through their entire process... and then HR sent me a sad letter, that the headquarters in the company home country, blocked my hire because it would violate policy.
The policy in question, is that for that job, people needed experience. But also, they needed a local. But... they were the first company offering that particular job in the country, ever. So you have this company trying to be the first company to hire for a particular job in the country, but wants someone with experience, complaining endlessy about it on the media. I felt bad for the employees that were dealing with that bullshit.
(the job in question was Game Producer, I have a bachelor degree for it, but back then this company was the only company in the country with such job opening. Some other game companies DID exist in the country but all of them imported producers from their other studios, so for example there was some french and canadian producers in the country)
I literally can’t relate to this on any level. I’m an HM at a company that pays on the order of a FANG and at best matches one of these credentialist barriers and yet we can’t come close to hiring targets on devs.
I don’t get how people can see the plethora of individuals under 10yrs experience in SWE and other tech roles in SV/NYC/SEA with incomes of $250-600k/yr and think this happens without a “shortage” of talent.
Shortage in quotes because it’s hard to define in context of supply/demand but it’s clearly the case that devs have a lot of bargaining power.
I think the author is talking about pretty large, well-known companies (e.g., FAANG -- see his first point). Many people applying to these well-known companies are auto-filtered by resume software, which artificially decreases supply.
Small and mid-size companies have a different problem: people haven't heard of them and don't know to apply. My company is in this situation. We have a good culture, I think, and pay very well but people don't know about us or don't think of us as a "tech" company, even though we do quite a bit of innovative software development.
Personally, I’d happily accept being a lifeless drone, at least for a few years. Save the extra income and invest it. Reap the dividends.
Having said that, I don’t know how bad those roles actually are. Obviously, it’s not worth it if it affects your mental health… and unfortunately yeah, that is an issue working in this field.
The difference between both taxes and the "next in line" isn't large enough.
Hedge funds pay as much as Google/Facebook, but work and life balance at SV companies is much better.
Compare my two offers from a few years ago - well known hedge fund in CT vs a food delivery tech company.
Well known hedge fund paid $250k+50k bonus for expected minimum 50hour weeks and 20 days of vacation time.
Food delivery company offered $170k+200k in stock over 4 years for 6 hour work days in a relaxed environment and unlimited PTO.
It's at the point that it's not worth the money. Sure it's about $3k extra monthly income.... and if you're not burdened with student debt, it's not a game changer.
They are the minority with a VERY small staff, compared to most others. (Also HRT engineers work a lot, not leasurely 40 hours per week)
Pointing to extreme outliers is not giving your opinion much credence. Because I can point to some people who work in crypto, that earn $600k+ without breaking a sweat - in Singapore with Singaporean taxes(which blows HRT salaries with US taxes out of the water)
Is this auto filtering happening at the senior level for FAANG? Amazon keeps reaching out to me (a junior who already failed one of their interviews) on LinkedIn. Google did as well at one point.
If I am somehow worth personal attention as a not terribly impressively pedigreed and inexperienced developer, are they really dumping seniors through crappy filtering software and missing them there?
The stakes are lower. As a CTO (hypothetically) I get to hire 4 junior devs, 2 senior, and 1 architect.
Hire the wrong junior? No biggy, he'll be less effecient but we may yet turn him around. Anyway, I get three more tries. Anyway, he'll leave after 2 years. They always do.
Hire the wrong architect? I'm stuck with him, for a very long time. Moreover, I now have the wrong guy for a high-impact job. And one that is very visible.
So you betcha I'm going to be much more picky, the more senior the job becomes.
Except none of his points apply to FAANG companies either.
>A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
FAANG companies do not interview like this. I've done interviews with most of them twice in the last 5 years and all questions are the typical algo stuff.
Then his whole rant about credentials... I am a self-taught dev with no degree, none of my interviewers ever cared about that. Every interview is about whether or not you can solve the algo question.
> I think the author is talking about pretty large, well-known companies (e.g., FAANG -- see his first point).
Except almost nothing outside of some amount of resume filtering fits his points. Seriously, go to levels.fyi and look at the pay of the FANGs (ex. Amazon). You think his bad pay point is a problem for them?
Hiring at these companies is very different from the bad examples described here, except for the indexing on degrees (if you don't have extensive experience you're not getting hired without a degree). They don't test trivia and don't typically look for "X years experience with Y framework". I remember seeing that in lots of smaller, lower paying companies' job postings on websites like Indeed but I've never seen that at a big bay area tech company unless it's something sufficiently broad like "infrastructure" or "frontend"
The difference is that big tech companies aren't meant to be applied to over the internet. Seriously, it's like throwing your resume into a black hole. Referrals are the same way, honestly. The only good way to get hired is to get a recruiter to message you on Linkedin. I have never got an interview at these companies from applying on their websites and have made it to the first round of interviews every time if I was contacted by a recruiter.
And because of that, it should be no surprise that nobody is scouring the internet to find your company and send in an application on your company's website. Everybody has been conditioned for that to essentially not work. Even though it's expensive you really should be paying third or even first party recruiters.
If you accept non-US people, tell me what company you work for so I can send my resume.
Because all the issues the guy pointed out I am on receiving end of them right now.
And although I've been in leadership roles before and started programming when I was 6 years old (my dad taught me), I started lately to see if sending my applications to junior developer roles will get me any replies (people don't even tell me they got my application, except the occasional robot).
I'm pseudonymous for a reason but here's a list of companies, none of which I am employed at, that have similar pay and issues with staffing:
Uber, Doordash, Asana, AirBnB, Pinterest, LinkedIn and literally so many more. Especially if you are willing to accept mature but not yet liquid equity and then there's Stripe, Airtable, Robinhood and so many more.
Post your resume. Tried to go to your personal website but it wouldn't load.
I was a professional game designer (still a designer, but more a hobbyist now) with extensive (>10 years) game, mobile, full stack web and enterprise development experience, and all of that is current, as I'm developing games, including mobile games, in my spare time. It's very possible to do both.
From the hiring manager perspective it’s a numbers game of time and risk mitigation. Firing people sucks; managing people out sucks. Not firing people that should be fired sucks. Unless you’re in a big company with centralized hiring and onboarding, having headcount that needs an expensive ramp up period sucks.
If you’ve done a lot of different things because you’re smart and creative, maybe I’ll have to spend more time making sure you’re motivated (so you’d have to be worth the extra time cost). It’s also common to see people with an ungrounded perception of their abilities, and I often see breadth-heavy people suffer from an inflated sense of their own abilities due to lots of small scale, diverse wins.
Most people don’t understand how valuable a hard worker who will agreeably take orders and deliver consistent results is; magnitude doesn’t even matter that much. Unless you’re single handedly driving significant business metrics (e.g., directly saving millions of dollars), from my perspective, my job success is tied to predicting your output. If I succeed, I get to expand the teams or build new ones. If a product release is late or buggy, it’s also wasting tons of other teams’ time or damaging customer relationships besides pushing the eng roadmap back.
We reject a bunch of faang people for having experience we don’t find valuable. If you work at a big tech company, but don’t have an impactful role, you’re potentially not going to succeed in a small startup at the level you’re demanding.
Finally, one bad hire can ruin a team (i.e., one bad hire converts others into bad hires). “Bad” is subjective and can refer to different things. At the end of the day, it’s my job to define it and make sure we’re avoiding it. You can ask about this in an initial phone screen, or in a follow up conversation because it’s not secret, but I can’t talk to you about it after we reject you due to lability.
I’ve interviewed with many of those listed. They’re not struggling for talent. They all have a very high hiring bar. I’ve seen them reject many people (besides myself) on trivia and whether or not you studied the right set of problems on LC.
For instance, could you regurgitate topological sort out in less than 20 minutes to solve a problem? You forgot the implementation but generally know what it’s used for? Failure. You’re a failure. Even if you know how to solve the problems but get tripped up on some simple parts of the algorithm because you haven’t really studied or used it in years, failure. Same with system design type interviews and other stuff.
The bar is very high for people who will never use any of that work. It’s hazing.
If your place pays FANG ish and allows full remote (as Facebook does) feel free to hit me up. Preparing final round at facebook but it's a crapshoot (philosophecles0@gmail.com)
Me neither. Every single point the author makes does not match my (or any other dev I know) experience. The only explanation is the guy is in a really bad tech market, in which case, move.
As a perfectly competent dev having immense difficulty getting anyone to consider me for any position, I cannot see this as anything other than false.
I have a job now (and by all accounts my employer is really happy with me), but the interview gauntlet I had to run to get here was absolutely ridiculous.
Then it seems like your replying to me with your experience not matching isn’t very reasonable, eh? I’m being very explicit about the US SV/NYC/SEA experience.
Paying that much for a tech worker doesn't mean there is a shortage of them, it means FANG companies are gambling on "rockstars" to try get an edge.
Flood the market with very good but not exceptional workers, and the top salaries won't change much.
Flood the market with exceptional workers and it probably won't change much either, FANG will just be even more selective with their top salaries.
Top devs have a lot of bargaining power not because companies need some "X amount" of development work done but can't find anybody who will do it. They have bargaining power because those companies are competing against one another and they're hoping the next billion dollar idea will come from one of _their_ employees first.
If you aren't playing this kind of roulette, I don't understand why you would try to compete in the same job markets. You can get developers for far less. And yes that may mean moving elsewhere, SV is obviously heavily selecting for such developers (people who can get those salaries will tend to move there, those who can't will tend to be pushed out).
If you are playing in that space but you just can't afford to pay for its inputs then it doesn't automatically mean those inputs are in a state of shortage, sometimes it just means your business does not create enough value to to pay for said inputs. This is the market's way of telling you to fold. Capitalism is a harsh mistress.
> If you aren't playing this kind of roulette, I don't understand why you would try to compete in the same job markets.
Ever since Blockbuster failed dramatically, large brick and mortar company execs are worried that SV will take their market. And, for good reasons too, I'd say. Software is eating the world etc.
Well that would be the expected outcome, no? The author claims a problem exists in hiring and sets out articulate what that problem is. If the problem exists, then as a hiring manager, it's a good bet that you are, at some level, involved with that problem. For your stance/perspective to lie anywhere from a harsh opposing view to merely unable to unable to endorse the author's perspective ("what is water?") would be unsurprising.
(Note that this is true just as a matter of logical consistency and is not particular in any way to hiring itself; try replacing "hiring" here with "skub" and it's still true.)
Because the shortage is self induced. First of all you mentioned only super expensive locations. I would need 600k in SV to equal the mediocrity I enjoy in Texas. So while that sounds like an insanely huge number it doesn’t really say anything.
Second, at this point in my career developers at large companies aren’t expected to write code. Save that for startups. Instead developers are expected to debug things and string tools together like a homemade necklace. If you are an established company and want somebody to write original code you have a lot extra work to do to ensure a good cultural fit.
I've mentioned this on HN before, but I have 10+ years experience, a BS in CS from a top 10 school, worked as SWE at Google for over 3 years, I've done 100+ leetcode questions, studied grokking the systems interview/designing data intensive applications, I live in the Bay Area, and I've _still_ failed 90% of my onsites last few years at the top tech companies (Stripe, Lyft, AirBnB, Square, Dropbox, etc).
Reasons for failure vary, you don't get much feedback but when I've gotten it it's been distributed across coding/systems/behavioral.
I've also been rejected at resume round by companies like Instacart and Coinbase.
The interview bar has gotten insanely high it seems. And I left Google way back without anything lined up assuming in this job market I could waltz into a good job with some modest prep but that has not been the case.
I objectively have top credentials, and I find tech interviewing an absolute nightmare. The standards have gone through the roof and one slip up and you get dinged. And the system is way more arbitrary and subjective than anyone admits.
Now, this isn't a woe-is-me story becasue to your point, there's a lot of companies paying top dollar and I have a decently paid job. Furthermore, I'm not failing interviews at random startups but as senior engineer at top companies that would probably offer $400k if they made an offer. They have the right to be extremely picky and subjective, but let's at least admit that they _are_ extremely picky and subjective.
The "I'm a HM and can't hit dev targets", reeks of ignorance as to your own process. I wonder if you do things like tell your interviewers "a false negative is better than a false positive" ? Or let one interviewer use some arbitrary criteria to dock a candidate and then pass on them because of one bad score? Because you probably do lack perspective on how many good devs your company is rejecting if you're only sitting on the HM chair and not seeing what it feels like to go through these rounds as an IC SWE.
> The interview bar has gotten insanely high it seems.
Software developers are starting to commonly earn doctor-like salaries. Doctors typically burn ~12-15 years between school and residency before they start getting paid serious salaries.
A top 20%-30% software developer can be earning $150k in their mid to late 20s, outside of the Bay Area.
It's no surprise that the hurdles are going up for such high compensation. Software devs in the US as a mass employment field (1.5m people) are the best paid large group of people in world history. Combined wages (not total compensation, that's far higher) for the 1.5 million software devs in the US is in the neighborhood of $215 to $250 billion per year. It's doubtful anything like this concentration of huge globally important industry dominance + very high pay will ever been seen again anywhere else in the world, it's an outlier economically to put it mildly. Enjoy it while it lasts.
I agree to the extent that it might not last and "make hay while the sun shines."
At the same time, I disagree it's that unprecedented. There's about as many lawyers as software developers and the compensation distribution is surprisingly similar (including some bimodal aspects). Yeah they put in 3 years and took some debt but it's not that significant big picture, many CS students get an MS.
There's a lot of doctors in my family. It used to be a gold mine field and now it's much less so, as hospitals have a lot more power over the doctors than they used to.
If you want a really good bang for your buck, look at salaries for nurses who get some specialization like CRNAs, who can make similar money to SWEs, with about 2 years extra school work.
I mostly agree we're in a golden age of software engineering compensation and as I mentioned in my first post, these companies have a right to be picky. Still, to some extent I think engineers of all stripes were relatively underpaid relatively to some other white collar professions historically and its just been catching up a bit.
Interviewing is a skill of itself for sure. Random offer, if you want to get some honest no-consequence feedback dm me and we’ll do a mock interview. Have hired a lot of people and want to pay it forward for all the people o have rejected not because they err bad but because I was bad at interviewing. Send me a message.
This seems like the most relevant anecdote in this thread. When I talk to friends about how they interview, it’s never about skills. Some say they’re not actually hiring, but they interview experts for free advice. If they are desperate, they hire for exact experience. I don’t know who out there is hiring new grads at giant salaries for Leetcode skills, but I think they’re mostly looking for impressionable followers.
Employees don't seem to have enough bargaining power to meaningfully control working conditions, though. Maybe these are worth a ton of money to the company, or such desires are an outlier. But here is my experience:
I'm a professor of computer science, and frequently get recruiters trying to get me to jump ship to industry. I'm open to it in principle. I'm reasonably happy in my job, but there are certainly things I don't like about academia, and the pay is not industry-level. But it's generally a rewarding job, and has various perks, like private offices and considerable control over your own schedule.
A question I ask recruiters: I have a private office... could you match that? So far, the answer has always been no. They can double or occasionally triple my salary, but they can't offer me a private office. I am not sure what to make of that. They are willing to offer me $100k+ over my current salary, but are absolutely unable to offer me an office with a door.
> They can double or occasionally triple my salary, but they can't offer me a private office.
You might have more luck if instead you asked about working remotely full-time. It's not the same if you want to go into an office, but companies are seriously thinking about their post-covid office plans.
True, that's an interesting possibility with the current trend towards remote work. With enough of a pay raise, I could solve the private office problem by just renting the office myself out-of-pocket...
The hiring managers don't have that power. Not sure if you have done an interview loop but I assume that as a tenure track/tenured professor you're going to be L6+ individual contributor in a research group. In that interview loop you're probably going to have a decent amount of face time with a director level or VP. IMO if you're actually interested in making the jump the right play is to get the job, and then negotiate the office with the director/vp that you'd be reporting to, they will 99% of the time not let office access be something that stops them from hiring a staff+ engineer. Feel free to ping me directly if you want to ask more questions.
I've had similar experiences with desks, even though desks are a much easier problem to solve than 4 walls that make an office. $200 at IKEA would do it. And yet it's still an unsolvable problem to many companies. Desks have been the main reason I quit two of my past ten jobs.
One was at a euro stoxx 50 telco. They had a desk with a single plate that 10 people sat at. I had to sit with the project team I was working with who, unfortunately, weren't all the same height. But the plate could only be adjusted to one height for everyone which was way too low for me. Every day at the office, it felt like working at a coffee table and my back and knees hurt like crazy. I was fighting the corporate system for half a year, including making a fool of myself in front of the global director of human resources and company medical officer. This was ultimately unsuccessful as I was a freelancer, not an employee, and earned me the scorn of my direct manager. The whole experience was so undignified and humiliating that it was ultimately one of the main reasons I quit that gig. After all I was just trying not to have to endure physical pain.
The other occasion was at a well-known Wall Street investment bank back in 2010. They put the computers in the space under the desk that should normally be legroom and every day at the office felt like a long haul flight in economy class.
My boss's boss, a partner at that firm, privately owned a floor in a highrise residential building in Tribeca. Yet, during the work week, he still basically never got to see daylight. Our business unit wasn't high enough in status to be able to swing a work area on the outside of the building that had daylight. He had an office but still no privacy. One of the walls of his office, facing his underlings' open plan space, was made of glass. Glass walls is something that these firms do these days even for very high-ranking executives to create witnesses in cases of allegations around what may or may not be happening behind those walls between colleagues of opposite gender (or preempt those kinds of goings-on or allegations).
Grad students and postdocs seem like a fairly untapped source for tech recruiting, especially outside of the CS department. Physics, neuroscience, econ, biology, and many other fields now involve lots of programming and data analysis, sometimes under demanding conditions (real-time or huge, noisy data sets). Many of the people are smart and highly-motivated, but making a tenth of the numbers you quoted (and with rubbish job security to boot). It should be like shooting fish in a barrel.
And yet.... they don't seem to be on many company's radars. I'm the only one in my group who is ever contacted by recruiters, and it's an undergrad CS degree.
Yes, you'll have to screen to figure who tweaks "the script that gives the numbers" and who's more like a developer. Recruiters might need to put in a little legwork to figure out how different kinds of researchers map onto open reqs. You might want to somehow prep non-traditional candidates for a developer interview, or figure out an on-boarding track. But you can afford a whole heck of a lot of that if a $250k/year job is sitting open.
From talking with my PhD and MS friends, it's mainly about time. PhDs work around 40-60 hours a week. Full time MS students are juggling courses, research, and part time work, also around 40 hours a week. That usually leaves little time and energy to apply for jobs and practice interviewing.
As a terminal MS student, most of the interviews and offers I've gotten were from professor recommendations to their industry colleagues. I researched computational linguistics and dynamical systems in my undergrad, and in grad school I researched HPC and distributed systems. I still interview poorly because I don't invest enough time practicing/applying compared to reading papers or doing grad student grunt work. On paper, having an MS can also be a negative signal.
Another broken thing is LeetCode style of programming exercises asked for a job asking 15+ yrs of experience. Not saying we do not solve complex stuff on a day to day basis, but foundational problems are already solved & we have patterns/solutions/libraries available. We do not do DFS/BFS on a day to day. We do have Stackoverflow, Google to figure things out.
FAANG companies - filtering candidates by asking tough LeetCode questions, which is understandable. But what is with Startups? If someone can solve hard LeetCode problems why would they join Startups? They will join FAANG. Startups are blindly copying FAANG before becoming FAANG themselves.
I don't like leetcode either, beyond some very simple problems to demonstrate basic proficiency[0], but if you're going to force poor junior developers to do them, it's only fair that seniors suffer the same process. If it's only an expectation for junior developers then it's just an advanced form of hazing.
[0] on the level of "here's a list of strings that are names in Lastname, Firstname format, turn them into a list of Firstname Lastname", or something dead simple that's designed to definitively rule candidates out
> FAANG companies - filtering candidates by asking tough LeetCode questions, which is understandable
Not sure that I agree it is understandable but I definitely am glad they make this bad decision. I dodged the bullet on interviewing with a FAANG and failing on one question (the recruiter told me it was the answer on a single question that kept me from getting an offer) after doing an onsite in SV.
I did not know what I was worth and would've felt compelled to accept an offer that would've been 30-50% less than I could command at the time and I would've had to move somewhere with 4-5x the cost of a home than where I live now. I didn't get that offer, and after a little bit more time I got an offer somewhere where I earn 2-3x as much as I originally said I was worth to the FAANG (based on places like glassdoor, etc.).
The culture is better, I can work wherever and whenever I want, and would have to go out of my way to not make impactful decisions that go to prod for millions of customers multiple times a week. It'd take 2-4x my base salary to get me to walk, which I could possibly command, but I don't feel any desire to look because I didn't fall into the FAANG trap and enter a cycle of pretending consultants selling quiz books know what software engineering is and jumping to be able to survive in SV.
I messed up something on a whiteboard with an apathetic interviewer about a special tree inversion or something - who gives a shit - and I have been extremely happy that happened every day since.
I great many salient points. I've been a hiring manager for many years now, and in the last few years a candidate twice so I've had recent exposure to the 'current trends'. It's difficult to strike a good balance between filtering for candidates that will be a good fit, and missing out on ones that would be great, but don't fall into the job description square box. I also wrote some comments on this problem last year https://www.linkedin.com/pulse/thoughts-hiring-engineers-rob...
> The general rudeness is ridiculous. I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
> This experience is fairly common.
Is it? I've done a fair bit of interviewing on both sides of the table, and can say with complete honesty I've never heard a curse said in anger in any of them. I've also never heard of it happening from a co-worker or friend.
Yeah this sounds more like a crazy anecdote to me. I once had a new CTO come in at a place I’d been working at for about a year and a half, and he refused to interview any candidates that weren’t Muslim (as existing staff were replaced 1 at a time). While this is extremely fucked up, I would be surprised if I could find another tech company in the state where this happened. Cursing at someone for having experience in Rust sounds…similarly absurd albeit more benign
I was surprised to learn that in Northern Ireland, you are legally required to ask candidates whether they are Catholic or Protestant. If they decline answering, you must make an educated guess and document that. The goal is to ensure you are not hiring all Catholics or all Protestants.
Northern Ireland is in a unique situation. The Troubles were horrible. I can’t imagine having to write regulations to put a society back together. I should not judge the wisdom of this approach. It is just so different from what I am used to in the U.S., that it is hard not to be confounded.
What’s interesting is that of the other developed countries, the US actually sounds the closest to this. No other country that I know of (maybe Canada?) will ask you to describe your “race” when applying to university for example
Heh. That’s true. I wouldn’t have been at all surprised if we had to ask about race. I guess each country/culture has to address its particular fault lines. Like I said, I don’t envy folks drafting laws to try to rebuild civil society.
It may sound crazy but I’ve seen something similar happen at a startup I used to work at. The founders (Muslim) very clearly preferred to hire people of similar backgrounds. All their recruiting efforts were focused on Muslims and they went so far as to hire clearly incompetent developers over much more qualified applicants simply because they were Muslim. I’m talking about hiring someone fresh out of school vs someone with years of experience simply because the new grad was Muslim. One guy on my team dared to speak up about it and was accused of being racist. He had to do cultural sensitivity training as a result.
I wonder if it is possible that the recruiter said something like "ah, damn" which would be unprofessional of course, but seems in the general range not-completely-absurd human reactions.
I just recently had someone ask me not to curse when I said “ah, damn” in relation to some trivial thing (from memory I was just expressing disappointment that a project wasn’t going ahead, or part of a project).
It’s the first time in my life I’ve ever met someone (over 10yrs old) who considered “damn” to be cursing but apparently they do exist.
It is informal speech. Some people choose to use informal speech in work environments. Others believe it to be inappropriate. I'm in the latter camp but I don't push my language preferences on others - just as I don't push my coding style. So now you've met two people, but in reality you probably are familiar with many more who are silent.
i usually say 'darn' just to be safe, unless/until everyone knows each other, etc.
and i'm still surprised when an interviewer drops an S-bomb or F-bomb or whatever.
when i moved from north (US of A) to the south, back in the day, some religious folks would cuss by saying things like 'Dah-gommit' and things like that.
I once, 30 minutes into what was supposed to be a 1 or 2 hour phone interview, had an engineer at Google cut me off in the middle of their standard "write code in a Google Doc" with a "oh, I have a meeting I have to run to, good work we'll get back to you."
I assume it was not, in fact, good work, as I did not progress to the next interview.
I think a phrase like "typical" would be inaccurate; possibly "common" as well. But, I think, most people who have interviewed a decent amount have at least one story like this. Cursing is another step beyond, but its not insane; many of the people on the other end simply get drafted, they don't want to be there, and in some companies even see you as a threat to their career advancement.
I had a Google research scientist telling me during an interview that they don't like their job and don't recommend it. At a different occasion, Google's VP showed up 15 minutes late, asked one question, and stopped paying attention for the rest of the interview too busy with their laptop.
I understand that these are probably outliers but I will not be reapplying soon.
Absolutely. It can be quite painful in the short term, but the long term benefits (both for you and that particular relationship) can be huge, especially if you're naturally averse to confrontation.
It wasn't an interview but when I was first starting my engineering career I was in a little three-way meeting with my manager and the department director in a tiny break-out room presenting some automation I'd developed to save time provisioning DC infrastructure.
The director was not paying attention at all and was pecking at their iPad. iPads had just come out and every VP/director was carrying them around and chicken-pecking them during meetings.
I stopped presenting and said I would wait until they weren't busy anymore ;D Was a bit irritated as they were the entire reason we were in that room.. Luckily I had quite a bit more tenure than that director haha(and a lot of political cover).
I interviewed for a company that was (maybe still is?) the leader in industrial cameras. I was being vetted for a EE role by a bunch of non-EEs until I got to the one poor woman who was the only EE left in the company after they had gutted their in house development and switched to using fancy enclosures around SZ commodity cameras. I was asking probing questions and had her on the verge of tears during the interview. Glad I never got a call back from them.
Well... There are cases when you just need to cut the interview off.
Google is purely consensus company, where one "outlier" can literally block staffing of a whole department. So if that one person was against you - you had 0 chance.
I think it depends somewhat on what the cursing at me really means - if the recruiter said something like:
"Screw you, you little shit, I can't believe I wasted my time with your worthless ass!" and hung up that would be one thing, if they said "oh damn it" and hung up that would be another, both still rude but quite different. I'm assuming of course it was probably something like the second but the phrasing makes it sound like the first.
I think cutting off an interview is fine if it's clear that it's not going to work out. It saves everyone's time. Maybe he could have been less rude about it.
I interviewed at a small company just for an internship several years back. It was an iOS position, but again, internship/jr. level. I said I wasn't an expert but wanted to learn and had spent some time developing some basic iOS apps on my own.
Guy proceeds to seriously ask me about low-level memory management, i.e. ARC (Automatic Reference Counting) vs. other methods (this was roughly 2013 or so).
I attempted to give an answer from what I knew just reading the docs, as I hadn't written complex-enough code for it to matter. Mentioned I didn't have first-hand experience using it, so that's my frame of reference.
He basically laughed and went off to tell the recruiter it wasn't worth having me finish my interview loop.
I understand for an experienced iOS engineer at the time, those would've been entirely valid questions and it'd be reasonable to expect enough time spent using them that a quality answer could be given.
But I was honest in saying I hadn't gone that far and this was for an internship.
Of course that was also when I realized that in the real world, there are small companies who tend to want FTE-level of productivity out of young engineers/interns for that pay level who aren't experienced enough to know it.
Edit: Coincidentally that same day I reached out over Twitter to the CEO of a company I admired, also in SF, and asked if I could just tour the office since I was in the area.
That CEO spent his lunch hour with me, had a good laugh about the interview story, and worked with one of his teams and recruiters to get me in the schedule to interview. Got an internship there the right way, spent two years interning, went full time for 3.5 years, and that was the beginning of my full-time career.
I have a feeling this will get me a downvote, but I grew up in a very blue collar town and the idea of paying one's dues is not crazy to me. I see a lot of people entering the tech market as if they don't have anything to prove, like their degree says it all. In any industry, you shovel some shit early on, IMO. I was a good programmer, but I got my start racking servers in a data center. I crawled under raised floor to run cable, replaced batteries, worried about cooling, and generally did a lot of work no one else wanted to do. I was a programmer already, and I think it was a waste of my ambition for $COMPANY to not give me a job writing software, but I don't mind the idea of people paying their dues, and I think I'm better for my experience. Careers aren't supposed to start with you having a big corner office. It is surprising to me how many people feel entitled enough that they truly believe they ought to start at the top.
>I don't mind the idea of people paying their dues, and I think I'm better for my experience. Careers aren't supposed to start with you having a big corner office. It is surprising to me how many people feel entitled enough that they truly believe they ought to start at the top.
he is trying to pay his dues. its an intern position. at the very low level.
As usual - it depends. FAANG internship is way more valuable than other big names and big names are much more valuable than anonymous web shop hiring 3 people.
So if they went directly for big name that isn’t exactly paying their dues.
FAANGs have massive intern support programs and their interviews aren’t usually like this. Interns are the ultimate try before you buy so for orgs with the ability they’re worth it.
Does this have anything to with what the parent comment even described? Expecting someone to apply for an internship with extensive iOS skills is a bit of a joke.
It kind of reminds me when I got asked for an internship experience if I had any experience doing large Python 2 to 3 migrations. The job description didn't even use the word Python. (I later found out through Glassdoor that this company paid interns about the same rate as the entry rate for the H&M down the block.)
That's not paying your dues. Being a software engineer forced to work as a network technician (not even a network engineer) is akin to having the junior accountant just get everyone coffee.
Maybe writing tests is paying your dues, because it often feels like a thankless job. Building UIs in a JS framework... Those could be "paying your dues", or more precise getting real world development experience.
But there's a lower limit to that "paying your dues", when it comes to educated professions.
It also sounds like an incredibly bad idea to put a junior engineer with no network technician experience in a network technician role. Have fun when your server goes down at 2am because something is fried, somewhere!
In mechanical engineering, it's considered good practice to make recently-hired engineers work as blue-collar operator in the shop for a while. When it's proposed it's even usually appreciated by the engineer as a rare opportunity to learn.
Ye you need oil and saw dust on your hands to design machines properly. In a SWE analogue running the milling machine would be ... using computers? Workshop experience is harder to come by than computer dito.
I think it’s really easy for people to accidentally have a net negative impact on the productivity of a team. Especially early in their career, especially if they’re only there for a few months.
Having interns is probably still worth risking that - they bring some life and variety into an office and they’re only around for a few months anyway. But I would be leery about adding a junior engineer to my team if we’re using manual memory management and they don’t get it. You might have to obsessively code review all their stuff to make sure they don’t introduce memory bugs. Memory correctness in iOS programming probably usually doesn’t matter that much, but a bit of wariness is reasonable and understandable.
Overworked engineers might also not want to spend their time handholding an intern if its not in their KPIs to do so, and they don’t consider that to be part of their role. This is a cultural thing as much as anything else.
I'm not sure I understand your argument. Are you implying that in the end, I did the least amount of work to get an internship?
If so, that's awfully wrong. I still had an interview loop and all at the company I joined. All he really did was refer me to a recruiter and matched me up with a team that he knew needed an intern. I'm sure his referral meant something but it wasn't an automatic job offer at all.
Seems like an unfortunately odd leap to consider that not doing the work to get the job.
I really don’t see what you went through as “paying your dues”. Would it be normal for a doctor to start their career as a vet, and work their way up to humans? Would it be normal for a car mechanic to be asked to start on lawnmowers and work up? Not really
And being a junior programmer isn’t “having a big corner office” or “being at the top”. It’s literally the bottom of the software engineering ladder
that would be the equivalent of a developer internship i guess? they're still doing a doctor's job in residency, they're not wiping arses or manning the reception desk
> Guy proceeds to seriously ask me about low-level memory management
Some internship candidates would have been able to answer those questions.
I interview a dozen or so internship candidates every year, and i see a lot of variation in what they know. They're all good students from good universities, so they've got a grounding in theoretical computer science, and they've all done some coursework projects and one or two group projects. But some have done a lot more than that. One was into competitive programming. One had built a business around automated eBay sniping. One had built a few iOS apps that were making money.
My approach is to hire anyone who has any practical experience (a group project is fine) and doesn't try to bullshit me. But i could imagine some people focusing more closely on the handful of people with deeper experience. It depends on what you want your internship programme to do.
It reminds me of a recruiter I spoke to who asked me how much experience I had with "winforms". I said "None, I've never heard of that" and she couldn't believe it. She went into this tirade about how five years of experience with winforms was required for this job and how could I not know anything about it, and was I sure I didn't have at least some exposure somehow to winforms somewhere.
Very odd experience and the only time I've never had someone get angry in a context like that. I guess if you're a recruiter and recruiting for a job that lists winforms as a requirement you may think that's a super critical thing and not have any conception of the relative importance of knowing things like that.
I didn't go forward with the recruiter and I've never bothered to check what winforms are, but I assume it's some kind of library for creating GUIs in Windows and I further assume I could have been productive with it in a day or so.
Sounds more like the recruiter was frustrated and panicked that they still couldn’t find anyone suitable, and was trying to nudge you into inventing some winforms experience in order to get to the next round
I haven't gotten it from interviewers, but I have from tech recruiters. Specifically remember being cursed at for "not bothering to learn Rails yet". I did not put Rails on my resume or LinkedIn and the recruiter reached out to me, apparently without thoroughly reading anything about me.
But I have been laughed at on a phone interview before. It was for a game dev job, and I was told by the recruiter ahead of time "They just need anyone with any game dev experience at all," so I didn't spend too much time studying for the interview. I had developed and released several full games, even popular ones, but they were all 2D Flash web games.
So I was completely unprepared for 30 minutes of being grilled on 3D graphics math and console development. I answered to the best of my ability, and could have done better if I hadn't been misled by the recruiter, but no, it felt like I was being toyed with by the interviewers (kept hearing laughter multiple times after I answered).
I got a different and (equally good) job in the industry and the company that interviewed me ended up closing down about 6 months later, so it worked out for the best anyway.
I have had a very similar experience at a tech company. Was told they just wanted to have a chat (I wasn't applying for a job posting), and then suddenly it was a full-fledged interview that I wasn't prepared for. I got humiliated and was angry as hell for being misled. I still remember it to this day.
> Furthermore, if you really want a C++ developer you can just expect a developer to learn C++ on the job if they have any adjacent experience with any other language.
Is this really accurate? C++ is a very different language than even Java, not to mention Python or JS. Languages have their own quirks and attributes that often matter at some point. Especially C++.
I am on a team where we are constantly building stuff with new technologies that nobody on the team has learned, so a certain extent I understand the sentiment, but we are under no impression that we are doing that good a job at it.
It can be pretty safe, but it requires restraint and selecting a good subset of the language. There's still plenty of footguns that an inexperienced person might hit.
And footguns that an experienced person might hit. One family of such footguns is:
const auto &foo = something(args);
…
other_thing(foo);
Depending on exactly what you’re doing and what type something(args) returns, this can be entirely correct and idiomatic. In other circumstances it accesses a reference after its lifetime.
One can debate whether the const belongs there and how many &’s to use, but, unless something has changed dramatically in the last couple years (I’ve been focused on things that aren’t C++), there is no answer that is universally safe and efficient.
I think the point is just that unlike Rust there's no compiler enforcement that you only use refs in their lifetimes: you can easily accidentally cause a use after free.
Some times it can be pretty indirect: eg if the ref ends up pointing into some std container then it might need invalidated by making an otherwise unrelated change to the container.
The reference itself is indeed valid, in the sense of existing, until it falls out of scope. But the object it references may not be, so using the reference can be UB. Consider an std::vector v with length known to be at least 1:
const auto &ref = v[0];
v.push_back(42);
cout << ref;
That works fine until push_back reallocates out of place, at which point you may start to notice that it’s actually UB.
Rust will not permit this problematic usage. GC languages tend not to offer this pattern — you can reference a boxed vector element with different semantics than the above C++ code, and you mostly can’t reference an unboxed element. C++ lets you do things like this but has little ability to statically verify correctness.
(Doing the above maneuver with a vector is a bit silly: it saves typing, and indexing a vector is extremely fast. With a map, though, indexing is not so fast, and keeping an iterator or a reference around may be a big performance win. At least if you keep an iterator around, dynamic checkers have a better chance of noticing errors.)
It's not even so much that the footguns exist but that the consequence of hitting them is "undefined behavior" ie: anythign from core dump to reformatting your hard drive. Compare to Java where the consequence is one thing doesnt work right and someone has to debug it. Rarely it takes down a whole server side process but even then you get a lot of instrumentation and diagnostics to manage it and / or figure out what happened.
C++ is a nightmare language but this specific complaint is completely overblown. The compiler isn't going to format your hard drive (I know that one blog post exists - that is a deliberately constructed example).
A C++ program with UB is just buggy. Same as a java program with bugs. The program does something you don't want it to do. That's what a bug is. The compiler isn't going to maliciously introduce code that you didn't write to order pizzas.
I think there is a factor of UB that makes it have a steeper learning curve than the corresponding issues in other languages: with Java a lot of that category of bad code will throw exceptions and you'll get useful stack traces. UB often results in some seemingly nonsensical runtime state (eg something being null immediately after a null check, or a null dereference only leading to a segfault later in a place that locally has no pointers).
Compare mutating a container in a way that invalidates a live iterator: in java it's a specific exception that you can read on stack overflow, and in C++ it's just a use after free that might still appear to work correctly a random percentage of the time.
Yes and no. You can write c++ code that handles memory in a safe and consistent way. Or you can write code which silently leaks and corrupts as it goes. The language doesn’t care and unfortunately even if you do everything correctly another programmer can mess with your allocated memory and silently break everything.
I think if you're looking to write a simple HTTP server with some API functions that talk to some RDBMS at less than 100 requests per second, yeah, C++ is pretty hygienic and safe these days.
If you need to play around with memory management strategies like non-default allocators then yeah, the knives are still very sharp and will cut you if you're not careful. This comes up a lot when writing C++ extensions for scripting languages like PHP, Python, etc and you have to interact with objects managed outside of your C++ code.
C++ these days still supports all the syntax and programming style of C++ in the 70s. You probably mean "you can program in a hygienic and safe way in C++", which is true, but also is not necessarily a feature of the language but of the programmer (just a few years ago I interacted with some theoretically senior C++ programmers who claimed mixing raw pointers with smart pointers is fine because they're senior and know what they're doing).
Ask developers to safely define a string constant that is accessible outside of that translation unit. Now do it without C++17, which many companies aren't using yet.
Things have gotten a lot better, but even these incredibly basic needs can be really tricky.
Leaving aside the hyperbolic fringe, I'd guess that what you've heard is that it's possible for a team with discipline and experience to develop in such a way that they sidestep C++'s memory pitfalls. The situation being discussed here is the exact opposite.
For example, while I'm not particularly fond of Python as an engineering language, I've never worked on a team with poor enough process that we deal with (eg) production runtime failures due to typo-ed variable names that would have been caught by the compiler. And yet I'd never claim that it's impossible for such a problem to exist, given arbitrary levels of talent composed in arbitrary teams and processes.
Yes and no. A good programmer could learn it, but it exposes concepts that python and java abstracts from the programmer.
C++ requires you to think quite a bit about memory. Modern C++ not so much. However the kind of job that requires C++ will probably require you to know some hardware / embedded which is a completely different domain than web devs and could make java / python transitions even more difficult.
>A good programmer could learn it, but it exposes concepts that python and java abstracts from the programmer.
Education varies wildly, and overall in industry you will not apply 100% of your learnings. I'm sure I forgot plenty of algorthms that others use daily. Likely, others forgot plenty of low-level memory management than I use daily.
Let's not turn this into a programmer measuring contest. They are different concepts and tools done for the purpose of solving problems, not flexing IQ's. coments like this are no better than the ones you complain about.
Low level stuff, I happily code off the top of my head in pure PIC and AVR assemblies, is not same as C++ low level stuff.
(IMO) C++ is quickly becoming that middle ground language that is destined to be a niche language in a decade. It's not low level enough and not high level enough to give people dealing with assembly code or business logic code a reason to switch.
You can pass everything by value, write very child-friendly C++ code, using std::map like Python dict and std::vector like Python list, and still VASTLY beat the speed of an interpreted, weakly-typed language like Python.
But nobody does that. Chances are someone on the team takes a shit about unnecessary memory copies, the code will be littered with a smattering of pass-by-reference and pass-by-pointer, there will be std::shared_ptr, std::weak_ptr, std::unique ptr everywhere, and if you're lucky some intern will have committed some C-ish C++ code that will leave you gift of memory leaks, and now all of a sudden you need everyone to understand all the nuisances of the language and how memory works.
> But nobody does that. Chances are someone on the team takes a shit about unnecessary memory copies
It’s not just performance. In any moderately complicated C++ program, you will want a function to mutate its argument, and this falls apart.
Sure, you can write in a pure functional style with immutable data structures, but I wish you luck implementing an immutable data structure with asymptotically reasonable performance without using pointers of some sort.
Unfortunately many programmers underestimate the speed at which computers can copy flat regions of memory these days and overestimate speed of code littered with pointers and indirection. Often using pointers to avoid copying a few bytes leads to worse performance.
In my experience a combination of pass-by-value with move semantics provides good code readability and almost optimal performance in most cases, so that's my default. Unless a profiler disagrees in specific cases, of course.
A map or pretty much any nontrivial data structure is not a flat region.
In any event, waiting to optimize until a profiler tells you to is a reasonable practice as long as you pay attention to scaling. It’s very easy to write, for example, a JSON parser that performs fine in small tests and has a nice small n^2 coefficient. And then someone throws in a bigger input than you tested and your game takes ten minutes to load.
> A map or pretty much any nontrivial data structure is not a flat region.
Not necessarily. A hashmap can be implemented in a way it stores both the keys and values in a flat memory region, as long as keys and values are fixed size, and such a structure is way more efficient that traditional array-of-pointers implementation, where fetching each key requires following a pointer and getting the value requires following another pointer.
I develop business backend servers in C++, no problems there and no hardware / embedded is required. I also happen to be familiar with electronics and do develop firmware every once in a while but I mostly use plain C for that.
That sounds like you're trying to stab yourself in the face...
The unfortunate bit is - there is a lot of people that are learning Python or TypeScript that can develop that business logic as fast as you at a fraction of the cost.
>"That sounds like you're trying to stab yourself in the face"
Sounds like you have no idea what are you talking about. It was exactly Python project I've recently completely rearchitected, rewrote and greatly improved. Client can't thank me enough as it performs hundreds of times better than the old one. And from what the client told it was developed in less time than the original Python version.
In general I use multiple languages including Python. I just do not see anything in Python that noticeably speeds up development of big and complex projects vs modern C++ ( or any other decent language for that matter ).
You just have to know what are you doing. Language is secon
C++ is one of those languages where people have deep expertise. They are on standards committees, they have a high profile in the industry. But yes if you have general programming experience you can certainly pick up modern C++ and not make a complete mess of things. It’s a multi-paradigm language with lots of gotchas that take a while to learn and require a career to memorize and stay on top of. But I think if you are an average developer in, say, a functional and OO language, you can be expected to become an average C++ developer with a little effort.
Maybe... if there are other experienced C++ developers around who can show you the ropes. But C++ has enough footguns that I wouldn't want the only C++ developer on a project to be someone who just picked it up. That's just asking for trouble.
I can't comment on whether this holds for C++, but I've experienced it at my current position with Elixir. While it's a high level language like most programming languages I know, it's still a large paradigm shift to a purely functional language. And yet, I could get to the level where I could make useful contributions to our backend within a few days. I went through Elixir's "Getting Started" guide, and afterwards, I just learned concepts as I needed them. Yes each language has its quirks, and I guess C++ has gained quite a few of them over the years, but you can get quite far with a basic understanding of a language, and an existing code base to learn common usage patterns from as well.
normally i would agree with you but no. not for C++. having worked with C++ in the past I would not venture to say I know C++ today (it’s been a while) or have high hopes that I would just pick it up in a few weeks like any other normal language
I think if you want somebody to learn the syntax of C++, and more/less understand some code, then that would work.
But many places are using C++ only because something about the problem domain requires it, often performance. Understanding C++ and cpu architectures well enough to write high performance code is a completely different beast than just understanding c++ well enough to write code.
Understanding C++ syntax is a long ways from writing C++ that's not full of memory corruptions, as others have mentioned.
So it's not just "train somebody in C++", it's "train somebody in C++ and writing memory-safe C++ and writing fast C++".
People undervalue other people’s skills and contributions and overvalue their own skills and contributions.
I notice this more and more in hiring process. Teams expecting new member to perfect fit wrt hard skills over soft skills. Frankly, hard skills can be taught, soft skills can’t be taught and take long time to modify behavior.
I haven’t been able to articulate it as succinctly as you did, but this is so true and Ive used the principle to push for many hires who didn’t do so hot in their technical round.
If a person is excited about technology and is familiar with translating ideas into code, that’s really all that I’m really looking for. Writing good code, understanding OS, networking etc are things that can be looked up and learned by people who are motivated to do so… there are so many resources to learn from.
One caveat here is that for “senior” hires, the expectation is opposite: not that they write perfect idiomatic code, but they’re able to write solutions. I think the practice of less technical interviews for higher level seems somewhat paradoxical: you want your Software architects and Principal Engineers to be able to code with a degree of competence.
As someone who studies math (one pf the hardest skills), no, sometimes skills just can’t be taught. Some people just don’t get it. Unfortunate, but that’s the way it is.
You can teach someone math who already graduated with basic science degree in much shorter time than it will take to teach a math whiz to consider opinions from someone else’s point of view.
I've been writing C++ for like 15 years now and still need to visit Stack Overflow 500 times a day to do my job. It is not a language somebody picks up on the job.
Coming from Pascal/C/C++ to Java in early 00's I really hate it the style of non-existing global variables. To use global variables I had to declare another class? Such heresy!! To this day I still hate Java, personally, but when it comes to a real challenge I really don't care the programming language. Programming languages are tools, each fits better for a particular problem and my clients pay me to solve their problems, not to bitch why one language is better than other.
That ain't happening with C++ unless you have a very good understanding of the bazillion things C++ lets you control. Just deciphering the STL errors when you compile is a headache. C++ gives you way too much rope to hang yourself with, compared to even languages like C, which is already a tough thing for someone who's never worked with a language where there is no garbage collection and typing is not strict.
Yes, for typical corporate development tasks which is the bulk of the tech job market. As long as they are reasonably seasoned vs what you need done and you don't throw them in to the deep end on day one. Every language has quirks and corner cases but after you've learned enough of them, the oddities don't tend to trip you up for very long. Learning the specific frameworks and business knowledge tends to be the lions share of the learning that needs to happen... takes longer but also not a big deal.
Realistically, the majority of developers spend their days doing rather mundane work with CRUD/data-munging probably being a good description for most of it (regardless of whether it's server/desktop/mobile/web) which isn't rocket science. Now if you need an expert to write a memory management system for language X on OS Y, that's a different story.
If you are at a company with highly automated style checking, strong developer education resources, and a culture of using sanitizers all the time - you can let people learn C++ on the job.
But if you are just writing code with code review from other team members as your only option? Oof. C++ is a barrel of knives. Incredibly safe looking code can actually be filled with horrible horrible nightmare bugs.
Here's what I expect will happen when an average developer is "to learn C++ on the job":
The inexperienced developer will write code that is subtly wrong. The senior developers will spend more time debugging than the time would take to write the code themselves.
The new hire will effectively have negative productivity.
And when the new hire has learned enough, s/he will get a new job. The comapny will not have recouped the investment on the developer.
The problem with C++ is that every firm has their own flavour of C++ that they use.
Someone experienced in C++ will be able to pick it up a lot faster than someone transitioning from the Java world, but there's always going to be a fair learning curve for a new hire.
I've probably spent ~1000 hours writing C++ in my life (admittedly, years ago) and objectively speaking I wouldn't hire myself even as a junior C++ dev.
Tech companies lowballing employees? That's news to me. On the whole the market seem very good for tech employees.
Also, what company is only paying 50-70k to Juniors but 300k to Seniors? It seems like most companies that pay well do it across the board, not just for Seniors.
If you've ever been on the other end of the pipe for hiring you'll understand the need for filtering. The alternative is to never list jobs and hire through networks, which has other problems.
A good number of people apply to positions that list "5 years in Java" with 1 year in Python, because it's impossible to tell if the role being fulfilled is specialized enough to justify needing half a decade of deep java knowledge or if it's something someone can learn on the job if they're clever. For hiring managers who really need that deeper knowledge that's a lot of filtering.
Why is that hard to see? With a lot of simplification about "good" and "bad" candidates...
It's the natural outcome of there being a very small group of bad candidates who apply for a lot of jobs, and a very large group of good candidates who don't apply for jobs very often. What if there's only 50 bad candidates in a particular region, but they all apply for every posted job opening? That's a lot of chaff to get through on every single job posting.
Things aren't that simple for a lot of reasons, but the basic idea holds - you don't need a huge number of people applying for jobs they're clearly unsuited for in order for those people to add up to a huge portion of applicants for any particular job opening.
Really good point. The really good candidate/engineer/whatever might end up only doing 3-10 interviews over 10 years, or less. They do well and get rewarded where they are at, and get picked up quickly when they do interview - and with a good offer.
The really badly interviewing candidate might end up doing 50 a month for a year before they stop looking - and be on the market in another 6 months to a year, where they do it all again.
You'll see the bad pennies a whole lot more often than the good ones.
Upwards of 90% of applicants for many roles - talking about external postings, it's usually only 50% for internal - have clearly (in my experience) not even actually read the job posting, let alone have an understanding of what the job would entail or any of the requisite experience to be successful in it.
Many of the remaining 10% have read enough they'll try to fake the requisite experience or understanding of it, but on the job would fail almost immediately (and not in a coachable 'oh yeah, we use bit x instead of y here', but in a 'have no idea how to use the calendar App we use, despite claiming years of hands on experience). Only a couple % of applicants for a public posting will have the actual experience and ability to do the job.
And that is before we start talking about fit with others/ability to work in the culture effectively, and other soft skills.
I've had candidates apply for senior Java developer positions that couldn't write out the most basic class structure on a white board while claiming 10 years of experience (like class Foo {}), candidates applying for engineering managing jobs that struggled with basic arithmetic, candidates applying for executive admin jobs that had no idea how to process an inbox at all (except to sort everything with a billion filters - except I needed them to, you know, actually figure out what needed to happen and sort out the junk, not categorize the junk for me to sort through), and a million other weird things like that. I had a lawyer who wasn't a lawyer once. That one I filed a criminal complaint against.
Sometimes it may be brain lock, but in many cases I think it was fluffery and 'fake it till you make it' thinking.
A large part of being a successful company is figuring out how to filter out the frauds/incompetents/won't actually fit or work outs, from the people who can get things done and can work with everyone who is already there without making a giant mess. It's surprisingly hard. Most don't do a good job at it.
Not surprising to me, It's a field that pays an insane amount of money for such low barriers to entry (notably, it does not require expensive credentials). And there's swaths of stories out there about people going from 0-100 in a matter of months.
Additionally, this may be a popular opinions, but there are a lot of places where you don't have to be particularly competent where you can earn more money than you could otherwise.
> That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he’s the best, and now, in this contrived example, every employer thinks they’re getting the top 0.5% when they’re actually getting the top 99.9801%.
I've interviewed a ton of bootcamp and "I took a class on Udemy so I'm a Full Stack Engineer(TM) now" candidates in the past year. There have been some really good engineers hired from bootcamps, but a lot of people just didn't learn how to code.
Bootcamps are hit or miss, but sometimes I think they spend more time on having their students create shiny LinkedIn and GitHub profiles to impress recruiters than teaching them how to write software.
That or the "I've been working with Drupal for 10 years" and now I'm applying to a position looking for 4ish years of Java. Sometimes I need someone with experience and that's just not going to cut it.
My favorite is getting word doc resumes filled with red squiggles. How am I going to trust you to care about accurate code when you can't be bothered to spell check a resume.
> It’s hard for me to fathom that such a large proportion of candidates are terrible.
It’s not that most candidates are terrible, it’s that most job applications are 90% mismatched. Don’t forget many many people are applying to multiple jobs, and most of them are great candidates for something, just maybe not the high paying lead role as the first job out of college.
As someone who’s done a lot of hiring and mentoring, I often tell people to apply lots of places and punch above your weight class, a little, for some of it. This is just like applying for college - you put in the app to Harvard on the wild off chance you’ll get in, you put in the app to your state school so you have a safety, then you apply for a range of schools, half of them long shots. Turns out, Harvard rejects more than 90% of their applications... because they get a lot of them, and most of them are long shots. This does mean they have some filters in place, for better or worse.
I see this same advice play out among applicants - many of them are applying for jobs that they might have only half or a third of the qualifications for. But maybe that’s okay, especially for junior positions. Many companies hire people who don’t have 100% of the listed qualifications, so as an applicant, it might be worth checking if you pass their filter, and as a hiring manager, it might be worth learning how to avoid interviewing people who are obviously more hopeful than qualified.
We were hiring for a front end dev, and had 40 applications in a few days. Majority were either still in uni, in another continent, or just had 0 experience/ education that was directly relevant, not even a portfolio at times.
Majority of 'decent' applicants that passed the filtering step very obviously followed some tutorial once, and promptly listed it under their skills. Many didn't have much, if any, work on GitHub. During the interview process a few were clearly fabricating their experience, and would get very uncomfortable if we asked for any more details.
I don't get it - it's disrespectful of our time, and a waste of theirs, to lie. Do they just hope they will get that first job without any relevant knowledge, train on the job for a year, and be a proper dev then? Like, we're hiring for a business not a bootcamp. If you can't be semi-productive within a few months, who knows if we ever do get some return on the investment, both in terms of other dev's time, and in terms of compensation.
Ended up filtering more on ability to communicate, parse requirements, and how well they could pick new skills up, than what they already knew. This was for a lower/mid range dev, in terms of experience.
I've been on the other side of hiring. It was in Europe and it wasn't an American superstar company. A long queue of folks after bootcamps and attempting to requalify from various non-IT industries...
Is this style of discourse really what Hacker News is about? I come here specifically because it is one of the few places where vague sentimental ranting is discouraged over directness and constructing thought out arguments for points. It's disappointing to see something make it to the top just for having an aggressive "hot take" and not because the content is well presented.
If it happens too often people don’t like it, but this particular topic hasn’t been seen in a while, and it’s something people feel fairly strongly about, so it makes sense that it keeps coming up once in a while.
Writer doesn’t seem to know what drives a lot of things and seems to suspiciously get a lot of poor interactions.
I have never been cursed at for anything by an interviewer. I have never heard anyone I know tell me they were cursed at.
The older guy who had his school paid for? Guess what? College was insanely cheaper back then. Also, it was extremely rare. Today, all the education you need to learn any language is available for free in any medium you like. Even CS fundamentals.
The article doesn't mention the #1 problem with tech hiring: leetcode. Some advice for recruiters: try starting your emails with "NO LEETCODE" in the subject line and watch your response rate from senior experienced engineers skyrocket! There is an artificial "shortage" caused by this barrier.
Leetcode implies complex, contrived algorithm scenarios presented to be taken apart in a brief interview (usually at most 40 minutes for the coding question). Real world scenarios do not resemble leetcode questions, and hard real world problems are solved with more time and careful thought.
This creates serious inertia. Once you are 3-4+ years into a job, you probably haven't done much leetcode studying in a while outside of you doing interviews yourself. Interviewing at other companies is actually a pain in the ass, so it's often not worth the bother.
It's automated and mostly mindless. They are looking for "smart" solutions, that fail to account for testability and code maintanance.
I fail a lot of leetcode challenges, yet I've built a critical data platform for Grubhub, IBM, Expedia, etc... some are still in operation to this day.
There are also a lot of engineers out there with 1 year of experience x 10 (or even 20 times), or even 20 years of experience with some narrow niche technology that no longer applies - but want to be paid like they have been keeping on top of things and learning broadly for 20 years.
A solid experienced engineer is worth their weight in gold. A lot of folks consider themselves solid experienced engineers who couldn't program a hello world in any modern computing environment. This is quite unfortunate, and more chaff to sort through.
Not defending leetcode. At least it shows someone is trying?
I’m not one to do the boss’s work for them, but you’re observations aren’t wrong. Your expectations are. Personally, I am thankful to be young, single, and have a lot of free time to keep up with things myself. But I have no interest in the society you seem to desire. This business of expecting constant self-education from workers alienated from the product of their labor or any reason to appreciate the daily grind they’re tasked with is asking for a spiraling mess of societal consequences that I am starkly against. I don’t know any simple solutions. I’m afraid socialists might be right.
It doesn’t have much to do with me frankly. And I’ve seen this in every society I’ve been exposed to, from India, Japan, Switzerland, Bulgaria, Germany, France, UK, you name it.
If you aren’t able to do the job (defined by your peers and the market), you either don’t get paid, or you have to force the market to pay you or change the job, despite not doing the original job (often through legal threats/strikes). It’s a market protectionism vs market need thing.
We seem to be advocating here that the best solution (software, market) should win, and that’s what I’ve seen in the global marketplace where legal threats like strikes generally have low impact.
What I’ve seen in other areas where the legal situation allows more leverage from labor is happier but fewer and lower paid labor, in often a much smaller market. Essentially a ‘I got mine’ type setup where incumbents get good slots and it’s super hard to get into once established because the pie overall is smaller and guarded. It screws over the newcomers and unestablished in favor of the incumbents.
China has started to export some really amazing home grown tech (including software) in some verticals, and if you think they give a rats ass about EU, US, etc. programmers - well, they don’t. Just like French don’t really care about Japanese labor conditions.
So we either wall off that software (often to everyone else’s detriment - those would be good products for less cost otherwise for people to use) to protect the local labor/market conditions and cause distortions elsewhere, or.... keep up? Japan is notorious for the protections it has, and is terrible software wise almost everywhere. Pretty solidly stuck in the late 80’s when they were the newcomers and were actually innovating.
And if we aren’t even trying to keep up, well - that just means the people who are will win/define the end state won’t it?
It’s the harsh reality of the real world. EU has been going the way of protectionism for a long time, which is great from a ‘retirement community’ type sense, but there is a reason there aren’t many cutting edge tech firms originating there. It’s pretty clear from the constant handwringing from the EU on anything regarding tech or competitiveness that they know it too, but can’t make the trade offs to fix it. Great if you’re already established and looking to keep things cushy, pretty terrible if you’re trying to get established though.
Like the thread with the folks who broke into tech by problem solving a case as a kid - imagine if they wouldn’t have been allowed to shell script until they’d gotten certified or joined the appropriate union?
It’s also why salaries are generally so much lower there for engineers. The real world doesn’t much care about what we (as producers or market participants) want in an abstract ‘it’s not fair’ sense, it’s about the economics of the markets and the needs and who can meet them best. If someone can get me firewood for $5 at the same or better quality as the person selling it for $10, it would require a lot to not take the $5 person up on their offer for the vast majority of people. It’s what has led to a massive expansion in wealth for all humans, as we constantly look to optimize and create more value for less cost.
If someone has 20 years of experience in tech x, but I use tech y - and they have shown zero interest in, and can’t demonstrate how to apply that experience in tech x to tech y - why should I or anyone be paying them for something that is not applicable or helpful to me at all? So they can feel like it wasn’t wasted? Good for them, bad for me.
What you say is an empty statement because it doesn't rank which skills are the most important to a software engineer.
Coding is the core skill of software engineering.
For other skills, say, communication, you will need to have an adequate amount of it, but you don't need to be godlike (e.g. think Bill Clinton's level).
If you have the Bill Clinton's level of communication, you will likely be in other positions.
Now if you have the Bill Clinton's level of coding, you will be software engineer.
I agree that coding is the core skill of software engineering, no question about that. What I don't agree with is when we make it as a deciding factor in interviews for mid and senior levels. At such stage, I'd assume someone who worked for few employers already know how to code and there are different standards of skills we need to hold them for, such as designing relatively complex systems and understanding tradeoffs, communicating these trade offs, how they deal with priorities to ship a functioning software etc etc.
I think we should limit the algorithm problems in an interview to either college graduates/engineers entering the field, or that's an essential part of the job (unlike most Web development)
The last place I interviewed at used leet code as a filtered. The code problems were fun and challenging. I score a 850 out of 900 points. I failed the next round of interviewing after mentioning something about enjoying writing original code, software shaves off stability concerns and tech debt the more portable it becomes, and seniors aren’t in a position to force juniors away from deliberately doing foolish things.
This person sounded really experienced, so I looked them up on LinkedIn. 7 months at their first company. 9 months at their current company. That's it, aside from non-programming jobs before their bootcamp.
The whole thing reads like inventing scenarios that didn't happen or embellishing them.
> A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
Not that believable, but okay.
> I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
Didn't happen.
> Nobody in their right mind is going to move to San Francisco, California to be a “Lead developer” for only 70k with zero equity.
Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything? I put in a limit buy of $3000 for 1 BRK/A on a whim once.
Yeah, I think this post is much too generalized compared to what the author has really experienced. It is pretty clear reading between the lines that they're finding getting an entry level job frustrating.
I own an agency. Yes there are shitty agencies, but there are also _plenty_ of shitty companies hiring directly. We have shared our developers' bafflement at how poorly they get treated by Internal Recruiters at the hiring company several times (and generally never worked with the hiring company again).
I've seen some "top performing" code, that I had to just trash... because making any changes to the hack job of top performing "just ship it" people is a nightmare.
I'll give the benefit of the doubt to someone with 25 years experience that they know the difference between a true 10Xer and one who 10Xes by leaving 20X of tech debt in their wake.
Bootcamp grads haven't been in the workforce long enough, so whether they can weather the fickle winds of the technology landscape is an open question. That's where the CS degree shows its worth: technologies change but fundamentals change less. Comparison-based sorting is still O(nlogn). You still have to partition and break down large data sets in order to work on them. Time and space tradeoffs will always exist and will need more than a bootcamp education to be able to evaluate properly.
meh - I had basically 2 data structure courses, which is not a "year of classes" since the class met for 1 hour, twice a week for about 20 weeks, and times 2 for that second semester. So I have 20 * 2 * 2 or 80 hours of O notation and heap sorting.
The rest of my CS degree consisted of a lot of stuff I used in class (assembly programming) and maybe I got something out of that. I also took a functional languages course which was taught with Scheme (a lisp dialect) which is a little iffy on practical skills. A formal database class (which was an elective)
So I know boyce codd normal form and o-notation, is that really much of an edge over the bootcampers after a few years?
And to be honest because everyone brings up O notation every time we have this talk I'm pretty sure most bootcampers learn that by looking it up and probably binary trees. Yeah. so I'm really not very convinced from a practical level how much more they're pulling.
It seems to me I was in the wrong classes altogether - the real money at this point is in ML and there's not much a CS degree helps with in that area really - so yea, the fundamentals did kinda change, right?
No. Look around you in any tech organisation and see how much value is generated by the people who code vs. data scientists, and how many software people there are vs data scientists. ML is very popular and the startup ecosystem has latched on to it for funding but the fundamentals of CS have not changed. Sure, there's real money in ML but there's plenty of lucrative opportunities in software development.
Your post somewhat proves my point: you are here (and presumably thriving) in software dev despite taking many courses that you deem only tangentially related, years ago. Whether the same can be said of bootcampers remains an open question, because they haven't been in the industry long enough. Anecdotal evidence from software dev managers I know who have tried hiring bootcampers has been overwhelmingly negative (but they are often comparing BS/MS/PhDs who have spent 4-10 years immersed in various aspects of CS to bootcampers, which isn't fair).
I had a few like this particularly when I was first entering the field professionally, but not so much anymore. I had one that wanted me to move out to some random town outside myrtle beach for around $17/h iirc.
If he had only that much experience and he applied for some senior position that required years of knowledge, I'm not sure I would curse at him, but I would definitely be really angry at him and whoever let his resume turn into an interview.
> Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything?
During an active season (spring, fall, usually) I get one of these a day, or every other day at least. Other times it slows to a trickle--1 a week or so. Usually it's some "I have an urgent requirement for a 6 months contract position for $45/hr. with (litany of skills/responsibilities that screams shitty Dilbert-esque cesspool). This is for in person only at (place on the east coast which would require me to uproot my family and move across country)" style content. Some of the more amusing ones are for contract positions in the Bay Area--those usually have people who, bless their hearts, think they're making an effort with $75-$80/hr rates.
Is this one of those "We couldn't hire locally so we have to get someone in on visa" type situations? I know that happens here (Australia), at least pre-covid
Somewhat relevantly, a closure isn't a "specific thing in a specific framework." Its a concept that exists in many languages, and has no real relation to frameworks.
I would never treat someone like they're stupid in an interview, but being completely unfamiliar with common programming concepts and treating them as irrelevant or trivial things is definitely a red flag.
The person may know what is and how to use it without knowing its formal definition in programming language theory. I personally find interview questions that ask you to regurgitate definitions like an exam to be poor indicators of real world skills. It would better if the interviewer first established terminology to avoid confusion and then ask how they would use such language constructs
I don't think it's unreasonable to expect someone applying for an engineering role to know the technical terminology of their field. Especially if they've been "programming for many years" as this person has.
I know approximately what a closure is, and I am sure I have used such constructs instinctively in my work many times. I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff.
Once a guy asked me to write out merge sort on a whiteboard and I couldn't. I didn't get the job. Surprisingly I'm doing just fine in my current position and am very productive (as much as I may say so myself) and have never heard complaints from anyone that I don't know what I'm doing.
So if you don't see a CS degree in the resume then don't ask what a closure is or to implement a merge sort in the interview. Ask them to solve a real problem. The top computer scientists didn't discover the merge sort for years or decades and you want me to figure it out on the spot? Or you just expect me to memorize useless shit like this? Give a problem a programmer would encounter on a day to day basis that wouldn't need a lot of googling. Let them figure out how to solve it and see if it works for you.
You probably won't need merge sort in your day to day programming, but closures (sometimes called lambdas), definitely. Every time you create a function that captures some variables outside its scope, congratulations, you've just used a closure.
Yeah, without knowing the term closure or lambda(which are not necessarily closures but could be as an implementation detail) I'm not sure how one would effectively communicate with others about code in a high-functioning environment using high-level languages. They are very widely used.
That's true. The problem in this case is that they are weeding out applicants based on their knowledge of terminology. Talking about a concrete code sample may not fall into that trap.
i now know of closures, and have actually used them intentionally, and rarely, and def not enthusiastically.
i lived mostly in the java world, and discovered closures when i was getting wacky results while playing around with a Clojure looping example.
then ran into similar situations about once a year when doing something in javascript -- usually passing some function for a callback, and needing access to 'this' in the original/calling scope - which only confused things when i needed access to 'this' in the (local?) function scope, too.
guess i'm not against closures -- they just seem mysterious to me.
ditto lambdas. they seem like a good way to write esoteric code, and write more error-prone/less-defensive code -- that, for instance, might be more likely to produce NPEs, and generally be less maintainable b/c of the focus on brevity instead of clarity, and be geared more towards expert users/coders instead of the generalists (like me) who are often brought in to maintain older code.
> "I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff."
...that statement looks kinda sus. In a code review I'd maybe get you to simplify it or break it up to confirm the negatives end up meaning what you wanted them to mean.
Adding to this, I think even a little bit of genuine esoterica is okay in an interview process so long as:
1) You're looking for someone with deep knowledge of that subject
2) You don't treat it as an automatic fail when they get it wrong
If I'm interviewing for a senior role, and I ask them a few super obscure questions about the language/framework/platform I need them to be an expert on, that serves as a litmus test for their overall depth of knowledge. Those facts individually may not be required for the job, but they give a read on how deep the person's knowledge goes in general.
But, as you pointed out, I wouldn't really even put closures in that category. For JS it would be something more like, "What does '{} + 12' evaluate to?"
Again, it's just a signifier. If you know the answer (or can explain a good guess!), you probably also know a bunch of actually-useful dark corners of the language. If you don't know the answer, you may still know all those other things. It's just one data point among many.
You're right! Though the original question - '{} + 12' - is extra tricky and actually evaluates to 12 ;) I'll leave figuring out why as an exercise for the reader
at this point, i'd love to know when the answer is just '12'.
i remember going at it with some dude back in the day who was 100% certain, and got visibly upset, when i stood my ground that java only used pass by value. i allowed that even object references were being passed, but that they were passed by value.
>at this point, i'd love to know when the answer is just '12'.
Ctrl+Shift+k in a browser (firefox) opens a console. Just write {}+12 there and hit enter.
My guess is that {} is (in some circumstances) evaluated as a block of code (instead of an empty object). Since the block is empty it evaluates to undefined. The +12 is considered another block of code ( the + operation takes here only one parameter - so it is not a sum ). Consecutive blocks of code are evaluated to the value of the last block of code, which is +12.
{}/12 for example doesn't work at all - which is a hint that the + is not a summation operation.
Edit: I'm wondering why we use 12 and not 42
Edit2: Technically you are correct about java being pass by value. But at this point I'm questioning the sanity of the distinction. It feels more and more like a philosophical discussion.
If you claim to be very experienced in JavaScript but then say that you are ignorant of closures, then that's definitely a red flag. That language relies heavily on closures, more than others, and almost every programming pattern in the browser involves capturing some sort of state about enclosing scopes etc. given the asynchronous nature of things.
The inordinate amount of space the article devotes to complaining about 'credentialism' just reinforces the impression that the writer hasn't taken the time to know his tools/languages/frameworks at a deeper level, and is dismayed to have been found out in interviews.
> > ask (...) “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
> Not that believable, but okay.
To me, it sounds very believable. I have been asked about defining what closures are multiple times.
I switched a couple of times between backend, frontend and mobile, and I had to learn bunch of interview questions that never came up in real life.
In different communities, there are different concepts that they love to ask, even if in the end at your day job, you rarely use them.
The JavaScript interviews are always about quirks very specific to JavaScript that the interviewer learned last week. They then act like without that knowledge you can't possibly contribute to their Angular dashboard.
JavaScript people always go through some examples of the "you don't know js" book, and they ask about the quirks of the language. My opinion is that the code they ask about would be rejected at most companies PR review process, because they are tricky, unclear, surprising. The "You Don't Know JS" book is a great book, and you shouldn't use 95% of the code in there if you want to scale your team without very-hard-to-find bugs.
Java and Android people love their design patterns and clean architecture questions, and they would be floored if you told them that you don't need 13 layers of classes just to call your backend and build a plain old Java object from a JSON.
People also love asking questions they themselves could barely answer. Yesterday, the team lead of my team had to accidentally clarify the event loop in a technical meeting, he was squirming, his clarification was terrible, yet we expect juniors to nail the question, and if they don't explain it exactly like we would, we act like the candidate is a "script kiddie".
If you're looking to get hired as a front-end dev at any level above entry-level, you definitely need to know what a closure is - not just for its utility, but because it can cause nasty bugs when you implement it unknowingly.
If I were hiring a mid-level or senior-level front-end engineer and they do not know what a closure is, that'd be a red flag for unfamiliarity with a core language feature. It's on par with not knowing what a decorator is in Python, or reflection in Java.
we hired a confident 2 year out bootcamp grad that was able to pass our interview process and he nearly destroyed our company, twice. There is a reason the interview is difficult to pass, being a dev is a job with an insane amount of responsibility, you do not want bad people in there.
It sounds more like your company has failed to implement robust processes to catch mistakes before they're big problems to me. No individual should have the power to destroy the company except maybe a CTO or a lead sysadmin. For everything else important there should be layers of security and QA checks, with automated sanity checks on config and data for really important stuff. If a new hire can deploy stuff without multiple people seeing it before it gets to production then everyone in the company is responsible for accepting a process that can lead to serious issues.
You recognise this and you didn't implement processes to catch problems after the first mistake (obviously, because there was a second mistake). If there's a third mistake I think you're going to have to accept it was partly your fault.
I don't think that. I think that when someone fucks up so badly it almost ends the company you review all your processes and work to limit the possible damage any one person can do. That would be a matter of putting in lots of additional checks for things to start with, and then removing them as you figure out what things don't need multiple people's oversight.
That sort of bureaucratic process is horrible and annoying, but it's less horrible and annoying than everyone losing their jobs when the company fails.
We're very fortunate in tech that we can automate 99% of this stuff. Stopping someone pushing bad code that fails tests or hasn't been peer reviewed is a straightforward case of adding some deploy rules to a repo. It's much harder to fix processes where things are manual checklists people need to follow.
This is what I call the "Perfect World Fallacy". Yes, in a perfect world, you'd be absolutely right. But that's not the reality we're living in – in particular, that's not the reality small and young companies are living in.
When you're scaling up, or when you're short on staff, and there are fires to be put out everywhere, you just don't have the capacity to design and test those perfect processes. Where are they supposed to come from?
> layers of security and QA checks, with automated sanity checks on config and data
Ha! I've never, ever seen any company which comes even close to that platonic ideal.
Yes, in a perfect world, you'd be absolutely right.
A lot of companies choose not to do process oriented work, and just wing it instead because they believe they can go faster. That's fine. It's a choice driven by resources.
What's not fine is complaining that someone you hire is "bad" because they get stuff wrong when you're forcing them to work without a process-based safety net. People will always make mistakes. If your belief is that everyone should be perfect because you've chosen the no-safety route then you don't get to complain when someone nearly sinks the company. Expecting people never to get things wrong is unreasonable, and it's the exact reason why we have processes to catch problems.
> If your belief is that everyone should be perfect [...]
Well, you seem to believe there's such a thing as a perfect process. How is a non-perfect employee (or a group of non-perfect employees) supposed to come up with a perfect process?
> [...] because you've chosen the no-safety route [...]
Who said anything about no safety net? Maybe there was a process, or a safety net, but it wasn't perfect and didn't catch those mistakes?
I didn’t fire him because he made 2 mistakes. I fired him because I was giving him 10-15 hrs/week of coaching and mentorship and he wasn’t improving at all. The process that was bad was our interview process and our process change was changing our interview process.
Pretty strong disagree on this. I prefer working on teams that optimize for execution speed and just hire people who won’t go up in flames in that environment.
Focusing on process and making the safest process will kill your team. Your best team members don't want to be hampered by a process that slows them down to protect them from their worst team members. The advantage you have as a startup is speed, don't throw it away so easily.
In a company there are seldom human failures, those are process failures. If deploying means sshing into prod server and messing around, anybody is going to eff that up sometime. That person is then not a failure, having to do those error prone tasks is the failure.
>A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
Is this a good example? Isn't "what is a closure?" more of a smell test "do you know the language" question?
Maybe asking "oh you know python? Tell me how to implement and use a metaclass" without access to the documentation would be a better example.
Damn. I've been coding in Python for 10+ years and never came across this "metaclass" thing. Starts wondering whether I'm rusty and un-hireable. Curious what it is, I read the first result on Google, which goes through an example that I don't understand the point fully, and it concludes with "metaclasses can easily veer into the realm of being a “solution in search of a problem.”"
Oh well, good luck hiring python devs :)
I'd agree more on the closure part in javascript though.
582 comments
[ 3.1 ms ] story [ 323 ms ] threadIf you're a competent dev, move to a place with a good tech scene and you'll do fine.
In any case, it's like an arm race for SEO. What was once a useful measure will lose meaning as everyone adopts these tools.
Also, if you are even vaguely talking to a recruiter (e.g. via career fair) then they are not going to screen you using an automated system.
You are still quite young, it doesn't hurt to take 1-2 years to build your experience in this industry before going to top companies. And believe, they are not that picky.
When you are a college student, it is really hard to distinguish yourself from your peers, unless you are truly outstanding, otherwise most resumes look likes clones to each other.
Whenever I start interviewing, it takes a few fails before I finally realize: my talents are not (at all) what interviewers care about. Talent is just the icing on the cake. Once I remember that, I focus on being personable and start getting multiple offers. It’s always been like that.
We all benefit from an educated society and higher education should be funded by the state.
>You try to lowball your employees then you act surprised when you’re struggling to find good labor.
This applies to service industry jobs as well.
1 - Pay
2 - Work life balance (incl. remote work)
3 - Strong peers
4 - Control in _how_ things are done for senior developers
5 - Efficiency
I'm pretty sure that most companies are, at best, 1/5.
Most people aren't going to be passionate about building, oh, I dunno, software for insurance companies, but it still needs to get done. There might be a handful of "disruptive" companies doing something in the space, but 99% aren't.
There's a lot more "boring" software (even in the startup world) that needs to be built than anything else. The problem is really that these companies don't seem to be self-aware and they don't adjust #1-#5 (especially #1) accordingly.
Once, I got approached for a job at Amazon to help "build the next big e-billing system"... What an uninspiring thing to do.
I get my overall high level fix from outside of work activities, so work is enjoyable mostly for the little puzzles it generates every day. I am sure that there are some fascinating considerations for a mega e-billing system, even if it isn't all that interesting in itself.
I do have an eventual interest to do research focused role, but interesting impactful research I think requires either high management (professor leading a large lab/research director) or making your own thing. The first I lack the experience for and the second doing a startup feels too risky to me today. If I was wealthy enough I would probably try making a research themed ai startup.
If they’re totally unfamiliar with the problem, and yet they make significant progress in just one hour that should be interpreted as a good sign this person would provide a lot of value to your company """
I think this is extremely important. A developer that can make a lot of progress on something they haven't seen before is often times just as good as a developer who can tell you the big-O efficiency of reversing a red-black tree off the top of their head. Although the latter may indicate a very interested systems-level hobbyist, which is also an excellent value in terms of an engineering quality but impossible to tell from a whiteboard interview if they're a hobbyist or if they just studied.
I can tell during my limited time in an interview if a developer is capable of making logical deductions and not flail when exposed to a problem they may not have seen before. And, better yet, if they do study algos for fun, this will become apparent!
I’m not really interested in whether or not they know this. I’m more interested in whether they can explain it to me.
I'm more interested in knowing if they can debug something nasty or opaque with patience and using deduction instead of flailing. Chances are the person who can do this might also be able to explain why a red-black tree inversion is a certain O-notation, but its not strictly necessary.
But I have a story myself: A certain company that is probably in the top100 biggest of the world, one time attempted to hire me, but their hiring process was a mess and they forgot me in the middle.
Then I noticed they kept complaining on media about not finding anyone for that job. 2 YEARS later, after they posted another complaint, I decided to apply again, and even mentioned the previous hiring process.
The HR department said they were sorry, explained that the previous time it was a contractor and they were bad at their job and got fired. So I thought this time I would get hired.
Went through their entire process... and then HR sent me a sad letter, that the headquarters in the company home country, blocked my hire because it would violate policy.
The policy in question, is that for that job, people needed experience. But also, they needed a local. But... they were the first company offering that particular job in the country, ever. So you have this company trying to be the first company to hire for a particular job in the country, but wants someone with experience, complaining endlessy about it on the media. I felt bad for the employees that were dealing with that bullshit.
(the job in question was Game Producer, I have a bachelor degree for it, but back then this company was the only company in the country with such job opening. Some other game companies DID exist in the country but all of them imported producers from their other studios, so for example there was some french and canadian producers in the country)
I don’t get how people can see the plethora of individuals under 10yrs experience in SWE and other tech roles in SV/NYC/SEA with incomes of $250-600k/yr and think this happens without a “shortage” of talent.
Shortage in quotes because it’s hard to define in context of supply/demand but it’s clearly the case that devs have a lot of bargaining power.
Small and mid-size companies have a different problem: people haven't heard of them and don't know to apply. My company is in this situation. We have a good culture, I think, and pay very well but people don't know about us or don't think of us as a "tech" company, even though we do quite a bit of innovative software development.
I had a recruiter try to lure me for a $130K “senior” role on the east coast in the US. I earn several times that.
Unless you want to be a lifeless drone for a HFT fund. But then living expenses aren't that high in NYC, compared to Bay area.
Having said that, I don’t know how bad those roles actually are. Obviously, it’s not worth it if it affects your mental health… and unfortunately yeah, that is an issue working in this field.
The difference between both taxes and the "next in line" isn't large enough. Hedge funds pay as much as Google/Facebook, but work and life balance at SV companies is much better.
Compare my two offers from a few years ago - well known hedge fund in CT vs a food delivery tech company.
Well known hedge fund paid $250k+50k bonus for expected minimum 50hour weeks and 20 days of vacation time. Food delivery company offered $170k+200k in stock over 4 years for 6 hour work days in a relaxed environment and unlimited PTO.
It's at the point that it's not worth the money. Sure it's about $3k extra monthly income.... and if you're not burdened with student debt, it's not a game changer.
$400k new grad TC, Free food, 40 hour work weeks, great company culture (many events)
Facebook this year had many intern events trying to convince people that FB > Quant, evidently the brain drain is there
Much appreciated :)
Pointing to extreme outliers is not giving your opinion much credence. Because I can point to some people who work in crypto, that earn $600k+ without breaking a sweat - in Singapore with Singaporean taxes(which blows HRT salaries with US taxes out of the water)
If I am somehow worth personal attention as a not terribly impressively pedigreed and inexperienced developer, are they really dumping seniors through crappy filtering software and missing them there?
Hire the wrong junior? No biggy, he'll be less effecient but we may yet turn him around. Anyway, I get three more tries. Anyway, he'll leave after 2 years. They always do.
Hire the wrong architect? I'm stuck with him, for a very long time. Moreover, I now have the wrong guy for a high-impact job. And one that is very visible.
So you betcha I'm going to be much more picky, the more senior the job becomes.
>A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
FAANG companies do not interview like this. I've done interviews with most of them twice in the last 5 years and all questions are the typical algo stuff.
Then his whole rant about credentials... I am a self-taught dev with no degree, none of my interviewers ever cared about that. Every interview is about whether or not you can solve the algo question.
Except almost nothing outside of some amount of resume filtering fits his points. Seriously, go to levels.fyi and look at the pay of the FANGs (ex. Amazon). You think his bad pay point is a problem for them?
The difference is that big tech companies aren't meant to be applied to over the internet. Seriously, it's like throwing your resume into a black hole. Referrals are the same way, honestly. The only good way to get hired is to get a recruiter to message you on Linkedin. I have never got an interview at these companies from applying on their websites and have made it to the first round of interviews every time if I was contacted by a recruiter.
And because of that, it should be no surprise that nobody is scouring the internet to find your company and send in an application on your company's website. Everybody has been conditioned for that to essentially not work. Even though it's expensive you really should be paying third or even first party recruiters.
Post on Hired.
Because all the issues the guy pointed out I am on receiving end of them right now.
And although I've been in leadership roles before and started programming when I was 6 years old (my dad taught me), I started lately to see if sending my applications to junior developer roles will get me any replies (people don't even tell me they got my application, except the occasional robot).
Uber, Doordash, Asana, AirBnB, Pinterest, LinkedIn and literally so many more. Especially if you are willing to accept mature but not yet liquid equity and then there's Stripe, Airtable, Robinhood and so many more.
Post your resume. Tried to go to your personal website but it wouldn't load.
https://www.linkedin.com/in/gamedesigner
And your highlighted recent experience as a game designer would just make me disqualify from any engineering role.
It's like starting a restaurant and banning chefs with baking experience.
Satoru Iwata was a notable game designer. He was very much a skilled engineer, but his resume would've been trashed.
If you’ve done a lot of different things because you’re smart and creative, maybe I’ll have to spend more time making sure you’re motivated (so you’d have to be worth the extra time cost). It’s also common to see people with an ungrounded perception of their abilities, and I often see breadth-heavy people suffer from an inflated sense of their own abilities due to lots of small scale, diverse wins.
Most people don’t understand how valuable a hard worker who will agreeably take orders and deliver consistent results is; magnitude doesn’t even matter that much. Unless you’re single handedly driving significant business metrics (e.g., directly saving millions of dollars), from my perspective, my job success is tied to predicting your output. If I succeed, I get to expand the teams or build new ones. If a product release is late or buggy, it’s also wasting tons of other teams’ time or damaging customer relationships besides pushing the eng roadmap back.
We reject a bunch of faang people for having experience we don’t find valuable. If you work at a big tech company, but don’t have an impactful role, you’re potentially not going to succeed in a small startup at the level you’re demanding.
Finally, one bad hire can ruin a team (i.e., one bad hire converts others into bad hires). “Bad” is subjective and can refer to different things. At the end of the day, it’s my job to define it and make sure we’re avoiding it. You can ask about this in an initial phone screen, or in a follow up conversation because it’s not secret, but I can’t talk to you about it after we reject you due to lability.
For instance, could you regurgitate topological sort out in less than 20 minutes to solve a problem? You forgot the implementation but generally know what it’s used for? Failure. You’re a failure. Even if you know how to solve the problems but get tripped up on some simple parts of the algorithm because you haven’t really studied or used it in years, failure. Same with system design type interviews and other stuff.
The bar is very high for people who will never use any of that work. It’s hazing.
I have a job now (and by all accounts my employer is really happy with me), but the interview gauntlet I had to run to get here was absolutely ridiculous.
Some of them are actually legitimately senior, despite short tenures on paper - but many are barely entry level qualified.
Flood the market with very good but not exceptional workers, and the top salaries won't change much.
Flood the market with exceptional workers and it probably won't change much either, FANG will just be even more selective with their top salaries.
Top devs have a lot of bargaining power not because companies need some "X amount" of development work done but can't find anybody who will do it. They have bargaining power because those companies are competing against one another and they're hoping the next billion dollar idea will come from one of _their_ employees first.
If you aren't playing this kind of roulette, I don't understand why you would try to compete in the same job markets. You can get developers for far less. And yes that may mean moving elsewhere, SV is obviously heavily selecting for such developers (people who can get those salaries will tend to move there, those who can't will tend to be pushed out).
If you are playing in that space but you just can't afford to pay for its inputs then it doesn't automatically mean those inputs are in a state of shortage, sometimes it just means your business does not create enough value to to pay for said inputs. This is the market's way of telling you to fold. Capitalism is a harsh mistress.
Ever since Blockbuster failed dramatically, large brick and mortar company execs are worried that SV will take their market. And, for good reasons too, I'd say. Software is eating the world etc.
> I literally can’t relate to this on any level
Well that would be the expected outcome, no? The author claims a problem exists in hiring and sets out articulate what that problem is. If the problem exists, then as a hiring manager, it's a good bet that you are, at some level, involved with that problem. For your stance/perspective to lie anywhere from a harsh opposing view to merely unable to unable to endorse the author's perspective ("what is water?") would be unsurprising.
(Note that this is true just as a matter of logical consistency and is not particular in any way to hiring itself; try replacing "hiring" here with "skub" and it's still true.)
Second, at this point in my career developers at large companies aren’t expected to write code. Save that for startups. Instead developers are expected to debug things and string tools together like a homemade necklace. If you are an established company and want somebody to write original code you have a lot extra work to do to ensure a good cultural fit.
Reasons for failure vary, you don't get much feedback but when I've gotten it it's been distributed across coding/systems/behavioral.
I've also been rejected at resume round by companies like Instacart and Coinbase.
The interview bar has gotten insanely high it seems. And I left Google way back without anything lined up assuming in this job market I could waltz into a good job with some modest prep but that has not been the case.
I objectively have top credentials, and I find tech interviewing an absolute nightmare. The standards have gone through the roof and one slip up and you get dinged. And the system is way more arbitrary and subjective than anyone admits.
Now, this isn't a woe-is-me story becasue to your point, there's a lot of companies paying top dollar and I have a decently paid job. Furthermore, I'm not failing interviews at random startups but as senior engineer at top companies that would probably offer $400k if they made an offer. They have the right to be extremely picky and subjective, but let's at least admit that they _are_ extremely picky and subjective.
The "I'm a HM and can't hit dev targets", reeks of ignorance as to your own process. I wonder if you do things like tell your interviewers "a false negative is better than a false positive" ? Or let one interviewer use some arbitrary criteria to dock a candidate and then pass on them because of one bad score? Because you probably do lack perspective on how many good devs your company is rejecting if you're only sitting on the HM chair and not seeing what it feels like to go through these rounds as an IC SWE.
Software developers are starting to commonly earn doctor-like salaries. Doctors typically burn ~12-15 years between school and residency before they start getting paid serious salaries.
A top 20%-30% software developer can be earning $150k in their mid to late 20s, outside of the Bay Area.
It's no surprise that the hurdles are going up for such high compensation. Software devs in the US as a mass employment field (1.5m people) are the best paid large group of people in world history. Combined wages (not total compensation, that's far higher) for the 1.5 million software devs in the US is in the neighborhood of $215 to $250 billion per year. It's doubtful anything like this concentration of huge globally important industry dominance + very high pay will ever been seen again anywhere else in the world, it's an outlier economically to put it mildly. Enjoy it while it lasts.
At the same time, I disagree it's that unprecedented. There's about as many lawyers as software developers and the compensation distribution is surprisingly similar (including some bimodal aspects). Yeah they put in 3 years and took some debt but it's not that significant big picture, many CS students get an MS.
There's a lot of doctors in my family. It used to be a gold mine field and now it's much less so, as hospitals have a lot more power over the doctors than they used to.
If you want a really good bang for your buck, look at salaries for nurses who get some specialization like CRNAs, who can make similar money to SWEs, with about 2 years extra school work.
I mostly agree we're in a golden age of software engineering compensation and as I mentioned in my first post, these companies have a right to be picky. Still, to some extent I think engineers of all stripes were relatively underpaid relatively to some other white collar professions historically and its just been catching up a bit.
Employees don't seem to have enough bargaining power to meaningfully control working conditions, though. Maybe these are worth a ton of money to the company, or such desires are an outlier. But here is my experience:
I'm a professor of computer science, and frequently get recruiters trying to get me to jump ship to industry. I'm open to it in principle. I'm reasonably happy in my job, but there are certainly things I don't like about academia, and the pay is not industry-level. But it's generally a rewarding job, and has various perks, like private offices and considerable control over your own schedule.
A question I ask recruiters: I have a private office... could you match that? So far, the answer has always been no. They can double or occasionally triple my salary, but they can't offer me a private office. I am not sure what to make of that. They are willing to offer me $100k+ over my current salary, but are absolutely unable to offer me an office with a door.
You might have more luck if instead you asked about working remotely full-time. It's not the same if you want to go into an office, but companies are seriously thinking about their post-covid office plans.
One was at a euro stoxx 50 telco. They had a desk with a single plate that 10 people sat at. I had to sit with the project team I was working with who, unfortunately, weren't all the same height. But the plate could only be adjusted to one height for everyone which was way too low for me. Every day at the office, it felt like working at a coffee table and my back and knees hurt like crazy. I was fighting the corporate system for half a year, including making a fool of myself in front of the global director of human resources and company medical officer. This was ultimately unsuccessful as I was a freelancer, not an employee, and earned me the scorn of my direct manager. The whole experience was so undignified and humiliating that it was ultimately one of the main reasons I quit that gig. After all I was just trying not to have to endure physical pain.
The other occasion was at a well-known Wall Street investment bank back in 2010. They put the computers in the space under the desk that should normally be legroom and every day at the office felt like a long haul flight in economy class.
My boss's boss, a partner at that firm, privately owned a floor in a highrise residential building in Tribeca. Yet, during the work week, he still basically never got to see daylight. Our business unit wasn't high enough in status to be able to swing a work area on the outside of the building that had daylight. He had an office but still no privacy. One of the walls of his office, facing his underlings' open plan space, was made of glass. Glass walls is something that these firms do these days even for very high-ranking executives to create witnesses in cases of allegations around what may or may not be happening behind those walls between colleagues of opposite gender (or preempt those kinds of goings-on or allegations).
Grad students and postdocs seem like a fairly untapped source for tech recruiting, especially outside of the CS department. Physics, neuroscience, econ, biology, and many other fields now involve lots of programming and data analysis, sometimes under demanding conditions (real-time or huge, noisy data sets). Many of the people are smart and highly-motivated, but making a tenth of the numbers you quoted (and with rubbish job security to boot). It should be like shooting fish in a barrel.
And yet.... they don't seem to be on many company's radars. I'm the only one in my group who is ever contacted by recruiters, and it's an undergrad CS degree.
Yes, you'll have to screen to figure who tweaks "the script that gives the numbers" and who's more like a developer. Recruiters might need to put in a little legwork to figure out how different kinds of researchers map onto open reqs. You might want to somehow prep non-traditional candidates for a developer interview, or figure out an on-boarding track. But you can afford a whole heck of a lot of that if a $250k/year job is sitting open.
As a terminal MS student, most of the interviews and offers I've gotten were from professor recommendations to their industry colleagues. I researched computational linguistics and dynamical systems in my undergrad, and in grad school I researched HPC and distributed systems. I still interview poorly because I don't invest enough time practicing/applying compared to reading papers or doing grad student grunt work. On paper, having an MS can also be a negative signal.
FAANG companies - filtering candidates by asking tough LeetCode questions, which is understandable. But what is with Startups? If someone can solve hard LeetCode problems why would they join Startups? They will join FAANG. Startups are blindly copying FAANG before becoming FAANG themselves.
[0] on the level of "here's a list of strings that are names in Lastname, Firstname format, turn them into a list of Firstname Lastname", or something dead simple that's designed to definitively rule candidates out
Not sure that I agree it is understandable but I definitely am glad they make this bad decision. I dodged the bullet on interviewing with a FAANG and failing on one question (the recruiter told me it was the answer on a single question that kept me from getting an offer) after doing an onsite in SV.
I did not know what I was worth and would've felt compelled to accept an offer that would've been 30-50% less than I could command at the time and I would've had to move somewhere with 4-5x the cost of a home than where I live now. I didn't get that offer, and after a little bit more time I got an offer somewhere where I earn 2-3x as much as I originally said I was worth to the FAANG (based on places like glassdoor, etc.).
The culture is better, I can work wherever and whenever I want, and would have to go out of my way to not make impactful decisions that go to prod for millions of customers multiple times a week. It'd take 2-4x my base salary to get me to walk, which I could possibly command, but I don't feel any desire to look because I didn't fall into the FAANG trap and enter a cycle of pretending consultants selling quiz books know what software engineering is and jumping to be able to survive in SV.
I messed up something on a whiteboard with an apathetic interviewer about a special tree inversion or something - who gives a shit - and I have been extremely happy that happened every day since.
Uh, what lol? Is this really what it's like to have HN brain? Not everyone in the tech industry is just working their way up to a FAANG.
> This experience is fairly common.
Is it? I've done a fair bit of interviewing on both sides of the table, and can say with complete honesty I've never heard a curse said in anger in any of them. I've also never heard of it happening from a co-worker or friend.
Be curse at because I was not NEVER.
I was surprised to learn that in Northern Ireland, you are legally required to ask candidates whether they are Catholic or Protestant. If they decline answering, you must make an educated guess and document that. The goal is to ensure you are not hiring all Catholics or all Protestants.
Northern Ireland is in a unique situation. The Troubles were horrible. I can’t imagine having to write regulations to put a society back together. I should not judge the wisdom of this approach. It is just so different from what I am used to in the U.S., that it is hard not to be confounded.
It’s the first time in my life I’ve ever met someone (over 10yrs old) who considered “damn” to be cursing but apparently they do exist.
and i'm still surprised when an interviewer drops an S-bomb or F-bomb or whatever.
when i moved from north (US of A) to the south, back in the day, some religious folks would cuss by saying things like 'Dah-gommit' and things like that.
I assume it was not, in fact, good work, as I did not progress to the next interview.
I think a phrase like "typical" would be inaccurate; possibly "common" as well. But, I think, most people who have interviewed a decent amount have at least one story like this. Cursing is another step beyond, but its not insane; many of the people on the other end simply get drafted, they don't want to be there, and in some companies even see you as a threat to their career advancement.
I understand that these are probably outliers but I will not be reapplying soon.
The director was not paying attention at all and was pecking at their iPad. iPads had just come out and every VP/director was carrying them around and chicken-pecking them during meetings.
I stopped presenting and said I would wait until they weren't busy anymore ;D Was a bit irritated as they were the entire reason we were in that room.. Luckily I had quite a bit more tenure than that director haha(and a lot of political cover).
The psychological tax of seeing your team dissolve and not be replaced seems brutal.
Google is purely consensus company, where one "outlier" can literally block staffing of a whole department. So if that one person was against you - you had 0 chance.
"Screw you, you little shit, I can't believe I wasted my time with your worthless ass!" and hung up that would be one thing, if they said "oh damn it" and hung up that would be another, both still rude but quite different. I'm assuming of course it was probably something like the second but the phrasing makes it sound like the first.
Guy proceeds to seriously ask me about low-level memory management, i.e. ARC (Automatic Reference Counting) vs. other methods (this was roughly 2013 or so).
I attempted to give an answer from what I knew just reading the docs, as I hadn't written complex-enough code for it to matter. Mentioned I didn't have first-hand experience using it, so that's my frame of reference.
He basically laughed and went off to tell the recruiter it wasn't worth having me finish my interview loop.
I understand for an experienced iOS engineer at the time, those would've been entirely valid questions and it'd be reasonable to expect enough time spent using them that a quality answer could be given.
But I was honest in saying I hadn't gone that far and this was for an internship.
Of course that was also when I realized that in the real world, there are small companies who tend to want FTE-level of productivity out of young engineers/interns for that pay level who aren't experienced enough to know it.
Edit: Coincidentally that same day I reached out over Twitter to the CEO of a company I admired, also in SF, and asked if I could just tour the office since I was in the area.
That CEO spent his lunch hour with me, had a good laugh about the interview story, and worked with one of his teams and recruiters to get me in the schedule to interview. Got an internship there the right way, spent two years interning, went full time for 3.5 years, and that was the beginning of my full-time career.
he is trying to pay his dues. its an intern position. at the very low level.
So if they went directly for big name that isn’t exactly paying their dues.
It kind of reminds me when I got asked for an internship experience if I had any experience doing large Python 2 to 3 migrations. The job description didn't even use the word Python. (I later found out through Glassdoor that this company paid interns about the same rate as the entry rate for the H&M down the block.)
Maybe writing tests is paying your dues, because it often feels like a thankless job. Building UIs in a JS framework... Those could be "paying your dues", or more precise getting real world development experience.
But there's a lower limit to that "paying your dues", when it comes to educated professions.
No one really expects much from them.
But I personally like that blue collar work ethic.
I think it’s really easy for people to accidentally have a net negative impact on the productivity of a team. Especially early in their career, especially if they’re only there for a few months.
Having interns is probably still worth risking that - they bring some life and variety into an office and they’re only around for a few months anyway. But I would be leery about adding a junior engineer to my team if we’re using manual memory management and they don’t get it. You might have to obsessively code review all their stuff to make sure they don’t introduce memory bugs. Memory correctness in iOS programming probably usually doesn’t matter that much, but a bit of wariness is reasonable and understandable.
Overworked engineers might also not want to spend their time handholding an intern if its not in their KPIs to do so, and they don’t consider that to be part of their role. This is a cultural thing as much as anything else.
If so, that's awfully wrong. I still had an interview loop and all at the company I joined. All he really did was refer me to a recruiter and matched me up with a team that he knew needed an intern. I'm sure his referral meant something but it wasn't an automatic job offer at all.
Seems like an unfortunately odd leap to consider that not doing the work to get the job.
And being a junior programmer isn’t “having a big corner office” or “being at the top”. It’s literally the bottom of the software engineering ladder
Some internship candidates would have been able to answer those questions.
I interview a dozen or so internship candidates every year, and i see a lot of variation in what they know. They're all good students from good universities, so they've got a grounding in theoretical computer science, and they've all done some coursework projects and one or two group projects. But some have done a lot more than that. One was into competitive programming. One had built a business around automated eBay sniping. One had built a few iOS apps that were making money.
My approach is to hire anyone who has any practical experience (a group project is fine) and doesn't try to bullshit me. But i could imagine some people focusing more closely on the handful of people with deeper experience. It depends on what you want your internship programme to do.
Very odd experience and the only time I've never had someone get angry in a context like that. I guess if you're a recruiter and recruiting for a job that lists winforms as a requirement you may think that's a super critical thing and not have any conception of the relative importance of knowing things like that.
I didn't go forward with the recruiter and I've never bothered to check what winforms are, but I assume it's some kind of library for creating GUIs in Windows and I further assume I could have been productive with it in a day or so.
But I have been laughed at on a phone interview before. It was for a game dev job, and I was told by the recruiter ahead of time "They just need anyone with any game dev experience at all," so I didn't spend too much time studying for the interview. I had developed and released several full games, even popular ones, but they were all 2D Flash web games.
So I was completely unprepared for 30 minutes of being grilled on 3D graphics math and console development. I answered to the best of my ability, and could have done better if I hadn't been misled by the recruiter, but no, it felt like I was being toyed with by the interviewers (kept hearing laughter multiple times after I answered).
I got a different and (equally good) job in the industry and the company that interviewed me ended up closing down about 6 months later, so it worked out for the best anyway.
Didn't this interviewer review/read the CV/Resume before calling?
Is this really accurate? C++ is a very different language than even Java, not to mention Python or JS. Languages have their own quirks and attributes that often matter at some point. Especially C++.
I am on a team where we are constantly building stuff with new technologies that nobody on the team has learned, so a certain extent I understand the sentiment, but we are under no impression that we are doing that good a job at it.
One can debate whether the const belongs there and how many &’s to use, but, unless something has changed dramatically in the last couple years (I’ve been focused on things that aren’t C++), there is no answer that is universally safe and efficient.
“In C++ it’s harder to shoot yourself in the foot, but when you do, you blow off your whole leg.”
Some times it can be pretty indirect: eg if the ref ends up pointing into some std container then it might need invalidated by making an otherwise unrelated change to the container.
Rust will not permit this problematic usage. GC languages tend not to offer this pattern — you can reference a boxed vector element with different semantics than the above C++ code, and you mostly can’t reference an unboxed element. C++ lets you do things like this but has little ability to statically verify correctness.
(Doing the above maneuver with a vector is a bit silly: it saves typing, and indexing a vector is extremely fast. With a map, though, indexing is not so fast, and keeping an iterator or a reference around may be a big performance win. At least if you keep an iterator around, dynamic checkers have a better chance of noticing errors.)
A C++ program with UB is just buggy. Same as a java program with bugs. The program does something you don't want it to do. That's what a bug is. The compiler isn't going to maliciously introduce code that you didn't write to order pizzas.
Compare mutating a container in a way that invalidates a live iterator: in java it's a specific exception that you can read on stack overflow, and in C++ it's just a use after free that might still appear to work correctly a random percentage of the time.
I think if you're looking to write a simple HTTP server with some API functions that talk to some RDBMS at less than 100 requests per second, yeah, C++ is pretty hygienic and safe these days.
If you need to play around with memory management strategies like non-default allocators then yeah, the knives are still very sharp and will cut you if you're not careful. This comes up a lot when writing C++ extensions for scripting languages like PHP, Python, etc and you have to interact with objects managed outside of your C++ code.
C++ these days still supports all the syntax and programming style of C++ in the 70s. You probably mean "you can program in a hygienic and safe way in C++", which is true, but also is not necessarily a feature of the language but of the programmer (just a few years ago I interacted with some theoretically senior C++ programmers who claimed mixing raw pointers with smart pointers is fine because they're senior and know what they're doing).
Ask developers to safely define a string constant that is accessible outside of that translation unit. Now do it without C++17, which many companies aren't using yet.
Things have gotten a lot better, but even these incredibly basic needs can be really tricky.
For example, while I'm not particularly fond of Python as an engineering language, I've never worked on a team with poor enough process that we deal with (eg) production runtime failures due to typo-ed variable names that would have been caught by the compiler. And yet I'd never claim that it's impossible for such a problem to exist, given arbitrary levels of talent composed in arbitrary teams and processes.
C++ requires you to think quite a bit about memory. Modern C++ not so much. However the kind of job that requires C++ will probably require you to know some hardware / embedded which is a completely different domain than web devs and could make java / python transitions even more difficult.
>A good programmer could learn it, but it exposes concepts that python and java abstracts from the programmer.
Education varies wildly, and overall in industry you will not apply 100% of your learnings. I'm sure I forgot plenty of algorthms that others use daily. Likely, others forgot plenty of low-level memory management than I use daily.
Let's not turn this into a programmer measuring contest. They are different concepts and tools done for the purpose of solving problems, not flexing IQ's. coments like this are no better than the ones you complain about.
(IMO) C++ is quickly becoming that middle ground language that is destined to be a niche language in a decade. It's not low level enough and not high level enough to give people dealing with assembly code or business logic code a reason to switch.
You can pass everything by value, write very child-friendly C++ code, using std::map like Python dict and std::vector like Python list, and still VASTLY beat the speed of an interpreted, weakly-typed language like Python.
But nobody does that. Chances are someone on the team takes a shit about unnecessary memory copies, the code will be littered with a smattering of pass-by-reference and pass-by-pointer, there will be std::shared_ptr, std::weak_ptr, std::unique ptr everywhere, and if you're lucky some intern will have committed some C-ish C++ code that will leave you gift of memory leaks, and now all of a sudden you need everyone to understand all the nuisances of the language and how memory works.
It’s not just performance. In any moderately complicated C++ program, you will want a function to mutate its argument, and this falls apart.
Sure, you can write in a pure functional style with immutable data structures, but I wish you luck implementing an immutable data structure with asymptotically reasonable performance without using pointers of some sort.
In my experience a combination of pass-by-value with move semantics provides good code readability and almost optimal performance in most cases, so that's my default. Unless a profiler disagrees in specific cases, of course.
A map or pretty much any nontrivial data structure is not a flat region.
In any event, waiting to optimize until a profiler tells you to is a reasonable practice as long as you pay attention to scaling. It’s very easy to write, for example, a JSON parser that performs fine in small tests and has a nice small n^2 coefficient. And then someone throws in a bigger input than you tested and your game takes ten minutes to load.
Not necessarily. A hashmap can be implemented in a way it stores both the keys and values in a flat memory region, as long as keys and values are fixed size, and such a structure is way more efficient that traditional array-of-pointers implementation, where fetching each key requires following a pointer and getting the value requires following another pointer.
The unfortunate bit is - there is a lot of people that are learning Python or TypeScript that can develop that business logic as fast as you at a fraction of the cost.
Sounds like you have no idea what are you talking about. It was exactly Python project I've recently completely rearchitected, rewrote and greatly improved. Client can't thank me enough as it performs hundreds of times better than the old one. And from what the client told it was developed in less time than the original Python version.
In general I use multiple languages including Python. I just do not see anything in Python that noticeably speeds up development of big and complex projects vs modern C++ ( or any other decent language for that matter ).
You just have to know what are you doing. Language is secon
But many places are using C++ only because something about the problem domain requires it, often performance. Understanding C++ and cpu architectures well enough to write high performance code is a completely different beast than just understanding c++ well enough to write code.
Understanding C++ syntax is a long ways from writing C++ that's not full of memory corruptions, as others have mentioned.
So it's not just "train somebody in C++", it's "train somebody in C++ and writing memory-safe C++ and writing fast C++".
I notice this more and more in hiring process. Teams expecting new member to perfect fit wrt hard skills over soft skills. Frankly, hard skills can be taught, soft skills can’t be taught and take long time to modify behavior.
If a person is excited about technology and is familiar with translating ideas into code, that’s really all that I’m really looking for. Writing good code, understanding OS, networking etc are things that can be looked up and learned by people who are motivated to do so… there are so many resources to learn from.
One caveat here is that for “senior” hires, the expectation is opposite: not that they write perfect idiomatic code, but they’re able to write solutions. I think the practice of less technical interviews for higher level seems somewhat paradoxical: you want your Software architects and Principal Engineers to be able to code with a degree of competence.
Realistically, the majority of developers spend their days doing rather mundane work with CRUD/data-munging probably being a good description for most of it (regardless of whether it's server/desktop/mobile/web) which isn't rocket science. Now if you need an expert to write a memory management system for language X on OS Y, that's a different story.
If you are at a company with highly automated style checking, strong developer education resources, and a culture of using sanitizers all the time - you can let people learn C++ on the job.
But if you are just writing code with code review from other team members as your only option? Oof. C++ is a barrel of knives. Incredibly safe looking code can actually be filled with horrible horrible nightmare bugs.
The inexperienced developer will write code that is subtly wrong. The senior developers will spend more time debugging than the time would take to write the code themselves. The new hire will effectively have negative productivity. And when the new hire has learned enough, s/he will get a new job. The comapny will not have recouped the investment on the developer.
Someone experienced in C++ will be able to pick it up a lot faster than someone transitioning from the Java world, but there's always going to be a fair learning curve for a new hire.
Also, what company is only paying 50-70k to Juniors but 300k to Seniors? It seems like most companies that pay well do it across the board, not just for Seniors.
It's hard for me to fathom that such a large proportion of candidates are terrible.
It's the natural outcome of there being a very small group of bad candidates who apply for a lot of jobs, and a very large group of good candidates who don't apply for jobs very often. What if there's only 50 bad candidates in a particular region, but they all apply for every posted job opening? That's a lot of chaff to get through on every single job posting.
Things aren't that simple for a lot of reasons, but the basic idea holds - you don't need a huge number of people applying for jobs they're clearly unsuited for in order for those people to add up to a huge portion of applicants for any particular job opening.
The really badly interviewing candidate might end up doing 50 a month for a year before they stop looking - and be on the market in another 6 months to a year, where they do it all again.
You'll see the bad pennies a whole lot more often than the good ones.
Many of the remaining 10% have read enough they'll try to fake the requisite experience or understanding of it, but on the job would fail almost immediately (and not in a coachable 'oh yeah, we use bit x instead of y here', but in a 'have no idea how to use the calendar App we use, despite claiming years of hands on experience). Only a couple % of applicants for a public posting will have the actual experience and ability to do the job.
And that is before we start talking about fit with others/ability to work in the culture effectively, and other soft skills.
I've had candidates apply for senior Java developer positions that couldn't write out the most basic class structure on a white board while claiming 10 years of experience (like class Foo {}), candidates applying for engineering managing jobs that struggled with basic arithmetic, candidates applying for executive admin jobs that had no idea how to process an inbox at all (except to sort everything with a billion filters - except I needed them to, you know, actually figure out what needed to happen and sort out the junk, not categorize the junk for me to sort through), and a million other weird things like that. I had a lawyer who wasn't a lawyer once. That one I filed a criminal complaint against.
Sometimes it may be brain lock, but in many cases I think it was fluffery and 'fake it till you make it' thinking.
A large part of being a successful company is figuring out how to filter out the frauds/incompetents/won't actually fit or work outs, from the people who can get things done and can work with everyone who is already there without making a giant mess. It's surprisingly hard. Most don't do a good job at it.
Additionally, this may be a popular opinions, but there are a lot of places where you don't have to be particularly competent where you can earn more money than you could otherwise.
> That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he’s the best, and now, in this contrived example, every employer thinks they’re getting the top 0.5% when they’re actually getting the top 99.9801%.
https://www.joelonsoftware.com/2005/01/27/news-58/
Bootcamps are hit or miss, but sometimes I think they spend more time on having their students create shiny LinkedIn and GitHub profiles to impress recruiters than teaching them how to write software.
That or the "I've been working with Drupal for 10 years" and now I'm applying to a position looking for 4ish years of Java. Sometimes I need someone with experience and that's just not going to cut it.
My favorite is getting word doc resumes filled with red squiggles. How am I going to trust you to care about accurate code when you can't be bothered to spell check a resume.
It’s not that most candidates are terrible, it’s that most job applications are 90% mismatched. Don’t forget many many people are applying to multiple jobs, and most of them are great candidates for something, just maybe not the high paying lead role as the first job out of college.
As someone who’s done a lot of hiring and mentoring, I often tell people to apply lots of places and punch above your weight class, a little, for some of it. This is just like applying for college - you put in the app to Harvard on the wild off chance you’ll get in, you put in the app to your state school so you have a safety, then you apply for a range of schools, half of them long shots. Turns out, Harvard rejects more than 90% of their applications... because they get a lot of them, and most of them are long shots. This does mean they have some filters in place, for better or worse.
I see this same advice play out among applicants - many of them are applying for jobs that they might have only half or a third of the qualifications for. But maybe that’s okay, especially for junior positions. Many companies hire people who don’t have 100% of the listed qualifications, so as an applicant, it might be worth checking if you pass their filter, and as a hiring manager, it might be worth learning how to avoid interviewing people who are obviously more hopeful than qualified.
Majority of 'decent' applicants that passed the filtering step very obviously followed some tutorial once, and promptly listed it under their skills. Many didn't have much, if any, work on GitHub. During the interview process a few were clearly fabricating their experience, and would get very uncomfortable if we asked for any more details.
I don't get it - it's disrespectful of our time, and a waste of theirs, to lie. Do they just hope they will get that first job without any relevant knowledge, train on the job for a year, and be a proper dev then? Like, we're hiring for a business not a bootcamp. If you can't be semi-productive within a few months, who knows if we ever do get some return on the investment, both in terms of other dev's time, and in terms of compensation.
Ended up filtering more on ability to communicate, parse requirements, and how well they could pick new skills up, than what they already knew. This was for a lower/mid range dev, in terms of experience.
Is this style of discourse really what Hacker News is about? I come here specifically because it is one of the few places where vague sentimental ranting is discouraged over directness and constructing thought out arguments for points. It's disappointing to see something make it to the top just for having an aggressive "hot take" and not because the content is well presented.
I have never been cursed at for anything by an interviewer. I have never heard anyone I know tell me they were cursed at.
The older guy who had his school paid for? Guess what? College was insanely cheaper back then. Also, it was extremely rare. Today, all the education you need to learn any language is available for free in any medium you like. Even CS fundamentals.
This creates serious inertia. Once you are 3-4+ years into a job, you probably haven't done much leetcode studying in a while outside of you doing interviews yourself. Interviewing at other companies is actually a pain in the ass, so it's often not worth the bother.
I fail a lot of leetcode challenges, yet I've built a critical data platform for Grubhub, IBM, Expedia, etc... some are still in operation to this day.
Companies use Leetcode because they don’t want to pay for experience.
A solid experienced engineer is worth their weight in gold. A lot of folks consider themselves solid experienced engineers who couldn't program a hello world in any modern computing environment. This is quite unfortunate, and more chaff to sort through.
Not defending leetcode. At least it shows someone is trying?
If you aren’t able to do the job (defined by your peers and the market), you either don’t get paid, or you have to force the market to pay you or change the job, despite not doing the original job (often through legal threats/strikes). It’s a market protectionism vs market need thing.
We seem to be advocating here that the best solution (software, market) should win, and that’s what I’ve seen in the global marketplace where legal threats like strikes generally have low impact.
What I’ve seen in other areas where the legal situation allows more leverage from labor is happier but fewer and lower paid labor, in often a much smaller market. Essentially a ‘I got mine’ type setup where incumbents get good slots and it’s super hard to get into once established because the pie overall is smaller and guarded. It screws over the newcomers and unestablished in favor of the incumbents.
China has started to export some really amazing home grown tech (including software) in some verticals, and if you think they give a rats ass about EU, US, etc. programmers - well, they don’t. Just like French don’t really care about Japanese labor conditions.
So we either wall off that software (often to everyone else’s detriment - those would be good products for less cost otherwise for people to use) to protect the local labor/market conditions and cause distortions elsewhere, or.... keep up? Japan is notorious for the protections it has, and is terrible software wise almost everywhere. Pretty solidly stuck in the late 80’s when they were the newcomers and were actually innovating.
And if we aren’t even trying to keep up, well - that just means the people who are will win/define the end state won’t it?
It’s the harsh reality of the real world. EU has been going the way of protectionism for a long time, which is great from a ‘retirement community’ type sense, but there is a reason there aren’t many cutting edge tech firms originating there. It’s pretty clear from the constant handwringing from the EU on anything regarding tech or competitiveness that they know it too, but can’t make the trade offs to fix it. Great if you’re already established and looking to keep things cushy, pretty terrible if you’re trying to get established though.
Like the thread with the folks who broke into tech by problem solving a case as a kid - imagine if they wouldn’t have been allowed to shell script until they’d gotten certified or joined the appropriate union?
It’s also why salaries are generally so much lower there for engineers. The real world doesn’t much care about what we (as producers or market participants) want in an abstract ‘it’s not fair’ sense, it’s about the economics of the markets and the needs and who can meet them best. If someone can get me firewood for $5 at the same or better quality as the person selling it for $10, it would require a lot to not take the $5 person up on their offer for the vast majority of people. It’s what has led to a massive expansion in wealth for all humans, as we constantly look to optimize and create more value for less cost.
If someone has 20 years of experience in tech x, but I use tech y - and they have shown zero interest in, and can’t demonstrate how to apply that experience in tech x to tech y - why should I or anyone be paying them for something that is not applicable or helpful to me at all? So they can feel like it wasn’t wasted? Good for them, bad for me.
Many companies pay for raw skills, ability to learn quickly, ability to hone their skills, attention to details.
If you can ace leetcode, topcoder, codejam, and alike in a short period of time, you probably have a very high capability of learning.
Coding is the core skill of software engineering.
For other skills, say, communication, you will need to have an adequate amount of it, but you don't need to be godlike (e.g. think Bill Clinton's level).
If you have the Bill Clinton's level of communication, you will likely be in other positions.
Now if you have the Bill Clinton's level of coding, you will be software engineer.
The whole thing reads like inventing scenarios that didn't happen or embellishing them.
> A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
Not that believable, but okay.
> I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
Didn't happen.
> Nobody in their right mind is going to move to San Francisco, California to be a “Lead developer” for only 70k with zero equity.
Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything? I put in a limit buy of $3000 for 1 BRK/A on a whim once.
No software eng. experience 2015.
2016 Bootcamp
2017 Salesforce
2018 - today - our company: TS, React, Vue, NodeJS, Python, Main devops developer that brought up our docker infra.
> Didn't happen.
Yikes...
I've seen some "top performing" code, that I had to just trash... because making any changes to the hack job of top performing "just ship it" people is a nightmare.
The rest of my CS degree consisted of a lot of stuff I used in class (assembly programming) and maybe I got something out of that. I also took a functional languages course which was taught with Scheme (a lisp dialect) which is a little iffy on practical skills. A formal database class (which was an elective)
So I know boyce codd normal form and o-notation, is that really much of an edge over the bootcampers after a few years?
And to be honest because everyone brings up O notation every time we have this talk I'm pretty sure most bootcampers learn that by looking it up and probably binary trees. Yeah. so I'm really not very convinced from a practical level how much more they're pulling.
It seems to me I was in the wrong classes altogether - the real money at this point is in ML and there's not much a CS degree helps with in that area really - so yea, the fundamentals did kinda change, right?
Your post somewhat proves my point: you are here (and presumably thriving) in software dev despite taking many courses that you deem only tangentially related, years ago. Whether the same can be said of bootcampers remains an open question, because they haven't been in the industry long enough. Anecdotal evidence from software dev managers I know who have tried hiring bootcampers has been overwhelmingly negative (but they are often comparing BS/MS/PhDs who have spent 4-10 years immersed in various aspects of CS to bootcampers, which isn't fair).
I get some very crappy spam offers like that every few weeks. 35K to be a Java dev in Atlanta kind of thing. They do happen.
During an active season (spring, fall, usually) I get one of these a day, or every other day at least. Other times it slows to a trickle--1 a week or so. Usually it's some "I have an urgent requirement for a 6 months contract position for $45/hr. with (litany of skills/responsibilities that screams shitty Dilbert-esque cesspool). This is for in person only at (place on the east coast which would require me to uproot my family and move across country)" style content. Some of the more amusing ones are for contract positions in the Bay Area--those usually have people who, bless their hearts, think they're making an effort with $75-$80/hr rates.
I would never treat someone like they're stupid in an interview, but being completely unfamiliar with common programming concepts and treating them as irrelevant or trivial things is definitely a red flag.
Once a guy asked me to write out merge sort on a whiteboard and I couldn't. I didn't get the job. Surprisingly I'm doing just fine in my current position and am very productive (as much as I may say so myself) and have never heard complaints from anyone that I don't know what I'm doing.
So if you don't see a CS degree in the resume then don't ask what a closure is or to implement a merge sort in the interview. Ask them to solve a real problem. The top computer scientists didn't discover the merge sort for years or decades and you want me to figure it out on the spot? Or you just expect me to memorize useless shit like this? Give a problem a programmer would encounter on a day to day basis that wouldn't need a lot of googling. Let them figure out how to solve it and see if it works for you.
The only reason I know what a closure is in JavaScript is because I have heavily practiced for Frontend interviews.
I've been otherwise using them productively forever now.
i lived mostly in the java world, and discovered closures when i was getting wacky results while playing around with a Clojure looping example.
then ran into similar situations about once a year when doing something in javascript -- usually passing some function for a callback, and needing access to 'this' in the original/calling scope - which only confused things when i needed access to 'this' in the (local?) function scope, too.
guess i'm not against closures -- they just seem mysterious to me.
ditto lambdas. they seem like a good way to write esoteric code, and write more error-prone/less-defensive code -- that, for instance, might be more likely to produce NPEs, and generally be less maintainable b/c of the focus on brevity instead of clarity, and be geared more towards expert users/coders instead of the generalists (like me) who are often brought in to maintain older code.
...that statement looks kinda sus. In a code review I'd maybe get you to simplify it or break it up to confirm the negatives end up meaning what you wanted them to mean.
1) You're looking for someone with deep knowledge of that subject
2) You don't treat it as an automatic fail when they get it wrong
If I'm interviewing for a senior role, and I ask them a few super obscure questions about the language/framework/platform I need them to be an expert on, that serves as a litmus test for their overall depth of knowledge. Those facts individually may not be required for the job, but they give a read on how deep the person's knowledge goes in general.
But, as you pointed out, I wouldn't really even put closures in that category. For JS it would be something more like, "What does '{} + 12' evaluate to?"
It would be really hard for me to take the process serious if I was asked that during an interview.
evaluates to
"[object Object]12"
omg, I need to learn / start using typescript
x = {} + 12;
x has the value "[object Object]12". So, it' not always 12 :P
https://replit.com/@atlwellwell/EsotericJSInterviewQuestion#...
at this point, i'd love to know when the answer is just '12'.
i remember going at it with some dude back in the day who was 100% certain, and got visibly upset, when i stood my ground that java only used pass by value. i allowed that even object references were being passed, but that they were passed by value.
i didn't get the job.
Ctrl+Shift+k in a browser (firefox) opens a console. Just write {}+12 there and hit enter.
My guess is that {} is (in some circumstances) evaluated as a block of code (instead of an empty object). Since the block is empty it evaluates to undefined. The +12 is considered another block of code ( the + operation takes here only one parameter - so it is not a sum ). Consecutive blocks of code are evaluated to the value of the last block of code, which is +12.
{}/12 for example doesn't work at all - which is a hint that the + is not a summation operation.
Edit: I'm wondering why we use 12 and not 42
Edit2: Technically you are correct about java being pass by value. But at this point I'm questioning the sanity of the distinction. It feels more and more like a philosophical discussion.
The inordinate amount of space the article devotes to complaining about 'credentialism' just reinforces the impression that the writer hasn't taken the time to know his tools/languages/frameworks at a deeper level, and is dismayed to have been found out in interviews.
> Not that believable, but okay.
To me, it sounds very believable. I have been asked about defining what closures are multiple times.
I switched a couple of times between backend, frontend and mobile, and I had to learn bunch of interview questions that never came up in real life.
In different communities, there are different concepts that they love to ask, even if in the end at your day job, you rarely use them.
The JavaScript interviews are always about quirks very specific to JavaScript that the interviewer learned last week. They then act like without that knowledge you can't possibly contribute to their Angular dashboard.
JavaScript people always go through some examples of the "you don't know js" book, and they ask about the quirks of the language. My opinion is that the code they ask about would be rejected at most companies PR review process, because they are tricky, unclear, surprising. The "You Don't Know JS" book is a great book, and you shouldn't use 95% of the code in there if you want to scale your team without very-hard-to-find bugs.
Java and Android people love their design patterns and clean architecture questions, and they would be floored if you told them that you don't need 13 layers of classes just to call your backend and build a plain old Java object from a JSON.
People also love asking questions they themselves could barely answer. Yesterday, the team lead of my team had to accidentally clarify the event loop in a technical meeting, he was squirming, his clarification was terrible, yet we expect juniors to nail the question, and if they don't explain it exactly like we would, we act like the candidate is a "script kiddie".
Somewhat similar to hazing (itself an extended "interview" process). "I had to get through it, so you have to too."
If I were hiring a mid-level or senior-level front-end engineer and they do not know what a closure is, that'd be a red flag for unfamiliarity with a core language feature. It's on par with not knowing what a decorator is in Python, or reflection in Java.
It sounds more like your company has failed to implement robust processes to catch mistakes before they're big problems to me. No individual should have the power to destroy the company except maybe a CTO or a lead sysadmin. For everything else important there should be layers of security and QA checks, with automated sanity checks on config and data for really important stuff. If a new hire can deploy stuff without multiple people seeing it before it gets to production then everyone in the company is responsible for accepting a process that can lead to serious issues.
What makes you think those two fuck ups by the same person where the same kind of mistake, or even related?
That sort of bureaucratic process is horrible and annoying, but it's less horrible and annoying than everyone losing their jobs when the company fails.
We're very fortunate in tech that we can automate 99% of this stuff. Stopping someone pushing bad code that fails tests or hasn't been peer reviewed is a straightforward case of adding some deploy rules to a repo. It's much harder to fix processes where things are manual checklists people need to follow.
When you're scaling up, or when you're short on staff, and there are fires to be put out everywhere, you just don't have the capacity to design and test those perfect processes. Where are they supposed to come from?
> layers of security and QA checks, with automated sanity checks on config and data
Ha! I've never, ever seen any company which comes even close to that platonic ideal.
A lot of companies choose not to do process oriented work, and just wing it instead because they believe they can go faster. That's fine. It's a choice driven by resources.
What's not fine is complaining that someone you hire is "bad" because they get stuff wrong when you're forcing them to work without a process-based safety net. People will always make mistakes. If your belief is that everyone should be perfect because you've chosen the no-safety route then you don't get to complain when someone nearly sinks the company. Expecting people never to get things wrong is unreasonable, and it's the exact reason why we have processes to catch problems.
Well, you seem to believe there's such a thing as a perfect process. How is a non-perfect employee (or a group of non-perfect employees) supposed to come up with a perfect process?
> [...] because you've chosen the no-safety route [...]
Who said anything about no safety net? Maybe there was a process, or a safety net, but it wasn't perfect and didn't catch those mistakes?
Focusing on process and making the safest process will kill your team. Your best team members don't want to be hampered by a process that slows them down to protect them from their worst team members. The advantage you have as a startup is speed, don't throw it away so easily.
Is this a good example? Isn't "what is a closure?" more of a smell test "do you know the language" question?
Maybe asking "oh you know python? Tell me how to implement and use a metaclass" without access to the documentation would be a better example.
Oh well, good luck hiring python devs :)
I'd agree more on the closure part in javascript though.