A friend of mine is currently looking for .NET developer job in Switzerland. Looks like everyone there is doing a one day of on-site interviews with HR, technical tests/pear programming and meeting managers.
> Anyway, the task they sent me was estimated to take 8 hours of work and couldn't be paused.
Once I was given a task to create some validation code for given criteria and integrate it in the given project.
They then invited me to an in person interview. At one point, I had to pair program with one of their developers and what I saw kind of shocked me.
They integrated my code from the interview into their production code and their developer had an issue with it and asked me to help getting it working and write a couple of extra tests. So I did and they seemed very happy.
I didn't get the job though. They said I am not a "cultural fit".
I asked them if they actually used my code and if so they would have to pay me for the whole day, but they never responded afterwards.
I decided it wouldn't be worth to legally pursue, but since then I decided to not do any pair programming or coding tests.
I actually noticed that started happening in Europe. Last month I had a similar experience, where a mobile startup wanted to hire me as a mobile developer, but wanted to test me, and the test was to implement a new feature and screen of their existing app released on the App Store..
I aced it, they were more than pleased, yet in the end they did not hire me as they said that they are actually closing the position because of the market downturn.
At least they gave me a 50€ amazon gift card..
So your work is good enough to use in production, but not good enough to pay for? I would contact a lawyer on principle. Minimum write a Glassdoor review.
I am a bit on the spectrum and their team was quite younger than myself, they've been talking a lot about how they like to party together after work etc. Not my cup of tea, so to speak.
I much prefer apple programming to pear programming. (ba dumm tsss.... sorry, couldn't resist :))
Although I'm on the Java side, I've yet to see a leetcode interview in CH, maybe I got lucky so far, but most of the interviews I had before were completely reasonable, maybe even too easy. The one that I failed miserably was an architecture discussion, in which I got an empty paper with a pen, and was expected to come up with the design of their existing system (I was allowed to ask questions). But even from that I learned so much, so no hard feelings. I will know much better what to do next time :)
Part of OPs problem may be that it's hard to differentiate yourself in that kind of position. Full stack web development is not easy to get right, but the competition pool is huge. It helps to find even the smallest little angle to differentiate yourself.
The personality tests can fuck right off, though. Agree with that.
For me this is not answerable question because it is lacking context. If it was not possible to go to the next question, it would be where I would end the interview.
Context is everything, and why these fail. When I did one, the process included the narrative version of the results. I had a question that was something like "It's important to support your organization", which I agree with. In the narrative form of the results, it concluded that I "may not tell the truth to superiors if something is wrong" from that.
Of course I support the organization, and I think being honest with superiors is the best way to do that.
In the end, these things are so imprecise that you have to get to know somebody to know which parts are accurate (some were) and which aren't. By †he time you know how accurate it was, you know the person well enough to not need the test.
Only if the person taking the test is willing to lie. I imagine most people understand that you are supposed to lie on these tests, but I could imagine some extremely honest people failing them even if they were smart enough to figure out what the employer wants to hear.
I once aced an interview before and been told they'd make an offer after this one little Big Five personality test, I think it was called. Fail with no feedback. That's not constructive or actionable. Is that test any better than phrenology or palmistry in practice?
Probably the big 5 personality matrix/dimensions. It's based on statistics to cluster personality questions and answers that tend to cluster together. The acronym most used to remember those dimensions is OCEAN.
Openness - how easily you are willing to accept new ideas
Conscientiousness - how careful and how hard working you are
Extraversion - how quickly you are to engage with the outside world
Agreeableness - how quickly you are to agree versus disagree
Most people aren't a point on the spectrums, they have a range. For example a lawyer might be very disagreeable at work when talking with opposing counsel, but very agreeable when dealing with their children.
Most people, without practice, are not a range as wide as "very disagreeable" to "very agreeable", most people are flexible around a point, to a lesser extent if they've never paid attention to how they behave and never tried to directly practice behaving differently.
Sure, though I certainly see pretty wide variances in myself based on my environment. If I’m happy and in a good environment then I tend to be very agreeable. As my stress and unhappiness go up, I tend to get pretty disagreeable.
I had one job that was absolutely awful, and to be brutally honest my attitude sucked. I wasn’t as nice to my coworkers as I wish I had been. I wasn’t a complete asshole or anything, and my behavior was never raised with me as being problematic, but I’m not proud of how I acted through that time.
But over the course of a fairly long career I’ve gotten a lot of comments about how laid back and friendly I am, and how I tend to go out of my way help people. I like to think that’s who I really am, but I can definitely be unpleasant if I’m miserable.
First, the trait examined is a range and is also situational. Second, your self knowledge of your ranges and situations is also variable and introduces more error. Third, the test introduces more error, it seems. Nobody on this thread has given any evidence this is a useful hiring tool.
My impression is hiring is difficult and there's no shortage of companies pretending to solve it with science, but it's not solved and it's not science.
This test addresses some of those problems by not only posing the personality questions to just the person you're trying to study the personality of but also friends and co-workers that know them. You can capture that range there. If you're always a jerk at work but nice at home this would capture that You just have to dig into the details.
In fact stability is the strength of Big5. People's personalities seem to be stable over their lifetime. See the 3rd paragraph [0].
The weakness of Big5 is it may/probably does not capture everything. It seems to completely miss abnormal personality traits. Which in a job interview... I hope has been ruled out with initial screening.
I wonder why personality tests are not illegal? This is essentially screening for neurodivergent people and facilitation of discrimination based on disabilities.
Until risk to the business increases, a possibly worthless speedbump on the hiring path doesn't hurt hiring and effectively makes more work for the HR manager's team, which means team growth - HR win!
Don't forget to Strongly Agree with everything your boss would want to hear and Strongly Disagree with anything that suggests you're a functional human being with goals outside the company's.
> Is that test any better than phrenology or palmistry in practice?
As a rule of thumb, if it involves psychology, the answer is always no. Humans do not have the ability to do valid experiments to verify claims, so it is all BS.
The competition pool is huge but also the number of jobs. I'm not sure he would have it easier if he specialized in some esoteric think Erlang. Yes he would compete against less people but also have barely any openings to apply to.
I meant even within the world of being a full stack dev, having an "angle" on your experience or resume. Full stack dev with lots of experience in Pandas. Heavy database optimization background, etc etc. Nothing quite as esoteric as Erlang, but I think in a pool that big you need to find something to stand out a bit.
Most full stack roles aren't that specialized (by definition). So if someone has a heavy database optimization background he probably wasn't a full stack dev. It's just a different role. Sure you can maybe pick up on some of those skills on your job while troubleshooting some performance issue, but those issues are quite rare and far between.
And again, I'm not sure a database optimization guy would find the current market any better than a full stack developer who specialized in Node and React. How many companies need a heavy database optimization background guy? Why does it make you more attractive if you have that on your resume than someone who worked only on Node and React for 8 years?
At the moment the number of open jobs is not huge. The majority of companies that haven't had lay offs have simply closed their open positions. Combined with a ton of layed off developers, most job postings get hundred of applicants within a few hours.
At the moment the number of open jobs is not huge.
As someone else mentioned here, Walmart apparently has over 1000 software related openings right now. I know a few companies outside the traditional 'Silicon Valley' company ecosystem trying to hire developers and I can promise you they're not getting 100s of applications within a few hours. The jobs are definitely out there, they're just not where most people are looking and perhaps not in a field, company or geographic location that are most people's first choice.
> The personality tests can fuck right off, though.
Disagree. I can train you to do your job but can't train you to have a better personality. If someone has a toxic personality I would like to screen them out before sinking time into them.
I suspect OP was referring to myers-briggs questionarres or similarly borderline-pseudoscience survey based means of answering "are you a $a or a $b?".
I agree that personality is an important thing to consider in interviews. But trying to gauge it with tools like that is at best a waste of time and at worst actively misleading.
Then you would need to screen them for personality disorders such as narcicism, not for how introverted they are or how much they appreciate art.
No, neuroticism isn't what you are looking for either, neither is conscientiousness. It can be argued that for an academic position you would want high conscientiousness, but I think many would argue that you want some of your professors to have disorganized, messy offices.
The problem is that the most common "personality test", the "Myers-Briggs" has nothing to do with "personality", let alone "toxic personality", so an argument about "personality" is not an argument for that particular personality test. This is a bait-and-switch dishonest argument - the gap between them is exactly the problem.
This is because the "Myers-Briggs" is hogwash, with as much predictive power of personality as astrology. i.e. none.
If the people administering them are using them for the intended purpose, they're rejecting candidates on nothing more than a roll of the dice. If not, then as others suggest, they are covert way of "screening for neurodivergent people""
So: This _personality test_ can fuck right off.
I doubt that any other quick multiple choice questionnaires are much better. If anyone wants to claim that they're worth anything, show the proof please.
My last interview was with some large US corporation. I had scheduled the first interview with their tech lead in one of the departments. Interview started on time, we managed to say hello to each other, then something bizarre happened.
I think the tech lead thought he has lost the connection, but I could see him and hear him clearly. Suddenly he started shouting, swearing and then he violently swept things off his desk and that's when the interview was cut off.
I got a call an hour later that they have "technical issues" and the interview will be rescheduled.
Three days later I got an email that I didn't pass the interview that I didn't really have in the first place.
That was quite funny actually.
The takeaway from this is that in communities open to everyone there is an overwhelming input from people with zero experience struggling to get on the ladder.
I have to agree, the current job market is truly flipped upside down and you can feel the uncertainty in the air, at least in Europe.
It seems there is a mismatch currently in the market, between what companies are demanding, and what employees are offering.
I am honestly thinking of creating a service, where I would create a database full of developers looking for work, and then only give access to companies seriously looking to hire, so basically like LinkedIn but minus the trash and spam.
meanwhile, we hire managers that don't have basic decision-making or people skills...
They justify their higher salaries due to their higher responsibilities, which they just assume the risks and jump jobs when shit goes south.
A reminder that your pay corresponds with your expected skills, hiring a top 1% de offering market average, is a delusion. But the interview process is out of control for devs, and basically non-existent for managers.
Ps: I'm a manager, so I can say that I'm overpaid for what I deliver, while devs are underpaid and the expectation on them is out of reality.
Line managers basically never have the final word on pay, at most they sometimes get discretion to move pay around within a defined band. Pay bands are handled by the C-suite in small companies and compensation departments in large companies. Both generally reference databases of "market rate" compensation.
As a rule, people are not paid "what they are worth", they are either paid market rates or convince the company they have a differentiated skillset that warrants compensation beyond what is normal in the market (usually by tying their performance to some important metric). No one has yet found a way to change this from within a corporate structure.
Agree there are a lot of bad managers out there, a decade of tech bull market and hyper growth didn’t help. Not sure why you think expectations and interview standards are lower for managers in general though. For me, managers have a much higher bar than ICs because they must have a high level of technical experience and judgement in addition to all the people skills and strategy. An EM must fill the gaps between other functions because at the end of the day engineering (for software shops) is who ships the product. If you think it’s easier than being an IC I don’t think you’re doing it right.
I interviewed a bazillion times last year. What most places are looking for is a replaceable commodity they don’t have to train. If you want to be employable against that focus only upon what’s currently trendy/popular. If want to appear as a rockstar in that context spend about an hour each with up to 30 different popular tools. The goal here is do not differentiate yourself, but just be extremely proficient in the most common technical requirements building a CRUD tool with the flavor of the moment.
Echoing a comment from that thread, IT does have a huge superiority complex. I feel these long interview processes are related to the hiring managers’ need to feel superior due to feelings of inadequacy. Perhaps because huge sums of cheap money has allowed many departments which produce very little to exist for a long time, so they look for meaning and value in the hiring process
The place I'm currently at is hiring a principle engineer. I've performed a few tech interviews so far. We just started the process less than a month ago.
We have (2) interviews. The first is more of a soft skill analysis (casual conversation) that the engineering manager does and the second is a tech interview. Each are 1 hour long and are usually scheduled on different days. There's no algorithms, whiteboarding, puzzles, take home tests or desktop sharing. We just video chat about a range of tech topics for an hour and ~20% of the time is left to ask us questions.
In the past I've mentioned that if I were ever in a position to hire someone I think it's possible to accurately identify someone's skill sets with a casual conversation and I still believe that[0]. No matter how good of a speaker you are you can't BS your way through certain kinds of practical tech questions. You either know them and can explain them in detail or you can't. There's a million little things to pick up on through out the conversation which weigh in on being a hire or not-hire in the end.
[0]: There's exception of course, my specific case applies to fairly standard web apps (something comparable to GitHub or Shopify in scope). Exceptions would be hardcore low level programming.
This is similar to what I do and IMO it works. 90% of a good developer can be found in their desire to learn / desire to problem solve as long. You can get most of what you need from an interview just by getting somebody talking enough to geek out on you.
IMO, the rates are very bad after a lot of layoffs from big companies and a few big bank collapses. The interview processes frustrated me before. It's not good (mentally and physically too) for you if you get frustrated. So, forget all the failed interviews and move on.
The multiple rounds, take home test + online examination, followed by 3 interviews etc nonsense has been a part of tech interviews for the past few years. Perhaps more people are exposed to it now because they haven't been seriously job hunting until the recent bloodbath of layoffs, but it's certainly not a new thing. I think there's many reasons:
1. There's a lot of risk aversion in corporate culture these days, the cost of a bad hire can be very high and nobody wants to be held responsible. By having multiple rounds - which in turn requires a lot of people involved - responsibility is diluted so if there's a bad hire you can blame the process rather than one manager.
2. It's an endurance test. Someone who can power their way through round after round of interviews, home projects, online tests and so on shows good "work ethic" or at least a genuine interest in the job.
3. Cargo-culting FAANG. If Google or Meta do this, then we should too (even though we're a tiny startup). It's a bit like picking microservices or Kubernetes: there's good use cases, but for a lot of projects they are overkill.
4. Concern about discrimination: companies are scared of showing bias (whether against or for certain ethnic groups, genders etc) and a formal process should in theory be meritocratic than the old days of "let's just have a quick chat and hire based on gut feeling".
There's good reasons here, but it's probably gone to extremes, particularly for positions at smaller companies with corresponding smaller salaries and benefits.
These are actually all great reasons. Speaking from experience a bad hire can be extremely detrimental.
While all valid points i do dislike how often those tests and interviews focus a lot on areas that you will not be doing in the role. This is where I see the biggest frustrations. When we hire we do try to tailer the interview process in a related to the work involved as possible. It adds confidence that we have hired the right candidate for the job.
But usually there’s a 90 or 120-day probation period for new hires. How about letting them “interview” for the job, on the job. Screen them obviously, but after that… I mean the best way to see if they’re a good hire is to actually hire them. There’s no interview question or interview process that can perfectly duplicate that.
In the US I suspect "contract to hire" fills a similar function. I see that all the time but I don't think I've ever seen an official "probation period" on an employee role. (Could also be regional or industry dependent.)
The idea behind probation period is that it becomes much more difficult to fire someone after that due to labor laws. US doesn't have such laws, most states are at-will employment so you don't have to give any reason to fire someone.
Probation periods are seen in the US, despite "right to work" labor laws because A) the company is large and has employees in California, or another state where labor laws favor the employees a bit more or B) the company wants to minimize the chance of getting slapped with a wrongful termination lawsuit. Regardless of labor laws, it's universally illegal to discriminate/fire someone for their race, religion, gender, marital status, age, et. al. and I think companies, especially when they want to fire someone who might believe they are being discriminated against, want an airtight defense (usually a PIP). Even though the employer will probably win the legal case, they still would rather not have a lawsuit at all.
From the point of view of the applicant, I wonder if I would prefer a long probation period over a long interview period.
If I'm unemployed and I have bills to pay, a paid probation period is the better option - even if I get fired after 90 days, that's still 3 months' salary. On the other hand, if I already have a job, joining another company is a big risk - I'm giving up a comfortable position for a job I might lose in 90 days if it doesn't work out - maybe I'll be in over my head, maybe I don't get along with the manager or the team, whatever. A long interview process gives me plenty of opportunity to gauge my prospective employers and back out at any point.
Sure, but, at least in my experience, new hires are ALWAYS on probation. So to me the status quo is this: you get vetted "harshly" in the interview process, then you have to clear the probation period. That said, I think it's pretty much a given you clear the probation period if you don't clash with coworkers, and write decent code. During your first ~90 days, you're ramping up, learning the company's procedures and coding conventions (and code base itself), and getting to know your coworkers... so I think the only time probation really bites you is if it's a bad fit culturally (which I would think you're at higher risk for the smaller the company - those startups are selective as hell about who they hire).
You can and probably should negotiate that clause away. If an employer offers you an at-will contract, it should have a US salary written on it or at least a large sign-on bonus.
I've never had a job where there wasn't a probation period. It's one of my major gripes with the current hiring process. They can fire you at any point during the probation period, so why the hunger games during the hiring process itself? That's the whole point of probation periods: because sometimes they get it wrong.
My guess is because of the opportunity cost. If you hire the wrong person you end up firing 3 months later, you likely missed your chance to hire a better candidate (who is unlikely to apply again to work for you) and you will need to restart the whole expensive hiring process again (even a more lightweight process is expensive in employee time, maybe paying recruiters and job listing sites, etc).
Also onboarding is expensive: even an experienced developer who has all the skills you need still has to learn your codebase, processes, business logic etc. while drawing a salary, and all that goes to waste if they leave before they can start becoming a net positive to your company.
Perhaps this is the right place to ask -- what would be the point of a probation period in the USA? All contracts I've seen here are at will and can be terminated for any reason or no reason. Now my experience is rather that most managers are uneasy about firing, but legally they are in the clear afaiu.
Probation in Germany goes both ways. Recently I worked there at a (small end of medium sized) company where work and pay was just so-so (nice, smart colleagues though). Then in a meeting the superior or my superior mentioned that there was some redundancy. Aha, I thought, I take that as a sign and promptly resigned some two weeks before the end of the probation period. They still expected me to come in 'til the last day, which I didn't mind too much, but still found a bit silly, since both parties agreed about the separation (also given the finite funds of that company).
It provides additional legal protection to the employer in the case they decide to terminate the employee during the first X days. Additionally, it serves as a "motivator" for new employees to be on their best behavior and to give it their all, at least for the first x days.
Laws that benefit the company, such as "right to work", mean that employers will often win lawsuits from former employees for things like wrongful termination suits, however companies would prefer to not be sued at all- even if they have a strong case. Court is expensive and a hassle.
That said, I did some moonlighting work for an employment law firm, and they say that they take less than 5% of the prospective clients who contact them, because they (and most law firms who only get paid if the client wins) want to be as sure as possible they will win the case. Of course if the prospective client were willing to pay up-front regardless of the case outcome, I'm sure most law firms would oblige. In such cases, I expect the former employers like to settle out of court to save time and money, even if the odds are good that they'd win in court.
This works well. I’ve been in the industry about 20 years now and every job I’ve taken has had a short interviewing process followed by a probationary period, and then a full time offer is made after the probationary period.
I’ve only seen this approach fail once, and it wasn’t that big a deal, because very little time was sunk in to hiring the employee that had to be let go. At most a day or two was lost on-boarding.
If you have 10 promising candidates, and you'd like to hire one of the better ones among them -- then how are you going to accomplish that, with the strategy to "actually hire them"?
If among promising looking and speaking candidates, few are actually good, then what will the current employees think about people getting hired, fired, replaced a lot
This depends on where you are. What if the company is paying for the candidate's relocation? That can be quite expensive if it's international. And probationary terms might not be so easy to do in some countries.
Part of this is due to fraud from the last couple of years. I know multiple companies who dealt with remote employee fraud over the last 2 years. Companies are defensive now.
I saw a lot of that while doing phone screens: People who were getting coached via earbuds, people who were frantically searching Google for answers, etc.
The 100% virtual hiring process means that it is much easier to sub out your interview as there’s no point in the process where you show up for an on-site, present your government issued ID, and then interview.
I don’t remember ever showing my id in onsites. In some of those big places one could def skate by having someone else interview and then show up on first day and nobody would notice. Ime id doesn’t come up until hr wants work authorization on your first day
Yeah, I worked for a large employer who complained about this happening when people were onsite all day. Different people interviewed and showed up for work.
This is nothing new, it's just a media blitz by status quo lovers.
There were a few articles about people getting multiple remote jobs, doing the bare minimum to avoid getting fired for a while, eventually getting fired, and accruing large sums of money by doing that for years while presumably also holding a normal job in secret.
I think it's potentially more complicated than that. If an employer asks you if you have another job and you are working a second one, it is lying for you to say that you don't.
But what exclusive right does your employer have to your labor? That depends on your contract of course.
So if you signed away exclusive access to your labor, it's fraud. And that's not uncommon - there's often at least a "you will disclose other employment" clause in developer at-will contracts. That said, I think the only consequence of not disclosing is potentially getting fired with cause if you get found out. IANAL but I don't know of precedent for clawing back pay (which would be fitting for actual fraud).
If you didn't, then it's your employer trying to get more than they signed. And in that case, the lie is a necessary evil.
You know, when a working class dude busts his ass taking two, or even three jobs to improve his family's living standard, he's admired and they call him hard working. But when an office worker manages to slice up his day such that he can take two jobs (and do them up to performance expectations) they call it fraud. Not sure I understand this double standard. People get so hung up on this idea that full time should imply exclusive.
I think it's employers playing the game and optimizing.
Full-time employees are salaried. They cost the same no matter how much work they do. So full-time employers want them to do as much work as possible. They view time as zero-sum, so any hours you spend on another job are hours you could have spent on them. Even if - as we all know - there are diminishing returns on hours and those hours at job 2 would not produce the same output if pumped into job 1.
So, as always, full-time employers resort to soft power and psychological tricks to exert control over salaried employees. And I'd say it's increasing lately because remote work as shifted the power imbalance and employers are realizing the other side of at-will, salaried employment is that employees can work as little for them as they can get away with so long as they are good enough to remain willfully employed.
My employment agreement states that I agree to only hold one full-time job and that I agree to inform my employer if I decide to work another concurrently. This seems like pretty standard practice.
Personal favorite was refusal to turn on cameras while a different voice participated in each conversation, if at all. There was always a different reason why the camera couldn't be turned on too, while it clearly wasn't a problem during the interview. Tracked IP address access and it was hopping all over the world on a day to day basis.
Constantly acting confused after acing the interview. Never getting anything done and insisting on pairing with somebody else who just did the work for them.
Essentially the goal seemed to be to collect a paycheck for as long as possible until somebody noticed and you ended up fired. I heard variations of this from a few people and saw one first hand.
Point 3 is pretty important. I have seen so many small companies, that did not need really the very best engineer on the world to do their C# API suddenly ask Google questions straight from the "Cracking the coding interview".
Asking a 21 year old about a recursive O(nlogn) algorithm solution or how many ping pong balls fit on an airbus because you heard Google asks it when all you need is someone who can write a good integration test suite, use springboot, and create documentation for the clients to make the API useable and scalable is such a weird way to go about it.
And it seems entirely based on "if FAANG does it, it must be right".
The hardest interview in my life was a long time ago when I tried getting a part time/side job updating content on a mostly static PHP website (no database or backend). Thought this would be a nice way to get some extra beer money or something. The interviewer was the person who was currently maintaining the site and had just graduated from Yale and wanted to move on. Not a single question about PHP, javascript, HTML, instead question after question about implementing various algorithms in pseudo code. I figure he was asking me questions from a textbook or something. I didn't get the job.
Been a while since I've been in an interview but everything has been cake since.
I'll point out just one side effect. A highly qualified candidate interviews with three companies. One does two interviews in a week and extends an offer. The others take two weeks to get back to the candidate, then do two interviews and a take home, then two more rounds of interview. Meanwhile, the first offer is on the clock.
The only reason not to accept the first offer is because one of the other companies is that much better to work for. So the companies with the most onerous processes lose out on the best candidates or have to offer double the compensation to keep them in the maze.
The reality is that most companies can do fine with average employees. Bad hiring practices that lower the talent or increase costs don't kill them.
> I've yet to see any evidence that it actually does reduce bad hires
And the OP's own point "responsibility is diluted so if there's a bad hire you can blame the process rather than one manager" would be needless if the process actually did avoid bad hires.
It's not a reasoning I would agree with either. The core of my original comment is "avoid responsibility": people don't want to be held responsible for a bad hire (or a discrimination lawsuit), so adding multiple rounds to the process shares that responsibility among as many other people as possible. By cargo-culting from FAANG you can also use the "nobody got fired for buying IBM" argument and this dilutes responsibility further.
So does that actually reduce bad hires (or increase good to excellent hires)? Probably not, but that's not really the purpose of all this theatre. The purpose is that if there's a bad hire, do I, personally, get the blame?
But the silly thing it, the convoluted interviews don't avoid the risk of a bad hire because they test for the wrong things.
The analogy I use is that it's like a hospital trying to hire a heart surgeon by extensively grilling candidates on trick questions about organic chemistry. I mean sure, the surgeons probably took that class a few decades ago prior to medical school. So they end up with surgeons that are wizards in organic chemistry but might well not know how to use a scalpel or know where the heart is.
I think this actually works in their favor. If a candidate invests a week into you, they can only match that commitment a few times with other companies, and they might not actually get offers everywhere. Then you don't have to negotiate offers as hard, and they are more likely to accept your offer.
If candidates can get an offer after only a half day, they may as well have a dozen options, and you only have a 1/N chance of getting picked.
So your premise is that a company should draw out their interviewing process so that the top 60% of candidates will accept offers elsewhere and they can lowball the 40% that stick it out? And you justify this because they would only have a 10% chance of landing any of the good candidates?
I actually ran into this. I was considering two companies, both about equivalent in terms of being "places I would want to work for", but one was quick to turn around with an offer and the other dragged their feet. I went with the company that made the offer. The other company I never heard from again, despite their engineering director totally assuring me "we get back to every candidate".
> By having multiple rounds - which in turn requires a lot of people involved - responsibility is diluted so if there's a bad hire you can blame the process rather than one manager.
That's an interesting take I haven't heard emphasized before, but it seems plausible.
From the company point of view that might make sense if they don't think about the consequences. But for the person, since we all know that usually any such projects are silently rejected without explanation it's totally not worth the effort.
Having been on the inside watching some people review take-home projects and arbitrarily reject them for the most random reasons ("I don't like the way he writes comments, what a loser") I also have zero faith on them being evaluated fairly.
The only way I'd ever consider doing any kind of endurance project for an interview is if the company guarantees results if I put in the effort. Could be something like: Write code to interact with and/or provide these well-documented APIs, it'll be run against a test suite where I can see the results and it needs to meet xyz performance criteria and if you can deliver it in X hours or less we guarantee a competitive offer. Only then would it be worth the work.
But to spend a lot of time just to be ghosted? Big no to that.
Companies should be hiring people on a contract basis to perform REAL WORK. This work should ideally be the very type of work they would be doing if they were hired full time.
If they do a good job, then great! Hire them on full time.
If they don't do a good job, but they meet the acceptance criteria of the contract, then they get paid, but don't get hired full time.
If they don't complete the contract requirements, then they don't get paid at all.
This arrangement is completely fair to both parties, and doesn't waste anyone's time. It's a win/win scenario.
Unfortunately, most companies are too lazy to set up a hiring process that looks like this.
Have been hiring designers and developers for nearly 15 years. The easiest way around this is to just make a website that shows your work. Put up a small project on Github (even if it's a small hobby). A resume tells me nearly nothing and the logos on it only get you past the recruiter. It is absolutely mind boggling to me that people looking for Internet-related jobs do not own the story of their own career on a website of their making.
If I need to have a conversation with you to figure out if you know what you're doing, I'm wasting your and my time. I'd rather have a conversation about whether you're a good fit.
I've experienced the exact same thing. People would go, "After seeing your resume and noticing you made X software by yourself, I immediately installed it and it worked great. I just wanted to say thanks!"
Proceeds to ask me to solve random leetcode questions anyway.
What would you expect if it the person interviewing was a mobile developer, or backend developer? What should they put on the website? A mobile developer perhaps some screenshots of app screens? What about backend logic?
I'll give my two cents as someone who's in the same position.
I look for code style, commit messages (both proxies of quality of work), following standards, good code orga and tests. Show me that you understand why clean code is important basically
I suppose a backend engineer could produce screenshots of parts of the front-end that they helped enable, charts that visualize any improvements to metrics they made, and maybe systems diagrams to show services they built or maintained. Each one would need some accompanying text to give context
This is what has landed me 3 of my 4 programming jobs.
1. Having a web portfolio which has system designs, images, or gif videos of my apps, and points to my github code which interviewers can view.
2. Then walking interviewers through a project during the interview.
Whereas 3 months ago, I had a call w/ a "Director" of Engineering for a small startup (5-10 engineers, about 10-20 other staff). He wanted me to do a take home project. "it's just a 2 hour project: a CLI tool to lookup data via REST API, based on arguments passed in. And expose a gRPC endpoint, writte in Go or your favorite language, but we want to see it ready for production with tests". Everything except the REST API part was new to me: a CLI framework, gRPC, protobuf typing stuff.
Three hours in, I realized I crossed my self-imposed timebox and that the project would really take about 8 hours (or perhaps 16 if I wanted to polish it and have a higher rate of getting hired). However, I was on my vacation and the purpose was to spend time away from technology.
in my opinion, all job postings shall state their pay ranges in the title, to avoid wasting everyone's time.
followed with key requirements, locations(and if remote is OK)
followed by your interview process steps.
that's all I need, I don't need schedule a 20-30 minutes call for each recruiter for info I can filter in a 2-minute read, in fact a twitter-size job post can cover all the essentials before any meaningful talk, why making a lengthy process longer than necessary.
and, if you're asking for many years experience for a junior position, or you're asking a senior developer to be great at leetcode challenges, you might be doing something wrong.
Nobody gets a CS degree dreaming of working for Walmart, but they have 1315 openings with the word “software” in the title. Many jobs are in CA, TX or WA
My brother has been a software engineer since 1996. After working exclusively at mid-to-large tech companies, he started working at a very large national retailer in 2019, mostly because he wanted to move closer to family and that was one of the few good employers around.
He now says that this has been the most fulfilling job he's had. This retailer was working on ancient systems that, while old, were exceptionally well-designed. Moving these systems over to a modern tech stack was challenging but also incredibly rewarding.
I work in finance and a lot of my job is getting the right numbers to come out of the system in the desired timeframe. To my son that sounds boring, and he asked me if I'd switch to work on VR or something flashier. I told him that there's a lot of challenge in solving the problems that I do, and I wasn't sure that optimizing rendering or something in VR would be more rewarding or not (not to mention I'd have probably been laid off by now anyway). I suspect the challenge and reward is the same but using different tech stacks.
Working for a non-tech company can feel different though, because they are less developer-centric. Especially in the early days I remember many weird conversions I never had before: why do you need this weird software on your computer, or even admin rights? Do you really need that expensive computer/phone/monitor for your development, it's not the company standard? Why do you need to access non-standard ports via VPN?
On the other hand, I really enjoy working on things that benefit non-tech users and solve "real-world" problems.
Walmart, CVS, and Target are not sexy at all (on the tech side). But they're stable, pay well, and you get to work on interesting technical problems that actually matter. You are more likely to deal with an interesting issue at WCT then at a FAANG, there's less red tape to deal with, and everything is just better designed in general since it needs to be reliable.
If you're still there after a year you'll probably spend your career there.
Not too long ago I was approached by a recruiter from Walmart for a role that was deeply technical in areas that I never would have imagined Walmart to be hiring for. So they seem to have some great teams doing interesting tech work.
Unfortunately they wanted on-site presence in a different state than where I live so couldn't go forward with it. Otherwise might well have taken it, to my surprise.
I can't pair program, especially not in an interview setting. Being watched makes me so nervous that I can't think straight, unless it's someone I know well. I also can't think and talk at the same time, and someone talking to me makes me lose my entire train of thought. I don't think I'm the only one.
You're not the only one. I will say that comfort often comes with practice.
I do pair programming sessions with people as part of my job. This has made me a substantially better at pair programming as part of interviewing (on both sides). Perhaps it would be worthwhile for you to time to work with some colleagues to build some of these muscles.
I do agree that alternatives should be offered if someone is uncomfortable.
Then you are not gonna do well in any interview or team setting; which basically disqualifies you from working in this field unless it’s open source or something.
Pair programming is quite rare in most orgs. Most code is discussed async after its been written. A take home test where you modify some existing code based on new business requirements would be far more similar to the real job. LIVE Discussion about the requirements before or code after would also be similar.
Interviewers all seem to state the problem and then let me work quietly between a few clarifying questions. My impression of pairing is a lot more talking with no time to start thinking.
What on earth are you talking about? I’ve been in the industry a really long time and have never seen anyone actually pair program. The entire concept of pair programming is silly. If anything it’s ear phones on and don’t bug me.
I don't think it's the same at all, because people aren't watching every character you type, including the mistakes.
My mother told me I spoke very little as a child, but in the evening she could hear me practising words outside my bedroom door. I suppose this is some deeply seated neuroticism.
This is very close to what our company does, and I think it's a great process. We like to give a two part problem - something relatively simple like an "early-December" Advent of Code problem. We give the first portion as a take-home project, then do a pairing style interview, where we spend a little bit of time discussing the solution, and then pair on the second part.
We see how the candidate approaches problems from their initial solution, and then we get to see how they react to being asked to extend things. We get to talk to them about how easy their code is to change, how their tests helped support the changes. We get to see them work through a problem under slight pressure, and hear them communicate with a partner about the problem.
* We keep the problem easy like the one above because we're not trying to see if a person is a genius or has memorized a lot of algorithms. We just want to get a basic pulse on their skill level. For a junior dev, this kind of problem is doable but might take a little while. For a senior, this should be basically trivial.
* When I mention that a candidate is under some pressure, I don't mean that we add any artificial pressure - that would be dickish. I just mean that interviews are naturally a bit of a high-pressure situation, so we get to see if they keep their cool, etc.
* The candidate drives, but we try to approach the problem as a real pairing situation, so the candidate should talk through ideas with the interviewers, the interviewers can and should _actually help_ solve the problem, etc.
* The "take-home" portion is designed with the intent of not taking up more than an hour or so of the candidate's time, and is really there just to give us a starting point to talk about. It also ensures that the candidate has a project set up and ready to go for the interview in the language of their choice, which eliminates a lot of churn from the beginning of the interview.
I helped design the process so I'm biased, but I think it's extremely effective.
I would hate that and do terrible myself. I need to focus to do my best and having another person around to interact with would be a huge distraction. Plus in 25 years of working on software I've never produced anything of value working that way.
Hell no. If I could possibly smell whether you had a shower this morning, you are too close. I'm not going to share a keyboard, terminals are cheap and have been for a long time.
This is a cultural thing. Don't expect me to become a new person to fit into your work flow.
Now I know that buddies of mine did great work like that as teenagers creating games (and some sold reasonably well), so yes this can work beautifully. Thing is just, you're not my buddy and I'm no teenager any more.
I participated in a paired programming interview once. I didn't get the job, but I walked away with respect for the organization doing it.
It gave them a chance to see how I worked as part of a team. Even if day to day I'm not pair programming, it starts off the relationship saying "If you need help on a problem, you can be comfortable working with your teammates."
The great thing about the setup is that it doesn't have to be a unique or complex problem. "Write a function to reverse a string. We'll write unit tests in parallel with that."
Or one of the thousand other problems. You're not testing algorithms here, you're testing whether the candidate is arrogant. Or talks too much. Or doesn't ask for help. What happens when they get stuck?
You're right, it's a lot of effort. But the resources spent on a bad hire can be even more expensive.
Not only for developers. My current "favorite", which I hope is never surpassed, was a 3+ months long process involving nearly a dozen different interviews, essays, tests, an interview with the CEO who actually approved hiring me, a direct statement that I was the only person who had made it through all of that and that it was probably impossible to find someone better suited for the specific role, and, then, nope.
Developer hiring is exceptionally awful for lots of reasons, but there are wider problems now.
No doubt, the number of interviewing antipatterns out there is nuts. Leetcode games, hiring by committee, and a market flooded with candidates with resumes that look and read the same.
On the flip side, I’m interviewing candidates with a decade of experience (per their resume) that can’t discern the difference between basic data types and how they are stored with the very language they claim expertise.
Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well.
If you’re skilled, don’t despair. Most companies are terrible at hiring and terrible at business as well. Those rejections from the gauntlet of flaming hoops they make your jump through are doing you a favor.
Rejection is God’s protection and all that. And I like to think that’s right.
I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews, and I’ve always wondered if they really don’t know these things, or if it’s just the environment- like in my experience I can wax and wax and wax in a non-interview setting, but in an interview setting, even from the comfort of my home office, I seem to block out- not forget, because in the moment I know I know something- parts of my knowledge. You might say “well you should practice interview more” or something to that effect, but I have to wonder, if so many developers seem to “know nothing” despite their supposed experience, perhaps it’s not that they “know nothing”.
On my LinkedIn I have the following: what I currently get paid by my current employer (!!!), what I am looking for in my next role, both regularly ignored by recruiters of course, and then I have links to my StackOverflow, Medium and Github profiles, any of which ought to demonstrate my “expertise” as well or better than an interview ever could. Heck if you just read some of my answers to StackOverflow questions, I think you’d see I am capable of writing code for your company…
> I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews
i cant remember who said it but many people with 10 years experience really have 1 year of experience and 9 years performing tasks doing the same thing over and over.
First of all, software frameworks and technology evolve. Second, it's pretty hard to find someone who worked for 10 years at the same company with the same software project doing CRUD actions.
On the other side, if you meet linux kernel engineer who maintained kernel for the past 10 yers, this argument fails short. Same for someone who worked on Postgres internals.
> and 9 years performing tasks doing the same thing over and over.
I mean that's what experience is.
If I want an expert in x, I want someone who has being doing x for ten years. I don't want someone who has dabbled in ten different things in ten years, thus having very superficial exposure to ten things and expertise in nothing.
If I need a heart surgeon, I want the doctor who has been doing only heart surgeries for a couple decades. That's an expert. I certainly don't want some doctor who has been switching from heart surgery to podiatry to dentistry and on and on without specializing in anything.
Most people aren't this consistent. At work does someone say that I will watch you code in a particular time of the day and you will be able to perform on a random question that's useless?
No.
Interviews have 0 context that's needed for anyone to perform. Usually you can't use your IDE, your settings or your ways of working and you've never paired up with the interviewer so might not feel comfortable.
To make matters worse the interview topic is 90% chance not what you do on a day-to-day basis. No 1 is answering leet code questions at work. We're going to be using a library or tool and not to try write an analytics algorithm.
Another harsh reality is that for most jobs, the initial interview is by far the hardest part of the job. Once you pass it, the rest is cake. It takes a lot less effort and brainpower to keep a job than it does to get it.
I still look back to a FAANG interview a decade ago being the most difficult thing I've ever done in my life, and I've worked my way up from a shit mining town to the middle class, developed a complete complex software product starting from an empty text file, gotten an advanced degree, built a single engine airplane, and managed to stay married for 20 years. But out of all that, a stupid FAANG interview was the most difficult. It's just ridiculous what companies put people through.
I've bombed interviews numerous times only for the answers to come to me when the interview is over. My best outcomes are when I am relaxed (already have a job ;)) and I've gone through some basic material and whipped up some example programs.
I've never had a problem in a real world setting or writing code.
Its just so different talking while being judged by people you dont know, throws things off. I bombed a few last time, one in particular where I was writing a switch statement. They wanted me to use a map. They asked what if the cases kept growing and... it didnt occur to me to use a map.
Im sure i looked like a novice. But in my day to day code... i flip between maps and conditionals and switch statements all the time, with ease. Its natural. But while interviewing? It just doesn't come out of me.
It’s weird because at the end of the day, it shouldn’t matter. I’m about to interview for a job two states away. If I fail, well I fail. The worst outcome is status quo, but I’m still terrified of looking like an idiot tomorrow.
There are developers great at solving business problems, which is what the vast majority of companies actually want.
And there are developers who say things like "[other programmers] can’t discern the difference between basic data types and how they are stored with the very language they claim expertise"
That's not the actual job we do. Unless you happen to write libraries or crazy high performance code.
Most of the time it doesn't actually matter how the data is stored in the language, it actually matters how it's stored in the DB. Because that's where the performance problems are.
Most of us don't even have to remember that, even if we ever learnt it. It simply doesn't matter.
Most of our jobs are to turn business requirements into working programs. That makes us an expert, not knowing a language spec verbatim. That doesn't matter at all. It's a meaningless metric.
It reminds me of a colleague who could tell you all the performance problems of += vs StringBuilder but shipped sweet FA for 6 months. And do you know what the difference actually is? Nanoseconds. NANO.
Or the person who seemed to be able to quote the entire SQL manual, yet typed with one finger and spent 3 months building a 10 line SQL statement.
Or the colleague who could give you text book definitions of every design pattern you can imagine, but when asked why they'd implemented a complicated mediator pattern for saving simple forms couldn't explain, "that's how it's done!".
And when I ripped out the several thousand line monstrosity and rewrote it in 100 lines or so, they still admantantly said it was better even when presented with load tests that showed the new code was orders of magnitude faster.
What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. Sometimes they intersect. Sometimes they don't.
> There are developers great at solving business problems, which is what the vast majority of companies actually want.
Many developers find themselves in a position of being a subject matter expert in a particular business or industry, and that becomes the primary value they deliver. They remember where that error message originates or why that column in the database is named so strangely. They know the lingo and business quirks inherent to their industry.
Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly. Their programming muscles atrophy while their subject matter expertise grows. But that knowledge doesn't always transfer well.
I've fallen prey to this trap (personally) on more than one occasion, getting lost in what I was doing instead of seeking to better understand what I do.
> What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two.
I'm recruiting problem solvers, and I think it's necessary to understand the tools you are using to solve problems at least one level deeper than autocomplete shows.
Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort. When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags.
Sure, tools and language (e.g. Javascript) often abstracts much of the details away, but my experience is that those developers with a familiarity of those details and why they matter (even if they might need an occasional reminder from a search engine) are a cut above.
> When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags.
Why do you feel this is important? To clarify, what are you testing here?
It’s important because "001234500" and "01234500" are two strings that don’t compare equal (and that sort in a specific way), but after conversion to an integer they do compare equal. When you use such a value as an ID, for example, the type you use makes an important difference here.
It shows that you understand how equality relates to values and data types, and that changing the type of something can make the same conceptual operation behave differently. This is the kind of fundamental technical understanding and precise thinking you want a developer to be absolutely familiar with.
Actually, in the old days a string number with a leading 0 in javascript got parsed as an octal. You used to have to do parseInt('0012345', 10) to get it to parse properly.
Faced a similar issue in Java. Someone decided it was a good idea to convert string postal codes to int. For sorting... Using Integer.decode()... Everything was ok until a "09677" show up.
> Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly.
That's what the majority of all the industries on the planet are doing. Repeating the correct patterns in the right place and right time. The value is knowing the right patterns and repeating them at the right time and place.
And it makes sense - how many different ways are there to iterate and manipulate a given set of data that contains customer/user records, orders, social post meta or whatever is commonly used in modern tech? Aside from very specialized organizations that are working on the cutting edge of the tech in this or that specific sub-specialization, most of what we are doing is juggling data in the same way everyone does. The chances of anybody bringing a totally new way to juggle that data through exemplary and precise knowledge of the language are ultra slim. And if that ever happens, everyone would soon know and start using that method anyway. Which brings us to the point below:
> I'm recruiting problem solvers, and I think it's necessary to understand the tools
The problem solvers would know that we are living in 2023, and not only the abstractions that we use, but also the stacks and languages that we use have evolved to handle as much as they can to make our work easier, including data types and their manipulation. The memory space inside a developer's mind that is allocated to knowing those data types and manipulating them manually is memory space that is wasted and not being used for remembering other things and increasing his or her impact.
If your logic held out, we would still be manually allocating memory in our programs. We dont. Those who need to know allocating memory on a daily basis and needing to not letting that knowledge atrophy are those who work on hardware, low level hardware-softare interfaces, those who build and maintaing languages, packages, or stacks for industry-wide use. Not the developer who solves !business! problems.
> Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort
Yes. And that's what enables them to take on the ownership of increasingly broader features and systems. In the same way it enables even fewer founders to bootstrap or launch more complex startups. Everything we do in tech is for automating, optimizing and making easier a given level of problems to be able to rely on that automation to move on to the next level.
> Sure, tools and language (e.g. Javascript) often abstracts much of the details away
Yes. They do. Every stack, language, framework does. That's what amplifies productivity. Not holding on to knowledge you will rarely ever use.
...
The difficulty of modern tech is in creating reliable, user-friendly and cheap systems that bring advanced technology to the masses. Anything that prioritizes specialized knowledge on what is already handled by the existing technology stack is more academic than anything practically engineering related. Such approaches could exist inside gigantic old-school organizations like IBM when they had their heyday, and they did exist inside tech gians which literally made themselves a continuation of the colleges which their founders graduated from, fueled and floated by zero-interest investor money, prioritizing only 'growth' without paying attention to the business fundamentals. But in the new, non-zero-interest economy, they can hardly be justified.
> The value is knowing the right patterns and repeating them at the right time and place.
And that discernment, at least in part, comes from understanding what that code is really doing.
I get 45 minutes face-to-face to develop an opinion as to whether or not a candidate can do the job well. I value candidates who’ve not only asked “what?” but have also asked “why?”
I’ve no doubt my approach has filtered out people who would have done good work. I’ve certainly passed people through that didn’t work out for various reasons. But generally, my approach has served me well so far.
> comes from understanding what that code is really doing
It does come from understanding the !business code! that is involved. Not the rarely important features of the underlying language that the stack, the framework or the models handle.
Which makes that argument further moot - you should not be messing with how the models or the framework handle those data types. There is a reason why they were built and deployed.
In regards to experience, I’ve noticed this too. I took over the lead position at a company with multiple senior engineers that wouldn’t pass a junior interview with me. No intuition for time complexity and not a care in the world to reuse functions etc (every task was a from scratch build out of mostly duplicate code) etc. the worst was a guy who claimed 15 years experience
> Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well.
LOL I've noticed this too! Somebody must be out there teaching people to do this! I mean I interview people, and they are so over-prepared with their sound bites and their canned speeches, and they deftly try to steer all conversations back to topics they are prepared with. Their style, body language and communication tactics are polished and sophisticated. They sound very pleasing. Their slick enunciation, cadence, and confidence make them sound like 20 year NPR veterans. But the content itself is a millimeter deep. It probably fools the exec class, but it doesn't fool a practicing engineer or technical manager in the trenches.
I'm not a dev anymore, but even when I was decent to good with multiple languages over the years, I would not have known this.
I do remember being in interviews where one smart person on the other side of the table asked me some piece of tech that was mostly specific to their daily use, and when I didn't know it, they were shocked -- shocked, I tell you.
" I've been in the market for a couple of months, and I have no idea what employers are looking for"
IMO that's because they (employers) too have no idea what they are looking for. It's a mess and only getting worse.
My 2 cents is just say yes to that rare proposal that comes after one or 2 interviews. And yes, they do exist but almost everyone passes them because "if it was so easy the role must suck". Well, the possibility of role sucking is exactly the same if you went through 10 hoops to get the job.
I’ve been doing this for a long time now, and I’ve had good results from companies with humane interview practices.
Places that treat candidates poorly tend to treat employees badly, and companies that drag out the interview process tend to miss out on in-demand talent.
As a result, places that respect your time and well-being have been more likely to have good engineers who have stuck around. Places that are toxic and/or bureaucratic tend to combine bad hiring with high turnover and create a terrible environment.
My current company has the most humane interview process I have ever experienced. When I started I was shocked by how many good engineers had stuck around for 5+ years, a few for more than 10. That's crazy for a non-FAANG non-legacy software company. It turned out to be a great sign that the company respects one's time and well-being!
I don't think this anecdotal reddit post says much of anything. We don't know the persons resume/background/experience, nor the position. $65/hr with 10 years of experience is uber low. That rate is comparable to FANG intern pay. You could find a contract job 15 years ago paying that, working for some insurance company or large boring bank. It just sounds like a shit job at a shit company. Probably located in a small market/geo. OP also says "actual client" - so this job is likely via a third party (either a staffing firm or some MSP); AKA that $65/hr rate is even lower than it should be, because the third party needs to take its 20-40% cut.
Hey everyone, if you're frustrated with interviewing processes I high recommend build your own company. You do not have to aim for 1 billion USD valuation after 5 years. Just aim for happiness and make your customers happy too. It is not as hard nor scary as many of you think it is. It requires you to take responsibility though. The world is still mostly running on spreadsheets and we all know software developer skills can transform spreadsheets into better business value.
It’s true, and partially why I pivoted away from web development. Web development is so repetitive. It can be oversimplified to “make me a GUI for this database”. Yawn. I didn’t want to spend the rest of my life correcting my CSS and JS for subtle changes to browser engines. When IE died, Safari took over as the “problem browser”. I think there will always be a “problem browser”.
It's very difficult to pull off though. Especially outside the US. My advice is:
- Don't aim too big (there will be way more competition if you're trying to build a world-changing product).
- Don't go into any sector where big tech corporations are already offering products (no matter how bad those products are, you will not be able to compete on marketing; nobody will find out that your product exists).
- Find a niche. The more boring and tedious the niche, the more likely you are to succeed.
Basically, base your entire strategy around minimizing competition at all costs. Do not underestimate competition. Do not underestimate the power of a great big pile of capital in the hands of your competitors; no matter how terrible they are.
This is not capitalism. This is crony-capitalism. NEVER FORGET THAT. As you rise up the ranks, prepare for less ass kicking and more ass kissing.
264 comments
[ 4.2 ms ] story [ 244 ms ] threadThey had an online test to take that I had to pass in order to actually have an interview (or more, I don't know how it worked with them).
Anyway, the task they sent me was estimated to take 8 hours of work and couldn't be paused.
I was on vacation, I didn't want to bother so I just declined.
Once I was given a task to create some validation code for given criteria and integrate it in the given project.
They then invited me to an in person interview. At one point, I had to pair program with one of their developers and what I saw kind of shocked me. They integrated my code from the interview into their production code and their developer had an issue with it and asked me to help getting it working and write a couple of extra tests. So I did and they seemed very happy.
I didn't get the job though. They said I am not a "cultural fit".
I asked them if they actually used my code and if so they would have to pay me for the whole day, but they never responded afterwards.
I decided it wouldn't be worth to legally pursue, but since then I decided to not do any pair programming or coding tests.
I aced it, they were more than pleased, yet in the end they did not hire me as they said that they are actually closing the position because of the market downturn. At least they gave me a 50€ amazon gift card..
That's a codeword to cover racism, sexism, and/or ageism.
They solicit a huge amount of applications but very rarely hire people who make it beyond a year.
Although I'm on the Java side, I've yet to see a leetcode interview in CH, maybe I got lucky so far, but most of the interviews I had before were completely reasonable, maybe even too easy. The one that I failed miserably was an architecture discussion, in which I got an empty paper with a pen, and was expected to come up with the design of their existing system (I was allowed to ask questions). But even from that I learned so much, so no hard feelings. I will know much better what to do next time :)
I'm still getting offers to interview daily. I've helped people land jobs, but all of mine have been posted online and applied to by me.
Just another data point.
The personality tests can fuck right off, though. Agree with that.
When I see an error, it bothers me.
Mostly agree
Somewhat agree
Neither agree or disagree
Somewhat disagree
Mostly disagree
Of course I support the organization, and I think being honest with superiors is the best way to do that.
In the end, these things are so imprecise that you have to get to know somebody to know which parts are accurate (some were) and which aren't. By †he time you know how accurate it was, you know the person well enough to not need the test.
Openness - how easily you are willing to accept new ideas
Conscientiousness - how careful and how hard working you are
Extraversion - how quickly you are to engage with the outside world
Agreeableness - how quickly you are to agree versus disagree
Neuroticism - easily experienced negative emotions
Most people aren't a point on the spectrums, they have a range. For example a lawyer might be very disagreeable at work when talking with opposing counsel, but very agreeable when dealing with their children.
I had one job that was absolutely awful, and to be brutally honest my attitude sucked. I wasn’t as nice to my coworkers as I wish I had been. I wasn’t a complete asshole or anything, and my behavior was never raised with me as being problematic, but I’m not proud of how I acted through that time.
But over the course of a fairly long career I’ve gotten a lot of comments about how laid back and friendly I am, and how I tend to go out of my way help people. I like to think that’s who I really am, but I can definitely be unpleasant if I’m miserable.
First, the trait examined is a range and is also situational. Second, your self knowledge of your ranges and situations is also variable and introduces more error. Third, the test introduces more error, it seems. Nobody on this thread has given any evidence this is a useful hiring tool.
My impression is hiring is difficult and there's no shortage of companies pretending to solve it with science, but it's not solved and it's not science.
In fact stability is the strength of Big5. People's personalities seem to be stable over their lifetime. See the 3rd paragraph [0].
The weakness of Big5 is it may/probably does not capture everything. It seems to completely miss abnormal personality traits. Which in a job interview... I hope has been ruled out with initial screening.
[0] https://archive.org/details/psychology0000scha/page/475
Until risk to the business increases, a possibly worthless speedbump on the hiring path doesn't hurt hiring and effectively makes more work for the HR manager's team, which means team growth - HR win!
As a rule of thumb, if it involves psychology, the answer is always no. Humans do not have the ability to do valid experiments to verify claims, so it is all BS.
As someone else mentioned here, Walmart apparently has over 1000 software related openings right now. I know a few companies outside the traditional 'Silicon Valley' company ecosystem trying to hire developers and I can promise you they're not getting 100s of applications within a few hours. The jobs are definitely out there, they're just not where most people are looking and perhaps not in a field, company or geographic location that are most people's first choice.
I agree that personality is an important thing to consider in interviews. But trying to gauge it with tools like that is at best a waste of time and at worst actively misleading.
No, neuroticism isn't what you are looking for either, neither is conscientiousness. It can be argued that for an academic position you would want high conscientiousness, but I think many would argue that you want some of your professors to have disorganized, messy offices.
This is because the "Myers-Briggs" is hogwash, with as much predictive power of personality as astrology. i.e. none.
If the people administering them are using them for the intended purpose, they're rejecting candidates on nothing more than a roll of the dice. If not, then as others suggest, they are covert way of "screening for neurodivergent people""
So: This _personality test_ can fuck right off.
I doubt that any other quick multiple choice questionnaires are much better. If anyone wants to claim that they're worth anything, show the proof please.
https://www.vice.com/en/article/bjv8y5/the-myers-briggs-pers...
https://amanda-obryan.medium.com/9-reasons-the-myers-briggs-...
https://www.businessinsider.com/most-personality-tests-junk-...
Throwing shit around is a red flag, though.
> Do not post here unless you have minimum 3 years experience.
https://www.reddit.com/r/ExperiencedDevs/comments/10b4x3e/is...
It seems there is a mismatch currently in the market, between what companies are demanding, and what employees are offering.
I am honestly thinking of creating a service, where I would create a database full of developers looking for work, and then only give access to companies seriously looking to hire, so basically like LinkedIn but minus the trash and spam.
A reminder that your pay corresponds with your expected skills, hiring a top 1% de offering market average, is a delusion. But the interview process is out of control for devs, and basically non-existent for managers.
Ps: I'm a manager, so I can say that I'm overpaid for what I deliver, while devs are underpaid and the expectation on them is out of reality.
If you are able to recognise this, surely you have the power and the incentive to change this?
As a rule, people are not paid "what they are worth", they are either paid market rates or convince the company they have a differentiated skillset that warrants compensation beyond what is normal in the market (usually by tying their performance to some important metric). No one has yet found a way to change this from within a corporate structure.
Except in the tiniest of startups, managers and even directors have just about zero say in compensation ranges.
From your POV what do you think we should do?
That said, without a link to the resume, it's not even an anectdote, it's just venting out.
I held out for something better.
The place I'm currently at is hiring a principle engineer. I've performed a few tech interviews so far. We just started the process less than a month ago.
We have (2) interviews. The first is more of a soft skill analysis (casual conversation) that the engineering manager does and the second is a tech interview. Each are 1 hour long and are usually scheduled on different days. There's no algorithms, whiteboarding, puzzles, take home tests or desktop sharing. We just video chat about a range of tech topics for an hour and ~20% of the time is left to ask us questions.
In the past I've mentioned that if I were ever in a position to hire someone I think it's possible to accurately identify someone's skill sets with a casual conversation and I still believe that[0]. No matter how good of a speaker you are you can't BS your way through certain kinds of practical tech questions. You either know them and can explain them in detail or you can't. There's a million little things to pick up on through out the conversation which weigh in on being a hire or not-hire in the end.
[0]: There's exception of course, my specific case applies to fairly standard web apps (something comparable to GitHub or Shopify in scope). Exceptions would be hardcore low level programming.
1. There's a lot of risk aversion in corporate culture these days, the cost of a bad hire can be very high and nobody wants to be held responsible. By having multiple rounds - which in turn requires a lot of people involved - responsibility is diluted so if there's a bad hire you can blame the process rather than one manager.
2. It's an endurance test. Someone who can power their way through round after round of interviews, home projects, online tests and so on shows good "work ethic" or at least a genuine interest in the job.
3. Cargo-culting FAANG. If Google or Meta do this, then we should too (even though we're a tiny startup). It's a bit like picking microservices or Kubernetes: there's good use cases, but for a lot of projects they are overkill.
4. Concern about discrimination: companies are scared of showing bias (whether against or for certain ethnic groups, genders etc) and a formal process should in theory be meritocratic than the old days of "let's just have a quick chat and hire based on gut feeling".
There's good reasons here, but it's probably gone to extremes, particularly for positions at smaller companies with corresponding smaller salaries and benefits.
While all valid points i do dislike how often those tests and interviews focus a lot on areas that you will not be doing in the role. This is where I see the biggest frustrations. When we hire we do try to tailer the interview process in a related to the work involved as possible. It adds confidence that we have hired the right candidate for the job.
Also, even with a probation period, a bad hire can damage morale and waste a lot of the team’s time.
If I'm unemployed and I have bills to pay, a paid probation period is the better option - even if I get fired after 90 days, that's still 3 months' salary. On the other hand, if I already have a job, joining another company is a big risk - I'm giving up a comfortable position for a job I might lose in 90 days if it doesn't work out - maybe I'll be in over my head, maybe I don't get along with the manager or the team, whatever. A long interview process gives me plenty of opportunity to gauge my prospective employers and back out at any point.
Also onboarding is expensive: even an experienced developer who has all the skills you need still has to learn your codebase, processes, business logic etc. while drawing a salary, and all that goes to waste if they leave before they can start becoming a net positive to your company.
Probation in Germany goes both ways. Recently I worked there at a (small end of medium sized) company where work and pay was just so-so (nice, smart colleagues though). Then in a meeting the superior or my superior mentioned that there was some redundancy. Aha, I thought, I take that as a sign and promptly resigned some two weeks before the end of the probation period. They still expected me to come in 'til the last day, which I didn't mind too much, but still found a bit silly, since both parties agreed about the separation (also given the finite funds of that company).
Laws that benefit the company, such as "right to work", mean that employers will often win lawsuits from former employees for things like wrongful termination suits, however companies would prefer to not be sued at all- even if they have a strong case. Court is expensive and a hassle.
That said, I did some moonlighting work for an employment law firm, and they say that they take less than 5% of the prospective clients who contact them, because they (and most law firms who only get paid if the client wins) want to be as sure as possible they will win the case. Of course if the prospective client were willing to pay up-front regardless of the case outcome, I'm sure most law firms would oblige. In such cases, I expect the former employers like to settle out of court to save time and money, even if the odds are good that they'd win in court.
I’ve only seen this approach fail once, and it wasn’t that big a deal, because very little time was sunk in to hiring the employee that had to be let go. At most a day or two was lost on-boarding.
If among promising looking and speaking candidates, few are actually good, then what will the current employees think about people getting hired, fired, replaced a lot
The 100% virtual hiring process means that it is much easier to sub out your interview as there’s no point in the process where you show up for an on-site, present your government issued ID, and then interview.
This is nothing new, it's just a media blitz by status quo lovers.
But what exclusive right does your employer have to your labor? That depends on your contract of course.
So if you signed away exclusive access to your labor, it's fraud. And that's not uncommon - there's often at least a "you will disclose other employment" clause in developer at-will contracts. That said, I think the only consequence of not disclosing is potentially getting fired with cause if you get found out. IANAL but I don't know of precedent for clawing back pay (which would be fitting for actual fraud).
If you didn't, then it's your employer trying to get more than they signed. And in that case, the lie is a necessary evil.
Full-time employees are salaried. They cost the same no matter how much work they do. So full-time employers want them to do as much work as possible. They view time as zero-sum, so any hours you spend on another job are hours you could have spent on them. Even if - as we all know - there are diminishing returns on hours and those hours at job 2 would not produce the same output if pumped into job 1.
So, as always, full-time employers resort to soft power and psychological tricks to exert control over salaried employees. And I'd say it's increasing lately because remote work as shifted the power imbalance and employers are realizing the other side of at-will, salaried employment is that employees can work as little for them as they can get away with so long as they are good enough to remain willfully employed.
They're all very similar, American salaried at-will agreements.
They say that
1. I must disclose any prior agreement that may affect my eligibility to be employed by Employer.
2. I must disclose any outside activities.
3. I am employed at-will.
(2) doesn't mean I can't have another job, but combined with (3) it does in practice.
Constantly acting confused after acing the interview. Never getting anything done and insisting on pairing with somebody else who just did the work for them.
Essentially the goal seemed to be to collect a paycheck for as long as possible until somebody noticed and you ended up fired. I heard variations of this from a few people and saw one first hand.
Asking a 21 year old about a recursive O(nlogn) algorithm solution or how many ping pong balls fit on an airbus because you heard Google asks it when all you need is someone who can write a good integration test suite, use springboot, and create documentation for the clients to make the API useable and scalable is such a weird way to go about it.
And it seems entirely based on "if FAANG does it, it must be right".
Been a while since I've been in an interview but everything has been cake since.
The only reason not to accept the first offer is because one of the other companies is that much better to work for. So the companies with the most onerous processes lose out on the best candidates or have to offer double the compensation to keep them in the maze.
The reality is that most companies can do fine with average employees. Bad hiring practices that lower the talent or increase costs don't kill them.
And the OP's own point "responsibility is diluted so if there's a bad hire you can blame the process rather than one manager" would be needless if the process actually did avoid bad hires.
So does that actually reduce bad hires (or increase good to excellent hires)? Probably not, but that's not really the purpose of all this theatre. The purpose is that if there's a bad hire, do I, personally, get the blame?
But the silly thing it, the convoluted interviews don't avoid the risk of a bad hire because they test for the wrong things.
The analogy I use is that it's like a hospital trying to hire a heart surgeon by extensively grilling candidates on trick questions about organic chemistry. I mean sure, the surgeons probably took that class a few decades ago prior to medical school. So they end up with surgeons that are wizards in organic chemistry but might well not know how to use a scalpel or know where the heart is.
If candidates can get an offer after only a half day, they may as well have a dozen options, and you only have a 1/N chance of getting picked.
Let me guess, are you an actual hiring manager?
That's an interesting take I haven't heard emphasized before, but it seems plausible.
From the company point of view that might make sense if they don't think about the consequences. But for the person, since we all know that usually any such projects are silently rejected without explanation it's totally not worth the effort.
Having been on the inside watching some people review take-home projects and arbitrarily reject them for the most random reasons ("I don't like the way he writes comments, what a loser") I also have zero faith on them being evaluated fairly.
The only way I'd ever consider doing any kind of endurance project for an interview is if the company guarantees results if I put in the effort. Could be something like: Write code to interact with and/or provide these well-documented APIs, it'll be run against a test suite where I can see the results and it needs to meet xyz performance criteria and if you can deliver it in X hours or less we guarantee a competitive offer. Only then would it be worth the work.
But to spend a lot of time just to be ghosted? Big no to that.
Companies should be hiring people on a contract basis to perform REAL WORK. This work should ideally be the very type of work they would be doing if they were hired full time.
If they do a good job, then great! Hire them on full time.
If they don't do a good job, but they meet the acceptance criteria of the contract, then they get paid, but don't get hired full time.
If they don't complete the contract requirements, then they don't get paid at all.
This arrangement is completely fair to both parties, and doesn't waste anyone's time. It's a win/win scenario.
Unfortunately, most companies are too lazy to set up a hiring process that looks like this.
If I need to have a conversation with you to figure out if you know what you're doing, I'm wasting your and my time. I'd rather have a conversation about whether you're a good fit.
I interviewed at one place that used my work and ran my code in production. Still had to do a take home test.
Which is fine, I quite enjoy them.
Proceeds to ask me to solve random leetcode questions anyway.
I look for code style, commit messages (both proxies of quality of work), following standards, good code orga and tests. Show me that you understand why clean code is important basically
1. Having a web portfolio which has system designs, images, or gif videos of my apps, and points to my github code which interviewers can view.
2. Then walking interviewers through a project during the interview.
Whereas 3 months ago, I had a call w/ a "Director" of Engineering for a small startup (5-10 engineers, about 10-20 other staff). He wanted me to do a take home project. "it's just a 2 hour project: a CLI tool to lookup data via REST API, based on arguments passed in. And expose a gRPC endpoint, writte in Go or your favorite language, but we want to see it ready for production with tests". Everything except the REST API part was new to me: a CLI framework, gRPC, protobuf typing stuff.
Three hours in, I realized I crossed my self-imposed timebox and that the project would really take about 8 hours (or perhaps 16 if I wanted to polish it and have a higher rate of getting hired). However, I was on my vacation and the purpose was to spend time away from technology.
The whole thing felt a bit silly. Learned a new framework though so that was cool (yargs -- https://www.npmjs.com/package/yargs ).
followed with key requirements, locations(and if remote is OK)
followed by your interview process steps.
that's all I need, I don't need schedule a 20-30 minutes call for each recruiter for info I can filter in a 2-minute read, in fact a twitter-size job post can cover all the essentials before any meaningful talk, why making a lengthy process longer than necessary.
and, if you're asking for many years experience for a junior position, or you're asking a senior developer to be great at leetcode challenges, you might be doing something wrong.
https://careers.walmart.com/results?q=software&page=1&sort=r...
CVS has 492
https://jobs.cvshealth.com/job-search-results/?keyword=softw...
The non-tech Fortune 500 companies are still hiring. Go down the list
https://fortune.com/ranking/fortune500/
He now says that this has been the most fulfilling job he's had. This retailer was working on ancient systems that, while old, were exceptionally well-designed. Moving these systems over to a modern tech stack was challenging but also incredibly rewarding.
On the other hand, I really enjoy working on things that benefit non-tech users and solve "real-world" problems.
If you're still there after a year you'll probably spend your career there.
Unfortunately they wanted on-site presence in a different state than where I live so couldn't go forward with it. Otherwise might well have taken it, to my surprise.
(Horrible, it turns out).
What's insane is the hiring market during the longest bull run in history, which has now ended.
Get a simple kata or problem - that the interviewer AND interviewee haven't seen before.
Set up a "code with me" session. Pair program.
See what happens in two pomodoro - have a chat in-between. Swap roles.
1) Do you see tests? 2) Do the tests pass? 3) Did anyone lose their cool? 4) Does the code look good?
Have a score - keep the scores of all interviews (anonymize them of course) - and as you go along see where a candidate fits on the curve.
The problems have to fit into two pomodoros - you have to try this against one of your junior devs and a lead to verify.
I do pair programming sessions with people as part of my job. This has made me a substantially better at pair programming as part of interviewing (on both sides). Perhaps it would be worthwhile for you to time to work with some colleagues to build some of these muscles.
I do agree that alternatives should be offered if someone is uncomfortable.
My mother told me I spoke very little as a child, but in the evening she could hear me practising words outside my bedroom door. I suppose this is some deeply seated neuroticism.
We see how the candidate approaches problems from their initial solution, and then we get to see how they react to being asked to extend things. We get to talk to them about how easy their code is to change, how their tests helped support the changes. We get to see them work through a problem under slight pressure, and hear them communicate with a partner about the problem.
As an example of the level of problem we're looking at, here's an AoC problem we've used before: https://adventofcode.com/2021/day/2.
A couple of notes:
* We keep the problem easy like the one above because we're not trying to see if a person is a genius or has memorized a lot of algorithms. We just want to get a basic pulse on their skill level. For a junior dev, this kind of problem is doable but might take a little while. For a senior, this should be basically trivial.
* When I mention that a candidate is under some pressure, I don't mean that we add any artificial pressure - that would be dickish. I just mean that interviews are naturally a bit of a high-pressure situation, so we get to see if they keep their cool, etc.
* The candidate drives, but we try to approach the problem as a real pairing situation, so the candidate should talk through ideas with the interviewers, the interviewers can and should _actually help_ solve the problem, etc.
* The "take-home" portion is designed with the intent of not taking up more than an hour or so of the candidate's time, and is really there just to give us a starting point to talk about. It also ensures that the candidate has a project set up and ready to go for the interview in the language of their choice, which eliminates a lot of churn from the beginning of the interview.
I helped design the process so I'm biased, but I think it's extremely effective.
This is a cultural thing. Don't expect me to become a new person to fit into your work flow.
Now I know that buddies of mine did great work like that as teenagers creating games (and some sold reasonably well), so yes this can work beautifully. Thing is just, you're not my buddy and I'm no teenager any more.
Most companies aren't willing to invest these kind of resources into the preparation of each interview.
It gave them a chance to see how I worked as part of a team. Even if day to day I'm not pair programming, it starts off the relationship saying "If you need help on a problem, you can be comfortable working with your teammates."
The great thing about the setup is that it doesn't have to be a unique or complex problem. "Write a function to reverse a string. We'll write unit tests in parallel with that."
Or one of the thousand other problems. You're not testing algorithms here, you're testing whether the candidate is arrogant. Or talks too much. Or doesn't ask for help. What happens when they get stuck?
You're right, it's a lot of effort. But the resources spent on a bad hire can be even more expensive.
Developer hiring is exceptionally awful for lots of reasons, but there are wider problems now.
On the flip side, I’m interviewing candidates with a decade of experience (per their resume) that can’t discern the difference between basic data types and how they are stored with the very language they claim expertise.
Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well.
If you’re skilled, don’t despair. Most companies are terrible at hiring and terrible at business as well. Those rejections from the gauntlet of flaming hoops they make your jump through are doing you a favor.
Rejection is God’s protection and all that. And I like to think that’s right.
On my LinkedIn I have the following: what I currently get paid by my current employer (!!!), what I am looking for in my next role, both regularly ignored by recruiters of course, and then I have links to my StackOverflow, Medium and Github profiles, any of which ought to demonstrate my “expertise” as well or better than an interview ever could. Heck if you just read some of my answers to StackOverflow questions, I think you’d see I am capable of writing code for your company…
i cant remember who said it but many people with 10 years experience really have 1 year of experience and 9 years performing tasks doing the same thing over and over.
First of all, software frameworks and technology evolve. Second, it's pretty hard to find someone who worked for 10 years at the same company with the same software project doing CRUD actions.
On the other side, if you meet linux kernel engineer who maintained kernel for the past 10 yers, this argument fails short. Same for someone who worked on Postgres internals.
I mean that's what experience is.
If I want an expert in x, I want someone who has being doing x for ten years. I don't want someone who has dabbled in ten different things in ten years, thus having very superficial exposure to ten things and expertise in nothing.
If I need a heart surgeon, I want the doctor who has been doing only heart surgeries for a couple decades. That's an expert. I certainly don't want some doctor who has been switching from heart surgery to podiatry to dentistry and on and on without specializing in anything.
No.
Interviews have 0 context that's needed for anyone to perform. Usually you can't use your IDE, your settings or your ways of working and you've never paired up with the interviewer so might not feel comfortable.
To make matters worse the interview topic is 90% chance not what you do on a day-to-day basis. No 1 is answering leet code questions at work. We're going to be using a library or tool and not to try write an analytics algorithm.
I still look back to a FAANG interview a decade ago being the most difficult thing I've ever done in my life, and I've worked my way up from a shit mining town to the middle class, developed a complete complex software product starting from an empty text file, gotten an advanced degree, built a single engine airplane, and managed to stay married for 20 years. But out of all that, a stupid FAANG interview was the most difficult. It's just ridiculous what companies put people through.
I've never had a problem in a real world setting or writing code.
Im sure i looked like a novice. But in my day to day code... i flip between maps and conditionals and switch statements all the time, with ease. Its natural. But while interviewing? It just doesn't come out of me.
And there are developers who say things like "[other programmers] can’t discern the difference between basic data types and how they are stored with the very language they claim expertise"
That's not the actual job we do. Unless you happen to write libraries or crazy high performance code.
Most of the time it doesn't actually matter how the data is stored in the language, it actually matters how it's stored in the DB. Because that's where the performance problems are.
Most of us don't even have to remember that, even if we ever learnt it. It simply doesn't matter.
Most of our jobs are to turn business requirements into working programs. That makes us an expert, not knowing a language spec verbatim. That doesn't matter at all. It's a meaningless metric.
It reminds me of a colleague who could tell you all the performance problems of += vs StringBuilder but shipped sweet FA for 6 months. And do you know what the difference actually is? Nanoseconds. NANO.
Or the person who seemed to be able to quote the entire SQL manual, yet typed with one finger and spent 3 months building a 10 line SQL statement.
Or the colleague who could give you text book definitions of every design pattern you can imagine, but when asked why they'd implemented a complicated mediator pattern for saving simple forms couldn't explain, "that's how it's done!".
And when I ripped out the several thousand line monstrosity and rewrote it in 100 lines or so, they still admantantly said it was better even when presented with load tests that showed the new code was orders of magnitude faster.
What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. Sometimes they intersect. Sometimes they don't.
Many developers find themselves in a position of being a subject matter expert in a particular business or industry, and that becomes the primary value they deliver. They remember where that error message originates or why that column in the database is named so strangely. They know the lingo and business quirks inherent to their industry.
Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly. Their programming muscles atrophy while their subject matter expertise grows. But that knowledge doesn't always transfer well.
I've fallen prey to this trap (personally) on more than one occasion, getting lost in what I was doing instead of seeking to better understand what I do.
> What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two.
I'm recruiting problem solvers, and I think it's necessary to understand the tools you are using to solve problems at least one level deeper than autocomplete shows.
Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort. When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags.
Sure, tools and language (e.g. Javascript) often abstracts much of the details away, but my experience is that those developers with a familiarity of those details and why they matter (even if they might need an occasional reminder from a search engine) are a cut above.
Why do you feel this is important? To clarify, what are you testing here?
It shows that you understand how equality relates to values and data types, and that changing the type of something can make the same conceptual operation behave differently. This is the kind of fundamental technical understanding and precise thinking you want a developer to be absolutely familiar with.
That's what I assume the GP is referring to.
They changed it in ECMAScript 5.
More details here:
https://eslint.org/docs/latest/rules/radix
That's what the majority of all the industries on the planet are doing. Repeating the correct patterns in the right place and right time. The value is knowing the right patterns and repeating them at the right time and place.
And it makes sense - how many different ways are there to iterate and manipulate a given set of data that contains customer/user records, orders, social post meta or whatever is commonly used in modern tech? Aside from very specialized organizations that are working on the cutting edge of the tech in this or that specific sub-specialization, most of what we are doing is juggling data in the same way everyone does. The chances of anybody bringing a totally new way to juggle that data through exemplary and precise knowledge of the language are ultra slim. And if that ever happens, everyone would soon know and start using that method anyway. Which brings us to the point below:
> I'm recruiting problem solvers, and I think it's necessary to understand the tools
The problem solvers would know that we are living in 2023, and not only the abstractions that we use, but also the stacks and languages that we use have evolved to handle as much as they can to make our work easier, including data types and their manipulation. The memory space inside a developer's mind that is allocated to knowing those data types and manipulating them manually is memory space that is wasted and not being used for remembering other things and increasing his or her impact.
If your logic held out, we would still be manually allocating memory in our programs. We dont. Those who need to know allocating memory on a daily basis and needing to not letting that knowledge atrophy are those who work on hardware, low level hardware-softare interfaces, those who build and maintaing languages, packages, or stacks for industry-wide use. Not the developer who solves !business! problems.
> Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort
Yes. And that's what enables them to take on the ownership of increasingly broader features and systems. In the same way it enables even fewer founders to bootstrap or launch more complex startups. Everything we do in tech is for automating, optimizing and making easier a given level of problems to be able to rely on that automation to move on to the next level.
> Sure, tools and language (e.g. Javascript) often abstracts much of the details away
Yes. They do. Every stack, language, framework does. That's what amplifies productivity. Not holding on to knowledge you will rarely ever use.
...
The difficulty of modern tech is in creating reliable, user-friendly and cheap systems that bring advanced technology to the masses. Anything that prioritizes specialized knowledge on what is already handled by the existing technology stack is more academic than anything practically engineering related. Such approaches could exist inside gigantic old-school organizations like IBM when they had their heyday, and they did exist inside tech gians which literally made themselves a continuation of the colleges which their founders graduated from, fueled and floated by zero-interest investor money, prioritizing only 'growth' without paying attention to the business fundamentals. But in the new, non-zero-interest economy, they can hardly be justified.
And that discernment, at least in part, comes from understanding what that code is really doing.
I get 45 minutes face-to-face to develop an opinion as to whether or not a candidate can do the job well. I value candidates who’ve not only asked “what?” but have also asked “why?”
I’ve no doubt my approach has filtered out people who would have done good work. I’ve certainly passed people through that didn’t work out for various reasons. But generally, my approach has served me well so far.
It does come from understanding the !business code! that is involved. Not the rarely important features of the underlying language that the stack, the framework or the models handle.
Which makes that argument further moot - you should not be messing with how the models or the framework handle those data types. There is a reason why they were built and deployed.
LOL I've noticed this too! Somebody must be out there teaching people to do this! I mean I interview people, and they are so over-prepared with their sound bites and their canned speeches, and they deftly try to steer all conversations back to topics they are prepared with. Their style, body language and communication tactics are polished and sophisticated. They sound very pleasing. Their slick enunciation, cadence, and confidence make them sound like 20 year NPR veterans. But the content itself is a millimeter deep. It probably fools the exec class, but it doesn't fool a practicing engineer or technical manager in the trenches.
Got me!
I'm not a dev anymore, but even when I was decent to good with multiple languages over the years, I would not have known this.
I do remember being in interviews where one smart person on the other side of the table asked me some piece of tech that was mostly specific to their daily use, and when I didn't know it, they were shocked -- shocked, I tell you.
:-D
IMO that's because they (employers) too have no idea what they are looking for. It's a mess and only getting worse.
My 2 cents is just say yes to that rare proposal that comes after one or 2 interviews. And yes, they do exist but almost everyone passes them because "if it was so easy the role must suck". Well, the possibility of role sucking is exactly the same if you went through 10 hoops to get the job.
Places that treat candidates poorly tend to treat employees badly, and companies that drag out the interview process tend to miss out on in-demand talent.
As a result, places that respect your time and well-being have been more likely to have good engineers who have stuck around. Places that are toxic and/or bureaucratic tend to combine bad hiring with high turnover and create a terrible environment.
There are still 1000s of open developer jobs.
- Don't aim too big (there will be way more competition if you're trying to build a world-changing product).
- Don't go into any sector where big tech corporations are already offering products (no matter how bad those products are, you will not be able to compete on marketing; nobody will find out that your product exists).
- Find a niche. The more boring and tedious the niche, the more likely you are to succeed.
Basically, base your entire strategy around minimizing competition at all costs. Do not underestimate competition. Do not underestimate the power of a great big pile of capital in the hands of your competitors; no matter how terrible they are.
This is not capitalism. This is crony-capitalism. NEVER FORGET THAT. As you rise up the ranks, prepare for less ass kicking and more ass kissing.