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.
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 [email protected] 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.
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”.
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.
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?
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 :^)
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.
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 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.
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.
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?
[+] [-] rr808|2 years ago|reply
[+] [-] mewpmewp2|2 years ago|reply
[+] [-] logicalmonster|2 years ago|reply
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.
It's so painfully stupid it hurts.
[+] [-] hahamrfunnyguy|2 years ago|reply
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 [email protected] 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.
[+] [-] ProZsolt|2 years ago|reply
[+] [-] whywhywhydude|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] kayodelycaon|2 years ago|reply
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.
[+] [-] CapmCrackaWaka|2 years ago|reply
[+] [-] karmelapple|2 years ago|reply
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.
[+] [-] sshine|2 years ago|reply
Combine the scrutiny with a 3-6 month hiring process, I decided to dodge whatever that was.
[+] [-] woleium|2 years ago|reply
Bingo! Remember that the interview process is bidirectional, you are also interviewing them to see if you want to work there or not :))
[+] [-] jarsin|2 years ago|reply
Everyone has become Seinfeld trying to find a perfect match and inventing all kinds of idiotic tests.
It's not like getting a job is getting married. Average tenure is like 2 to 3 years now. Most of these companies won't be around in 5 years.
[+] [-] leke|2 years ago|reply
[+] [-] steveBK123|2 years ago|reply
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?
[+] [-] Krisjohn|2 years ago|reply
[+] [-] BiteCode_dev|2 years ago|reply
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.
[+] [-] slekker|2 years ago|reply
[+] [-] anonzzzies|2 years ago|reply
[+] [-] logicalmonster|2 years ago|reply
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.
[+] [-] narag|2 years ago|reply
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.
[+] [-] fmajid|2 years ago|reply
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.
[+] [-] phkahler|2 years ago|reply
"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".
[+] [-] albert_e|2 years ago|reply
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.
[+] [-] PheonixPharts|2 years ago|reply
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.
[+] [-] lnsru|2 years ago|reply
[+] [-] throwaway2990|2 years ago|reply
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.
[+] [-] Lapsa|2 years ago|reply
[+] [-] gnfargbl|2 years ago|reply
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?
[+] [-] karmakaze|2 years ago|reply
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.
[+] [-] DandyDev|2 years ago|reply
[+] [-] Eumenes|2 years ago|reply
[+] [-] marcosdumay|2 years ago|reply
That's a contradiction right there. If experience is important, the "resource" can't do as they are told. If they can, experience is not important.
> and not rock the boat
And that's a different kind of attitude that has absolutely no relation to independence.
Anyway, from the article:
> He said: “He asked us a ton of questions that the team didn’t have the answers to.”
If you don't have the answers, you are clearly unfit to manage "resources". If you want blind followers, you better have all the answers.
[+] [-] andrewstuart|2 years ago|reply
Once you truly understand that then you can relax.
If you get the job, you get it. If you don’t then you don’t.
Roll of the dice. Means nothing.
I went to a job interview recently and the feedback from the recruiter was I couldn’t explain the (many) projects I’d built.
My recollection was I wasn’t asked, in a 30 minute interview that started late.
My lifetime of software development skills and experience was judged in minutes to be inadequate. Roll of the dice.
[+] [-] axpy906|2 years ago|reply
[+] [-] krackers|2 years ago|reply
I'm giddy that the glib article from 7 years back has finally become reality: https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/
[+] [-] JJMcJ|2 years ago|reply
VP: "He kept asking questions we weren't prepared to answer."
Recruiter: "I think I'll go work for my cousin's parking lot striping company."
[+] [-] remote_phone|2 years ago|reply
[+] [-] specialist|2 years ago|reply
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?
[+] [-] fmajid|2 years ago|reply
https://www.thinkwithgoogle.com/future-of-marketing/manageme...
[+] [-] kazinator|2 years ago|reply
[+] [-] oldandtired|2 years ago|reply
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.
[+] [-] SloopJon|2 years ago|reply
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):
https://tspace.library.utoronto.ca/handle/1807/80108
[+] [-] harles|2 years ago|reply
[+] [-] Leires|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] brycewray|2 years ago|reply