In my experience at previous employment there were a lot of chancers in technical contracting for Java and front-end dev in London.
They all interview well, but when on the ground and asked to do stuff they are usually found out to be useless fairly quickly.
The "one weird trick companies dont want you to know!" is that it takes about a week or two for people to fully appreciate the contractor is useless and needs to be sacked, by which point they've made £500/day over a week or two which is £2500-5000 for half a month's effort which for a majority of people in London is a pretty tidy sum.
My lesson learnt from this is dont just quiz people in a face-to-face interview, but get them to do something in the interview.
Contractor in London here. I've seen this for Python / dev-ops as well, well more the aftermath since the contractors were usually already gone. But the level of incompetence was jarring for someone on 500 pounds per day (this was before Brexit).
Remember the people in these examples have been employed in the industry for years. You'll probably be working either alongside them or on the code they produced...
This has always been true in London - if you are willing to blag it you can get a well paid contract role. You can normally spot them because they have a lot of 3-6 month contracts, and no renewals
I've never had a contract that wasn't renewed (apart from one two week project based contract because the work was completed), in three years I've had four clients. All contracts started off as three month contracts.
I once attended an interview for a contract in the south of the UK with a company that I had applied to before a couple years back but sadly had a mandatory "must have degree" caveat. Strangely enough they'd dropped it the second time round.
I step into the interview room and this tired looking 55-60 year old gent asks me the first question.
> What does the "private" keyword do.
Said in such a tired fashion that I skipped the question mark to effectively transmit its delivery.
So I answer, as you do and this gent breathes the biggest sigh of relief I've ever heard. I ask him what's up and he replies:
> You're the sixth candidate I've asked that to today and the only one to get it right.
We have issues with finding real talent in the UK (my company STILL has an entire team of 4-6 developers to fill) and Brexit really isn't helping.
I exaggerated the number a little. I think I was the third or fourth.
At that company I met a contractor who thought architecture meant just turning everything into a Singleton. I was asked to write some tests for his code (fml).
One chap at my last place had a crusade against the global variables littered throughout the code base. By gods did he fight the good fight. After what must've been a good 2 years of active bitching and pruning, a new product was developed by a sub team without him - to be considered the pinnacle of tech that the team could produce.
Look at this - just a single global variable!!! Amazing! The progress!
Just that one global Dictionary<string,object> which contained everything the various classes would ever want, all easily grabbed with nothing more than a string and a quick cast into whatever the actual type was.
yeah but Eastern Europeans that we got through the EU were culturally equivalent, the ones further east are much more of a crapshoot and the now the EU ones are less likely to want to come since we exited the EU because it doesn't guarantee them the rights they now expect.
Any visa fix is not as good as what we already have.
I'm a contractor, but I prefer to work remotely from my comfortable house in Cardiff.
The tech industry is changing, and there is no need to waste office space on developers if it isn't required, especially if it's a team of contractors anyway.
The story of the senior Java developer is startling but plausible.
If you work on legacy applications for 15 years and you're never the originial author who starts from scratch, it is very possible that you'll never write a main method. You always have one already.
yeah but how the hell do you even start to grok a code base without knowing how to identify the main entry point? This is what disappoints me with MS technologies like WPF where they go out of their way to hide the static void main.
You can abstract out how things are setup. If you have an inversion of control framework that creates all your objects and makes sure services get started in the correct order then you don't really care about the exact details.
I went to this data engineering interview and it appeared they had the same list of questions for all their roles (ranging from senior C++ engineers to Python ETL guys). After really struggling with some questions on libc, low level network and bitwise operations, I was asked "do you know how to quit vim?"
Why should I know the exact signature of the main method? It's not like you write it every day. Eclipse offers to add the main method for you with one clicking I guess IntelliJ does as well.
Hell after programming only Rust/Haskell/... for a while I forget the order of the statements of for loops in C/Java
For the first question it is very much possible that the interviewer expressed himself not clearly enough what he actually wants.
and if that technology doesn't have IDE support?
Lets say that due to an emergency you are the only person that can look at a problem with a WinForm client and there is an issue with Initialisation prior to the WinForm loading. Lets say (since this is a _very_ good example) that you need to create an architecture to share components between WinForm.
Without knowing of static void main within program.cs you're not going to find the entry point and any attempts to share components is going to result in static sadness without doing some sort of service container gubbins or constructor shenanigans (although that will fuck the designer) prior to Application.Run(form) hitting in static void main.
The ignorance of static void main is a key reason why so many WinForm applications actually suck and why so many developers make the sad mistake of putting their user interface FIRST which has the knock on effect of making code reuse problematic. This is fine when people make utils but I have a very long experience of seeing companies struggle with this issue as their util grows into something more complex.
The entry point IS important and if you're trapped in an IDE you suck. Go read pragmatic programmer the chapter: Wizards. You need to know how Wizards do their magic or you get burnt hard when the magic breaks.
you state that it's a problem when programmers don't know about the main function and I agree. The article on the other hand complained about people not knowing the exact function signature of main without thinking.
That's also something I'd want to filter out, developers that are entirely reliant on their IDE and can't do simple things without it. I love Visual Studio, but there are way too many working developers that assume something can't be done if if Visual Studio doesn't have a built in menu option to do it, or they assume that the built in VS way is the only way.
People like this tend to be the type of developers that can make stuff work, but because they aren't curious they never really learn how things are put together and their lack of knowledge comes out in several ways. The most common one is wheel reinventions, because googling available wheels isn't something they'd ever think of. Another common one is writing very inefficient code because they don't understand what's under the hood.
For a large codebase, normally I use the thing, note the different UI elements and messages, search the code to find where they are created and set up, pick one, and look into what happens when that particular element is triggered by the user.
In other words, ask "how does button ABC do its thing?" or "where does message XYZ really come from?" and plunge down the rabbit hole. This tends to be a more fruitful approach than trying to understand how the whole application works from start to finish.
Moreover, with existing codebases it usually happens that most of the issues are not in starting and finishing, but in all that happens in between.
In terms of IDE support, for me the most important feature is good search. When I stumble upon a hairy-looking method, for example, I want to be able to quickly see where and how it is being used.
> should be derivable by anyone who knows how programs work.
That ought to have been a clue. Knowledge of the function signature of the entry point of a program ought to indicate why the signature is the way it is for your favourite programming language. Although now, judging by the replies. Seems like that's a bar a little too high. /sigh, yep I think I should retire soon.
This is a phone screen. I have a candidate who presents himself a Java expert with all kinds of projects under his belt, certificates etc. He does give vaguely sensible answers to my questions but refuses to name any Java standard library class, any specific method in Spark (which he also claims to be using extensively), no specifics of anything. At this point I'm starting to wonder - is this guy really a hands-on programmer? Does he actually, personally write code? Sure, we all use IDEs and don't have to remember everything exactly, but this guy is drawing blanks on the seemingly most basic things. How do I find out? What is the one thing it is impossible to not know if you're any kind of java programmer. Hence - public static void main(String[] args)
Please understand that I don't care if the candidate remembers Java syntax for it's own sake. We don't even use Java at this project. I only ever ask Java questions if this happens to be the candidate's favourite language. If you don't remember how to write the 'Hello World' program in your favourite programming language after more than a decade of using it, then I don't even want to see you embarrass yourself in the next stage hands-on coding interview.
I realise that the way you've worded the exchange is just to make an example of your point, that said - I would've known the answer to the question, but the way it's worded might have made me look at you sideways in an interview if only because of how it's been framed.
If you had worded the query "Regardless of programming language, what's the [accepted/efficient] way to store a series of variables so that I can quickly find a single value later" I'd have given an answer.
Also, as hashtables / dictionaries are key-value stores I'd have been thrown off by the fact that in the question you're not looking for a value by a seperate key, but by the value itself. Fair point on the applicant not knowing how long that would take to return though, and not being familiar with the most common parts of the standard library after 16 years.
I've done a lot of recruitment over the years. In fact in a previous role I spent an entire year doing nothing but recruitment. This sort of thing is sadly commonplace.
It's not trendy or popular at the moment but asking somebody to write some simple code on a whiteboard is a reallygood indicator of whether or not they're a good programmer. Even if they're nervous and uncomfortable doing it you'll find out if they're a good programmer or not.
That being said you want to try and weed out the people who definitely aren't good programmers before you invest the time in interviewing them. Things like Codility can be helpful, or you can do a 20 - 30 minute telescreen/Skype call and ask them to write out some code in a shared Google Doc.
Honestly, if you can't reliably write some simple code on spec - e.g., write a function to reverse a string in a C-like language (if you're recruiting for Java, C#, C, C++, Go) - you may be many things, but programmer is not one of them.
An argument I often hear against this sort of question is that it's not "realistic", but that misses the point. The point with problems like this (also Fizz Buzz, and the simple data structure problem in the article) is not to be "realistic" but to cut to the essence of a person's skillset and leave very little room for blagging. If you can't handle these things I don't believe you can handle more "realistic" problems either.
Being a software developer is obviously more than "just programming", but the fundamentals matter, and programming is absolutely fundamental to software development. Do not accept any hand-waving or flannel from anyone on this point, ever.
I would disagree. I was far better at that sort of thing straight out of university where we did a lot of small scale coding problems. Now I think a lot more about architecture and avoiding clever coding, more about database design and how everything fits together. I write far better code than I did 15 years ago, but I am poorer at white board style problems.
Any decent programmer without a major handicap should be able to come up with a simple algorithm on the fly and write it on a whiteboard.
That doesn't mean you have to be good at it; you may take your time, the syntax doesn't matter and it'll likely not be totally correct. But if you can't do it at all, which many candidates can't, I find it hard to believe you could be a useful programmer in any capacity.
If we were talking about Google interview style problems - data structures and algorithms I might agree.
If you can't do something as simple as FizzBuzz, or reverse a string (in a language of your choice) then you aren't a programmer. You might be something else - a system engineer, possibly an architect - but you are not going to be useful in the role of writing code.
I get that, and I'm certainly not disputing the huge amount of extra skills you gain throughout your career. But reversing a string is categorically not clever coding.
While I agree that this is very common and that these basic skills are mandatory in any programmer, I don't think whiteboard interviews are helping very much.
How I like to hire new people is by working with them for an hour or part of the day. Just on one of the candidates toy projects. Within about few minutes you'll learn if this candidate is in fact a programmer. The rest of the time you can get to know the candidate a little better, learn a bit about how they work and how they think. And you don't put the pressure on them for coming up with solutions on the spot.
> It's not trendy or popular at the moment but asking somebody to write some simple code on a whiteboard is a really good indicator of whether or not they're a good programmer.
This again? This has been argued to death on HN. All the evidence points towards that type of interview having absolutely NO correlation to programming ability. It's also NOT what the author was talking about in TFA. He wasn't talking about general programming ability. He was talking specifically about data engineers who need to know how to do exactly what he was asking for on a daily basis. Notice nowhere in TFA did the author mention a whiteboard even once.
I dont think it even needs to be reverse a string or fizzbuzz or crossword solver to filter people out - personally I think that some of these "easy" questions often have too much of a riddle about them, especially if you are just hiring bums-on-seats to crank out CRUD or MVC code to meet a looming deadline.
I dont want to try and trick them or see if they grok my contrived question - I want to know if they are self-sufficient and get stuff done (sure if you are trying to hire a contractor to do significant design & architecting, then sure use the riddles)
Next time I am recruiting contractors I think I'd probably just hand them a clean-install laptop with just notepad + compiler (or browser, if they are a frontend dev) with no internet connection or fancy libraries, then ask them to write something super basic, like print out the 10 green bottles song on screen, then sit back and watch over their shoulder.
If they cant do that in 5 minutes, then "Thanks for coming, we'll be in touch!", if they can then the real interview starts.
Next time I am recruiting contractors I think I'd probably just hand them a clean-install laptop with just notepad + compiler (or browser,
Well, one more reason to love my employer who didn't pull this kind of craziness on me.
Just remember a lot of us hasn't written a main method for years:
Traditional Java web applications doesn't use main as an entry point even if I understand that todays cool ones probably do.
And compiling from the command line without maven? Haven't done for years.
I'll figure it out, fast, with internet. But leaving people with notepad and a compiler: that is going to sift out a number of good Java backenders - if not for anything else then because it feels stupid and a bad start of a relationship. That's not something you want when the market for programmers is red hot.
I'm still fairly competent at a lot of other aspects of Java and have successfully maintained and simplified a lot of software.
I think obviously it depends on specifics of the role etc - I'd not expect (nor need!) a web developer to know how to write a command line app etc. Just needing bums-on-seats developers to just churn out MVC code and who dont know how to do "javac -help" if all they've ever used is maven or gradle etc might be acceptable, but I might lose a bit of faith in humanity along the way (...and maybe I expect too much!) :-)
Perhaps it would be better to have a very, very, very simple application (like a simple calculator, or a simple web app, using the framework(s)/libraries you're using and the person is applying for (i.e. they should know it)), then show them a failing unit-test and/or a simple bug report and see what they do to resolve it.
Basically, I want to see someone actually do something realistic and actually produce something tangible for me to judge my decisions on. I've been burnt a few times in the past hiring people who were good at the "book smarts" during interview, but were bad when it came to actually doing stuff.
I think that these people are not necessarily dumb. Thr problem is that they started traversing the knowledge tree depth-first instead of using breadth-first for at least a few years.
The UK software contracting market seems to be flooded with people like this in general. It's infuriating if you can actually do the work because it makes it very difficult to make it past CV sift stage when everybody is blagging.
I have personally encountered this because while working on a legacy java code base. Maps were never used because java didn't even have maps until after 1.3 or 1.4.
60 comments
[ 3.7 ms ] story [ 117 ms ] threadThey all interview well, but when on the ground and asked to do stuff they are usually found out to be useless fairly quickly.
The "one weird trick companies dont want you to know!" is that it takes about a week or two for people to fully appreciate the contractor is useless and needs to be sacked, by which point they've made £500/day over a week or two which is £2500-5000 for half a month's effort which for a majority of people in London is a pretty tidy sum.
My lesson learnt from this is dont just quiz people in a face-to-face interview, but get them to do something in the interview.
I step into the interview room and this tired looking 55-60 year old gent asks me the first question.
> What does the "private" keyword do.
Said in such a tired fashion that I skipped the question mark to effectively transmit its delivery. So I answer, as you do and this gent breathes the biggest sigh of relief I've ever heard. I ask him what's up and he replies:
> You're the sixth candidate I've asked that to today and the only one to get it right.
We have issues with finding real talent in the UK (my company STILL has an entire team of 4-6 developers to fill) and Brexit really isn't helping.
> Its in the Gang of Four!
Was his defence.
Look at this - just a single global variable!!! Amazing! The progress!
Just that one global Dictionary<string,object> which contained everything the various classes would ever want, all easily grabbed with nothing more than a string and a quick cast into whatever the actual type was.
Magic
(sarcasm on the internet failure)
The tech industry is changing, and there is no need to waste office space on developers if it isn't required, especially if it's a team of contractors anyway.
If you work on legacy applications for 15 years and you're never the originial author who starts from scratch, it is very possible that you'll never write a main method. You always have one already.
I've never felt more super human.
(at least for emacs users)
We'll always have Switzerland, roel_v.
(It's Zug that has the 6% tax rate, right?)
For the first question it is very much possible that the interviewer expressed himself not clearly enough what he actually wants.
The ignorance of static void main is a key reason why so many WinForm applications actually suck and why so many developers make the sad mistake of putting their user interface FIRST which has the knock on effect of making code reuse problematic. This is fine when people make utils but I have a very long experience of seeing companies struggle with this issue as their util grows into something more complex. The entry point IS important and if you're trapped in an IDE you suck. Go read pragmatic programmer the chapter: Wizards. You need to know how Wizards do their magic or you get burnt hard when the magic breaks.
People like this tend to be the type of developers that can make stuff work, but because they aren't curious they never really learn how things are put together and their lack of knowledge comes out in several ways. The most common one is wheel reinventions, because googling available wheels isn't something they'd ever think of. Another common one is writing very inefficient code because they don't understand what's under the hood.
In other words, ask "how does button ABC do its thing?" or "where does message XYZ really come from?" and plunge down the rabbit hole. This tends to be a more fruitful approach than trying to understand how the whole application works from start to finish.
Moreover, with existing codebases it usually happens that most of the issues are not in starting and finishing, but in all that happens in between.
In terms of IDE support, for me the most important feature is good search. When I stumble upon a hairy-looking method, for example, I want to be able to quickly see where and how it is being used.
Honestly we can't go from disliking ^typical^ interview questions that have no relation to our daily work all the way to this.
The signature of the main function is standard in possibly every programming language and should be derivable by anyone who knows how programs work.
Clearly devnonymous has never programmed in his life if he does not know the exact main function signatures of java and C...
> should be derivable by anyone who knows how programs work.
That ought to have been a clue. Knowledge of the function signature of the entry point of a program ought to indicate why the signature is the way it is for your favourite programming language. Although now, judging by the replies. Seems like that's a bar a little too high. /sigh, yep I think I should retire soon.
Please understand that I don't care if the candidate remembers Java syntax for it's own sake. We don't even use Java at this project. I only ever ask Java questions if this happens to be the candidate's favourite language. If you don't remember how to write the 'Hello World' program in your favourite programming language after more than a decade of using it, then I don't even want to see you embarrass yourself in the next stage hands-on coding interview.
If you had worded the query "Regardless of programming language, what's the [accepted/efficient] way to store a series of variables so that I can quickly find a single value later" I'd have given an answer.
Also, as hashtables / dictionaries are key-value stores I'd have been thrown off by the fact that in the question you're not looking for a value by a seperate key, but by the value itself. Fair point on the applicant not knowing how long that would take to return though, and not being familiar with the most common parts of the standard library after 16 years.
It's not trendy or popular at the moment but asking somebody to write some simple code on a whiteboard is a really good indicator of whether or not they're a good programmer. Even if they're nervous and uncomfortable doing it you'll find out if they're a good programmer or not.
That being said you want to try and weed out the people who definitely aren't good programmers before you invest the time in interviewing them. Things like Codility can be helpful, or you can do a 20 - 30 minute telescreen/Skype call and ask them to write out some code in a shared Google Doc.
Honestly, if you can't reliably write some simple code on spec - e.g., write a function to reverse a string in a C-like language (if you're recruiting for Java, C#, C, C++, Go) - you may be many things, but programmer is not one of them.
An argument I often hear against this sort of question is that it's not "realistic", but that misses the point. The point with problems like this (also Fizz Buzz, and the simple data structure problem in the article) is not to be "realistic" but to cut to the essence of a person's skillset and leave very little room for blagging. If you can't handle these things I don't believe you can handle more "realistic" problems either.
Being a software developer is obviously more than "just programming", but the fundamentals matter, and programming is absolutely fundamental to software development. Do not accept any hand-waving or flannel from anyone on this point, ever.
That doesn't mean you have to be good at it; you may take your time, the syntax doesn't matter and it'll likely not be totally correct. But if you can't do it at all, which many candidates can't, I find it hard to believe you could be a useful programmer in any capacity.
If you can't do something as simple as FizzBuzz, or reverse a string (in a language of your choice) then you aren't a programmer. You might be something else - a system engineer, possibly an architect - but you are not going to be useful in the role of writing code.
How I like to hire new people is by working with them for an hour or part of the day. Just on one of the candidates toy projects. Within about few minutes you'll learn if this candidate is in fact a programmer. The rest of the time you can get to know the candidate a little better, learn a bit about how they work and how they think. And you don't put the pressure on them for coming up with solutions on the spot.
This again? This has been argued to death on HN. All the evidence points towards that type of interview having absolutely NO correlation to programming ability. It's also NOT what the author was talking about in TFA. He wasn't talking about general programming ability. He was talking specifically about data engineers who need to know how to do exactly what he was asking for on a daily basis. Notice nowhere in TFA did the author mention a whiteboard even once.
I dont want to try and trick them or see if they grok my contrived question - I want to know if they are self-sufficient and get stuff done (sure if you are trying to hire a contractor to do significant design & architecting, then sure use the riddles)
Next time I am recruiting contractors I think I'd probably just hand them a clean-install laptop with just notepad + compiler (or browser, if they are a frontend dev) with no internet connection or fancy libraries, then ask them to write something super basic, like print out the 10 green bottles song on screen, then sit back and watch over their shoulder.
If they cant do that in 5 minutes, then "Thanks for coming, we'll be in touch!", if they can then the real interview starts.
Well, one more reason to love my employer who didn't pull this kind of craziness on me.
Just remember a lot of us hasn't written a main method for years:
Traditional Java web applications doesn't use main as an entry point even if I understand that todays cool ones probably do.
And compiling from the command line without maven? Haven't done for years.
I'll figure it out, fast, with internet. But leaving people with notepad and a compiler: that is going to sift out a number of good Java backenders - if not for anything else then because it feels stupid and a bad start of a relationship. That's not something you want when the market for programmers is red hot.
I'm still fairly competent at a lot of other aspects of Java and have successfully maintained and simplified a lot of software.
I think obviously it depends on specifics of the role etc - I'd not expect (nor need!) a web developer to know how to write a command line app etc. Just needing bums-on-seats developers to just churn out MVC code and who dont know how to do "javac -help" if all they've ever used is maven or gradle etc might be acceptable, but I might lose a bit of faith in humanity along the way (...and maybe I expect too much!) :-)
Perhaps it would be better to have a very, very, very simple application (like a simple calculator, or a simple web app, using the framework(s)/libraries you're using and the person is applying for (i.e. they should know it)), then show them a failing unit-test and/or a simple bug report and see what they do to resolve it.
Basically, I want to see someone actually do something realistic and actually produce something tangible for me to judge my decisions on. I've been burnt a few times in the past hiring people who were good at the "book smarts" during interview, but were bad when it came to actually doing stuff.
Along with a thorough discussion about why it works and how it could be improved would give me pretty good faith about a data engineer's capabilities.
Everyone sucks!
I loved hearing about how people suck. I LAUGHED with him, at them.
Our codebase pre-dated that by a long haul...