The concept
We need to ensure that people have the skills they claim to have. I get that and accept that.
But how relevant are these co...
For further actions, you may consider blocking this person and/or reporting abuse
I once went to a PHP Developer interview and was asked to write an application, don't remember what it was supposed to do, but the thing is, they handed me a pen and a notepad, clearly expecting me to write this application by hand.
I gave them a puzzled look and asked if they had a computer to do this, perhaps using even Notepad. They declined.
I handed them the notepad and said that I don't think I'd like working there and walked out the door.
xD I wonder how many people did the same thing
Lol
Yeah, coding challenges as part of the interview process are a huge red flag IMO. They show that either:
or:
Both are generally signs of endemic issues with how the company is managed that will cause other problems down the road.
Now, there is a realistic way you can do a coding-based interview. You give the interviewee a (properly isolated) real development system as they would be using, give them their choice of editor, let them use the internet and the documentation, give them an actual problem to solve instead of something that's better designed to test their understanding of their native language than their coding skills, and then (and this is the important part) watch them while the work through it.
The process is more important than the result in cases like this. I don't care if you can regurgitate a dozen variants of fizzbuzz in any of half a dozen languages. I care that you understand how to effectively utilize documentation and online resources to figure out the correct way to solve a problem.
Separate from my other response in this thread, I want to add something...
I think code golfing challenges specifically are the red flag. I find it helpful if a company has some coding "challenge" task, either before or during the interview, which is (a) unique to them, and (b) reflects the work you'll actually be doing.
As an applicant, this helped me twice to realize I didn't have the experience for the job I was applying for! The coding challenges in both cases used the technology the job required, in a manner similar to how I'd be using it on the job. I was able to save myself and the hiring manager a few hours of effort, through those challenges alone.
A good coding challenge can be a real asset (as I comment separately). A bad one, including ALL code golfing challenges, is useless at best.
Agreed. I was definitely being a bit over-generic in my statement there. If done right, a coding challenge can be a good part of the screening process. The problem is that most places don't do them right.
Interesting. What do you think about having the candidate look into the used codebase and explain the process of understanding what is going on?
I assume it depends on various factors if that is suitable, but I had the chance of trying that out and found it had an excellent side effect: you basically get a code review from an external view. This can be a win as the existing team tends to create a "bubble" and inconsistencies, missing docblocks etc become more apparent. At the same time, you gain a pretty solid understanding of the candidates ability to "pick up work"
If it's a case where you can do that without needing multiple layers of NDA's just for the interview, then yes, I think that's a good option as well. It's kind of dependent though on how close to BCP for whatever language/platform you're using you are, as being too far just makes it too difficult for the candidate to pick up anything.
Sure, and there's probably an even longer list of cases where it's also not appropriate neither of us are thinking about. That is what I implied when I said it probably isn't a possibility in many cases.
I have a different problem during interviews. I panic. Like, a lot. Like, forgetting basics. Once I forgot how to iterate through an array. Or what does
popdo. Problem is, I am stressed when evaluated. I don't really know why, but I do. When I am hired, I can easily do pair programming or code sitting next to a manager, no problem at all. But during the interview, damn, I can't even spell my name right.Yes, that is more common that you would think. I think addressing that in the interview is most of the time the best move here. Sure, it will not always work, but most of the time you'll change the setting and trigger empathy. More importantly, if you notice that the person or the people interviewing you react encouraging, you often overcome the nervousness.
Yeah, recently it was like that:
But, some interviewers are being actually helpful, true.
When I interview people, I never ask them to write any code. I ask for code samples before the meeting, so I already know how they work in general.
First off, yes, code golfing is not a good indicator of coding skill. I do coding challenges as part of hiring at MousePaw Media, and it's a critical piece of the process, but the challenge is actually a real world problem with multiple viable solutions.
Done right, it's a useful tool. Done wrong, it's nothing but a waste of time.
So, the bulk of your article is right on the money.
BUT, I need to address one thing you said, though, that fundamentally spoils the whole point you were trying to make...
No, there's an underlying impertinence in expecting a hiring manager, who has to screen through hundreds of candidates, to make an hour for you merely on your say so. We don't know you. We have absolutely no reason to believe you're worth interviewing. To pitch a fit about having to prove your qualifications is, to put it honestly and objectively, extraordinarily myopic.
I've interviewed for several jobs with over 300 candidates each (after resume weeding). Is it reasonable for the hiring manager to interview all 300 candidates, at 1-2 hours each? Don't be absurd. You're applying for maybe two dozen jobs a week tops, so you're putting in maybe 12-24 hours of work if each one took two hours of effort on your part. But, wanting to spare yourself that inconvenience, you're literally asking each those hiring managers to put in hundreds of hours of extra work to spare you a couple hours each.
To be quite blunt, regardless of who you are: you are not that important. That's not personal; it's true of virtually all of us. Unless you're literally Guido van Rossum or Bjarne Stroustrup, you're going to have to bite the bullet.
The interview process is two-way. Hiring managers expect that as a legit possibility with every single candidate. Our answering your questions and taking that risk is how we repay you for your effort up to that point. (If the company doesn't, they're not worth it.) If you walk or we walk, we're both out the time.
And, to be honest, I don't think you do. You're wanting the person with the already large workload to spare you a little extra effort. You're approaching the hiring process with only one ruling mindset: "what's in it for me?" I would never want to hire someone with that attitude, especially when I've worked so hard to hire for and build a team of mutual trust and support.
If someone is not willing to prove they're a viable candidate, they're not a viable candidate...and that attitude spills over into the workplace. If they'll be so myopic with a hiring manager, I'd bet cash it'll be a matter of weeks or months before they do the same thing to the DevOps, the QA Engineer, the UX designer, the technical writer...
So, while coding challenge policies themselves could stand to be seriously improved, the expectation for you to prove your candidacy through such an activity is entirely reasonable.
Let's start by saying that this post is about how candidates aren't vetted effectively and not about that they shouldn't be vetted.
It's not that I don't see where you are coming from (although I think you misjudge my attitude massively), but let's put some things into perspective:
First, you seem to assume that I describe that problem only from the perspective of the candidate. Given the context, I can see how you can come to that conclusion, but in order to address some assumptions you made about me, I have to ask: What makes you think I have no experience in how the hiring process looks like from the perspective of the employer? What makes you think I never vetted candidates, worked hand in hand with HR departments and invested time to find the right team member?
I don't mean that confrontational, I just want to make you aware that a lot of what you write is based on things I do acknowledge on one side, but simply aren't as one-sided as you make them sound:
No, of course it isn't. I don't think you even CAN read my lines as "Instead, just talk to anybody sending you a resume", as you imply here.
So here is where I start to feel a little attacked. Let's look at what you are saying here: I am the arrogant one for "demanding" to spare me some time while it seems to be a given for you that the candidate's workload cannot be compared to the hiring manager? I find that interesting. Not to say distopian. Again, I am not saying that candidates shouldn't be willing to put effort into the process, but at the end of the day it is a give-and-take. If YOUR attitude starts with your time being more valuable per definition, then I can promise you that you will end up "hiring down" instead of with the best possible candidate for the position you seek to fill. It is statistically likely that the ideal candidate sits at another company for 60-80 hours, potentially with similar responsibilities than you. If that isn't even conceivable for you, than you will never talk to that (here hypothetical) person.
And that all wouldn't have bothered me as we don't know each other and I also sometimes make wrong assumptions regarding how something is meant, but then you go on cementing that one-sidedness by going all in:
Wow! So you would never hire someone with which attitude, precisely? The attitude you project on people who dare to have feedback to your hiring mechanism? You seriously use the words "mutual trust" when you mean:
"If you don't show me that you want it by complying without asking questions, and without knowing much about the working conditions, team or company, then it lacks evidence of an obedient laborer who - god forbid - might wonder what's in it for her/himself"?
Because the candidate has to take your word for it when you say "...especially when I've worked so hard...", but you would never trust the candidate on her/his word?
Yes, I see how that attitude is something you would want to prevent to
That would surely be devastating in a team of mutual trust.
But fight mode aside: Of course the candidates have to "prove they are worth your time". I certainly don't hold the position that it isn't adequate to have a reasonable investment and even agree on the general notion that the "work" of forming a new role must be divided on things like reasonable effort. As such, of course the hiring manager shouldn't spend days interviewing people that could have deemed the wrong match based on effective filtering methods (so back to the topic: let's find effective methods, not a "class war")
Not "more valuable", but "stretched thinner." There's a profound difference. If a hiring manager is putting in hundreds of hours, it's not unreasonable for them to expect each of their candidates to put in a tiny fraction of that time. It's no different from saying "I've covered the entire meal, and used all my available funds to do so, would you mind taking care of the tip?"
See your own post:
That literally states that you (apparently) believe it unreasonable for a candidate to have to go through a phone interview and a coding challenge before being granted a final interview. There's no other way to read it.
What's further:
No, I would never hire someone with the attitude I explicitly described:
A successful team needs to be mutually supportive. Each person supports and is supported. They recognize their own needs, but also the needs of others, and keep both in perspective.
For someone to have the attitude of "WELL! How unreasonable of that hiring manager, for wanting me to do this coding challenge before I get a final interview!" they must first fail to recognize the position the hiring manager is in. That indicates the person has clear difficulties empathizing with another individual.
First, of course I wouldn't expect that! Ergo...
In other words, you're interviewing us as much as we're interviewing you. It's the principle of reciprocity.
And, in any case, it's quite common that there's a "probation" period after hiring. The candidate may still turn around and walk out (with pay). So I expect to prove myself trustworthy, both in the interview and afterwards.
Interestingly, though, if it turns out the candidate is untrustworthy, guess who's out both the pay and the time of multiple employees involved in onboarding? So, as great as the risk is for the candidate, the risk is greater for the employer. Don't underestimate that.
Second, I would be taking the candidate's word for a lot already. One has to maintain a wise balance. If you say you improved the security of the email servers at your school, chances are, I won't be able to verify that. I'll just assume you're telling the truth...so long as what I can verify matches what you're saying. So, I verify the little I can, and believe the rest based on word alone.
If I hire someone without verifying their technical ability, I am disrespecting my entire team by saddling them with a peer who they will have to entirely carry. I owe it to my existing staff to verify essentials. Period.
Furthermore...
As a simple analogy, if you were to tell me that it's unreasonable to ask food service workers to wash their hands before returning to work, it'd be a safe assumption you'd never worked in any public health field. Your statements, as originally written, implied a lack of understand of what a hiring manager's workload is like. Again, your original post...
I'm willing to believe you didn't put that in the way you intended.
I'm glad you don't. Just understand that your opening "digression" summarily contradicted that, and that is what I took on. I cannot apologize for misunderstanding, because I only took your words at face value.
Because the hiring manager needs to allocate enough time to state his/her case on dev.to? But joke aside: Again, I think you base that on particular assumptions that translate to either what kind of candidate(s) you personally seek(ed) for or how you think that candidate spends the days. Because let's face it: if the candidate is at home looking for a job than it is more than logical that this person would do anything (including spending all of the available time) to seek employment. And if such a candidate is not willing to invest a large enough time then scepticism is appropriate. But if the candidate reaches out to seek better opportunities, things can look very differently. Do you know how often it happens that highly skilled people are contacted by head-hunters and if they show interest are presented with these procedures? So I guess I simply account for a different hypothetical candidate.
So I let that slip the last time as I thought it's more of a generalisation, but let's address it: Why does this hiring manager spend hundreds of hours? Your example was based on 300 applications and I assume that the scenario has an HR department responsible for actual job postings on various platforms etc. So we basically have:
as topics our hiring manager is potentially involved in prior to screening resumes? And then your mentioned 300 resumes on the table. So, if you don't mind me asking, what do I forget that would take hundreds of hours I am not accounting for? So far, it sounds like 40-60h. Not that that wouldn't be a time investment, but I'd look at this from a different angle: If the total amount of hours a company spends on recruiting really is in the hundreds (across multiple employees, of course), it's even more reason to look into the process.
About how I formulated what I find a reasonable demand:
Forgive me if I will not join a discussion of how I meant something after being presented with a text you pasted together from my post. The article as a whole is written with sarcasm and humour and taking things out of context is a rhetorical strategy one can use in debates to convince an audience, if you must, but not convincing for the actual author. I do take your word for it that the way you portray it is the way you perceived it. And there is no apology needed or expected for that. But there is really nothing beyond "That's not what I meant" I can add to that either.
Agreed. Fully! But pretending that the candidate has any kind of loyalty towards a team he/she doesn't know yet would be unrealistic (maybe even delusional). The candidate that doesn't attend an interview with the primary objective to find out "what's in it for him/her" probably doesn't even exists - and if such an exception comes along, I'd be highly interested in the primary motives. I just assume that we can openly talk about this here rather than playing this societal game where we have to pretend that there is any kind of personal attachment towards a (for the candidate at that point) soulless corporation. The human factor first has to grow.
As for most of what you say regarding the risk of hiring a person in the first place as well as the interview process itself I have nothing to disagree with. Again, it's not that I don't know this process (hint: maybe read the very first sentence of the post again). I really don't know how to formulate it any differently: I do not propose not vetting the candidate carefully and appropriately. I simply question how that t(r)ends to be done.
And yes, for the purpose of this post I do explore the topic from the perspective of the candidate. But there might be a future "Why you won't find your unicorn" version from a perspective you will more likely identify with.
Again, this is not about a class war employer vs. employee. I think in the end there is probably more that we agree upon than not (referring to the ideals of a mutually beneficial, invested and loyal team throughout the hierarchy).
Yes, 40-60 hours is reasonable, and what I would expect. That's a full work-week, and then some, assuming they have absolutely nothing further to do. God help the hiring manager (like me) who does things OTHER than hiring and HR.
The 300 hours I mentioned was, if you casually skim through again, what it WOULD take if a hiring manager was to take your (reportedly sarcastic) advice at face value and interview all 300 candidates who looked good on paper. Which is absurd.
I can appreciate if that wasn't what you meant, but it is what you said. I didn't need to "paste together" something, as you so strangely accused me of. I copy-pasted your paragraph so I couldn't be accused of misquoting.
I appreciate satire and sarcasm, having written plenty of it over the years. But the truth is, an author is entirely responsible for how that sarcasm is taken. If a reader indeed reads all of what you said, can quote it back to you, and misses your meaning, that responsibility falls entirely on you, the author, for being unclear.
I'm glad you were not serious when you spent several paragraphs roasting hiring managers for expecting coding challenges before a final interview. Unfortunately, that message wasn't quite clear as originally put, as I think you already know given the abruptness of your defensive reaction. In the future, just go "Ah, I think I was unclear, what I meant was X" and move on.
It's not an attack on you. There are just too many entitled people who really believe that the whole hiring system is unfair because they're not being pandered to, and would take the opening of your article at face value as justification for their 'tudes. You and I both have a responsibility to be mindful of that in writing sarcasm, satire, and irony.
Not only skimmed through it, but read the complete thread to make sure. You repeatedly make it sound like these hundreds of hours are a given, using it as an argument to make your point. I mean, apparently we are experts in misjudging each others words, but you made arguments like "If I pay for the meal you can at least pay the tip" and similar that all underlined that impression.
Yes, by now I have fully internalized that your position is that you are stretched thin and have a lot on your table (which I honestly don't doubt for a second, just to make that clear), while the candidate could be so kind to pause Netflix for a while to fill out some tests (and here is where I beg to differ). And again, if that's your hypothetical candidate, then that's probably a self-fulfilling prophecy.
I didn't meant to accuse you of misquoting, but of taking things out of context.
Ah, so we find ourselves in a value-difference. Uff, I don't think I want to get into that discussion. But no, I disagree and have a different opinion.
So, about that: Yes, why did you feel so triggered in the first place? I didn't even use the word "hiring manager" once in my original post. My post is structured like this:
The concept
Here I say that vetting is necessary
The investment
Here I say that the effort seems to have a trend of growing.
(And all the two of us talk about is within two short paragraphs in this section)
The conditions
Here I talk about unrealistic conditions of hakerrank & co
The time
Here I open up the discussion to the necessity of time-based assessment vs. the negative effects it has on quality
The challenges
This part is in regards to the use(full/less)ness of common coding challenges.
The tragedy
Here I claim that training for such challenges distorts what those tests are intended to evaluate.
So, I basically inserted a question regarding how much we can ask a candidate to invest in a post that is about coding challenges and that set you off? Let's see:
So here we get to the point, don't we? This is not a class-war as I misinterpreted. This is about your ego. And silly me said "No apology needed" when you actually expected me to apologize.
And you know what, I probably would if I shared your believe that
"author is entirely responsible for how that sarcasm is taken". But I don't. I think that the majority here "got it right" and you came in from an angle that didn't allow you to understand where I'm coming from. But tell you what - pinky promise: Should we ever meet in real life, let's have a beer (I pay for the beer, you the tip ;-) ). I think that we might have more in common than this thread would indicate.
I put candidates through coding challenges on paper. Hate me if you want, but if you can't iterate an array with a for loop on paper, I don't want you on my team. This should be muscle memory.
The truth is that I will overlook simple errors that would be caught by an IDE. What I'm looking for is how quickly you start writing. The problems I pose are extremely simple (e.g. I start with "write a function to return the area of a circle" and get slightly more challenging from there). If you can't do that on paper, you should look for a different profession.
If we're talking pseudo code, I see paper as valuable. But it is annoying. The reason has a lot to do with the style of coding. When I code, I sometimes decide to move functionality into own functions, delete or add lines etc. That just doesn't work the same way on paper. It completely destroys "the flow". And having watched many developers coding, I learned that such behavior is quite individual and additionally varies depending on IDE behavior, language, followed code style. So no, overall not a paper fan.
Yeah, I have used "on paper" a couple of times, but it really is incompatible with flow.
An analogous (and much more insightful) task is to have them flowchart a described algorithm on paper.
I probably should have been more clear. These are functions of 10 lines of code or less (some are 1). I don't care if you can write a bubble sort or Dykstra. It's completely useless. I just care if you can carefully read simple instructions and quickly write a loop or a couple lines of code to solve it. I don't even care what language it's in. In fact, I have prepared sheets with function definitions already written in the language they said they liked best on the phone interview to make them more comfortable with it.
Let's be honest - if you can't write a one liner on paper to solve the area of a circle given a radius, you have some work to do before you're ready for this line of work.
Well, I don't necessarily disagree that one should know that. But what for? The way you describe it sounds more like you boiled it down to a pure math question.
So not sure if I agree about that being an indicator of whether or not that makes you ready for that line of work.
So, carrying on the earlier thread in a hopefully less heated fashion...
Here's how I do hiring, with excellent results! (Many of my policies today were influenced by earlier mistakes in hiring; I now seldom mis-hire, based on outcomes.)
I hire entirely for a programming internship that requires some pre-existing coding skills. I expect that technical skill level will vary wildly, although there is a minimum.
Application phase. Core expectations are made clear, and the applicant must explicitly acknowledge them in the application. Portfolio of code is requested, although there are situations where this may be impossible, and thus waived. I also look for references, and in some cases, unofficial transcripts.
Initial interview (30 min - 1 hr). Learn more about the applicant, discuss the internship and how it will fit into their academic and career goals. This helps them decide if we're right for them.
A coding challenge. They get a full week to complete this, in any language they want! The prompt is a simple, real-world sort of problem, not some sort of a code golfing fizz buzz. I like to give them time initially, so they can really put their best foot forward, without nerves and tight time constraints getting in the way. They can use their favorite tools and technologies, and submit when they're ready. (The actual challenge only takes about 30 minutes to 3 hours to complete well, so the week is a HUGE amount of time.
I review the coding challenge in depth before the final interview, looking for specific things. I can't go into that here for obvious reasons, but my emphasis is on their creative problem solving and good use of their tools of choice. (This also helps me assess how to best tailor the internship to the applicant; it isn't just for screening.
The final interview. I do have them do some live coding here, relating to that coding challenge, which allows me to verify that they indeed can code (and hadn't just outsourced the coding challenge to Taiwan, as some people actually do!). I always account for nerves here — and nerves are actually good, since they indicate the person is aware of their not being The Second Coming™!
Especially because this is for an internship, I also provide constructive feedback to almost all applicants, even if they aren't hired. This allows them to know what they can improve before the next job or internship they apply for elsewhere.
We've gotten praise from many interns after the fact about our hiring processes. The Career Services departments at two universities even use us as an example for other employers!
I'm running out the door right now, but I'm happy to expound on, explain, or justify any of the above. I'm curious what your opinion is in light of your article.
Finally have some time to get to this. I apologise for the delay. Let me start by saying that this approach seems very time intensive for both sides and therefore probably not realistic for many companies.
But I have a lot of questions:
Regarding 1.
When you say references in the context of internships, what do you mean? I assume interns usually have little to no previous experience?
Regarding 2.
Is this interview usually in person or over the phone? And you mention that the prospect can learn about the company, but what do you want to learn about the candidate in this interview?
About 3.
This sounds very interesting. Here are the things that come to mind: how do you ensure the result is based on the candidate's work alone? I tutor on wyzant on the side and the amount of students that basically want to pay someone to do their homework is relatively high. And then there is the majority of students who are eager to learn while we work through the assignments, but probably would have some trouble reproducing the complete assignment on their own. So I am torn. On one side, the ability to "google for" help is an important skill we usually don't test for, but effectively will show the long term abilities required to keep up with emerging technologies. On the other side, I would want to know if a candidate can gather information or work through a process completely on their own. While you do mention that in 5., I assume that you will find yourself having invested quite some time for a "poser" sometimes.
About 4.
I respect that dedication. And maybe on a side note for readers: your GitHub account is always more important than the portfolio you polished to hell. Nothing gives me a better understanding of your abilities and practices then your code.
I usually do this in the resume screening phase, but frankly I have never hired interns so I am not sure what I would get out of it in this scenario. Additionally, I work in a field where proprietary work is common. So more often enough people (including myself) cannot share the work they are most proud of.
So I guess this approach is overall fair, but frankly sounds like the opposite issue to what I am describing in the post (and explains your reaction even better): You invest a lot of time with a relatively high risk. In this case it's just you who spends an unreasonable amount of time without knowing "what's in it for you"
I might lack some important details, but overall, I feel like this approach is not scalable. It might work well for you and your candidates/target group, but I am sceptical of this approach being something that can
a) provide companies with an accurate assessment of a candidate's skills while
b) give the candidate a fair chance to show abilities and
c) design the process so both sides have a reasonable amount of time and risk investment
Um, ha, that's assuming I go through all these steps with each person regardless. They don't necessarily make it all the way.
That's correct. I want to know about their work ethic and their character. Often, references are current/past professors or teachers, or supervisors at prior jobs (usually not tech jobs), and the like. Not having references is not a deal breaker, but it certainly helps.
We're 100% remote, so this is over video chat. I'm finding out about their career goals, what they want out of the internship, their work/study habits, and generally whether our program will be a good fit for them.
Well aware of this problem. The obvious first step is to check for copy/pasted code from online, but that doesn't guarantee they didn't outsource it. We discuss it and have the candidate work on it during the final interview, and that always routs out the rest.
I will have to answer the rest later, but understand: I've been putting this into practice for years, with a high hiring accuracy.
Sorry to switch gears here, but this little sentence opened up a world for me. Are you saying that you are applying long-term metrics to measure "hiring success"? If so, how does that look like? How do you evaluate e.g. that you made the right choice? And after which timeframe do you come to such conclusions?
You must remember, this is an internship, a training program. Whether someone thrives in and successfully completes the program, or washes out (variety of reasons), is a significant indicator. I'm also the internship supervisor, so I'm the one responsible for mentoring, tailoring the program to individual needs, answering questions, and helping the intern succeed.
It is worth noting that, of our 12 program graduates, 9 are in mid-level coding jobs, 1 is in the army, and 1 in graduate school. Only 1 is not in the industry because of the geographic area he wants to stay in.
The percentage of how many hirees actually graudate from the program has gone up significantly as we've refined our hiring process (although our hiring rate really hasn't dropped). I've even checked my assumptions inversely: we've hired some candidates despite some red flags from the hiring process, and they've always wound up washing out due to serious problems.
You also need to know that we have a very diverse team from many backgrounds, cultures, and fields of interest. I encourage interns to be involved in project management and standards development, to share their opinions openly, and to challenge even my ideas! So, their success really is dependent on forming the core soft skills and work habits necessary to thrive in software as a whole.
Regarding the rest of your original response:
I agree! I allow applicants to use their GitHub as their "portfolio" if they wish; and many do.
There are times when applicants have no portfolio, and I account for that as well.
Oh, I know plenty of "what's in it for" MousePaw Media. We have a number of projects going, and I also consider where an intern will best fit. There are times there's a mismatch between goals and interests that becomes quite apparent during the initial interview, wherein the applicant won't continue. We're not right for everybody - we do have actual projects that have to get done too.
We're not an easy internship program to get into. Two of the local universities advised on our program, and one of the Associate Professors (whose job history includes many years at Microsoft) called our program one of the most robust he's seen. He refers students to us directly.
So far, it's scaled well. 30+ interested parties, 14 pending applications (as of writing), and it's working well for a fairly reasonable effort from me.
Again, note the outcomes.
We've been able to spot, not just present ability, but raw and undeveloped talent beyond that. Remember, those same applicants are now in mid-level full-time software development positions at other firms, and very much enjoying their work from all reports.
I deliberately take a bit more 'time risk' on, so as to provide constructive (and legally appropriate) feedback to applicants. Often, this is the first tech position these applicants have applied for. We're forgiving of many reasonable faux-pas, and help applicants understand how to improve before they interview elsewhere.
All of that combined is a major reason why the Career Services departments at two of the universities we work with use us as an example for other internship programs.
Just to clarify: by "scalable" I meant "applicable to a wider range of companies". While a lot of what you write sounds great, it is a very specific and unusual scenario. In most settings, interns are the exception, not the rule.
So while I believe you that this might be the ideal approach for your organization, I remain sceptical of how transferable such an approach is.
And I don't say that to criticize, I say that as I am searching for solutions that can be applied in the broader context.
Unfortunately, the classic career "You come as a junior and stay for the senior positions" seems to be outdated. Most devs make their move after about 3-5 years.
Certainly, there is some blaming on the employer side to do, but there are many other reasons as well. This poses two issues: it's hard to have employees stay with you. And it is costly to fill positions. Especially in the higher roles, it sometimes takes up to a year to have the full output, as complex onboarding and in-depth understanding of code-base and processes are necessary. This makes "wrong decisions" often not immediately apparent.
It sounds to me (and forgive me with not being familiar with MousePawMedia), that you kind of place yourself between the industry and universities in order to buffer this risk. So I assume both the academic institutions as well as the private sector have an interest in "funneling resources" through you in order to bridge the gap.
And if I am right with this assumption, it makes sense that your approach is vastly different.
Nice post :)
I personally dislike Leetcode, probably even hate it, I can understand its intended purpose but I would rather invest my time learning real programming skills
I feel that most people disagree with that, whenever I mention it in websites like Reddit I get downvoted a lot
Well, Reddit downvotes are often related to hitting a point.
Or hitting a nerve. Completely benign statements can get dogpiled for that reason.
Personally going through this process.
I too think most of the challenges I’ve been presented have little to do with real on-the-job work.
By far, the very best I’ve seen so far has been by Woven (via Qualified) where the two problems presented do in fact mimic real case you might face on-the-job, (investigate a bug with little info on a small code base that could be just about any app and communicate with your peers about the findings + finish developing a feature that is half way and again could be part of just about any app).
And don’t get me started when the position is frontend and the tests are completely unrelated.
As you I do understand the goal of testing problem solving skills but most of the scenarios seem so off real life that it’s unreal.
Maybe we’re wrong...
Yes, it's fair to mention the good examples and I would have had an example as well. Unfortunately, I cannot recall the name. But they had a 2 hour screen sharing session where you checked out actual applications and debugged them.
Coding challenges seem to favor a specific personality type not real world coding skills. It also tends to give successful candidates a false sense of confidence in their coding skills. Too much emphasis is placed on an interaction that really only tests a certain type of stress reaction. These challenges test ones ability to solve a well defined problem with a relatively simple solution deterministically. Real world problems are not well defined and the solution usually lies in cooperation.
This. I encountered a candidate whose entire experience was wrapped up in code golfing, which had me concered: can he even write real code? Golfing and real coding are entirely different practices. It's like expecting to complete in the PGA World Cup because you're under par at the local Family Putt Mini Golf, to abuse the analogy. ;)
Well put
I am in midst of revolutionizing this. Going to make virtual chalkboard, with a proper screeching sounds when drawing. Anyone in with this? Just kidding. I absolutely love the original article. Testing culture has a few things that could be done much better, including transferring ability metrics more transparently without them being explicitly carved out by somebody.
There is I think a tendency for software developers to signal their superior intelligence. The job interview is a way to invent tests which exist simply to communicate how wonderfully intelligent they are. I won't be crude, but this is just a member measurement exercise for intellect.
Okay, so what are we aiming for when we give developers a test? Are we trying to find out if they know the syntax? That they have memorized the API to the point they don't need completion? Do they know how to do binary shifting? Generally no.
We are not trying to test the basic language skills as they should have already been excluded if they don't have these skills. We are not trying to perform some kind of intelligence test. Some companies give tests that are meant to test intelligence, but there is an underground market in training to pass these tests. So again, no.
Instead we need to focus on higher level understanding and coding practice in everyday coding. We want to see if a developer asked to modify an application can recognize and correct poor design or anti patterns. Such a test must respect the value of time for a developer, and so must not be too complex. Providing an existing project of small size with a explicit objective means the task can be completed quickly by a competent developer.
This is not a pass fail type of test, but rather a exercise to flesh out whether the developer picks up on common development mistakes and will refactor as they go.
I wrote a article covering the test I wrote. This is good not only for interviews but also as a training exercise.
The Test:
dev.to/cheetah100/java-developer-l...
The Solution:
dev.to/cheetah100/java-developer-l...
It doesn't even prove you know the target language: all of these coding interview questions involve writing everything in one file, a couple of functions, and using only arrays and integers/strings. Not how well you know the language, its features, abstractions, data structures, standard library etc. Just whether you can write a for loop (and only the kind involving i= 0; i < length; i++ type, not anything fancy or even understanding how the for construct works).
On these coding platforms like algoexpert, they claim to support 7 languages (all with imperative constructs), for all problems. What does that tell you? That all of these problems involve very basic imperative constructs - they're not going to write an idiomatic solution within each language, because there's no need.
Lol what a funny post, I don't know if it was intended but It kinda made me laugh a bit xD
And I totally agree, I don't get the point of these tests, and have always hated them (for interviews).
Was intended to be humourous, yes ;-)
Nonetheless I mean what I say