10+ years of experience and no hash maps or Fizz Buzz for data engineers
nadbordrozd.github.io
nadbordrozd.github.io
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.
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.
function reverse(str) { return str.split().reverse().join(); }
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.
I've never felt more super human.
(at least for emacs users)
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.
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.
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.
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.
We'll always have Switzerland, roel_v.
(It's Zug that has the 6% tax rate, right?)
Everyone sucks!
I loved hearing about how people suck. I LAUGHED with him, at them.
Our codebase pre-dated that by a long haul...
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.