For my current job I got grilled with leetcode style questions. Lucky I'd done a few before so knew the tricks. Now I work there the job is basic crud style work, nothing fancy required. Employer also hires grads almost exclusively from Ivy League universities and they mostly suck. Makes me look good. :)
I think most work is CRUD related, and I also think that it's actually counter productive to hire leetcode or university crowd for these jobs, as they will naturally try to treat CRUD problems as the problems they have been studying and practising, which would mostly yield something that could be done in a few lines of code as something that is really over engineered. They will start trying to figure out problems that have been solved already for them with countless of libraries and tools, because that's what they have been learning. Either following certain design principles, and over engineering, causing massive amounts of boilerplate code, or spending way too much time on trying to consider and optimise for certain types of edge cases, which libraries would handle for them anyway.
> For my current job I got grilled with leetcode style questions.
I don't mind being asked a leetcode style question or two in an interview. Even if somebody struggles with solving an unfamiliar problem off the cuff, you can see if they they take some logical problem solving approaches.
But it's frustrating that no practical web-development questions are ever asked for those kinds of jobs.
For instance, security is really important to the survival of any company. An insecure system that has a data leak could literally destroy a company overnight. Having a secure system is far more important than knowing a more efficient algorithm for sorting some data or whatever.
But I've never been asked 1 practical question about security in a technical job interview.
> Even if somebody struggles with solving an unfamiliar problem off the cuff, you can see if they they take some logical problem solving approaches.
I hear this a lot, from the likes of Google on down, but does any interviewer ever take away anything positive from "almost" solving an interview question? In my experience, most interviews are pass/fail and getting close isn't a pass.
> a data leak could literally destroy a company overnight
Source?
I'm sure we "wish" that were true, but data leaks haven't even destroyed companies whose entire existence is predicated on storing data such as Equifax.
That is peanuts for AWS. The OPs point stands: pretty much no engineer or software company suffered serious consequences over their security practices. The worst was some internet drama and slightly lower *profit*.
Ashley Madison tanked from a data break, and there's an ever growing list of cryptocurrency exchanges that were hacked and ended. It may be that for some businesses a data breach is manageable, but that's not always the case, though more importantly that kind of attitude towards the seriousness of data breaches and vulnerabilities is not wise.
Equifax operates in an industry with a strong network effect and the data they lost belonged to the targets of their data collection, who are neither the people who submit credit reporting information to them nor their paying customers.
Other companies can be much more screwed. Suppose your customer list gets leaked, including their contact info and how much they're paying you for which services. First of all they're pissed at you. The next thing that happens is a competitor downloads the data and sends each of your customers a custom email offering their services for 10% less than they're paying you. While they're pissed at you.
But also, suppose you're Equifax and the people who breach your systems, instead of leaking the data, just delete it. Including the backups. Now you're out of business, because you have nothing to sell.
I did recruiting for Full Stack developers for a number of years. I only gave two programming problems, one to be completed before an initial phone screen and one to be completed in the first part of the interview.
Myself and another team member worked on the questions, and we gave them to the team. Everyone was able to complete the exercises in a reasonable period of time, so we knew they weren't going to be too challenging.
Pre-screen question: For the numbers 1 to 99, print the number if its digits do not add up to ten. Otherwise, print the number and its digits 91 (9,1) if it adds up to ten. Download the file quiz.txt and use it a starting point for your program, keep it simple and make sure your output matches sampleoutput.txt exactly. When you've completed it, rename it to yourname.txt and email it to quiz@company.com with the subject of "Your Name: Completed Exercise".
A lot of people would just use convert the strings to numbers and then do the test to see if it adds up to ten, in this case I would kick it back to them and ask it to be solved mathematically. Usually, we'd get a response back right away with the "best" solution. Candidates that completed the exercise correctly and followed the directions got 15 minute phone screen to see if they had the technical background required.
For the in-person (or Zoom) interview question, we had a problem that required modifying HTML, CSS and JavaScript to come up with a solution. We stated this up front, and tell the candidates to use web resources to look up anything they need to. It also requires using modulus which they should already know (or figured out how to use!) in the screener exercise. If someone got stuck on something we felt they probably knew we'd give them some hints and they'd relax a bit. Most people solved it within 5-15 minutes, but there have been people that couldn't do it at all event with lots of hints.
In that case, we'd usually just end the interview and thank the candidate for their time.
From here we'd do some database exercises if their role called for database, and move onto an deeper assessment of technical background. That process worked well, and they're still following it today.
I think it just means taking the input as an integer and then separating out the “ones place”and “tens place” using integer division and modulo operator. E.g.,
ones = number % 10
tens = number // 10
do_print = (ones + tens) == 10
I think hahamrfunnyguy must have meant "convert the numbers to strings" - that's the only way I can make sense of it. quiz.txt must contain code, not sample data.
Yes, quiz.txt was the start of a C# program with a main method and a function that was called to do the work asked.
The common string based solution was to use a for loop, convert the counter to a string, parse the digits converting each one to a an integer and performing the calculation.
The exercise was given in C# so candidates just use string interpolation to output the result
The funny thing I joined a company where we building a database from the ground up. Regularly implementing algorithms and data structures from white papers. So it is as far from the crud style work as possible. The interview was just talking to different engineers about interesting problems, like you would do at a conference or at a meetup. No leetcode, no whiteboard, no take home or resembling a technical interview. But somehow they managed to build a top notch team, one of the best I ever worked with.
Writing correct distributed CRUD is hard. I have interviewed quite a few people who didn’t have a clue about how to insert into a table without creating data races.
I’ve had this experience. I passed all of the interviews only to be failed by a senior manager that had some kind of expectation I couldn’t figure out.
About 6 seconds into a phone call, I’d failed for not matching whatever expectation he had for how a phone call should go. As far as I can tell, he expected me to do everything his way without being asked.
That was truly bizarre. I think I dodged a bullet there.
I noticed long ago that many people have their own interviewing “secrets”. Remember that story about how Henry Ford would fail applicants if they put salt on their meal without trying it first? A lot of people take stories/ideas like that to heart. The person interviewing you was probably offended you called him by his first name or something. “A good applicant won’t do that”.
It’d also highly possible they did nothing wrong and the guy wanted to tank the interview for another reason. A favored candidate, opposing the team expansion, racism/sexism/ageism etc.
He seemed genuinely surprised when I asked him what he wanted to know instead of me following the script in his head.
I suppose he could have been acting, but I don’t think so. Looking back, I think he was expecting me to act like a vendor salesman promising the world in hopes of getting a commission.
I think it is more like doing things from habit vs from first principles. Maybe they just learn how to do things once and then repeat them blindly. Not sure it’s a good test but I think that is the intent.
When the actual hiring manager, or someone above that person, shows you a concerning aspect of themselves during in the interview, that’s them trying to impress you, demonstrating their best behavior. It won’t be better after you get hired.
I once failed a job interview at the algorithms exam. I don’t know what it is, I’ve done great in other BSc-level math oral exams. Felt weird to have two teams at the employer, one that felt confident about hiring me, and another that thought I’m deeply incompetent.
Combine the scrutiny with a 3-6 month hiring process, I decided to dodge whatever that was.
If there is high demand and not enough to fill the roles or you’re able to go almost anywhere… then sure it’s bidirectional.
But the majority of people it’s one sided. They don’t have the option to challenge the interviewer. They need the job, the income, and cannot risk getting rejected by appearing picky.
But that's why the best time to interview for a job is when you are already employed and are not really looking for anything new.
I did so many interviews without any intention of ever accepting the offer, it would be almost comical. But, it's great practice for when I actually want a new job, and refusing offers always massage my ego.
If the modern process didn’t involve so much leetcode and insane amounts of highly tuned preparation - I’d agree this would be reasonable. However, it takes most candidates that I know over 100 hours of prep to even pass most technical screens after they’ve had a job for a couple years. The regular occurrence being nights and weekends for a quarter then interviewing aggressively for the next quarter. (While still studying of course)
Maybe different in your roles or part of the world but in SV - it’s brutal.
Eh… it could be that the job is perfect in every respect except the one person (and they may be otherwise perfect in every respect except their interviewing skills.) It’s not 100% given that a bad interview experience implies a bad company to work for.
My final interview with a different company included the CEO. I took the job despite the red flags because I needed money. While his antics and temper caused a lot of problems for many people, it didn’t affect my department much.
I have a disability and no network to speak of. Getting job offers is difficult. I generally can’t afford to avoid every job with a red flag.
The interview process is a great filter for the candidates as well to understand if the company/team/manager is in one way or another, insane. The interview process exposes company culture in one way or another.
Things to watch for as a candidate:
* Is the process oddly impersonal with lots of gates to make it through before even talking to the team who is hiring?
Red flags - MBTI personality tests. Extremely hard tech tests that even half correct gets your through. Video recorded timed take home tests. Etc.
* Do the people hiring you know how to do the job, are they asking you anything relevant? Are all the interviews kind of high level 10k foot view, and/or in the weeds in weird ways?
Red flag - All there interviewees are peers to the hiring manager and above.
Red flag - Digging into arcane proof of concept code from 10+ year old white papers that the entire industry has moved past. Not the flex the interviewer thinks it is.
Red flag - Interviewers who seem confused why they are interviewing you, don't know what role it is for.
* If hiring into an existing team, are any of these peers part of the interview process?
Red flag if no - sign of huge turnover / mad max type org where you are being brought in to fight for survival.
* Is the process unclear, do new rounds keep popping up, do interviews keep getting rescheduled, are interviewees constantly late to the interview?
Red flag - Disorganized chaos, do they even actually have a role open they can hire, are they stalling?
The red flags above were compiled over 20 years of interviewing but honestly it's gotten worse and most of it was the last 10 years. In fact, 80% of the above was experienced in my last job search cycle.
I've managed to avoid leetcode/hackerrank due to my industry/niche/seniority, but orgs manage to invent their own BS.
I see a lot of geeks giving advice on how to hire other geeks, but I'm guessing most of them had never being involved in the hiring process.
In fact, if you sum up all the recommendations of people online about recruitment, you can't hire anybody, because every single move is something you should not do according to one of the self-proclaimed new expert.
Once again, as a developer, I can only notice how much of a diva my peers have become. We are very lucky we are a hot commodity on the market, because I tell you, no other professionals get a pass for a tenth of the things we claim we are entitled too.
And yet developers go through the most ludicrous interviewing processes, having to prove time and time again that they have enough technical skills, while having 10 years of experience in their CV :^)
I regularly gets paid by my clients to help them filter out candidates because they don't feel they have the technical skill to do so or their team is too busy coding something to be available for anything else than than validating the last batch.
One thing that comes over and over again is how much most candidates suck at programming. There are a huge quantity of people that are terrible at coding that will apply to your senior dev $200k job offer.
They all have a great CV, and they cheat at everything: fake interviews with a look-alike, using chatgpt or indian services to solve programming tests are not uncommon.
Last year, I had one former trader applying for a python job with a perfect resume, a stellar homework result, and who was claiming he likes "putting some good 10 hours of coding". First, there are maybe a 100 people in my country that can focus 10 hours in a row on code, and they won't apply for those clients. Second, the live coding review showed that he struggled to even create a basic virtualenv.
Last month I created a test that I knew had one question that ChatGPT got wrong. 2 candidates gave me the GPT answer last week.
So companies are desperate and try sieves after sieves, hoping to separate gold from mud. And they have limited time and resources to do so.
Of course the hiring process sucks. Even if they knew what they were doing, and most of them are not, it would suck.
Now don't get me wrong, it's nice the power balance is shitfing toward the workers for once, but hoping the other side won't react is just naive.
If you enjoy technical stuff and you want a job doing it every day, what’s wrong with doing it during an interview? I’ve never quite understood the complaints about having to prove technical skills in an interview.
CVs don’t prove anything about skills, even when they’re 100% truthful, and your 10 years is definitely different from my 10 years. Interviewers need a way to compare candidates so they can pick the best ones, right? How else would you do that aside from testing?
I think the most common complaint is that the interviews don't test technical skills, they test things that look like they're adjacent to technical skills but aren't the kind of work that you'd actually be doing.
- Many interview coding problems are very unlike what we have had to do in our daily tasks, and very unlike what will be required if we get the job.
- If the company is trying to avoid that problem by making the coding part of the interview working on actual problems they're having, then that means the interviewee is giving the company work for free. (Unless the company pays for it, but that's vanishingly rare.)
- Even if they manage to thread the needle and have the coding part of the interview be relevant to the job, but not actually getting free work out of candidates, it's very hard to make it representative of the environment in which the candidates are used to or will be working. It's time-limited, very high pressure, with unfamiliar tools, often without the ability to consult online sources—or they make it a take-home assignment, and run the risk of having the candidates just get someone else to do it for them.
- Most other types of jobs don't require you to prove your skills. They read your resume, they take it at face value, they check your references, and if it turns out you lied on your resume and got the job, you get fired. ...Or they don't do their due diligence, and end up with terrible employees.
The first two items there contradict each other. What’s an employer to do? This list of problems only reflects the point of view of a relatively inexperienced candidate who doesn’t like interviews, it’s not a list of problems that companies have, or that people with strong skills and experience have.
It’s an assumption to expect interviews need to reflect the work on the job or match daily tasks. Interviews are the employer trying to select the best candidate for an uncertain future, not mimic the drudgery of a day in the life at work. If I’m interviewing, I don’t want to know if you can code a specific task today, I want to know how well you can adapt to changing roles, whether you’re more extroverted lead material, or introverted and wicked smart or prolific, whether you’re ambitious or happy laying low. I’m much more interested in broad potential more than ability to perform technical tasks.
Isn’t the last item on your list a good reason to do some due diligence by checking whether people can code in practice before going through the expensive process of hiring them and having them fail and then having to try again with someone else? I haven’t seen a lot of outright lying on resumes, but I’ve seen a ton of overconfidence in one’s relative skill, I’ve seen people who are great on paper but duds in practice, but more than those I’ve see a lot of people who don’t communicate well, don’t get along well on a team, have bad attitudes, cover up mistakes instead of learning or admitting skill gaps, etc.
I don’t know what it means to claim most jobs don’t require proving skills. Most jobs are entry-level minimum-wage jobs. Anyone in the arts is used to constantly proving their skills via auditions, critiques, performances, etc. Doctors have it way worse with low paid grueling residency. We’re talking about high paid programmers where hiring the wrong person is an expensive mistake and can damage team productivity.
Yes, correct. You and I both left out nearly all job types. You’re making sweeping generic claims about all jobs without any specific evidence. And I still don’t really see a clear problem or any suggestion for an alternative. The point you didn’t address here is that programmers are paid more than accountants, museum curators, and much more than burger-flippers. If you want a high paying job coding, and it typically requires doing just a tiny bit of live coding, why not spend time practicing instead of complaining? Another thing you haven’t addressed is that there are a lot of stories of programmers faking their way through job interviews. I don’t know how often it actually happens, but kids trying to game the system to get high paying jobs seems to be an actual problem, whereas statistically nobody is trying to fake their way into a museum curating job.
Do you consider certifications and qualifications to be a pre-hiring demonstration of skills? Many many jobs require these. Programming jobs sometimes require them, and those jobs are less likely to ask for on-the-spot programming during interviews. Not all programming jobs ask for live-coding, you shouldn’t assume they all do. Do you consider an interview to be a demonstration of skill? All the jobs you listed require interviews where you have to talk in technical detail about what you’ve done.
Speaking of outliers, there are almost no museum curating jobs, and they have to typically do a master’s degree and then spend years doing intern style work, perhaps similar to a doctor’s residency. Then after all that, the median salary is less than half of the median programmer’s salary. Accountants and Baskin Robbins managers also make less than programmers on average, and the sum total of jobs available in all three jobs you just listed is relatively small compared to doctors and artists - in the US (for example) there are ~1.5M accountants, less than 10k curators, and just over 2k Baskin Robbins, while artist jobs alone are double that of accountants and including doctors is around ~4M jobs. The number of programming jobs in the US is around 4.5M. Between artists and programmers, the number of jobs that requires on-the-spot skills demonstrations is definitely much larger than all jobs you just listed so far, even when I give you the benefit of the doubt and include all fast food managers in the US and not just Baskin Robbins.
Above you illustrated some reasons why asking for a skill demonstration is a good idea, so I’m not sure why it matters whether or not it’s common for other job types. Maybe programming interviews have better outcomes than accounting interviews (fewer firings or bad employees per capita), in addition to higher average pay?
The answer to almost every technical question are "it depends" and "let me look that up for you."
> Interviewers need a way to compare candidates so they can pick the best ones, right?
For the "best" candidates they need a way of deciding which interviewers are worth their time to speak to, and overhead of the hiring process is a fantastic filter.
And somehow you still get very many people who claim to be experienced developers in $LANG and are unable to write or explain even basic things.
Usually engineers can spot the CVs talking around the fact they can't actually do what they claim well before it even comes to interview, but HR often can't and the recruiters will try it on anyway to get paid!
Isn’t it a total assumption to jump to the conclusion that being asked to write code in an interview means people think you’re lying? Try thinking about this from the interviewer’s perspective. They need to find out how good you are, and they need to know if your self-assessment is even using the same units as the next candidate’s self-assessment. Spoiler alert: they are different scales. Your idea of you having experience and doing well is very different from my idea of me having experience and doing well.
BTW don’t forget that some of the candidates you’re competing against are actually lying, and they’re claiming things on their resume that if taken at face value will get them the job over you. Do you really want employers believing and hiring based on what people can say rather than what they can do? Be careful what you wish for, because if that came true, getting hired would be harder than it is now.
I mean, I have never done or assigned a take-home or standardised test and never willingly will.
But at the first line, either CVs of unvouched-for engineers are pretty ruthlessly culled by active engineers based on "I don't think these skills are even genuine" or its done by others like HR or management based on some kind of universal system everyone takes. I don't agree with the second method, but I can see why it's done because I know people who give too much credit in the first way and waste days interviewing people for senior roles who think C# and C are "basically the same thing anyway" (that's a quote, by the way).
Personally, I'd rather just not proceed to interview rather then insult everyone's intelligence with game-able and non-representative tests like leetcode. Usually you can decide if a full interview is a good idea or not out of a phone call where you ask a few unstructured technical questions that are specifically appropriate for the role and/or based on previous experience.
So you have one job offer, 200 candidates, 170 sucks at coding but you don't know which ones, and you have 15000 euros (including man-hours and marketings) and 3 months to figure out the right one, convince to join, negociate and sign.
Oh, and your dev team is on a dead line and can spare very little time validating candidates, one is sick and you just hired an intern that needs baby sitting.
Fun hypothetical, but where I work we don't have that many candidates for any position, so it's, so far, never been an issue. I didn't think I'd need to say that "YMMV" but in case it's not obvious, YMMV!
Usually there's about a CV passed by me or others per week, an interview maybe every 8 weeks and a hire every 6-12 months.
Advantages of not being in a country or industry that offers SF FAANG/MAGMA/whatever salaries, perhaps.
It's not personal, it's a natural and inevitable result of the fact that there are a ton of scammers out there. If you maintain that attitude you will be selecting for naive and/or slow-to-adapt companies.
There are, but I (and many seniors) am easy to verify. If you know who I am and talked to previous employers (probably friends or at least people you met at conferences or fairs) or know me already from meet-ups but the rigidity of the hiring process has me do some dance, then please, find some other stooge.
> I am easy to verify. If you know who I am an talked to previous employers
Wasn’t parent complaining about being verified, because he assumes that implies he’s lying? If your problem with the process is whether your word is believed without verification, or verified, then what’s the difference between a code test in an interview and talking to a previous employer? (BTW there’s a lot of reasons I might prefer the code test to having people discuss me, even when I have a good reputation. You can’t control what people say or think about you.)
> the hiring process has me do some dance
You’re upset by having to do a little bit of the thing that you want the job doing? I have to audition if I want to dance or act or play music. Why shouldn’t we audition to write code, or do anything? If you walk into an interview expecting to demonstrate your skills on the spot, which is what interviews are for and always have been, then it’s no surprise and you’ll be prepared. I’ve watched people get upset in interviews because they were asked technical questions and expected their 20 years of experience or whatever should somehow exempt them from talking about code. That attitude is a huge red flag TBH, and I’ve seen people get rejected for it.
BTW something to keep in mind is that a ton of people complain about interviews that don’t involve coding. Many would-be programmers are quite frustrated by the focus on soft-skills or experience, and very much prefer to be judged strictly on coding skills.
I don’t mind talking about code and in depth tech discussions; what I do mind is getting a calendar invite with 6 weeks of interviews and take home work. I have no issues getting jobs without any interviewing, but sometimes I get these weird things. I hire myself at the current company (and many previous) and I know within 15 minutes if someone is ok or not. Haven’t been wrong so far and the past 25 or so years. But I do have the luxury of only having ever have to pick senior devs; juniors I would not really know how to do.
Interviews that don’t involve code are usually fine but not 6-12 of them. I usually start with (and we do not look for Haskell, ocaml, idris or prolog devs); do you know what Haskell is, what are some of the differences between Haskell, Idris and Ocaml. What’s the difference between prolog and Haskell. If they throw huge ‘i have no idea about any of this’ then I know they are going to be people we cannot use. What do lisp and prolog have in common. You cannot really fake knowing any of these and not having had hands on experience. It takes 15 minutes to filter out people who wouldn’t fit our team. But again: I hire seniors only and we work with very specialised financial software. I do apply for similar jobs where this applies as well and then I get a calendar invite with 12 interviews etc. No thanks.
I wish there were no detector guarding supermarket doors and google would not make me go through shenanigans every time I use a different device to login as well.
But we can't have nice things because of the proverbial bad apples.
You are free to reject the job offer, but thinking it will make any difference and that employers won't keep trying to protect themselves against being scammed is wishful thinking.
If you have no standing (as a junior) then sure, but as a senior, you can simply ask previous employers. If that’s not enough then indeed, I will refuse. I am not going to solve some crappy leethcode crap just because they are paranoid.
Lots of employers will not answer to that request for various reasons. So you may get a phone number of a buddy of the candidate that will tell you he was stellar.
I agree that some of the hiring processes out there are pretty nuts! On the other hand, there are people out there that have a CV that looks good on paper but are incompetent. One of my colleagues used the phrase one year of experience ten times.
I've worked with a few of these folks over the years. No one wanted them on the team and they contributed nothing, but somehow they managed to retain their job. These types were the first ones to go whenever there were staff cuts.
I've come across this interviewing too. We had a guy say "I can't do this.". I said, it's OK if you can solve it...let's just start it and work through it together. It's more important that we see how you approach problems and work through them. "No...I don't think I can."
Hmm. I have majors in CS and electronic engineering and minors in maths and physics. In EE I had jobs without any interviewing at all; just sending my diploma and resume. The CS interviewing system is highly broken compared to anything else I have been in touch with. I have been a software engineer, electronics engineer, ceo, cto, pre-sales and some more things. Software engineer interviews are sad shitty affairs; it’s easier to land a cto job than a developer job for me. It’s just dumb and companies who do it deserve to get told to stick that job somewhere.
> I see a lot of geeks giving advice on how to hire other geeks,
Is it out of place for a chef to critique the hiring process for a head chef position with a restaurant owner that's largely clueless about what happens in the kitchen? Most people would say that the chef might have a better clue about ovens and quiche recipes than the restaurant owner, right?
> Once again, as a developer, I can only notice how much of a diva my peers have become. We are very lucky we are a hot commodity on the market, because I tell you, no other professional gets a pass for a tenth of the things we claim we are entitled too.
Providing some advice about being a bit humble is always valuable. There's a fine line between being confident and knowing your worth and being cocky and a rude jerk.
That said, if you're a software developer, you have a skill that's in demand that most people on Earth have no capacity to perform even if given years of free training. It's reasonable for developers that might provide millions of dollars of value to a company to demand better treatment than people who provide a fraction of that value to a company.
Of course, and we were badly treated in the 90, so over-compensating is fair.
But I find that all those posts and articles about hiring usually come from the beautiful world of fairy-tales in the head of the authors, as they never had to solve the problem themselves.
There is no doubt that hiring suck, and you can't want capitalism and suddenly be surprised the market balances out in favor of the other side when demands of devs exceed supplies.
But the arrogance of my colleagues, many of them never having taken a professional risk in their entire life, is still astonishing me.
I won't give any advice, but the story strongly resonated with me.
Spoiler alert: Anand got hired.
I didn't. After a thorough technical interview with the guy that would have been my boss, the VP had a five minutes talk with me, asking about my hobbies, what I looked for in a company and similar platitudes. His added value was deciding he didn't trust me, for no reason, except the magic Excel sheet he was entering my answers in. The first guy did call me to apologize.
The weird thing is the same company reached to me a couple of times years later. The most recent, I learned that the VP was instantly fired as soon as the company was bought by a french conglomerate and the whole infrastructure replaced. It was a mess, so I guess I dodged a bullet.
Once again, as a developer, I can only notice how much of a diva my peers have become.
I totally agree with that. We need to live with the rest of the employees every day, so it's better not to be a jerk.
A lot of the advice is bad because many companies have terrible hiring processes and candidates have to work around that. Questions irrelevant to the actual job are a bad sign, unless they are asked early as part of the screening process or to assess the level of seniority and experience of the developer.
Ultimately you should treat the interviewer as you would a customer, try to understand quickly what they are looking for without asking too many questions, and demonstrate those qualities, assuming you are interested in doing so, of course.
"Interviewees are often told to use “I” to get credit for work done, but “we” is probably a more realistic depiction of how work gets done."
I've had too many candidates talk about "we" and the general project, or what the team they were on did. But when I try to get at what they specifically did I get nothing. Sure we need team players, but not just cheerleaders. Take credit for your work!
The weirdest was one guy who I could tell probably did a lot of good stuff but wouldn't say so. It was like he was coached to always talk about the "we".
I am not from the states but my IT career involved working on teams with US clients and also working in the US for a few years.
I find it very hard to say "I did X" for anything except for personal projects that I did myself from start to finish.
In typical work projects even the best of ideas always need to be bought by rest of the team and also executed collaboratively by the team. I would be dishonest if I were to say "I delivered this project on time/under budget" even if I did play significant part in keeping the project healthy and on track.
> I find it very hard to say "I did X" for anything except for personal projects that I did myself from start to finish.
I come from a culture that has a similar approach, where taking sole credit for team efforts is typically viewed negatively. Took me a few years to get the hang of lying on interviews and taking sole credit for team efforts.
And ironically, it only dawned on me when I became an interviewer myself. That's when I realized everyone lies on interviews. Especially interviewers.
When everyone is playing the same game, it's a fair ground.
You don't have to lie to talk in "I" form. You don't have to take the sole credit.
Just be clear about what your influence was on the project.
Not everyone lies on the interviews. I have absolutely never lied, and I can still use the "I" form.
I usually make proportions of my involvements clear.
For example if I start and architect/design the project, I will say so and then I will say I successfully onboarded others to the project and guided them successfully to achieve X results.
If I didn't start it, I will describe it like "I worked on the project X, with 3 other people. My responsibilities were A, B and C. etc".
>> Just be clear about what your influence was on the project.
God, stop being grandiose and talking about the project and deliveries. Did you implement a specific feature? Squash a a bug? Find a solution to a specific problem? If you didn't do any of those - specifically by yourself (or mostly so) I don't want you. Those are the key deliverables of a software developer.
Reminds me of the thing where apparently every guy adds two inches to their height on dating profiles, whereas I deducted an inch because of poor posture.
Apparently I was born with no guile (probably an exaggeration), which means in a world where nearly everyone tells what they consider to be harmless little lies, I’m actively damaging my own career prospects.
I think everyone has their own definition of deception, and mine is the act of allowing (by making no attempt at intervention) someone to go away believing something you yourself know to be false. Which seems to be quite a strict one from what I’ve seen.
If you had the idea and you convinced others of the idea, that is a good story in of itself, because it highlights both very important skills, ability to brainstorm solutions and ability to persuade and sell others on this solution.
So you say: "I had this idea A to solve problem B, but not everyone was initially onboard, so I had to do C to convince others. I was able to convince everyone and I led the project to fruition with D results.
If you were in a leading role, it will be more impressive the more people and the higher levels you had to convince or lead.
I realized in an interview that I have a "bad" habit of talking about my projects in terms of "we" because I naturally want to give the team credit even for projects that are almost entirely my work.
Personally it comes from my experience that really talented, passionate people work together they tend to share credit since the real goal is to accomplish great things. For me, over focusing on "this is mine" can be a bad sign of a candidate that is just there to get theirs and get out.
However I have been on the other side of the interview process only to realize that not everyone is driven by passion and excitement for the problems. I have had candidates that listed numerous things on their resume that they clearly only heard about during meetings and couldn't describe the most minor of technical details.
Which to me means the real solution isn't to enforce better phrasing of "I" vs "we", but dive into the technical details. People that are truly active contributors will understand every detail of the inner working of a project, whether they built it themselves entirely and just like to share credit with a team or they worked so closely with another it's impossible for them to disambiguate who did what.
I have this problem - I am one man hardware department for almost a decade. I am interviewing now and people don’t want to listen to this. I designed everything and own everything. So I started lying having imaginary colleagues who co-designed the these things. Then interviews went okayish again. Some toxic places do not want teamwork. It is called here “spoon feeding”.
> I've had too many candidates talk about "we" and the general project, or what the team they were on did. But when I try to get at what they specifically did I get nothing. Sure we need team players, but not just cheerleaders. Take credit for your work!
I had this conversation with a co worker when he was made redundant. I reviewed his CV and he didn’t put any of the stuff he had worked on.
He said he didn’t add it because it wasn’t something he did by himself. It was a team effort. So I asked. Did you do X on project? “Yes”. Did you do Y on project? “Yes”.
It sounds like you contributed to those projects. If you get asked during an interview, you can absolutely take credit for working on those things. That’s your contribution!!! Yes it was a team effort that got the project over the line and made it successful. But you contributed to that effort and you should be proud and take credit where credit it due!
He was a bit taken back. He thought it would be lying or stealing to put those projects on his CV.
This is highly regional, both within the US and throughout the rest of the world. In some cultures, you always downplay your own contributions, and listeners inflate them; in others, you always talk yourself up, and listeners adjust accordingly.
When you work in a large, heterogenous organization, it is important to pay attention to these differences, or else you end up either assuming someone did nothing or is a useless braggart because their culture doesn't match your own.
I see you've never been to Europe then, or just don't realize how worse it is there? I'd rather take the "ego management" of the US than the crazy rigid hierarchies in Europe.
At least you can take credit for your own work, which is better than never being able to get into management (say, become a "cadre" in France) just because you didn't go to a certain school, no matter how good you are or how much experience you have built up. Ivy league elitism exists in the US too, but it's not even close to how prevalent it is in a country like France. To me that's a much worse form of ego brain rot than America's.
grew up, living and working in Europe. no opinions on France though. somewhat bad experience working with Germans, somewhat good experience working with British. but the cultural differences that of States is something completely else - I feel like I'm expected to chant "team team team" 24/7. mix in prevalent religiousness, strong opinions on racism I know near nothing about and it's just never ending crawl through the minefield. all is not lost though - I dig the rooting for underdog attitude.
The set up of this article doesn't make a lot of sense. It describes a case where "not a good fit" was in fact exactly that; the candidate wanted an open workplace where he could express opinions and grow his skills, the hiring manager wanted an experienced resource who would do as they were told and not rock the boat.
Both types of workplace exist, and both types of candidates exist. The question for me is why the article author sent a type-A candidate into a type-B workplace. So that they could write an article about how they "educated" the VP?
This is a problem. It means the best output you're going to get is that of the level of the person doing the telling rather than the person who's first-hand doing and learning. I see this all the time. I once wondered why sometimes a new club/bar would open up, sparing no expense, but then the music would sound like shit. Not the sound system, but the DJ. It's because they were hired by someone who had more money than sense and didn't actually have good taste.
People being bad at at hiring is really orthogonal to whether people want someone who just does what they're told, or who also partially controls the direction of their work. You're making the assumption that it's some idiot owner hiring people, when it could just as easily been that the owner has hired someone with a particular vision to run their company, and that person needs you not for your creativity, but your level of craft.
It doesn't make me bad at hiring painters if I don't want them to have a say in the color.
Any place I work would offer more autonomy than being cog in the company. Somewhat more like as an interior designer than as a painter. It's hard to imagine a painter as executing a vision. I certainly agree that the degree varies by level of role.
I think the point of the article is that you should not want to build a type-B workplace. If you want innovation - and healthy companies should want that - you should hire people asking critical questions
Cause its HBR. Conventional HR wisdom doesn't believe in nuance when its coming from the employers side - everything must be repeatable, process driven, and very corporate. Deviating off of that, is scary because it introduces bias into the mix and HRs responsibility is protecting the company. Having a hiring process that is personalized to a specific candidate is a no-no.
It sounds like the VP is there one who needs to be fired. If he can’t handle questions like that it brands he is building a really bad team. Better to get rid of him and find someone who is better at team building and recognizing talent.
Interviewing practices are little better than folklore.
Has anyone figured out how to do this? Like reproducible experiments, formalisms, checklists...?
Last time I got good, actionable advice was from Journey of the Software Professional by Luke Hohmann. Covered stuff like self-selecting teams, assemblying a team with complimentary skills, and so on.
Or maybe there's some secret manual for interviewing as hazing and torture? Like the CIA's simple sabotage field manual?
Google used to be notorious for hiring only based on the prestige of the candidate's alma mater and gotcha interviews with Fermi questions or the kind where the interviewer is trying to show his superiority, like an adolescent pissing match. But they invested in researching the factors that best predict success and ended up with two: IQ tests and highly structured interviews. Everything else was worse than useless.
A couple of decades ago, I was being interviewed for a position as the support developer. The interviewer asked me to tell what a piece of code was meant to do. I responded by by telling him that without context, the code was quite unclear. Strangely enough that was what he was looking for - someone who could recognise that the code needed further study before answering.
Subsequently I was offered the job and took it.
In a later interview for another position, during that interview it became very clear that they were wanting someone who would follow IT policy and NOT look after the end-user. I then couched my responses to focus on what the end-user needed.
Subsequently I didn't get offered the job for which I was very happy.
Although this anecdote is presented as something that actually happened, it feels like a straw-man premise. The VP "practically growled at me" and "found Anand's questions 'super annoying.'" "His assessment that Anand was a 'bad fit' was really code for 'I don't want to feel uncomfortable.'" This seems uncharitable, but if it really does describe the VP accurately as a cartoonish pointy haired boss, this isn't the article that's going to change his mind, even if the fairy tale did have a happy ending.
I generally welcome questions in an interview, but not all questions are equal. Some may signal a lack of preparation, don't seem particularly relevant, or come across as canned, like something they read in an HBR article (just kidding).
I'm no expert interviewer on either side of the table. If there's one nugget I'd take from this article, it's a challenge to "uncover capabilities, not just experience." How do I convey my own capabilities as a job seeker, or elicit them as a hiring manager?
Incidentally, the "77% of all jobs ... require little to no creativity" link takes you to a marijuana podcast, as the Martin Prosperity Institute is apparently defunct. I believe the statistic refers to a footnote in this paper (co-authored by the author of the submitted article):
What an odd article. The title and contents don’t match (at least the title and main example where a candidate disqualified himself by asking annoying questions). I’m honestly not sure what point the author is trying to make.
Anand would do well to read the room. This is why soft skills are so valued. If he sees he’s annoying the vp with too many questions, maybe dial it back. Does Anand want the job or want to be right?
He wants to be right. A job interview is not like an exam, it's like dating. An opportunity for two parties to decide if they can work together. Hiding who you really are to 'pass' is a bad foundation.
That's why I don't like the conclusion of the article. Anand didn't fail the interview because the criteria were wrong - the interviewer failed because they suck at being an engineering manager.
It’s nothing like dating. Employees need a paycheck. It’s an asymmetric relationship. This becomes very apparent during economic downturns!
There’s really no use searching for the perfect job when the market is flooded with candidates and you have young children and mortgage payments due, yet you have to act like every job you’re applying to is some gift you’ve been searching for your entire life!
> Employees need a paycheck. It’s an asymmetric relationship. This becomes very apparent during economic downturns!
While this is certainly true, there still are usually enough jobs that fit the broad parameters of "pays enough to eat and take care of my rent". If you have a choice of a good boss at lower pay, or an a-hole boss at higher pay, you should take the good boss every time.
We spend 1/3, or more, of our lives at work, and life is far too short to spend any of it taking orders from an unpleasant, incompetent, or abusive a-hole. Not only will this make your time at work miserable, it will also lead to poor sleep and spending far too much of your "free time" brooding about your job. In that type of situation, you're not giving them 8 hours per day, you're giving them 24 hours per day. Eventually that's gonna take a toll on your physical and/or mental health. Don't do it.
This is also important if one wants to grow in their career. It’s hard to grow in a position that is only asked to do what they’re told. As a result, they won’t progress to a higher-level position and will lose money in the long-term. In other words, short-term thinking loses out, even economically.
To be fair, not all of us can be socially competent mentally healthy people who enjoy life and regularly stop to smell the flowers. Some of us just suck, some of us are miserable, so we have to put on a fake persona in order to entertain the other person enough for them to actually give us a chance. In a way, dating is all about entertaining and being entertained.
You are implicitly assuming that there's some finite amount of work that could make every such person "dateable without deception". While it may or may not be true in individual case, as a general statement it sounds to me more like "well, it's _your_ fault because you didn't work on yourself enough, so you deserve to be lonely".
I've encountered this too, where I was interviewed by many of the team I would be working with, and was considered a good fit, except for by the one high-standing academic type, who didn't. In that situation, I knew I wasn't impressing that person I was just being myself. Maybe I was subconsciously testing they're openness because I remember I would use a certain word/expression and they would rephrase it and instead of mirroring their phrasing I would say it the way I thought of it. It wasn't so much about being right/wrong but maybe not rocking the boat or just 'be like them'.
Anand could very well be moving across countries and investing immense amounts of times to start a new life. He could also be leaving a great job to seek a new challenge in a company he wants to invest years of his effort in. The VP has also dedicated time specifically for Anand's interview. He also probably has the power to fire him in short notice and with limited severance.
Anand should ask all the annoying questions. This way he's saving both himself and the VP all the wasted time of hiring him and then having a broken relationship because things weren't clear later. This way the VP can also see what concerns the potential employee and if they have a potential mismatch in expectations.
Finally, even if we disregard all that I said above, if it's Anand's working style to ask a lot of questions and he hides this style during the interview, then he will invariably clash with management later due to it if he's hired. Then he may have more to lose then just a potential future job.
I'm not sure why it's only on Anand. If the VP was getting annoyed, why couldn't the VP steer the conversation? He's the VP ffs. Isn't "having conversations" one of the key job requirements for any VP?
The problem with "just read the room" is that you can very easily misread someone when you're meeting them for the first time, for example during a several-hour-long interview session.
Its easy to misread people after several hours of interviewing. Especially if everyone else is open to questions and things go well. Id actually apply criticism to the VP ahead of the candidate. My expectation is that someone operating at the VP level has some degree of self awareness which this person clearly lacked.
The article says that being an effective contributor is more about bringing a fresh perspective to the table, rather than making leadership comfortable. It also says that Anand was ultimately hired and was effective in the role.
It's sad when "read the room" and "soft skills" are equated to agreeableness and making management comfortable. A company that thinks this way has only one real brain, the one in the head of the leader. Everyone else's job is to agree with that brain, not use their own brains to question it. If the leader happens to be a world-historical genius, this might work, but that's not true in most cases, so such a dictatorial structure doesn't seem likely to be the foundation of a successful company.
And actually, there's an even more devastating problem with being a dictator who surrounds themselves with yes-folk. Dictators don't like information that contradicts their perspective, and the yes-folk learn that. So eventually the dictator is only getting information that confirms what they think, and the org becomes incapable of adaptation.
Personally, I would not enjoy working for someone who was annoyed by me asking questions. Questions mean someone is interested in it, and is paying attention. To learn about something is to invest effort into it; it’s a great sign. Anand dodged a bullet here IMO.
OTOH maybe the VP feels challenged, which is why the questions are 'annoying'.
I mean, in this climate where people are being asked to win X-factor competitions for the privilege of a job, how sure are we that those already onboard would pass if they had to run the gauntlet?
