Technical challenges for interviews - rant

Soldato
Joined
1 Mar 2003
Posts
5,508
Location
Cotham, Bristol
Anyone ever come across coding challenges for interviews, where they use conflicting language like. Production ready, keep it simple, don't over engineer and recommend max of two days!

Just had one for a principal backed dev position that wanted a Web frontend, a rest api, csv parsing, orm, web client integration to a third party rest api and the rest api you create should accept an API token! Oh and create documents and supporting images.

Did all of the above in about four days including unit and integration testing and thought right I'll do a nieve approach for the token and just check some hard coded value as a bearer token just to wrap it up and make a note in the todo for OIDC/OAuth given more time.

Rejected :mad:
 
Last edited:
At least it was a realistic test, as opposed to the "solve this computer science problem" type that you likely would come across once or twice in an entire career and chances are you would just call a library someone else already wrote to solve the business problem.

Yes I did the algorithms courses, but no I don't memorise the solutions when they're in the textbooks should I need them.
 
At least it was a realistic test, as opposed to the "solve this computer science problem" type that you likely would come across once or twice in an entire career and chances are you would just call a library someone else already wrote to solve the business problem.

Yes I did the algorithms courses, but no I don't memorise the solutions when they're in the textbooks should I need them.

You mean "quote statements from a text book", or "memorise all possible algorithms even though you won't use them for day-to-day work"?

It's usually because they're too lazy/busy to create proper interviews.
 
You mean "quote statements from a text book", or "memorise all possible algorithms even though you won't use them for day-to-day work"?

It's usually because they're too lazy/busy to create proper interviews.

Yeah - the ones where you need to live on leetcode/hackerrank/algoexpert/codility etc for a while until you can regurgitate the algorithms from memory. Seems like all they're doing is filtering to choose people who will just learn by rote. If those types of problem are really what the day to day job is then I'd sure as hell not want to work there. Boring as hell.

I was on the other side of the process for a while last year - what we really wanted was to find some reasonably competent people who showed willingness to learn and the honesty to say when they didn't know. You can train that type of person up, they know they're learning and are far more motivated to stay when there's a feeling of progression both technically and in the business area.
 
Yeah - the ones where you need to live on leetcode/hackerrank/algoexpert/codility etc for a while until you can regurgitate the algorithms from memory. Seems like all they're doing is filtering to choose people who will just learn by rote. If those types of problem are really what the day to day job is then I'd sure as hell not want to work there. Boring as hell.

I was on the other side of the process for a while last year - what we really wanted was to find some reasonably competent people who showed willingness to learn and the honesty to say when they didn't know. You can train that type of person up, they know they're learning and are far more motivated to stay when there's a feeling of progression both technically and in the business area.

Yea, I think the majority are just looking for worker bees. Very rarely do companies invest in senior staff and rather just overwork those with the domain knowledge and have the rest churn out code.

I also host interviews on occasion and it's very much discussion based. Questions are based on actual problems that we've had to solve; allows for some good back and forth. if you're able to talk through a solution, it's usually a sign that you can think beyond 1 Google search.
 
you'll be shocked how many people will tell you in an interview to your face all the great things they've developed and everyone on their dev team comes to them with questions etc however as soon as you test them out with very basic questions they completely fail - i.e. not able to even attempt an answer, The Technical tests put people on the spot and you get a rough idea if they code regularly - no one should be bothered about specifics/spelling etc if people hire without them they are playing a risky game!
 
you'll be shocked how many people will tell you in an interview to your face all the great things they've developed and everyone on their dev team comes to them with questions etc however as soon as you test them out with very basic questions they completely fail - i.e. not able to even attempt an answer, The Technical tests put people on the spot and you get a rough idea if they code regularly - no one should be bothered about specifics/spelling etc if people hire without them they are playing a risky game!

Junior to mid maybe, but I find it gets more complicated with senior employees as their value lies beyond churning out code. That being said, I’d want more than just a code monkey for junior and mid positions.

Ultimately interviews should have a balance. I like to keep a personal project or two handy as that gives a better indication of my abilities.
 
Last one was fairly simple though a tad intimidating. Just had to code a simple console app to load and parse some data into specific format XML files but while sat in a board room with the it director and lead dev.
 
you'll be shocked how many people will tell you in an interview to your face all the great things they've developed and everyone on their dev team comes to them with questions etc however as soon as you test them out with very basic questions they completely fail - i.e. not able to even attempt an answer, The Technical tests put people on the spot and you get a rough idea if they code regularly - no one should be bothered about specifics/spelling etc if people hire without them they are playing a risky game!

Doing a technical test is not the problem. This one seems completely unreasonable though.
In fact, I would most likely withdraw my application if I was given a test like that. I get the impression that whoever set that test doesn't understand the development process or the timescales involved. Would it be similar if you got the job? Would you end up being given absurd deadlines on work similar to the test? I can't see it being a nice place to work if your manager doesn't understand or appreciate the work you'll actually be doing.
 
Last edited:
The tests we used had a range of questions/scenarios from very basic to more complex queries (which we wouldn't expect 60% of people to be able to answer) to get an idea on someone's level. This was alongside an interview etc. When you're hiring technical guys there is a lot of pressure to get a good candidate as it's not a job you can try and blag a lot of corporate jobs. No one likes firing people and if you make the wrong decision no one wins and it upsets the team so it's crucial to get that step right otherwise it just mean pain. The example given seems tough but I don't know what the job description/salary was so can't comment if it's excessive.
 
Tests are good for junior positions where you have a lot of applicants and people may not know the fundamentals. For senior level roles though, they don't provide any value imo. Most places I've worked we will still progress senior candidates even if they refuse to do a homework test.
 
The only technical tests i've done are reasonable and relate to skills required for the job and aren't over the top, even some curve balls in there.

However for me, if I were asked to do as much as you've been asked, I would consider that a company I wouldn't want to work for. If they're asking that much, kinda taking the **** just at the interview stage, what will they be asking when they pay your wages? I'd definitely put them down as a 'no' for me.
 
Anyone ever come across coding challenges for interviews, where they use conflicting language like. Production ready, keep it simple, don't over engineer and recommend max of two days!

Just had one for a principal backed dev position that wanted a Web frontend, a rest api, csv parsing, orm, web client integration to a third party rest api and the rest api you create should accept an API token! Oh and create documents and supporting images.

Did all of the above in about four days including unit and integration testing and thought right I'll do a nieve approach for the token and just check some hard coded value as a bearer token just to wrap it up and make a note in the todo for OIDC/OAuth given more time.

Rejected :mad:

Sounds to me like they wanted you to code up their system for them. Free coding.

I got this in a product management interview once - they wanted analysis and presentation (including a copy of the slides for selection consideration) with strategy etc. Didn't get the job but then the company product mysteriously aligned with the presentation..

Essentially any "you code this to production ready" to that level is a scam.

I'll interview with technical bod to ask questions or questions on a paper for them to complete, optional step for a short list is to bring the individual in for a day and have them code through with the engineers. This depends on the product/security etc but overall get the design and coding together. Then ask the engineers for feedback and their feedback on how they feel they fitted. If the org is large then you can't do that easily, but if they're an agile smaller operation then you can.
However the coding day is a commitment from both sides, and I'll pay the expenses (although not the salary for the day) - in company time and not "your time and money" so to speak.
 
Back
Top Bottom