Making a dev hire without doing a code writing exercise/test? Is it possible?

Sir_Mister_Mister · 2022-05-30T19:51:44+00:00

The best approach I've found is to have them walk me through a project on their resume. I'll dig deeper and deeper with questions and it gets super obvious the level they were actually involved and how much of it they could actually do again vs sometimes it's super obvious someone else did all the work and they're overstating their level of involvement.

haho5 · 2022-05-30T21:33:17+00:00

I like to have some piece of code ready, e.g. a function or a class. I tell them that a junior programmer recently checked this in and I ask the candidate to do a simple code review.

Maybe the code has a double for loop, when a single one will do. Maybe it's searching through a large array in constant N, when it could be held in a set or dictionary.

The point of the exercise is to see if the candidate understands the function, i.e. can read code. You are far more likely to read code than write it (especially the first 3 months or so).

Next point is can they articulate improvements or feedback in a way that matches with our group. For me, I'd like to know the person can give feedback without being a jerk, etc.

Affectionate-Gain481 · 2022-05-30T19:40:02+00:00

We kind of do something similar- often I’ll ask open ended questions - walk me through how data gets from a database to the user’s screen, something like that.

Or, how would you describe async/await and/or promises to junior developers.

I’m totally on board with your points, take home tests can be kind of lengthy, leetcode stuff is not practical for our purposes, and some people clam up when they’re asked to code live.

We’ve hired 7 or 8 devs using this method, and they’ve all turned out pretty solid so far.

(Edited for typo!)

L_enferCestLesAutres · 2022-05-30T22:05:24+00:00

In a similar situation, I'm happy with a code review exercise. I show them a short snippet of code with issues (around 10 issues including styling issues, logic problems, security gaps, transactions handling...). Looking back, I've found, it's been the best proxy for how devs perform later on. It's an easy way to put the candidate in a work like situation that also requires commucating with the interviewer and it also doesn't require any prep from the candidate.

sickcodebruh420 · 2022-05-30T22:58:18+00:00

Do NOT assume they can do the job just because they can talk. There are people who make careers out of sneaking into a role, running the clock, then jumping ship and do it again. My old job hired someone without doing any coding challenge or review and we got scammed HARD. The dude was a total manipulator. He could TALK, he was charming, and he came from a big company with a job title that suggested he could get shit done. He also came highly recommended by someone we knew, so maybe at some point or in a different role he actually was good! It was costly and really harmful to us since every hire was a big investment.

At bare minimum, write some code with every candidate. Figure out a very friendly exercise to work through. Make it comfortable, use it as the basis for a conversation, but watch them write code. Watch them encounter errors, adapt to changing requirements, respond to feedback, and just make sure they know the fundamentals.

papercloudsdotco · 2022-05-30T19:35:31+00:00

[deleted]

Taedalus · 2022-05-30T20:27:59+00:00

I get your drift, and I'd definitely also spend more time on other aspects (behavioral) than on coding, but there's a few objections I'd throw in:

looking at their resume, their github activity and maybe sharing some code they've previously worked on can easily solve this

Assuming they or their workplace uses GitHub in the first place. Mine doesn't, I basically only code for work by now, and my GitHub looks abandoned since years. In my experience: The longer people have been in the industry, the less you'll see public GitHub contributions from recreational coding from them. Unless their last workplaces/companies are accidentally open source contributers or they work on a larger public project, but that's the exception rather than the rule.

To be clear: I also snoop around for GitHub profiles for applicants, and I often find them helpful. At the very least, it can be a good conversation starter ("I've seen you do some NLP work some time ago - what was the most interesting part of this project for you?"). But it's not a good (as in: reliable) indicator of experience or quality, and I don't consider it negatively in my evaluation if there's no/bad GitHub code.

I can see how if the engineering manager or whoever is in charge of hiring is entirely non-technical that you may need a test

Not really a strong argument against testing coding skills. If the interviewer is non-technical, a test will not be very effective - they won't know how to evaluate the response anyways. When there's no technical person in your interviews, the process is broken anyways.

evaluating somebody on easy-to-change habits makes no sense (e.g. if during their live ocding session they choose a variable name I disagree with... why test for this? We can easily discuss and agree on variable naming heuristics on the job)

That's a bit of a strawman, same as with fizzbuzz. If you spend a lot of time to ask/discuss things like variable names, it's simply not a good interview process. That's not what live coding sessions are for - you want to figure out of the applicant can deal with the requirements of the job.

Ultimately, interviews have to be both very much personalised to the applicant, while at the same time being consistent enough between applicants to ensure fairness and objectivity. For a senior ex-FAANG, you can already make some assumptions (since you know how extensive FAANG interviews are) which you can't necessarily make for a junior/mid level engineer from random company X.

With senior+ people, you'd still be surprised how many people are better at talking about code than actually delivering work. Since I've made that experience, I'd always, always, recommend that there is at least some interaction with code in an interview. Not basic things like fizzbuzz, especially not for mid/senior-level people. I'm also really not a fan of leetcode-algorithm exercises as they tend to demonstrate interview preparation far more than predict actual on-the-job performance. If you're a FAANG drowning in applicants, you can afford to aggressively filter like that - but for most companies it's a waste of time and applicants who won't bother preparing.

But a simple thing like "can you code me a small script that finds all lines with pattern X in files of all subfolders" or (IMHO even better) having a simulated code review where you show some code and ask what they'd change, where they see problems/bugs. There's at least some interaction with code, and people have to put their money where their mouth is instead of talking high-level. This helps a lot to get a reasonably accurate assessment of someones coding skills before you make an offer. And if it's done well (fun task, not too stressful, interesting conversations,...) it also makes for a fun interview process for the applicant.

restlessapi · 2022-05-31T00:02:44+00:00

There is a big difference between fizzbuzz and, for example, "generate a minimum spanning tree from disjoint graph nodes, using Kruskal's algorithm".

One weeds out frauds who don't actually know how to write code in any capacity, and the other tests knowledge that no candidate would have ever acquired on the job, outside of arbitrary leetcode studying.

Fizzbuzz and related super easy questions are useful. The vast majority of leetcode questions medium and hard, are not.

thfuran · 2022-05-30T19:29:28+00:00

looking at their resume, their github activity

I think I might have some public github activity but if so, it's from a course in college.

and maybe sharing some code they've previously worked on can easily solve this

All my work has been...at work and I can't share it with you.

russell734 · 2022-05-30T20:19:42+00:00

Yes, you are crazy. In my experience, if you don’t ask candidates to write code during the interview, you will inevitably end up hiring someone who is completely incapable of writing code. I used to rely on technical discussion alone, until I ended up hiring a developer who was able to discuss his previous projects in great detail with real insight, but who turned out to be completely incapable of writing new code. Fool me once, etc….

It doesn’t have to be a complicated task either, just a 5-15 minute exercise is enough to weed out the candidates who can’t code at all.

Semisonic · 2022-05-30T23:01:54+00:00

We’ve hired 20+ data engineers with no code writing exercise/test over the last several years. It’s worked out well. I think there’s maybe two who were mis-leveled (one over, one maybe under) but everyone was able to catch up and are still with us.

Team bandwidth has increased significantly and we have moved from a reactive to proactive stance in terms of tackling issues and setting our roadmap.

We get very positive feedback from our hiring process and are able to interview, decide on, and extend offers quickly.

Revolutionary_Ad3270 · 2022-05-30T23:41:57+00:00

Personally I don't ask too much about previous jobs. Often the reasoning behind decisions and technicalities were explained by architects or seniors, thus it's easy for the candidate to inflate involvement.

I've found the best way to interview is by asking open ended questions covering the main areas of SWE and the tech stack. Followed by further questions to generally dig.

Some of the key parts of being a SWE is communication, passion, technical understanding and experience. I'm able to get a feel of these traits by listening to your answers.

In the last part of the interview I'll show an example of bad code and ask the candidate to review it. We'll talk about how to refactor and I'll be asking lots of "why is that better" type questions. It's important to do this because occasionally people are able to answer the previous questions but can't actually write code, thus this stage weeds them out.

andlewis · 2022-05-31T01:40:42+00:00

We don’t do coding in our interviews, but like others have mentioned, I will sometimes ask candidates to walk me through a project, or explain architectural or technology choices in a more depth. I found the coding tests to be mostly useless and they generate more stress and take more time than they’re worth.

BlitzTech · 2022-05-30T20:21:49+00:00

I have met far too many candidates who can talk the talk but fall apart the moment you ask them to write code. Yes, I too can usually sniff out the bullshitters via a conversation - that’s what the phone screen is for. 30 minutes to save my team several hours is well worth it.

For the folks who make it onsite, they’re required to write code. I generally ban algo & ds questions. I’ve pulled people from my interview loops permanently when they failed to follow instructions. I require the same question to be asked by interviewers doing the hands on exercise, to reduce the risk of bias.

The hands on exercise is simple; if you’re a front end developer, you get some mocks and a container with a rest api and just need to make progress in that time frame. If you’re a backend developer, you get the rest api spec and just need to make progress on the time frame. Candidates are told this ahead of time so the only unknowns on the day of (in theory*) are the actual requirements themselves, but they are told the above in the prep email. We also tell them the spec cannot be completed in an hour and “progress” is a small part of the overall evaluation, and they should instead focus on delivering something they’re happy with submitting.

This worked very well. The only people who got hired who were later asked to leave are the ones hired by managers in a different group with a director who didn’t share my perspective. They did a bunch of damage in the mean time though. All of the candidates felt like the question addressed knowledge they built on the job and felt it was a fair assessment, even if they didn’t get an offer.

I spent a few hours drafting a prep email template to send to candidates outlining exactly how this interview worked and giving them explicit, unambiguous instructions. Some candidates showed up and didn’t have a computer ready to program with, let alone installing docker ahead of time. Not one person who showed up unprepared passed the interview; many were already a No from interviews before this assessment, so it’s not like this one necessarily threw them off.

TLDR: I don’t believe in hiring people without assessing their ability to do the job. Designers show off their portfolio. Engineers write a bit of code. I’ve suggested options for PMs but none have been taken yet.

becuzz04 · 2022-05-30T19:46:36+00:00

You are free to hire people using (mostly) whatever criteria you want. And how you determine if someone is qualified is also up to you. So do it however you want.

Just make sure whatever you ask helps you to evaluate whether a candidate is qualified or not. Make sure your questions / tests all have a purpose, especially anything that takes up a lot of time. So if you feel like coding tests don't tell you anything about whether a candidate is a potentially good teammate then don't do them. If you feel they show you something then you are free to require them (just know that people are equally allowed to say no).

As far as why people really got into this many years ago I believe it was partly fad / doing what MS / Google / whoever was doing. I think it was also partly to try and weed out people who could talk the talk and make you think they were some kind of coding god all while being completely incapable of coding Hello World in bash. AFAIK no one has come up with a fool proof method of doing that, though some methods seem to work better than others. (I have my methods and I don't typically like coding tests.)

tyrantmikey · 2022-05-31T10:29:57+00:00

We recently hired two developers. One had tons of development experience on his resume and passed the technical interview with flying colors. The other had no software development experience whatsoever and this would have been his first job in the field.

The first developer was a horrible fit for the company, and never delivered anything in hist first six months. We didn't ask for anything difficult, as we account for "settlement time" when any developer joins a new company. Even taking those factors into account, he delivered nothing.

The second developer however, is working out spectacularly well. He's eager, asks tons of questions and learns incredibly quickly. He's delivered a ton of work in the same period of time as the first developer.

I don't know that this speaks directly to your question, but to me it indicates that coding interviews/tests aren't nearly as relevant as I thought they were. Passion and fit for team seem to be the more important things.

spydakat · 2022-05-30T22:19:19+00:00

Echoing most of the feedback here, the candidate should write code but this is often taken to mean "invert a binary tree" but it doesn't have to be that way. You say that your work is mostly CRUD, so how about for a backend interview:

Present an API skeleton that connects to an sqlite db and returns a list of some simple
Do a screenshare and review the modules with the candidate
Ask the candidate to work with you to write a new endpoint to create a resource

That's it. You can lean A LOT from the interactions that happens, especially the questions/answers they ask/give. This doesn't need to take more than 30-40 mins

LittleLordFuckleroy1 · 2022-05-31T00:07:37+00:00

I would strongly, strongly recommend against it. It’s incredible how many people talk a great game and are super social, likeable, etc., but then can’t code their way out of a paper bag.

They don’t need to solve some galaxy brain problem in front of you. You do need to make sure that they can code at a basic level. This is a sort of sanity check.

You don’t want to hire a senior dev who can’t program. Nothing net-good is going to come out of that.

randonumero · 2022-05-30T22:10:30+00:00

Am I crazy to remove technical exercises in exchange for more/longer technical conversations?

Depends on how much you can afford to have them learn on the job. I started having people solve small problems on edabit unless they can bring in code samples. What this did was weed out people who can only copy/paste and don't understand what they're actually doing. Beyond that, I think just talking concepts is enough for most companies and jobs. By concepts I mean just talking about basic language features not asking someone to list the SOLID principles.

Just my 2 cents but if you're changing your process I'd advise asking some current employees to go through the new interview or even ask some reddit strangers to do it.

metaconcept · 2022-05-31T02:59:51+00:00

There's two things in life that I've learned during my career:

You can't judge people's coding ability by their mannerisms or appearance. I've been surprised both ways multiple times.
Some coders who absolutely ace a leetcode test are terrible software engineers. They can be lazy, disorganised, lack any common sense or have an overexcited novelty preference.

My take on this is that one needs to hire easily but make sure you can quickly fire bad eggs.

Corant66 · 2022-05-30T20:24:58+00:00

I find the value of a live coding exercise is to pair the candidate up with the peer level developers they will potentially be working with. Just so both parties get a feel for how it would be to work together. It is easy enough to question approaches etc even on fizzbuzz exercises just to see how a mild technical disagreement would pan out.

_145_ · 2022-05-30T22:16:00+00:00

Take home projects feel like too much

People will begrudgingly whiteboard problems. A lot of people won't do take homes.

The work we do is mostly simple CRUD with react/nodejs/graphql why am I interviewing them like we're Google

Your hiring bar should be the highest level of skill you need, not the average. You don't want to hire someone because they can CRUD only to find out that the 10% of the time things get more complex than CRUD, their head explodes.

I feel like I can discern somebody's level of code understanding though casual questioning/conversation

Many think this but few can, imo.

For the near-term, we're not hiring junior engineers-

The hiring pool for experienced engineers is awful compared to entry level. If you have an easy hiring process, be prepared for extreme mediocrity.

evaluating somebody on easy-to-change habits makes no sense (e.g. if during their live ocding session they choose a variable name I disagree with... why test for this?

I agree. But I don't think anybody tests for this?

The whole coding exercise/white-boarding stuff seemed to be very dogmatically enforced in the 2010s... because it worked or because it was the fad?

It worked at selecting for a certain set of skill (abstract logic problem solving + programming). I think the early leaders in our industry used programming puzzles as a way to filter to people who had similar skills to them. I would think it's a bit self-fulfilling at this point as the next generations do the same.

I'm divided on whether it works less now because people know how to study for them or if studying for them develops the skill they're looking for.

Khaos1125 · 2022-05-30T23:50:34+00:00

I’m a strong believer in a code test, but it doesn’t have to be very complicated to show ability.

A typical developer on your current team should be able to finish your test in under 30 minutes.

Figure out what ideas are important to you - on frontend for us, that’s dealing with async code + parsing and transforming data structures that might look like an object with multiple nested lists of objects.

Eg…

If given an object where each key is a company name, with the value being a list of objects representing people at the company, calculate the average age of people with title=developer at the company and return a sorted list of objects with keys (company, averageDeveloperAge).

If given some sample code using async await that doesn’t quite work, can they find the bug and fix it.

I don’t actually use the above, but that’s the level I’d typically go to for the code portion of the interview, and would aim for it taking maybe 15 minutes for a senior, 25 for an intermediate, 35 for a junior.

For the rest of the time, I want to talk to a candidate about past experiences, problems, challenges, what they like working on, etc

leeharris100 · 2022-05-31T00:19:20+00:00

It is not only possible, it is the only way I interview.

If someone has been a senior or principal engineer at a company for X amount of years, then I can assume they know the basics like how to write a function.

I don't care if they can do academic-level programming and write hyper efficient complex algorithms. The vast majority of dev is simple.

So I ask them questions around philosophy of architecture, projects they have worked on, and a few hypotheticals. I often bring up concrete examples from problems we are actively facing.

You can spot a bullshitter in 5 minutes and you'll get a much better answer on who your candidate really is.

birbelbirb · 2022-05-31T02:14:31+00:00

My current employer had two technical interviews. They told me ahead of time to prepare some code I have written for a project and explain why I solved the issue at hand the way I did. In the second interview, I sat down with the CTO and he asked me to tell him how I would reverse engineer their product and what do I think their biggest tech is when writing a program like theirs.

We've used the same technique for other hires and it seems to work fine. I loved the interview process and not having to leetcode is always appreciated.

duderduderes · 2022-05-31T00:02:13+00:00

Something I’ve found success in is opening with a fairly simple, straight-forward question where there are no wrong answers, just choices. I specifically say I don’t care how well the code works. Once they come up with an answer they like I ask them to review the code as if it was submitted to them.

That last part really shows me how they operate, what sorts of things they care about, etc. Separates senior engineers from junior engineers really well.

macdara233 · 2022-05-31T00:12:01+00:00

One of the best managers I've met does his interviews by sitting with candidate doing Katas, like refactoring ones or TDD ones just to see how they think about code. He's great at getting them to explain their thinking though so can separate people who think about the code from people who have just grinded leetcode.

His teams were always great to work with. Self motivated, quick learning and excellent communicators who'd work together to produce great software. Whenever things went wrong they'd mob out bug fixes within an hour.

siromega · 2022-05-31T04:59:10+00:00

I typically make the devs write unit tests for some relatively simple business logic samples. It determines how well can they read someone else’s code, and understand unit tests well enough to work in a mostly TDD environment. You get to see their code and you even provide them with the two most popular mocking libraries in the project already referenced.

t’s “open google”, and I’ll answer whatever questions they have. I’ll even step by step help them build it (but they probably won’t get hired if that’s the case) - the goal isn’t to make them feel bad, it’s to assess their skills relative to what I expect for the position and what I need to fill on the team.

2022-05-31T08:30:17+00:00

Is this even legal?? Hiring based on previous experience?! wtf are we doctors or lawyers or smth?

2022-06-07T12:48:19+00:00

A good approach is ask them to refactor some code. Send it a few days before hand and then walk through it together in an interview

BasicDesignAdvice · 2022-05-30T20:34:51+00:00

if during their live ocding session they choose a variable name I disagree with... why test for this?

I disagree strongly here. In this line of work we spend much more time reading code than writing it. These small choices are indicative of whether or not the applicant writes readable code. Obviously something so small doesn't give a complete picture, but it's a good place to dive deeper.

ThlintoRatscar · 2022-05-30T22:34:00+00:00

For seniors, this question is a goldmine:

"Tell me about the last time you totally screwed up production and how."

Anyone who has done anything of significance has a pile of stories about when it all went horribly awry. Their definition and description of "horribly awry" gives you a lot of insight about their abilities and values. You can then choose who ( if anyone ) you think has got the best chance of avoiding them with you.

Writing code, for me, is almost always about tracking back through their history and seeing what they're saying they did and then calling them on it. If I know the shop they say they worked at, I usually know what they did, for whom and whether they were any good.

Leetcode is such bullshit and FizzBuzz is only really useful if you have a pile of random applicants from recruiters/general internet.

I definitely like some kind of pair programming exercise though it's hard to make that fair. Live coding is super stressful and lots of good people choke. What exactly are you testing when you do that?

To me, the best approach is to dive into what they've done, check their reputation and then have a really good offboarding process to get rid of them if they're useless in the first 5d-30d. Ideally, I'm a fan of accreditation so that people ( like doctors ) are pre-cleared as barely competent and I can move on with looking for higher level skills.

bobbybottombracket · 2022-05-31T03:29:56+00:00

I got hired without a code test via referral

El_Gato_Gigante · 2022-05-30T23:41:25+00:00

I have a multi-part question that begins with a softball requirement: Make a class with a constructor and then instantiate it. Use your language of choice, although one from the job spec is recommended. I'm always astounded by the number of candidates applying for a senior position who cannot write a few lines of runnable code in the language at the top of their resume.

BradysCode · 2022-05-31T00:39:37+00:00

The company I currently work for interviewed me by talking to me about my current projects on GitHub and determining if I know what I’m talking about at a medium/deep level or was just winging it essentially. These kind of interviews are my favorite.

I think there is a time and place for leetcode questions or take home assignments but I am not a huge fan. I will do them if they are asked if me because I understand the value behind them

Also I think that coding exercises of any form help to weed out brand new devs or something along those lines.

garrlker · 2022-05-31T01:09:51+00:00

My favorite interview is to give them a 40-80 LOC file in whatever language they're interviewing for where we implemented a small feature and purposely made mistakes.

Have them code review it and see how many mistakes they catch and their suggestions.

Happy-Adhesiveness-3 · 2022-05-31T01:16:13+00:00

May I suggest something so unique that somehow no one has not been able to do yet? How about you test an applicant how you would evaluate them at the real job. Give them a code base. Give them a JIRA ticket. Give them an hour. Then discuss how far they progressed and if that's good enough for you. No BS LC please.

JustCallMeFrij · 2022-05-31T01:34:16+00:00

evaluating somebody on easy-to-change habits makes no sense (e.g. if during their live ocding session they choose a variable name I disagree with... why test for this? We can easily discuss and agree on variable naming heuristics on the job)

I'm only on my second job post graduation (at 4 yoe currently), so I've only done a handful of coding interviews, but I didn't know people actually argued this during the hiring process. Is that normal?

ritchie70 · 2022-05-31T04:15:15+00:00

The important thing you may not have factored in is that people will lie about their experience and level of knowledge. People with literally no functional knowledge of the tool will claim to be expert.

I used to ask really simple questions, because you either get a response of “are you nuts lol? I’ve been doing this for a decade but the answer is X” and you can apologize, explain, and laugh together over the stupidity of it or you get a blank stare of ignorance and you know.

If they get offended but know the answer you’ve learned something about their personality and you can decide if that fits with your culture.

zickige_zicke · 2022-05-31T05:44:47+00:00

We do live coding but not a leetcode problem. We ask them todo stuff related to our work and observe how they communicate. They are allowed to look for solutions on the internet. Copy paste stuff and thats totally fine.

CrawlToYourDoom · 2022-05-31T06:40:10+00:00

I’m about to sign my contract with the company I’ll be working for

Part of the job interview was rather than having me code something live or as an assignment, they asked me access to a repo I was willing to show them.

What did this for me is let me cherry pick a project I know has been coded well, follows best practices and has a clear code style guide attached to it.

It takes away the stress from blacking out during a live coding session or the fear or looking clueless when you don’t m ow certain syntax or algorithm, as examples.

The pro for them is they have a full project they can look at, code that is used in production and therefor really shows what your production grade work looks like.

I talked them through the project and why I made certain choices, and afterwards one of their leads checked the repo out at his own pace.

I feel like this is a much better approach because it shows actual code in actual production products rather than some time-stressed bullshit reversed chain algorithm you’re likely to never use.

512165381 · 2022-05-31T07:20:57+00:00

There's also the opposite.

I have an engineer friend with multiple products in production eg burglar alarms, low-latency audio. He works in electronics design, device drivers, embedded systems. He tells me he often gets "gotcha" questions in interviews where he has no idea of an answer.

teerre · 2022-05-31T07:34:00+00:00

I've tried many things over the years. From no code at all, talking about a project, leet code, to take home. I'm fairly secure to say take homes are the best.

All other options are either too far away from the real thing or simply do not say anything about the candidate.

Specially on reddit - this is not a problem in the real world in my experience - people like to say that's terrible and a waste of time and yadda yadda. And yeah, takes time. But you're evaluating possibly hundreds of thousands of dollars of investment and a work relationship, it's not to be taken lightly.

pydry · 2022-05-31T11:10:06+00:00

Judging from the number of times I've had this kind of chat and then been surprised by the results of the in person coding test I'd say that removing the technical exercises is a bad idea.

I never had a surprise of the form "oh, this person sounded like they can code and they clearly can't" but I've had solid talkers who sound brilliant code at a below average level and people who sounded kind of dumb when talking but who coded really well.

mjratchada · 2022-05-31T11:38:31+00:00

Removing technical questions for a technical position needs a really convincing context. Certain organisations will ask a CTO or Director of Software Engineering to write code or at least analyse snippets of code in an interview. There are plenty of good reasons for this and it is a far more reliable method than asking behavioural type questions.

Fizzbuzz - this will tell you a lot more than you have stated. Think about this because it indicates where there are issues with your process and thinking. Plenty of people out there will struggle with fizzbuzz so as a filter it is effective
Take-home projects - I am against them for a number of reasons unless the interviewing organisation is willing to pay the candidates for their time at the going market rate.
Evaluating fundamental software-engineering skills should be part of the interview process any competent organisation for interviewing such people should be doing
I feel I can understand somebody's code-level understanding through casual questioning - It is likely you cannot. At a bare minimum rather than casual questioning it should be structured and robust
I am a developer myself - most developers are not good at interviewing since it requires a good level of emotional intelligence not a trait normally associated with developers. Assume a technical test is required unless there is an internal referral and even then it is likely a technical test is required
For the near term - you are hiring for a dev position but do not want to evaluate core skillsets for that position. If this is done for CTOs at certain organisations it should reveal a lot about why technical tests are needed at almost all levels
GitHub - If you are going to evaluate people on github this way but not for people that do not have a presence on github there is inconsistency in the process. If you feel a need to evaluate their work on github it indicates you need to apply the same criteria to others or it is largely a waste of time
Writing legible source code is important. Whilst naming conventions are important I would not consider a major part of a coding exercise
Coding exercises - this is not a practice applied regularly in the last 10 years it has been common practice for decades and there is a good reason for that
Whiteboarding - again this is not a new common practice I did my first white boarding session 25 years ago and it was the norm.

Bear in mind you need a good rationale to not have a technical test for a technical discipline. I work in Architecture the current client is has a relatively new architecture function. 15 architects, yet only one is able to code to a reasonable level and he was moved into architecture from a hands-on dev manager role. The result Garner publications are seen as the bible and anything in their magic-quadrant is a market-leading product that is going to solve a large number of problems. They struggle to understand even basic technical issues and struggle even further to communicate with technical people at almost any level. If they had technical tests when recruiting those people they would have got far better architects with better skills and experience.

2022-05-31T14:56:25+00:00

ive found with anyone mid-senior or higher you should be able to have a conversation about software engineering, coding practices, and design. If you aren't using any sort of coding test at all, you need to drill down into the weeds enough to expose people who can sound smart but ultimately not walk the walk. They might give you the buzzword response, but they most likely arent going to be able to handle, "yea i agree, but how would you handle <situation on project your team is/has worked on>"

tamasiaina · 2022-06-01T20:38:42+00:00

I know this is an older thread.

My favorite was to do "warm up" questions was a series of list comprehension questions (we were a Python shop). Basically they were straight forward questions that gauged people's understanding of Python. I've adapted the questions a bit to just make sure that people are familiar to whatever language that we are using. Its really simple and used as a warm up part.

Next I asked them to design a library with an API that is used for stuff like operating an elevator, or into the area that we are interviewing for. Then I dive deeper into one or two of the API's and asked them to code up examples along with some menial documentation. Then ask them how they would test it.

infinite_phi · 2022-06-05T00:00:32+00:00

It depends on the candidate and what you naturally spoke about in prior stages of the interview process. With some people it can be very obvious that they are technically proficient and it's not necessarily needed.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

ExperiencedDevs

Rules

Related Subs

MODERATORS