Disclosure: This post includes affiliate links; I may receive compensation if you purchase products or services from the different links provided i...
For further actions, you may consider blocking this person and/or reporting abuse
I think the biggest issue with technical interviews is the fact that a lot of the time the interviewer is not clear on what they want, so say you complete the tasks successfully, and then you get points off because its missing unit testing, or it uses ES6 syntax (happens too many times), or some other arbitrary thing that was never disclosed. As an interviewee, we are pushing our CVs to more than a single company and figuring our how your specific company works for free is not a good deal. For interviewers, I wish you could just be clear, set expectations and metrics and let us do the technical part, the problem is that most interviewers are not clear on these points either and every interview ends up being arbitrary. Good engineers end up with impostor syndrome because of bad recruiters.
Hey good point, I agree interviewers should be prepared and know what they want. One thing I would like to disagree is where you mentioned "let us do the technical part". what do you mean by this? Because in my view as a software developer it is not only "build a script with x stack", it goes beyond that, it takes problem solving, use of analysis, planning, etc.
Also, keep in mind a more seasoned developer will always take into account testing, IMO I rarely see a practical interview that requires a unit test, but it is not a reason to "take off points", as an interviewer I would even be opposed to using a "points" system...
Absolutely @jose and I couldn't agree more. If I really want that job, I will follow Interviewer's mind and tell him what he wants to listen to, but, if not then its also a good indication whether you want to work with close-minded people or not.
"files older than 30 days"
You specifically ask to delete files older than 30 days and then later suggest that candidate should have assumed that he should have archived last month's files. How he's supposed to infer that ?
Now if you asked me:
Can you write a script to archive files older than 30 days and which can be run on 1st day of the month using a cron job?
I would just say
:)
:-) think me as a client, That's why I posted that image. Most of the time don't really know what they want and we need to ask to confirm that. In this, you should ask, why you want to delete 30 days of files? That would lead to a real requirement that he want a monthly archive. I mean, you can disagree but that's the way I generally find what a user really wants.
I get your point, just a bad example with the script IMO. Must absolutely convey that questions as a client, because most people would completely trust a recruiter to get his requirements right. I would.
In one interview I was asked to perform a practical task. I came back with additional questions, because I wasn't sure about the exact requirements and hence the best possible DB solution. I was ridiculed for not inferring the requirements by myself.
After I said I would not continue with onboarding, I asked interviewee to disclose all details. He had no idea about the potential problems with real world implementation of the said task.
I guess my point is that people tend to have a sort of tunnel vision and rule out good candidates based on bad assumptions.
That's true and it happens many times and unfortunately, there is no way to really stop it because nobody questions Interviewer why he rejects a candidate?
This is a pretty good approach, I agree that good developers are good at spotting holes in the requirements and asking questions, but this takes experience too (technical and life experience) , I don't think people are born with any specific skill.
For a fair process I'd apply the method you described as long as I made it clear to the candidate that I expect something around those lines from them. For example presenting the task and telling them "do you need any clarifications before you proceed? Take 5 minutes to think about it and get back to me if you need more details about the requirement". Otherwise it's like putting the candidate to play a game in which they don't know the rules.
Thanks @rodbv , definitely we need to be careful while taking any advice as they don't apply in all the scenarios. If you ask this question to two graduates you don't find much difference but if you ask this to two senior developers, you will find a lot of difference. Also, giving hints is a fair way and shows that you are there to select and not looking for a reason to not-select the candidate.
When I became more senior I had the impression that good developers don't ask too many questions.
This had two reasons.
First, I had to ask less questions because I was working with the stack for many years now and knew it like the back of my hand and not because I was a good dev.
Second, we hired a bunch of devs coming right from university that knew next to nothing about developing and were asking questions constantly about the most basic stuff.
I constantly had the impression they knew next to nothing.
In the end I got the insight that the problem wasn't that they didn't know much, but that they asked in an intrusive fashion.
Sure, requirements have to be clearified with the people who made them, but otherwise try to get the answer from the Internet.
Ask a co-worker if anything is unclear OR you think that their answer would save you hours of online research (and you didn't bother them too often this day, haha)
Hello K,
You are right, but there is a difference between a functional and non-functional requirement. Senior Dev knows both of them so obviously they ask less but they definitely ask the right questions, particularly to users who often don't have any idea what they want. Our job as professionals is also to lead them towards what they really want. Also, on junior developers, there will be some who ask questions and some don't, Mostly the devs who don't ask questions means they are afraid unlike they understood. So, we need to help them and encourage them to ask questions.
Javin
Most of my life is spent answering other people's questions.
So much so, that I have tasks assigned at the moment to create a simple micro service (http get, RPC then DB call & return a simple model). If I had dedicated time, including 100% test coverage, that's two days of work. At worst.
I told PMO to expect 4 weeks, and if they're bringing snacks for me daily, they might get it in 3 weeks. Unfortunately, the PMO estimate is genuinely my considered thoughts on delivery time.
All interviewers want to find themselves on the next developer who is in the interview. That's not going to happen. Advice: drink a coffee or beer with the guy and see if he/she is a good person. All the rest, anyone can learn it.
Just to known, will the good developer drink beer or coffee?
Just to known, will the good developer drink beer or coffee?
Of course. But the main idea is try to get a social encounter with the person.
For me recruitment is more about the creation of well structured, maintainable code, with good tests than anything else. Team work and communication skills are also important factors.
Want to split a word based on screen size? I would assume that even the most experienced programmers will sometimes do a little bit of research beforehand just to see if someone has a better way.
I am on-board with questioning and suggesting requirements but this tends to come from experience in the application domain. Should I presume as someone who doesn't know anything about the context that the 30 day rule has issues? In a real work situation a may ask for clarification but in an interview, I'd only question this if I know that the interviewer is trying to catch me out.
This is a perfect article to demonstrate why an "AI" is not going to be replacing "humans" completely in the field of "computer programming".
Nor "common users" replacing "dedicated programmers". Both ideas that I have read about repeated times.
Thanks for the Article @javinpaul , do you have any advice for average developers, how they can get to the part where the automatically think like good developers.
@Peace Dube, good questions, while I am also an average programmer, but I can share a few things which I have seen good developers doing and learned from them
And, you can also find some more tips on my article javarevisited.blogspot.com/2014/01...
And, May be other great guys here can chip in and advice so that we all can learn from each other.
I'm sorry, but "don't commit time" sounds like bad advice.
We have a junior dev that refuses to give story point estimates & his reasoning is always "I need some time for analysis first" (even when seniors & PMs have broken the task into simple statements that require no thought).
That dev has been parked on our documentation project, and if that ever dries up, they'll be fired.
A good developer needs to learn how to forecast time, manage expectations & deliver on time.
This is a very interesting approach, based on my experience interviewing people, it doesn't matter how many things you try to get out the candidate, it is always a gamble. I read from someone in the comments that the interviewers most of the time don't know what they want, I agree... As an interviewer you need to do your diligence and hash out the things you need for the position and want out of a candidate, still it doesn't mean you will find the perfect person.
Great article!
There's no client can describe their requirements thoroughly, at least most of the clients. It's the our job to clarify the requirements.
Indeed, that's the point of this article. As a professional, it's our responsibility to get the requirement right just like a Doctor asks questions to diagnose a disease.
Interesting points. I’ll take some ideas from here to think about. Thank you for this post. I have written a post about a technical interview about 1,5 years ago. Maybe it can interest you - github.com/SurenAt93/Technical-Int...
"He did not think about two contradicting parts in this script, finding files older than 30 days and running it on the 1st of every month. Since the script's objective here is to back up last month's data and month can be any of 28, 29, 30, or 31 days. So if you run this script on 1st march, it will not archive any files because all of them are less than 30 days old because February is usually 28 days long."
Hello, I would like to add some thoughts to the CRON question.
First and foremost, I would try to make sure that we are talking about files on the filesystem (because for instance, they could refer to a database related file indexing or something like that).
As soon as I got the answer, I would try to clarify what "to archive" means. Does it mean moving the files to a separate directory? Maybe it means to change the file's name?
As soon as I am confident that I have all the details, I would outline how I would implement this script (ie. I would say that we need to split this task into 2 smaller subtasks, one for creating the archiving script and one for creating the CRON script and for running it). As soon as the interviewer (or the person I report to) agreed about it, I would go ahead and build it.
Actually, I believe that if after this process the person in charge is not satisfied with my work, the issue actually is on their part, as we are software developers and not mind readers. We can not read the minds of other people to figure out what they want. Actually, it's their responsibility to convey to us all the requirements and the scope of the deliverables (ie. they could just outline the main task, which in our case is, at the start of the next month, to archive all the documents of the previous one. What do you think?
Hello Nick,
You have started well, that should be the process, and it's not about mind-reading, its about experience. Doctors are not minded readers but their job is to treat the patient and for that, they need to ask the right questions and validate them. Ultimately, we all are trying to create a positive experience here and giving what the client wants is the best for all. Another thing is a quick demo for clients.
seldo.com/weblog/2014/08/26/you_su...