People suck at technical interviews (2014)(seldo.com)
seldo.com
People suck at technical interviews (2014)
http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews
314 comments
Except that the vast majority of programmers essentially say "I'm very good at taking pictures, but I can't actually show you any of them because they're all property of my previous employers, and I never take pictures just for myself".
> I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously.
100% agree, and Github in particular is great for this. Sadly, in my experience very, very few candidates have such a thing. Even non-code content such as issues they've filed or stackoverflow questions and answers is a very useful way to judge someone's technical abilities, but many candidates don't provide links and either use separate identities/aliases or don't participate.
> I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously.
100% agree, and Github in particular is great for this. Sadly, in my experience very, very few candidates have such a thing. Even non-code content such as issues they've filed or stackoverflow questions and answers is a very useful way to judge someone's technical abilities, but many candidates don't provide links and either use separate identities/aliases or don't participate.
I imagine the vast majority of employers would be pretty pissed if the vast majority of programmers shared their private code, and some might even wish to take legal action. As an employer interviewing and hiring candidates, one should respect and expect this confidentiality to be exhibited and adhered to.
For example, I build things for clients that are proprietary to their businesses. Some things are publicly accessible, like marketing pages, but the real stuff is locked behind employee-only auth. Other things run entirely on internal networks, and can't be accessed from the web. They would be rightly upset if they discovered I shared their code with a third party, or placed it on Github.
Moreover, just because Github exists, doesn't mean programmers should feel obligated to "participate". Outside of developers who maintain or participate in truly used projects, it's mostly noise. The only exception I can agree on is looking at issues a candidate has reported to gauge their depth of understanding, clarity of communication, offering of solutions, and other such valuable insights.
For example, I build things for clients that are proprietary to their businesses. Some things are publicly accessible, like marketing pages, but the real stuff is locked behind employee-only auth. Other things run entirely on internal networks, and can't be accessed from the web. They would be rightly upset if they discovered I shared their code with a third party, or placed it on Github.
Moreover, just because Github exists, doesn't mean programmers should feel obligated to "participate". Outside of developers who maintain or participate in truly used projects, it's mostly noise. The only exception I can agree on is looking at issues a candidate has reported to gauge their depth of understanding, clarity of communication, offering of solutions, and other such valuable insights.
I have all that stuff
No problem getting interviews
Still have to do the "brainteaser of the hour" technical interviews. Fortunately it is often the same question I realize, so this gets easier without needing to go through the whole book on this.
No problem getting interviews
Still have to do the "brainteaser of the hour" technical interviews. Fortunately it is often the same question I realize, so this gets easier without needing to go through the whole book on this.
100% agree, and Github in particular is great for this
No, it's useless for this, because companies don't look at it. That would require the recruiters and interviewers to spend more than fifteen seconds prepping for the phone-screen call, and we can't have that.
Incidentally, after my last job hunt one of my new policies was that I hang up on any company that throws me into their fizzbuzz phone-screen after being the one to initiate contact with me. If they didn't think I had the skills they shouldn't have reached out in the first place, and if they do think I have the skills they shouldn't need to waste my time and an interviewer's time on the fizzbuzz question.
(I say this after multiple companies tried to recruit me with a "we want a Django committer, that's why we're contacting you" pitch and then put me into their fizzbuzz-esque phone screens)
No, it's useless for this, because companies don't look at it. That would require the recruiters and interviewers to spend more than fifteen seconds prepping for the phone-screen call, and we can't have that.
Incidentally, after my last job hunt one of my new policies was that I hang up on any company that throws me into their fizzbuzz phone-screen after being the one to initiate contact with me. If they didn't think I had the skills they shouldn't have reached out in the first place, and if they do think I have the skills they shouldn't need to waste my time and an interviewer's time on the fizzbuzz question.
(I say this after multiple companies tried to recruit me with a "we want a Django committer, that's why we're contacting you" pitch and then put me into their fizzbuzz-esque phone screens)
Many companies don't bother looking at things like that. Even if you have a Github account with some amount of non-trivial, original code on it, they'll put you through a "phone screen" and have you do a longest increasing subsequence/subset sum/longest palindrome substring problem for a front end position. And yeah I'm talking about Silicon Valley/SF City/YC type startups here, not BigCorp Inc.
I agree completely, and this resonates with me particularly because I'm one of the many programmers also serious about other creative endeavors (in my case, the visual arts).
But it's worth considering that in larger companies, management is often terrified of the creative aspect of programming, because it messes with their primary goal of predictability. Thus they seek, many of them openly and explicitly, to make all technical roles fungible.
And as much as that's hurtful to us creative programmer types, it's not an irrational position for them to take.
The fact (or hope) that fungible programming roles can be more easily outsourced, especially to cheap-labor countries, is of course seen as a bonus.
This situation presumably gives a big advantage to any organization willing to engage with the creative aspects of programming, but I am starting to think it's in the nature of organizatins themselves to stop embracing that risk after a certain size is reached.
(Not that this is an argument against the portfolio idea. Even if you're going to work as a fungible cog, you'll probably get a better cog-job faster with a decent portfolio.)
But it's worth considering that in larger companies, management is often terrified of the creative aspect of programming, because it messes with their primary goal of predictability. Thus they seek, many of them openly and explicitly, to make all technical roles fungible.
And as much as that's hurtful to us creative programmer types, it's not an irrational position for them to take.
The fact (or hope) that fungible programming roles can be more easily outsourced, especially to cheap-labor countries, is of course seen as a bonus.
This situation presumably gives a big advantage to any organization willing to engage with the creative aspects of programming, but I am starting to think it's in the nature of organizatins themselves to stop embracing that risk after a certain size is reached.
(Not that this is an argument against the portfolio idea. Even if you're going to work as a fungible cog, you'll probably get a better cog-job faster with a decent portfolio.)
> it's not an irrational position for them to take.
It's about as rational as decreeing that it must not rain on Fridays, and then proceeding to fire the nearest person every time it does.
They do have some very good and rational reasons why they wish programming was not a creative job. When they assume they can change reality by wishing it, they completely destroy their people's (outsourced or not) productivity, throwing the cost of everything into the stratosphere, and the quality way under the floor.
It's about as rational as decreeing that it must not rain on Fridays, and then proceeding to fire the nearest person every time it does.
They do have some very good and rational reasons why they wish programming was not a creative job. When they assume they can change reality by wishing it, they completely destroy their people's (outsourced or not) productivity, throwing the cost of everything into the stratosphere, and the quality way under the floor.
I think the key -- the point at which the position becomes (to me) rational -- is to knowingly accept lower quality, less innovation, etc. in order to achieve predictability.
It's a continuum, so of course nobody ever gets 100% predictability with software. But most of us, if we really needed to, could ratched down our productivity to a level where we almost always delivered exactly what we said we would in each sprint or other schedule unit.
And I think that is the crux. Most people who write software don't want to live like that, but there are a whole lot of managers dreaming of a shop floor full of "individual contributors" who are not very individual, and plenty of CEO's who will happily take that over cat-herding their way to the next iPhone.
That should give a big advantage to any company capable of embracing a little chaos and giving a happy home to talented and creative programmers.
But when I look around and see even, say, Facebook -- a company that needs to innovate and seems to know that -- building developer-hostile open-plan offices, it makes me think we may all be doomed.
It's a continuum, so of course nobody ever gets 100% predictability with software. But most of us, if we really needed to, could ratched down our productivity to a level where we almost always delivered exactly what we said we would in each sprint or other schedule unit.
And I think that is the crux. Most people who write software don't want to live like that, but there are a whole lot of managers dreaming of a shop floor full of "individual contributors" who are not very individual, and plenty of CEO's who will happily take that over cat-herding their way to the next iPhone.
That should give a big advantage to any company capable of embracing a little chaos and giving a happy home to talented and creative programmers.
But when I look around and see even, say, Facebook -- a company that needs to innovate and seems to know that -- building developer-hostile open-plan offices, it makes me think we may all be doomed.
There's definitely a place, probably the majority, for programming jobs that are relatively 'turn key'.
There's probably a decent analogy in product photography. Unless you're going high end, bashing out well lit, well edited and well presented product imagery lies firmly towards the technical end of the photography technical - art spectrum.
Trouble is, many companies think the want these 'product photography' programmers but in reality they need the equivalent of 'stock photography'. And stock photography is one of the most difficult and challenging technical/artistic balances in the industry.
Both turn out similarly neutral end products that can be used almost anywhere and replicated, but getting to those final products requires very different mindsets and approaches.
That's likely stretching the metaphor more than it can handle but hopefully illustrates the point!
And as you mentioned, having that 'personal portfolio' that allows you to sell yourself (another important distinction I made in another comment) will get you the job ahead of someone who doesn't have one.
There's probably a decent analogy in product photography. Unless you're going high end, bashing out well lit, well edited and well presented product imagery lies firmly towards the technical end of the photography technical - art spectrum.
Trouble is, many companies think the want these 'product photography' programmers but in reality they need the equivalent of 'stock photography'. And stock photography is one of the most difficult and challenging technical/artistic balances in the industry.
Both turn out similarly neutral end products that can be used almost anywhere and replicated, but getting to those final products requires very different mindsets and approaches.
That's likely stretching the metaphor more than it can handle but hopefully illustrates the point!
And as you mentioned, having that 'personal portfolio' that allows you to sell yourself (another important distinction I made in another comment) will get you the job ahead of someone who doesn't have one.
There are also different types of programmers. Some will do well with portfolio like web developers. But how you would approach creating portfolio as embedded dev? When you work on proprietary stuff and github repo does not really show that you do well with hardware, because customer might not have time/knowledge to run this stuff to check if it is actually working.
A portfolio isn't something you just have and it does all the work for you. It's a living and evolving thing that is there to show that you can solve problems.
A portfolio says "I encountered X problem and here's what I did about it to make this other thing and therefore solved X problem."
A web dev is a very easy job to create a portfolio for because the product can be your portfolio but when I say 'portfolio' I'm not talking about a GitHub repo of some code you've written, I'm talking about something bigger than that.
I'm talking about having examples of your code, things you've made, perhaps technical writing, perhaps a personal project, perhaps video or other 'evidence' of the programmers work/approach. If that involves making a personal embedded hardware project to show your approach then that's what's needed.
Perhaps another important attitude change needs to be established...
In a creative technical art you are not really selling your 'product' to customers. You are selling yourself. You're selling your ability to solve problems and it's incumbent on the individual to prove their ability. Web devs aren't 'selling' their previously created websites, they're 'selling' their ability to create those past projects.
It's a crucial distinction and programmers would do well to adopt this distinction - they're not 'selling' their GitHub repo for instance, they're using that as an example of how they (their mind?) work to solve problems.
For sure there will be times you work on proprietary/secret stuff or on systems of such scale you can't possibly make an equivalent scale of personal project.
But you can demonstrate your ability and sell yourself, and that's really the key to it all. You have to get to the point in a creative career where you realise you aren't just selling your final product, you're selling yourself, your approach and your way of solving a problem.
Finding a way to do that is how you get the job ahead of someone else.
A portfolio says "I encountered X problem and here's what I did about it to make this other thing and therefore solved X problem."
A web dev is a very easy job to create a portfolio for because the product can be your portfolio but when I say 'portfolio' I'm not talking about a GitHub repo of some code you've written, I'm talking about something bigger than that.
I'm talking about having examples of your code, things you've made, perhaps technical writing, perhaps a personal project, perhaps video or other 'evidence' of the programmers work/approach. If that involves making a personal embedded hardware project to show your approach then that's what's needed.
Perhaps another important attitude change needs to be established...
In a creative technical art you are not really selling your 'product' to customers. You are selling yourself. You're selling your ability to solve problems and it's incumbent on the individual to prove their ability. Web devs aren't 'selling' their previously created websites, they're 'selling' their ability to create those past projects.
It's a crucial distinction and programmers would do well to adopt this distinction - they're not 'selling' their GitHub repo for instance, they're using that as an example of how they (their mind?) work to solve problems.
For sure there will be times you work on proprietary/secret stuff or on systems of such scale you can't possibly make an equivalent scale of personal project.
But you can demonstrate your ability and sell yourself, and that's really the key to it all. You have to get to the point in a creative career where you realise you aren't just selling your final product, you're selling yourself, your approach and your way of solving a problem.
Finding a way to do that is how you get the job ahead of someone else.
Could you make a Photography portfolio without any photographs?
You're allowed to include sketches, because you have time to make those for personal projects. But no photographs because they're all proprietary.
You're allowed to include sketches, because you have time to make those for personal projects. But no photographs because they're all proprietary.
This analogy makes no sense.
I often encountered situations where clients wanted to keep photos 'private'. I couldn't use them in my portfolio. To deal with that I took my camera and lenses (analogous to a computer) and made some equivalents that allowed me to demonstrate my skill in a similar way (analogous to writing some code in a personal project).
Suggesting you should sketch something to show your photo making ability is like writing pseudo code to say you can write python - it's an unrealistic analogy that doesn't happen and has no need to happen.
You can very easily use a camera or a computer for a personal project and make very real photographs or write very real code to demonstrate your ability.
I often encountered situations where clients wanted to keep photos 'private'. I couldn't use them in my portfolio. To deal with that I took my camera and lenses (analogous to a computer) and made some equivalents that allowed me to demonstrate my skill in a similar way (analogous to writing some code in a personal project).
Suggesting you should sketch something to show your photo making ability is like writing pseudo code to say you can write python - it's an unrealistic analogy that doesn't happen and has no need to happen.
You can very easily use a camera or a computer for a personal project and make very real photographs or write very real code to demonstrate your ability.
Think of "the photographs" in the analogy as the code that a full-time developer with a wife, kids, and non-coding hobbies has produced for his/her employer over the last five years. This person may produce a script or a basic website for a portfolio, but those 40+ hours a week spent coding at a full time job is where all of the real problems get solved.
> This person may produce a script or a basic website for a portfolio, but those 40+ hours a week spent coding at a full time job is where all of the real problems get solved.
That's it right there. That's the bit that makes the difference. It speaks to an attitude of 'I'm doing it, I don't need to prove it'. It's wrapped up in 'I'm doing it and I'm too busy to prove it because I should have a life and other people should just recognise my ability so I don't have to sacrifice my lifestyle to put the effort in to get the job I want"...but it really comes down to thinking I shouldn't have to show it because I'm doing it.
There's no can't show it inherent in your original statement. There's a large dollop of don't want but no can't.
You can find ways to prove you ability, to use work you do day to day, to make high quality personal projects or contribute to those that are already running (beauty of programming is it can be easier to collaborate like this and still show your skill).
It can be done. Plenty of people in all industries work one job and study, prepare or work towards another all whilst supporting families and trying to have a life.
Programmers aren't special snowflakes, they've got to work just as hard at selling themselves as all other people in the creative industries do. That's why I think programmers really need to grasp that they actually are creatives and adopt an attitude that deals with all the burdens that moniker brings with it.
That's it right there. That's the bit that makes the difference. It speaks to an attitude of 'I'm doing it, I don't need to prove it'. It's wrapped up in 'I'm doing it and I'm too busy to prove it because I should have a life and other people should just recognise my ability so I don't have to sacrifice my lifestyle to put the effort in to get the job I want"...but it really comes down to thinking I shouldn't have to show it because I'm doing it.
There's no can't show it inherent in your original statement. There's a large dollop of don't want but no can't.
You can find ways to prove you ability, to use work you do day to day, to make high quality personal projects or contribute to those that are already running (beauty of programming is it can be easier to collaborate like this and still show your skill).
It can be done. Plenty of people in all industries work one job and study, prepare or work towards another all whilst supporting families and trying to have a life.
Programmers aren't special snowflakes, they've got to work just as hard at selling themselves as all other people in the creative industries do. That's why I think programmers really need to grasp that they actually are creatives and adopt an attitude that deals with all the burdens that moniker brings with it.
Can you have a decent, up to date, programming portfolio without investing tons of time in it?
Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos than it is to set up an equivalent software project. More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project from 2010 might not cut it in 2016 when you're supposed to join a Scala project.
Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos than it is to set up an equivalent software project. More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project from 2010 might not cut it in 2016 when you're supposed to join a Scala project.
> Can you have a decent, up to date, programming portfolio without investing tons of time in it?
Why wouldn't you invest time in it? It's investing in yourself and could get you your next pay rise. It's not wasted time.
We're back to the point I made above about putting the effort in.
> Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos
Sure, as I already said it's not a perfect comparison, it's there to illustrate a point.
And I reject your second point very strongly. Even something simple like a single headshot can take hours of planning and setup. Something like a documentary project might take months or even years to complete.
Something like a commercial shoot might take a team of 20 a week to complete and cost hundreds of thousands of dollars - how do you get to put that sort of work in your portfolio? Sometimes you work for free, sometimes you create a whole shoot yourself at great cost. You work for it essentially. That's how.
And a single photo might be no more the 'whole' than a single file might be the 'whole' programme for instance.
Anyway, the exact vagaries of the industry aren't important, it's the assertion that programming is a creative discipline that is important.
> More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project from 2010 might not cut it in 2016 when you're supposed to join a Scala project.
Possibly, but a portfolio isn't trying to sell a product it's selling 'you'. Stuff that goes in the portfolio shows how you do what you do, gives a window on how you work, how you approach a problem, how you solve it.
Many photographers will create 'behind the scenes' shoots and videos to show how they work and show clients how they solve problems for instance.
These can be independent of the exact example and just because a programming language might change you can still use an older project to show your skill and approach to a particular type of problem.
Anyway, I've laboured the point long enough, feel free to grab the last word but I think I've outlined my point well enough to be understood.
Why wouldn't you invest time in it? It's investing in yourself and could get you your next pay rise. It's not wasted time.
We're back to the point I made above about putting the effort in.
> Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos
Sure, as I already said it's not a perfect comparison, it's there to illustrate a point.
And I reject your second point very strongly. Even something simple like a single headshot can take hours of planning and setup. Something like a documentary project might take months or even years to complete.
Something like a commercial shoot might take a team of 20 a week to complete and cost hundreds of thousands of dollars - how do you get to put that sort of work in your portfolio? Sometimes you work for free, sometimes you create a whole shoot yourself at great cost. You work for it essentially. That's how.
And a single photo might be no more the 'whole' than a single file might be the 'whole' programme for instance.
Anyway, the exact vagaries of the industry aren't important, it's the assertion that programming is a creative discipline that is important.
> More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project from 2010 might not cut it in 2016 when you're supposed to join a Scala project.
Possibly, but a portfolio isn't trying to sell a product it's selling 'you'. Stuff that goes in the portfolio shows how you do what you do, gives a window on how you work, how you approach a problem, how you solve it.
Many photographers will create 'behind the scenes' shoots and videos to show how they work and show clients how they solve problems for instance.
These can be independent of the exact example and just because a programming language might change you can still use an older project to show your skill and approach to a particular type of problem.
Anyway, I've laboured the point long enough, feel free to grab the last word but I think I've outlined my point well enough to be understood.
> feel free to grab the last word
I hope you realize you're having a discussion with three different people. It's not up to you whether the community continues this discussion without you.
I hope you realize you're having a discussion with three different people. It's not up to you whether the community continues this discussion without you.
Of course I realise, the usernames are literally right there. I was just saying I'm out of the conversation as I've laboured the point too long. As you say, a post here is a post to the community, so I was addressing the community - saying someone else can take the last word if they wish, I've gone on too long.
>made some equivalents that allowed me to demonstrate my skill in a similar way (analogous to writing some code in a personal project).
Except that doesn't work in programming. I can't take the core bits and re-release them in my own projects. In fact that's literally what I'm prohibited from doing.
While in photography you can make the same photo with different people, in programming you absolutely cannot simply rewrite the same code.
Except that doesn't work in programming. I can't take the core bits and re-release them in my own projects. In fact that's literally what I'm prohibited from doing.
While in photography you can make the same photo with different people, in programming you absolutely cannot simply rewrite the same code.
Did you miss the word equivalent in the statement you quoted? That's kind of the key word.
OK. Imagine this...
You photograph an event at an exclusive venue that you won't get access to again, with a setup you can't replicate (ever), with famous guests you'll never see again and a world famous VIP as the main subject.
Oh and to boot, the client wants total confidentiality. No photo use for portfolios whatsoever.
Seems just like the restrictions a programmer might face right? An infrastructure you can't replicate, code you can't publish, resources you won't have access too etc etc...
This was some years ago now and I've left photography behind but how did I ever get to do that job in the first place? Created stuff myself, off my own back, unpaid and at great time expense that showed I had the level of skill and ability to do it. I chased other photographers, contributed time and talent to their projects and made stuff myself.
And when the clients came looking I could show from my prior work and portfolio that I could do what they needed.
And what did I do afterwards? Took inspiration from what I saw at this event and made additions to my portfolio that showed I could solve the kind of challenges I faced there, proving to subsequent customers that new skill. I didn't just say 'oh dear, I can't use this so that was a total loss, let's not do anything about it.' I went out and made new stuff that showed equivalent skill, not recreating the photo, proving the skill.
Maybe I'm not being clear enough or maybe there's a misunderstanding of what type/level of photography I'm referring to so I'll state it plainly:
Photography was just an analogy. The key is you're not taking the original work that you did if it's restricted, the key is creating something that shows equivalent skill. Remember, I already said that as a creative you're selling yourself, not the end product, so you're not trying to recreate the particulars of the exact photo/code but demonstrate you have the skill/ability to create something of equivalent difficulty.
Need to prove you can run a big project? Well, run one. Do one yourself or join another. Find a way. Don't throw up a barrier every time something seems difficult or hard. It's meant to be hard. It might take a long time. Deal with it and get it done. That's what I'm saying.
People will tell you you're getting taken advantage of and doing too much for too little right up until you're working for some global mega corps running some incredible team, earning massive bucks and all that stuff. They'll keep telling you it until you believe it. Or you can ignore them and just keep going, keep making something to show what you can do and keep chasing the jobs you want with that big backing of proof of your ability that you've got.
OK. Imagine this...
You photograph an event at an exclusive venue that you won't get access to again, with a setup you can't replicate (ever), with famous guests you'll never see again and a world famous VIP as the main subject.
Oh and to boot, the client wants total confidentiality. No photo use for portfolios whatsoever.
Seems just like the restrictions a programmer might face right? An infrastructure you can't replicate, code you can't publish, resources you won't have access too etc etc...
This was some years ago now and I've left photography behind but how did I ever get to do that job in the first place? Created stuff myself, off my own back, unpaid and at great time expense that showed I had the level of skill and ability to do it. I chased other photographers, contributed time and talent to their projects and made stuff myself.
And when the clients came looking I could show from my prior work and portfolio that I could do what they needed.
And what did I do afterwards? Took inspiration from what I saw at this event and made additions to my portfolio that showed I could solve the kind of challenges I faced there, proving to subsequent customers that new skill. I didn't just say 'oh dear, I can't use this so that was a total loss, let's not do anything about it.' I went out and made new stuff that showed equivalent skill, not recreating the photo, proving the skill.
Maybe I'm not being clear enough or maybe there's a misunderstanding of what type/level of photography I'm referring to so I'll state it plainly:
Photography was just an analogy. The key is you're not taking the original work that you did if it's restricted, the key is creating something that shows equivalent skill. Remember, I already said that as a creative you're selling yourself, not the end product, so you're not trying to recreate the particulars of the exact photo/code but demonstrate you have the skill/ability to create something of equivalent difficulty.
Need to prove you can run a big project? Well, run one. Do one yourself or join another. Find a way. Don't throw up a barrier every time something seems difficult or hard. It's meant to be hard. It might take a long time. Deal with it and get it done. That's what I'm saying.
People will tell you you're getting taken advantage of and doing too much for too little right up until you're working for some global mega corps running some incredible team, earning massive bucks and all that stuff. They'll keep telling you it until you believe it. Or you can ignore them and just keep going, keep making something to show what you can do and keep chasing the jobs you want with that big backing of proof of your ability that you've got.
I think http://rossumblog.com/ is a fairly impressive portfolio of embedded development.
I've only done very small embedded projects, like http://canonical.org/kragen/light_sensing/ and https://github.com/kragen/ar_bytebeat.
I've only done very small embedded projects, like http://canonical.org/kragen/light_sensing/ and https://github.com/kragen/ar_bytebeat.
[deleted]
That is actually a really great point.
Its like hiring a writer based on their grammar. A writer could have perfect grammar but their books are boring as hell.
Or even hiring a writer for adhering to the techniques of connoisseurs. The book "Ready Player One" was heavily criticized as amateur work (it was, after all, the author's very first book), but it nonetheless was hugely successful (and even has a movie in the making).
Its like hiring a writer based on their grammar. A writer could have perfect grammar but their books are boring as hell.
Or even hiring a writer for adhering to the techniques of connoisseurs. The book "Ready Player One" was heavily criticized as amateur work (it was, after all, the author's very first book), but it nonetheless was hugely successful (and even has a movie in the making).
Would you hire a writer with bad grammar?
The point though, surely, is that having good grammar shows you can write not that you're a writer. The corollary being that passing a technical test means you can code not that you're a good developer.
I think it would be a step forward if it became standard practice to expect an online portfolio of a developer's work.
I think it would be a step forward if it became standard practice to expect an online portfolio of a developer's work.
It is only a certain sphere of devs that have such a portfolio. All my work is done for money and I don't have the rights to show it to anyone else.
The unwritten hand-waved expectation is that you should develop side projects in your spare time.
I find that this is incredibly discriminating against people who have other hobbies and don't like to spend 80 hours a week coding with only 40-50 of those being paid.
Where the programmer/photographer analogy fails is that usually, the photographer retains the right to the vast majority of their creative body of work, whereas a developer might not have anything client-facing to show at all, even if they have side projects.
I find that this is incredibly discriminating against people who have other hobbies and don't like to spend 80 hours a week coding with only 40-50 of those being paid.
Where the programmer/photographer analogy fails is that usually, the photographer retains the right to the vast majority of their creative body of work, whereas a developer might not have anything client-facing to show at all, even if they have side projects.
If they had a killer hook, yes. An editor can always review and fix the grammar. :)
A coding analogy: A compiler or debugger can catch bugs.
If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.
A coding analogy: A compiler or debugger can catch bugs.
If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.
Is the "technical" part really analogous to grammar? I don't think many interviewers care about that. They don't care about missed semi-colons. They want to see that you know how to solve a problem. And a github portfolio is not going to give them that.
As an aside, I think debugging is hard even with a debugger.
As an aside, I think debugging is hard even with a debugger.
Thats true, probably a poor analogy, but the overall point is that:
Determining a programmer's worth probably takes at least a month in my experience. Maybe even two months. I almost got fired within the first month of my first job, but quickly ramped up and turned around to be the highest value-adding employee by virtue of completing the highest paying contracts at a fast pace (the company was later acquired).
Most companies can't spend a month, but a day long take-home test is a great alternative.
There are so many facets to a programmer's worth, and so many ways to miss them or ask the wrong questions, that I just don't believe in short, high-pressure interviews. Take home tests have been highly successful in my experience (and a few others, from what I have heard).
Determining a programmer's worth probably takes at least a month in my experience. Maybe even two months. I almost got fired within the first month of my first job, but quickly ramped up and turned around to be the highest value-adding employee by virtue of completing the highest paying contracts at a fast pace (the company was later acquired).
Most companies can't spend a month, but a day long take-home test is a great alternative.
There are so many facets to a programmer's worth, and so many ways to miss them or ask the wrong questions, that I just don't believe in short, high-pressure interviews. Take home tests have been highly successful in my experience (and a few others, from what I have heard).
I disagree. A github portfolio combined with time spent via screenshare reviewing and discussing some of that work is far superior to a technical quiz IMHO.
how would a GitHub portfolio of problem solving projects and contributions not show that? I can't think of any better way.
While true for writing books, I wouldn't consider code that doesn't pass a linter or compiler a useful part of one's portfolio. There is no editor equivalent who will fix your syntactic and semantic errors for you, and getting that right is an important part of your experience with a language/tool.
There is no editor equivalent
It depends on what you are working on. A non-trivial part of my job involves working with domain expert scientists and taking their very clever, but badly written, code that solves some hard problem and turning it into fast, efficient and usable code.
It depends on what you are working on. A non-trivial part of my job involves working with domain expert scientists and taking their very clever, but badly written, code that solves some hard problem and turning it into fast, efficient and usable code.
[deleted]
I would hire a writer who can communicate effectively. Knowing the differences between a gerund phrase and participle phrase is irrelevent imo most of the time.
As an example of a brilliant book with awful grammar, there's Heinlein's The Moon is a Harsh Mistress.
Depends what you're hiring for, grammar never troubled James Joyce.
I have a portfolio (it's a bit dated now, though, and only includes the games I've worked on). It's always clear in interviews that my interviewers never bothered to look at it, though.
Still get the pop quiz interviews almost every time (with or without coding) and it's pretty clear my chances of getting an offer is at least 90% based on how well I do on their pop quizzes.
Still get the pop quiz interviews almost every time (with or without coding) and it's pretty clear my chances of getting an offer is at least 90% based on how well I do on their pop quizzes.
Portfolios are a good heuristic, but you can't be sure the person actually wrote the code/took the pics, which is why you need some other way to verify they're actually capable of producing that work, not just copying it. Hence technical interviews.
Even for a programmer with a portfolio, it's vital that you be able to probe them with questions about design decisions and expose someone who didn't actually write it.
Does photography have some sort of solution to this problem? Can you ask a photographer about how they took a picture to easily reveal whether they actually took it?
I'm guessing there's less of a need to verify skill with photographers since most of the work is on a gig or piece-work basis where it's easy to terminate the relationship or refuse payment in case of obvious frauds. OTOH, what stops an unskilled from stealing a portfolio (or using with their consent) to get work? What happens if they produce usable work, but which doesn't look anything like the quality suggested like their portfolio?
Even for a programmer with a portfolio, it's vital that you be able to probe them with questions about design decisions and expose someone who didn't actually write it.
Does photography have some sort of solution to this problem? Can you ask a photographer about how they took a picture to easily reveal whether they actually took it?
I'm guessing there's less of a need to verify skill with photographers since most of the work is on a gig or piece-work basis where it's easy to terminate the relationship or refuse payment in case of obvious frauds. OTOH, what stops an unskilled from stealing a portfolio (or using with their consent) to get work? What happens if they produce usable work, but which doesn't look anything like the quality suggested like their portfolio?
Even for a programmer with a portfolio, it's vital that you be able to probe them with questions about design decisions and expose someone who didn't actually write it.
Repeating what I said in another comment: during my last job hunt I had multiple companies which contacted me, unsolicited, asking me to apply to work with them, because they wanted an "extremely senior" Django person, preferably a committer (I got my commit bit in 2007). Every company which contacted me like that also put me into a fizzbuzz-esque phone screen. There is no sense in this; my work is publicly verifiable and vouched for (sometimes in an extremely literal sense, as it's my PGP key that provided the signature on a bunch of release packages of Django), so either they believe I am who I am, in which case no need for a fizzbuz, or they don't, in which case they shouldn't have been contacting me in the first place.
My policy now is to hang up on any company that reaches out to me for a skill they know I have, and then fizzbuzzes me in spite of that knowledge.
Repeating what I said in another comment: during my last job hunt I had multiple companies which contacted me, unsolicited, asking me to apply to work with them, because they wanted an "extremely senior" Django person, preferably a committer (I got my commit bit in 2007). Every company which contacted me like that also put me into a fizzbuzz-esque phone screen. There is no sense in this; my work is publicly verifiable and vouched for (sometimes in an extremely literal sense, as it's my PGP key that provided the signature on a bunch of release packages of Django), so either they believe I am who I am, in which case no need for a fizzbuz, or they don't, in which case they shouldn't have been contacting me in the first place.
My policy now is to hang up on any company that reaches out to me for a skill they know I have, and then fizzbuzzes me in spite of that knowledge.
A lot of photographers will now video behind the scenes stuff to show them at work and have that ready for clients if questions arise. Also, during meetings (interviews) with potential clients invariably I'd talk through and show a collection of work that was similar to the types of problem the client was trying to solve.
Might have been a wedding or a commercial shoot, I'd show them stuff that would solve what they needed and talk through with them.
Similar things have happened with editing.
I suppose an equivalent would be not just code but maybe wider community contributions. As I mentioned a portfolio goes beyond just 'code' or some 'product' that you made. It's there to sell 'you' so that includes things like bug fixing, visible issue solving, maybe mailing lists, maybe run a community platform, maybe clear contributions to open source projects or whatever. Anything you wnat I guess.
It's relatively easy to become 'public' enough to be obvious who you are, or use some kind of cryptographic proof etc.
There will be problems of due diligence, those are universal, but I think individuals and companies would both be better off if they took portfolios more seriously.
Might have been a wedding or a commercial shoot, I'd show them stuff that would solve what they needed and talk through with them.
Similar things have happened with editing.
I suppose an equivalent would be not just code but maybe wider community contributions. As I mentioned a portfolio goes beyond just 'code' or some 'product' that you made. It's there to sell 'you' so that includes things like bug fixing, visible issue solving, maybe mailing lists, maybe run a community platform, maybe clear contributions to open source projects or whatever. Anything you wnat I guess.
It's relatively easy to become 'public' enough to be obvious who you are, or use some kind of cryptographic proof etc.
There will be problems of due diligence, those are universal, but I think individuals and companies would both be better off if they took portfolios more seriously.
Thanks for the thorough answer to my concerns.
I both agree and disagree with this as many of the other comments took this in a very different way than I had.
You can still test for creative ability in the traditional coding interview construct through systems design questions. It requires you to have a deep understanding of various technologies, but at the same time focuses more on how you view various trade offs which are crucial in designing complex systems.
When discussing art with its creator, you could have the same kind of discussions about various tradeoffs they made in regards to various technical topics. For a writer, use of alteration in a certain way, or a photographer trying to draw focus to a certain aspect of the larger photograph, in particular to various editing decisions.
The issue here is that the vast majority of new-grads/young programmers are fresh out of school and haven't spent any time focusing on systems design so companies focus on what they know best, asking them to be creative in the domain of algorithms. I also think its the case that since so many people's first interviews were algorithms based the process just continues to be that way.
But, at the end of the day, to say choosing a particular data structure to solve a certain type of problem has no creative aspect to it is wrong.
You can still test for creative ability in the traditional coding interview construct through systems design questions. It requires you to have a deep understanding of various technologies, but at the same time focuses more on how you view various trade offs which are crucial in designing complex systems.
When discussing art with its creator, you could have the same kind of discussions about various tradeoffs they made in regards to various technical topics. For a writer, use of alteration in a certain way, or a photographer trying to draw focus to a certain aspect of the larger photograph, in particular to various editing decisions.
The issue here is that the vast majority of new-grads/young programmers are fresh out of school and haven't spent any time focusing on systems design so companies focus on what they know best, asking them to be creative in the domain of algorithms. I also think its the case that since so many people's first interviews were algorithms based the process just continues to be that way.
But, at the end of the day, to say choosing a particular data structure to solve a certain type of problem has no creative aspect to it is wrong.
Having been through interview processes at big tech companies recently, I invested some time in preparing a portfolio to try and improve my chances of success. What I encountered was that nobody is really interested in your portfolio (or even your resumé really). I appreciate your advice that a portfolio should improve your chances, but nobody from any of the companies looked at it. I'm not sure it's a good investment of time, considering how little importance is attributed to it.
In all honesty, I'm not sure the author did a lot of interviewing. For example,
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There's a rightfully vivid debate going on about the virtue of asking algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd wager that virtually all programmers iterate a collection at least once daily.
The followup sentence drives it home for me:
> Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.
Well, if it takes an applicant twenty minutes to Fizzbuzz, you're done! Just saved everybody lots of time.
I used to think Fizzbuzz was insulting and bullshit until I started interviewing. I haven't yet met a programmer who couldn't solve a Fizzbuzz-level question, but I've met many who took over 10 minutes and made little logical errors. It's a great predictor for "can this person actually program, well, at all?".
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There's a rightfully vivid debate going on about the virtue of asking algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd wager that virtually all programmers iterate a collection at least once daily.
The followup sentence drives it home for me:
> Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.
Well, if it takes an applicant twenty minutes to Fizzbuzz, you're done! Just saved everybody lots of time.
I used to think Fizzbuzz was insulting and bullshit until I started interviewing. I haven't yet met a programmer who couldn't solve a Fizzbuzz-level question, but I've met many who took over 10 minutes and made little logical errors. It's a great predictor for "can this person actually program, well, at all?".
I agree with the author that Fizzbuzz is about the modulo operator if you present it to the candidate like that.
What I would simply do is :
"Write fizzbuzz test for language ... use the modulo operator, which is ... for that language"
By doing this it's all about the loop.
On top of that I think the author is right, because the pressure of the candidate is sometimes huge.
I prefer giving a task that they can do at home. For example if it's a front-end position, it would be a small landing page. When I interview I usually tell the candidate :
"I really enjoyed the conversation so far. Just to let you know, the management wants from us to get from every candidate a code sample, so I will have to give you a small task that you can do at home. I'm really sorry about that, but I think it will be also helpful for you to check out what exactly you will be doing here. Do it whenever you want, just make sure you have something by the end of the week. You can also ask me anything at ..."
This sentence makes miracles. The candidate is motivated. The code is cleaner and though-trough. Then you can actually see if the person will be able to do the job.
What I would simply do is :
"Write fizzbuzz test for language ... use the modulo operator, which is ... for that language"
By doing this it's all about the loop.
On top of that I think the author is right, because the pressure of the candidate is sometimes huge.
I prefer giving a task that they can do at home. For example if it's a front-end position, it would be a small landing page. When I interview I usually tell the candidate :
"I really enjoyed the conversation so far. Just to let you know, the management wants from us to get from every candidate a code sample, so I will have to give you a small task that you can do at home. I'm really sorry about that, but I think it will be also helpful for you to check out what exactly you will be doing here. Do it whenever you want, just make sure you have something by the end of the week. You can also ask me anything at ..."
This sentence makes miracles. The candidate is motivated. The code is cleaner and though-trough. Then you can actually see if the person will be able to do the job.
I can second the value of the take-home assignment. My last company, Appstem, gave them out, and it never once failed. It additionally succeeded in weeding out people who were not motivated enough to want the job.
I had a pretty interesting experience with this.
We were doing a bunch of interviews and decided to try out FizzBuzz. I wasn't doing this round of interviews, but things ended up a bit confused with timings and I had a 30-40 minute very casual chat with each candidate prior to the actual interview.
In each of those I ended up probing a bit on technical stuff and everyone seemed to have a decent base level of competence. But they all went to pieces over fizzbuzz in the interview.
The one I actually saw, I had had a fairly in depth conversation about what it actually means to use "ref" and "val" in C#, but then watched the same guy freeze and barely scrape through fizz buzz.
My conclusion is that some people just can't write code in that kind of environment. What makes it tricky is some people (myself included) find it easy or even fun - maybe I can write fizz buzz in a single LINQ statement...Those people can assume that everyone not like them can't code.
We were doing a bunch of interviews and decided to try out FizzBuzz. I wasn't doing this round of interviews, but things ended up a bit confused with timings and I had a 30-40 minute very casual chat with each candidate prior to the actual interview.
In each of those I ended up probing a bit on technical stuff and everyone seemed to have a decent base level of competence. But they all went to pieces over fizzbuzz in the interview.
The one I actually saw, I had had a fairly in depth conversation about what it actually means to use "ref" and "val" in C#, but then watched the same guy freeze and barely scrape through fizz buzz.
My conclusion is that some people just can't write code in that kind of environment. What makes it tricky is some people (myself included) find it easy or even fun - maybe I can write fizz buzz in a single LINQ statement...Those people can assume that everyone not like them can't code.
I can confirm. I went to pieces once when asked to do FizzBuzz when I wasn't expecting to code in a phone interview. I'm not a "rock star" programmer but in the absence of pressure I can knock out a FizzBuzz in < 2 minutes. And I have written real software used by real users that made money for my employers.
Agree on technical questions + what he says on "team fit" really doesn't make sense: "You are NOT hiring for "team fit"
I have never heard a definition of "team fit" that didn't end up sounding like "let our bias run free". Phrases like "looks like they belong here" are terrifying. More insidious are complaints like "doesn't like the same social activities we do". Grow up. Your office is not your frat house, and socializing with your co-workers outside of work is not some crucial test. There is no requirement that you like someone socially as long as you want to work with them." You don't ask people to be exactly like but you expect them to be able to work in a cool mood with you and to share things. Who would hire somebody that doesn't get along with the team??!!
Team fit is actually pretty important as far as how long the Dev will stick around.
* It's a great predictor for "can this person actually program, well, at all?".*
How do you know, have you hired many who had trouble with the Fizzbuzz? Or are you just guessing? (I don't know either; there's a lot of missing data in interviews)
How do you know, have you hired many who had trouble with the Fizzbuzz? Or are you just guessing? (I don't know either; there's a lot of missing data in interviews)
Everyone I know doing recruiting says that FizzBuzz reliably disqualifies surprisingly large fraction of candidates. Even half of them, even after prefiltering by education or relevant experience.
That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so).
Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?
I once failed to answer what a right join is. I got the (freelancer) job anyway - and of course I knew all along what that is, but when I got that question I had not used any joins in years (doing infrastructure work instead), and under interview pressure I can't think except along narrow lines. I ended up doing most of the complicated SQL queries in the department, with people coming to me because to me that was easy. After failing a very simple interview question on joins.
Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?
I once failed to answer what a right join is. I got the (freelancer) job anyway - and of course I knew all along what that is, but when I got that question I had not used any joins in years (doing infrastructure work instead), and under interview pressure I can't think except along narrow lines. I ended up doing most of the complicated SQL queries in the department, with people coming to me because to me that was easy. After failing a very simple interview question on joins.
> That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so).
The same comment could apply to any rejection criteria. At my employer, we do have some data, since we do reinterview candidates after years in-between, especially if they are fresh from college. I can't speak for our organization but yes, basic programming hurdles do reliably weed out bad candidates. This is based on my experience of having done more than 150 technical interviews, all of which were balanced against the feedback of the other interviewers. Failing basic programming problems is a good predictor.
> But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?
Any kind of test that is given to candidates has the same risk.
But, let's break it down. Do you want to interview candidates for programming positions and _not_ have them program in some form or fashion during an interview? IMO that's nuts.
The same comment could apply to any rejection criteria. At my employer, we do have some data, since we do reinterview candidates after years in-between, especially if they are fresh from college. I can't speak for our organization but yes, basic programming hurdles do reliably weed out bad candidates. This is based on my experience of having done more than 150 technical interviews, all of which were balanced against the feedback of the other interviewers. Failing basic programming problems is a good predictor.
> But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?
Any kind of test that is given to candidates has the same risk.
But, let's break it down. Do you want to interview candidates for programming positions and _not_ have them program in some form or fashion during an interview? IMO that's nuts.
I'm sorry, but I just cannot accept that anyone who has any decent skill at programming would fail fizzbuzz.
It's genuinely surprising what people don't know.
"If I roll this d6, what will the average be over time?"
I've asked this to loads of supposed graduates, and apart from the odd one who made the "WTF are these monkeys hiring me for" face, a lot of people can't figure it out from first principles.
But a lot of people choke on it. Also I've had people choke on very basic general knowledge like "think of a large emerging economy in Asia".
Maybe it's nerves, maybe it's thinking too much about a simple problem.
With coding, perhaps the surprise comes from the fact that a FizzBuzz test would seem like quite a powerful test. If you can't do it, you know you can't do it. There's no doubt that you're not a programmer if you can't solve FizzBuzz and its ilk. So why do people apply, knowing they will be tested? That's the real question.
I guess the answer is you learn where you're at when someone asks you something you can't answer. Sometimes it's not where you thought.
"If I roll this d6, what will the average be over time?"
I've asked this to loads of supposed graduates, and apart from the odd one who made the "WTF are these monkeys hiring me for" face, a lot of people can't figure it out from first principles.
But a lot of people choke on it. Also I've had people choke on very basic general knowledge like "think of a large emerging economy in Asia".
Maybe it's nerves, maybe it's thinking too much about a simple problem.
With coding, perhaps the surprise comes from the fact that a FizzBuzz test would seem like quite a powerful test. If you can't do it, you know you can't do it. There's no doubt that you're not a programmer if you can't solve FizzBuzz and its ilk. So why do people apply, knowing they will be tested? That's the real question.
I guess the answer is you learn where you're at when someone asks you something you can't answer. Sometimes it's not where you thought.
I suffer, on occasion, from depression and anxiety. When I'm having an episode, my brain doesn't function.
I don't mean that I can't solve problems. I mean I can't hold a conversation.
I wonder if the reason so many people fail is because we've essentially put them in an artificial situation that shuts their brain down.
(I have also been dumbfounded by the inability of recent CS graduates to do FizzBizz... I feel like it's not certain our candidates are frequently flawed. Maybe it's our environment.)
I don't mean that I can't solve problems. I mean I can't hold a conversation.
I wonder if the reason so many people fail is because we've essentially put them in an artificial situation that shuts their brain down.
(I have also been dumbfounded by the inability of recent CS graduates to do FizzBizz... I feel like it's not certain our candidates are frequently flawed. Maybe it's our environment.)
> I don't mean that I can't solve problems. I mean I can't hold a conversation.
That sounds really hard. I'm sorry.
But I can't imagine any interview technique which would work reliably if you're brain dead during the interview.
That sounds really hard. I'm sorry.
But I can't imagine any interview technique which would work reliably if you're brain dead during the interview.
"If I roll this d6, what will the average be over time?"
I'll be honest, that's a really dumb question for testing programming skill.
I'll be honest, that's a really dumb question for testing programming skill.
We were looking for statisticians.
Still not a great question, maybe. But you grab whatever is in your bag.
Still not a great question, maybe. But you grab whatever is in your bag.
Yeah, if you're looking for statisticians, they should be able to figure that one out I'd guess lol
1/6?
The question is a weird way of asking "do you know the definition of expected value?" Expected value is calculated by taking each possible outcome, multiplying that outcome's value by its probability of occurring, and summing the results. So to calculate for a six-sided die, where each outcome has probability 1/6, you simply multiple each possible outcome by 1/6 and sum those results:
(1 * 1/6) + (2 * 1/6) + (3 * 1/6) + (4 * 1/6) + (5 * 1/6) + (6 * 1/6) = 3.5
Of course no actual roll of the die will ever come up 3.5, but as you roll the die more and more times, the average of all results seen so far will begin converging on 3.5 (and given infinite rolls, that's where it would end up).
(1 * 1/6) + (2 * 1/6) + (3 * 1/6) + (4 * 1/6) + (5 * 1/6) + (6 * 1/6) = 3.5
Of course no actual roll of the die will ever come up 3.5, but as you roll the die more and more times, the average of all results seen so far will begin converging on 3.5 (and given infinite rolls, that's where it would end up).
>> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
> Wait, what? No, it asks "can you write a for loop without breaking a sweat?".
There are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways:
1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This can totally happen when you spend a few years working on line-of-business CRUD apps that never turn out to need modulus arithmetic.
Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it.
That means you just took more than 10 minutes on fizzbuzz, which means you failed.
2) Trying to "clean up" the solution. http://c2.com/cgi/wiki?FizzBuzzTest has a good discussion on 'Why Fizz-Buzz is "hard:"', which points out that many of the most obvious solutions have code duplication, which some people then try to eliminate, tying themselves in knots trying to make it perfect.
The third possibility, that a candidate with years of experience shipping code nonetheless struggles to write a for loop, is IMO just not as common as the above two failure cases. (Much more likely is that the candidate has lied/exaggerated on their resume.)
> Wait, what? No, it asks "can you write a for loop without breaking a sweat?".
There are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways:
1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This can totally happen when you spend a few years working on line-of-business CRUD apps that never turn out to need modulus arithmetic.
Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it.
That means you just took more than 10 minutes on fizzbuzz, which means you failed.
2) Trying to "clean up" the solution. http://c2.com/cgi/wiki?FizzBuzzTest has a good discussion on 'Why Fizz-Buzz is "hard:"', which points out that many of the most obvious solutions have code duplication, which some people then try to eliminate, tying themselves in knots trying to make it perfect.
The third possibility, that a candidate with years of experience shipping code nonetheless struggles to write a for loop, is IMO just not as common as the above two failure cases. (Much more likely is that the candidate has lied/exaggerated on their resume.)
If you don't know about modulus, you don't have to re-implement it. For Fizzbuzz you're looping anyway, so you can just maintain two counters, one that counts to 3 and resets, and one that counts to 5 and resets. When one of the counters resets, you know the main loop counter is a multiple of 3 or 5. Like so:
def fizzbuzz_no_modulo():
counter_three = 1
counter_five = 1
for i in range(1, 101):
output = []
if counter_three == 3:
output.append('Fizz')
counter_three = 0
if counter_five == 5:
output.append('Buzz')
counter_five = 0
if not output:
output.append(str(i))
print(''.join(output))
counter_three += 1
counter_five += 1There's a lot of ways you can do it. I think it's fun to see how people solve it when they're not allowed to use the obvious answers (note: I don't interview people and probably would not choose no-modulo-fizzbuzz as an interview question).
Similar to your solution, instead of two counters, you can have two iterators that cycle every 3 / 5 elements, and add them. Then fill in any blank elements with their index+1.
Similar to your solution, instead of two counters, you can have two iterators that cycle every 3 / 5 elements, and add them. Then fill in any blank elements with their index+1.
from itertools import cycle, zip_longest, islice
fizz_list = ['', '', 'fizz']
buzz_list = ['', '', '', '', 'buzz']
output = [
fizz + buzz for fizz, buzz
in islice(zip_longest(cycle(fizz_list), cycle(buzz_list)), 0, 100)
]
for i in range(len(output)):
print(output[i] or i+1)On 1), I disagree -- if a genuinely senior engineer doesn't know of modulus (totally possible btw), then what they'll do is:
"Okay, let's assume I have some function that tells me whether something is divisible by p. [writes it while using that function] Now, how would I implement that function? Well, I'd search for some existing library function to do that, but if I can't, then here's how I would check divisibility ..."
That's because the senior dev knows how to break the problem into solvable pieces, even and especially where they don't already know the solution to each piece.
"Okay, let's assume I have some function that tells me whether something is divisible by p. [writes it while using that function] Now, how would I implement that function? Well, I'd search for some existing library function to do that, but if I can't, then here's how I would check divisibility ..."
That's because the senior dev knows how to break the problem into solvable pieces, even and especially where they don't already know the solution to each piece.
> Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it.
I've seen numerous people fail on FizzBuzz despite supposedly being senior engineers.
None of them failed because they didn't know the modulo operator. For one thing, it's actually pretty easy to solve even without modulo.
If someone doesn't know modulo, I'll happily explain it.
More commonly, people struggle with even basic things like setting up a loop at all.
I've seen numerous people fail on FizzBuzz despite supposedly being senior engineers.
None of them failed because they didn't know the modulo operator. For one thing, it's actually pretty easy to solve even without modulo.
If someone doesn't know modulo, I'll happily explain it.
More commonly, people struggle with even basic things like setting up a loop at all.
> Much more likely is that the candidate has lied/exaggerated on their resume.
If you don't do fizzbuzz or equivalent, how else do you catch that?
If you don't do fizzbuzz or equivalent, how else do you catch that?
#2 happened to me: I wrote the straightforward implementation in a few seconds, and then struggled and tied myself up trying to eliminate the duplication, making it worse and worse, until I started panicking. Luckily the interviewer understood what was happening and changed subject.
>Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it.
It's surprisingly easy actually.
var remainder = x - Math.floor(x/y)*y
(Math.floor because javascript)
It's surprisingly easy actually.
var remainder = x - Math.floor(x/y)*y
(Math.floor because javascript)
I think what he is pointing out is that if you don't know the modulus operator, you will fail FizzBuzz. The modulus operator is rarely used and somewhat obscure.
The only time I use the modulus operator is when I'm writing something to track what record / rule I'm processing and I only want to show every 10,000th record or so. I can't think of a time I've used it otherwise.
The only time I use the modulus operator is when I'm writing something to track what record / rule I'm processing and I only want to show every 10,000th record or so. I can't think of a time I've used it otherwise.
You can implement it yourself if you forget it. Or use a counter (urgh). Or ask whether there's a library function that does that.
If you're so crafty at sifting through candidates to resort to FizzBuzz to help you do it, why do you have to copy and paste FizzBuzz, why not come up with something original?
Actually I usually ask a comparably difficult question for fear that people might have actually remembered the solution to fizzbuzz by heart. But I didn't think it added to the discussion to mention that.
The trick part of FizzBuzz is that the easiest solution relies on the magic "15".
Even that's an unnecessary complication. The code solution should read like the spec, so that if someone comes along later to make FizzBuzz depend on some other set of constraints, they know what to do.
The compiler can optimize away the duplicate tests. That's its job.
The compiler can optimize away the duplicate tests. That's its job.
Hiring Manager Perspective: Everyone lies, sorry.
As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.
My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax.
I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume.
The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff.
That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate.
I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars.
And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.
My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax.
I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume.
The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff.
That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate.
I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars.
And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
Potential Employee Perspective: they can't be serious!!!
A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one.
Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying.
The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, done that).
"never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.
Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.
The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow.
That's the sad truth about software development. Well one of them at least.
A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one.
Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying.
The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, done that).
"never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.
Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.
The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow.
That's the sad truth about software development. Well one of them at least.
I think the laundry list interview happens most when you're hiring to replace someone. My last job is having that issue, we were an R&D team so we learned on the job. They're having an impossible time replacing any of us because to combine that specific skill set you basically have to have been on that team (or its twin) for a couple of years.
What they should be looking for is just someone with good basic skills who learns fast. Of course, they won't do that.
What they should be looking for is just someone with good basic skills who learns fast. Of course, they won't do that.
100% agreed.
Most of the time the hiring is about replacement, or expansion. And in expansion I mean "the current team is not enough to handle all the cr*p so we have to bring in people, preferably with the same skill set as the others, so we don't have to bother with getting them up to speed" not the "we need more people because we just started something new and we need fresh blood in the system".
Most of the time the hiring is about replacement, or expansion. And in expansion I mean "the current team is not enough to handle all the cr*p so we have to bring in people, preferably with the same skill set as the others, so we don't have to bother with getting them up to speed" not the "we need more people because we just started something new and we need fresh blood in the system".
So respond to that job spec with a resume which clearly highlights the 3-4 things you actually did master, with multiple specific project examples and real roles/jobs.
You may be pleasantly surprised.
Speaking for myself, I will gleefully hop over piles of candidates with a 1/4 page of alphabet soup on their CV trying to talk with the candidate who hammers Python, PHP, Javascript (etc) across a 5+ years of different projects. Even if I'm hiring for a slightly different technology, because I can be confident they actually know the trade.
Multiple skill-sets do add value if they are related and easily combined to deliver a larger solution. Eg. HTML + CSS + Javascript = Front End Web Dev + Python + SQL = Full Stack Web Developer. So I can staff that person in a larger role.
The spew of semi-related and adjacent buzzwords doesn't really help me feel comfortable with a candidate. And if I start asking you about them and learn all you did was read about them online (or used it once for a class), the rest of your resume goes into the danger zone real quick.
"I mastered X, Y, and Z and used them together to build <pure awesomeness>" will get you further than you think. Even if the job doesn't require X, Y, and Z....
You may be pleasantly surprised.
Speaking for myself, I will gleefully hop over piles of candidates with a 1/4 page of alphabet soup on their CV trying to talk with the candidate who hammers Python, PHP, Javascript (etc) across a 5+ years of different projects. Even if I'm hiring for a slightly different technology, because I can be confident they actually know the trade.
Multiple skill-sets do add value if they are related and easily combined to deliver a larger solution. Eg. HTML + CSS + Javascript = Front End Web Dev + Python + SQL = Full Stack Web Developer. So I can staff that person in a larger role.
The spew of semi-related and adjacent buzzwords doesn't really help me feel comfortable with a candidate. And if I start asking you about them and learn all you did was read about them online (or used it once for a class), the rest of your resume goes into the danger zone real quick.
"I mastered X, Y, and Z and used them together to build <pure awesomeness>" will get you further than you think. Even if the job doesn't require X, Y, and Z....
That is my plan. Working on an anonymous web based end to end encrypted chat system with that exact stack. Then I'm going to write an android app to accompany it. I'll see if I can get my foot in the door.
5 years of SQL experience and no idea of what a join is?
Isn't that like saying 5 years of C/Java/C#/... experience and not knowing what assignment is?
Isn't that like saying 5 years of C/Java/C#/... experience and not knowing what assignment is?
After interviewing thousands of candidates over the years, I say anything is possible. One candidate I recall was 24+ years of development experience mostly consulting in firmware. He graduated from a top school and was referred by our VP of ASIC engineering. Yet he struggled at the most basic C pointer question. He tried everything in the interview to prevent us from asking any coding questions.
Oh my! How can you work in firmware and not know the basics of C pointers? Firmware is mostly C!
I met a professional, working Rails dev who didn't know how to expose a class's instance variables for read access in Ruby. (i.e. write getters)
(Not an interview context though; it was a hack night where I was learning ruby and didn't know the right terms to use to look up that question from the docs.)
(Not an interview context though; it was a hack night where I was learning ruby and didn't know the right terms to use to look up that question from the docs.)
Just out of curiosity, did you phrase the question "expose a class's instance variables for read access," or "write a getter?" I see it as the difference between academic phrasing and colloquial.
I phrased the question in many different ways and verified that he understood that I meant, "how do I get the value of @foo from an object of a class that has @foo?" The answer he gave did not hinge on the distinction, and ended up being the ol'
def foo
@foo
endI don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of data.
But if you have loads of queries and do the "join" in your application code, you will suffer serious performance problems with any reasonable data set. If a programmer is going to be writing SQL for anything larger than a toy problem, they have to know how to use JOIN.
Arguably that's one year of SQL experience repeated five times.
Yep. Believe it or not depending on the team/manager/programmer that happens very often.
If the data you are querying is spread across multiple tables (and in "enterprise" environments databases with hundreds, thousands, tens of thousands of tables or more are fairly common) then you have to do a join somewhere - in SQL, in your application or even manually. Given that doing the join in SQL is by far the most common scenario not being aware of it is a bit odd!
Or you can use where a.id = b.id and you cover 90% of joins (inner join). I only once needed an outer join in the last 10 years all other cases and here inner joins. And I prefer the where syntax, it's cleaner for me than the join one.
THIS.
Yes, there are SQL statements without Joins. No, we don't usually run them in the reporting organization....
Yes, there are SQL statements without Joins. No, we don't usually run them in the reporting organization....
I have 3 years of SQL and while I do know what a join is, I doubt I could write a syntactically correct one that does what it's supposed to do, on a whiteboard. I'd need some test data and access to google, and at least three or four attempts.
Reason is, I work with a CMS that handles 99% of my queries for me. It would be monstrously inefficient for me to go around handwriting sql all the time. Any time it happens is by definition an extreme circumstance, so that's how I do it when it happens - with test data, google, and several attempts.
I'm pretty sure that would be reasonable for most jobs, but I wouldn't pass the tech screen if they wanted me to just freestyle it.
Reason is, I work with a CMS that handles 99% of my queries for me. It would be monstrously inefficient for me to go around handwriting sql all the time. Any time it happens is by definition an extreme circumstance, so that's how I do it when it happens - with test data, google, and several attempts.
I'm pretty sure that would be reasonable for most jobs, but I wouldn't pass the tech screen if they wanted me to just freestyle it.
That's fine, but you have 3 years of experience with a CMS. SQL is the Structured Query Language used to make queries, so if you're not writing that, then you aren't working with SQL.
I've been driving cars for twenty years, but it doesn't mean I have two decades of experience with fuel injectors.
I've been driving cars for twenty years, but it doesn't mean I have two decades of experience with fuel injectors.
Your example makes your point very well. You are totally right.
So you have three years of experience using tool which does the work of generating SQL for you. If you can't write a proper JOIN from memory then you shouldn't be putting "three years of SQL experience" on your CV.
Look, I think most companies put too many skills on their wishlist. And if, in fact, you weren't actually going to be using SQL too much, but using ActiveRecord all the time, maybe it is acceptable to say "Well, I actually don't know how to do that in SQL, but here's how I'd do it in ActiveRecord (do it correctly) and here's how you examine the SQL that ActiveRecord is generating, and I'm happy to study SQL and the guts of ActiveRecord if we need to do a lot of complex queries..." and okay, you made your case. But if the job requires SQL experience and you don't know how to do a basic join? Sorry, not gonna be a good fit. I mean, employers need to ask for some specific skills!
Agree with you MrLefHand, But would it not be responsibility of sql programmer to keep himself update? even if it is not possible in company. Like we never get to touch AD in any company because most of them already have it setup but we still go and test in VM with eval editions and such?
Yes you can and you should. Sometimes it's hard to get ahead to learn stuff by yourself when you have a mind numbing job to go to.
But then maybe the person doesn't belong in to the world of software development.
Another problem is, when you learn something outside of work it wont be enough, because they want "commercial" experience.
Like when they are hiring mobile developers and ask: "do you have any successful apps on the store?"
If I would have any successful apps on the store would I be here doing this interview with you?
But then maybe the person doesn't belong in to the world of software development.
Another problem is, when you learn something outside of work it wont be enough, because they want "commercial" experience.
Like when they are hiring mobile developers and ask: "do you have any successful apps on the store?"
If I would have any successful apps on the store would I be here doing this interview with you?
Sometimes you don't know what you don't know. I was completely torn apart the first time I was interviewed for a Scala position, because the guy didn't believe I could possibly have spent three months doing Scala professionally and didn't know basic List methods like fold (we'd been avoiding using Scala collections because we knew the migration was coming, and had just been writing Scala with the Java collections).
My first scala job was with a group that didn't like to use a lot of the more FP-like constructs such as folding. So I also didn't have experience with that after three months. You could argue that meant I wasn't really using scala but I wasn't totally clueless.
> A lot of times a job spec contains a minimum of 10-15 skill you need to know.
This can also happen if they are just bad at writing job requirements. Remember, it is typically programmers (or their managers) writing these things, and sometimes HR or a recruiter (who doesn't understand any technical details) "cleaning" it up.
They may just mean "Here are the skills we need, we want to hire someone that knows some of these, and is able to learn the rest fairly quickly".
Of course, they could also have someone specific in mind (but are required to post the job anyway), and in some cases may be delusional and really think they can find someone with all those skills.
This can also happen if they are just bad at writing job requirements. Remember, it is typically programmers (or their managers) writing these things, and sometimes HR or a recruiter (who doesn't understand any technical details) "cleaning" it up.
They may just mean "Here are the skills we need, we want to hire someone that knows some of these, and is able to learn the rest fairly quickly".
Of course, they could also have someone specific in mind (but are required to post the job anyway), and in some cases may be delusional and really think they can find someone with all those skills.
> Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.
You are not allowed to change anything and commit it :) But it's amazing how much cruft you can dig out by say, re-writting the build system so that everything links dynamically and then running an address sanitizer build in dev env.
You are not allowed to change anything and commit it :) But it's amazing how much cruft you can dig out by say, re-writting the build system so that everything links dynamically and then running an address sanitizer build in dev env.
> "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.
Most of my experience with SQL comes from being a game designer with access to analytics database - so, not exactly a lot.
But how the hell would you not touch join even a single time while working with SQL for 5 years?!
Most of my experience with SQL comes from being a game designer with access to analytics database - so, not exactly a lot.
But how the hell would you not touch join even a single time while working with SQL for 5 years?!
Two ways I can think of off the top of my head:
1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs)
2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships.
I'd wager #1 is the more common case.
1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs)
2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships.
I'd wager #1 is the more common case.
Or they're just using a bunch of SELECT * WHERE X queries and then filtering the results in their favorite programming language
This. With smaller amounts of data it's not even a big deal. Just pull everything into python or R and subset in there.
That, too.
But in #1 you're not working with SQL, you're working with a layer above it.
And wouldn't even the most basic data, properly normalized, require joins? I mean - learning about database normalization is one of the first things you're supposed to do when you work with relational databases, right?
And wouldn't even the most basic data, properly normalized, require joins? I mean - learning about database normalization is one of the first things you're supposed to do when you work with relational databases, right?
Both responses sound oddly like dating.
Because that is what the process of hiring is.
Dating and interviews go both ways. "I don't want to hire you" is a valid as "I don't want to work for you".
Dating and interviews go both ways. "I don't want to hire you" is a valid as "I don't want to work for you".
My first tech job assignment required SQL. I didn't know it, didn't claim I knew it, got the job, read the O'Reilly book on SQL on the plane on my way to California. I learned about joins (although maybe not the JOIN keyword).
This was about the time MySQL came out, and years before Postgres added SQL support, so at the time your rather pathetic argument might have had merit, because there wasn't actually a way to get hands-on experience with SQL without a pricey license for proprietary software.
I still don't think it's reasonable to claim that you have "SQL experience" if you haven't touched joins. That's like saying you have JavaScript experience but don't know how to define a function.
Now, though, Skype and every browser embed SQLite. If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. Don't blame your employer.
When I was hiring people, I wanted people who could do the job, not people who would lie that they could, then blame my company.
This was about the time MySQL came out, and years before Postgres added SQL support, so at the time your rather pathetic argument might have had merit, because there wasn't actually a way to get hands-on experience with SQL without a pricey license for proprietary software.
I still don't think it's reasonable to claim that you have "SQL experience" if you haven't touched joins. That's like saying you have JavaScript experience but don't know how to define a function.
Now, though, Skype and every browser embed SQLite. If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. Don't blame your employer.
When I was hiring people, I wanted people who could do the job, not people who would lie that they could, then blame my company.
> This was about the time MySQL came out, and years before Postgres added SQL support
Didn't those happen nearly at the same time? Postgres95 (which PostgreSQL started from) had support for some subset of SQL (including inner joins): https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f... outer joins were added a bit later: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
Didn't those happen nearly at the same time? Postgres95 (which PostgreSQL started from) had support for some subset of SQL (including inner joins): https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f... outer joins were added a bit later: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
I didn't realize Postgres already had SQL support in 1994! I didn't try to use it around that time; msql was a thing for a while, and then people moved to the protocol-compatible MySQL. I was using INFORMIX in that job (1996–7) and it wasn't for several more years that e.g. Slashdot switched to SQL backends.
So why didn't people use SQL in Postgres95? The licensing was fine. My best guess is that the SQL support wasn't yet good enough to be useful. The database as such (transactions, data types, persistence) was already pretty solid, as I understand it.
So why didn't people use SQL in Postgres95? The licensing was fine. My best guess is that the SQL support wasn't yet good enough to be useful. The database as such (transactions, data types, persistence) was already pretty solid, as I understand it.
"If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. "
Or other things have grabbed your interest. Are you saying that one lacks "intellectual curiosity" because they have had other priorities than learning this one specific technology?
Or other things have grabbed your interest. Are you saying that one lacks "intellectual curiosity" because they have had other priorities than learning this one specific technology?
If you're a programmer of any kind, sooner or later, you need to understand the relational data model and normalization. They're useful to you in every field of programming; they're one of those magic technologies that can frequently turn 200 lines of code into 10 lines, converting a day-long task into something so simple you can do it off-the-cuff. SQL is by far the most accessible way to use the relational data model, whatever the merits of Tutorial D and Prolog, and once you start normalizing your data, you need joins.
If we were talking about cuckoo hashing, 386 assembly, or FIR filter design, I would agree that it's "one specific technology" that someone could easily pass over with little loss in many programming fields. But not knowing how to do a join is more like not knowing how to open a file or use floating-point math: it's a crippling deficiency in your skills as a programmer, one that will slow you down in a wide variety of tasks.
If we were talking about cuckoo hashing, 386 assembly, or FIR filter design, I would agree that it's "one specific technology" that someone could easily pass over with little loss in many programming fields. But not knowing how to do a join is more like not knowing how to open a file or use floating-point math: it's a crippling deficiency in your skills as a programmer, one that will slow you down in a wide variety of tasks.
> A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one.
Most job listings I've seen don't really have that many hard requirements. They may mention technologies you'll be working with or things they'd like to see, but that shouldn't stop you from applying if you don't know them all.
Take this with a grain of salt because I've never done resume filtering, but when I interview someone, I look at their resume and ask them about the things on it that I also know. (And I'll decline the interview if there's no overlap.) So for my stage in the process, the optimal strategy is to put the things you're best at on your resume, even if they're not listed on the job description. You get to pick what we talk about. For the most part I'll assume that if you've mastered those things, you can master the things we're looking for too.
(Subject to some constraints: if there are four interviews, they shouldn't all be about the same things. So each interviewer might be assigned a broad area to discuss or have to write down their questions/area before the next interview starts so the next interviewer can pick something else.)
> "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.
I look for a core concept or two for each area/technology and ask about that:
* For SQL, that definitely means join. If you don't know how to join two relations, you should learn or take SQL off your resume.
* Likewise, for C/C++ I want to know that you understand memory safety. Who owns memory across an API boundary.
* For algorithms / data structures (a likely main topic if you're a recent CS grad), that for a simple problem you can use the best basic data structure (array / list / heap / balanced tree / hash table) and tell me the time and memory complexity in Big-Oh notation.
> Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.
That's not the sort of job I do or interview people for. I have no idea what interviews for that kind of job are like. But if you're not doing sophisticated SQL or algorithms, surely you're doing something with your time? What is it? Can you emphasize it and sell it?
> The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow.
That's not a problem with interviews; it's a feature. Why should someone want to hire you if you haven't been growing? Or if they do, why should they want to pay you as if you were actually gaining experience for those years?
I'd be looking for a better job the whole time.
Most job listings I've seen don't really have that many hard requirements. They may mention technologies you'll be working with or things they'd like to see, but that shouldn't stop you from applying if you don't know them all.
Take this with a grain of salt because I've never done resume filtering, but when I interview someone, I look at their resume and ask them about the things on it that I also know. (And I'll decline the interview if there's no overlap.) So for my stage in the process, the optimal strategy is to put the things you're best at on your resume, even if they're not listed on the job description. You get to pick what we talk about. For the most part I'll assume that if you've mastered those things, you can master the things we're looking for too.
(Subject to some constraints: if there are four interviews, they shouldn't all be about the same things. So each interviewer might be assigned a broad area to discuss or have to write down their questions/area before the next interview starts so the next interviewer can pick something else.)
> "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.
I look for a core concept or two for each area/technology and ask about that:
* For SQL, that definitely means join. If you don't know how to join two relations, you should learn or take SQL off your resume.
* Likewise, for C/C++ I want to know that you understand memory safety. Who owns memory across an API boundary.
* For algorithms / data structures (a likely main topic if you're a recent CS grad), that for a simple problem you can use the best basic data structure (array / list / heap / balanced tree / hash table) and tell me the time and memory complexity in Big-Oh notation.
> Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.
That's not the sort of job I do or interview people for. I have no idea what interviews for that kind of job are like. But if you're not doing sophisticated SQL or algorithms, surely you're doing something with your time? What is it? Can you emphasize it and sell it?
> The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow.
That's not a problem with interviews; it's a feature. Why should someone want to hire you if you haven't been growing? Or if they do, why should they want to pay you as if you were actually gaining experience for those years?
I'd be looking for a better job the whole time.
There's actually significant learning value in time spent figuring out legacy systems and linking them together. Doing ad-hoc reporting is the IT equivalent of being a short order cook.
Do it long enough, and you learn how to make almost anything from nothing.
And that should be considered an employable skill....
Do it long enough, and you learn how to make almost anything from nothing.
And that should be considered an employable skill....
I agree. Deciphering legacy systems, integrating them, debugging them, and finding minimal safe fixes involves a whole set of legitimate, resume-worthy skills.
> Doing ad-hoc reporting is the IT equivalent of being a short order cook.
Nice analogy.
I used to do a fair amount of ad-hoc reporting on an Oracle database. I used joins (inner and outer), subselects (or self-joins), aggregates, window functions (or whatever Oracle equivalent existed at the time), etc. I'd never hire someone who said they did ad-hoc reporting with SQL but didn't know joins, and I'd be skeptical of someone who didn't know some of these other concepts.
> Doing ad-hoc reporting is the IT equivalent of being a short order cook.
Nice analogy.
I used to do a fair amount of ad-hoc reporting on an Oracle database. I used joins (inner and outer), subselects (or self-joins), aggregates, window functions (or whatever Oracle equivalent existed at the time), etc. I'd never hire someone who said they did ad-hoc reporting with SQL but didn't know joins, and I'd be skeptical of someone who didn't know some of these other concepts.
I've been on the interviewer side in the past when this was the setup:
People are given a basic coding challenge. On the level of "parse roman numerals" or similar with some tests, standard kind of basic things that rosetta code will list implementations of in every possible language. The code was to be written in any language the person wanted. This was not timed, and was to be done at home.
50%, easily, didn't work. Many did not compile, or were totally incomplete. One was a broken implementation in C# submitted as a single function pasted inside a word document.
Only one person out of I think 20 sent a zipped copy of all the code, a short instruction of how to actually run it, and included some tests.
After that, I started to understand just why these kind of little programming tasks were given.
> And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
Hah. I've had someone who didn't know the difference between local and global variables trying to come in as a fairly high rate contractor.
People are given a basic coding challenge. On the level of "parse roman numerals" or similar with some tests, standard kind of basic things that rosetta code will list implementations of in every possible language. The code was to be written in any language the person wanted. This was not timed, and was to be done at home.
50%, easily, didn't work. Many did not compile, or were totally incomplete. One was a broken implementation in C# submitted as a single function pasted inside a word document.
Only one person out of I think 20 sent a zipped copy of all the code, a short instruction of how to actually run it, and included some tests.
After that, I started to understand just why these kind of little programming tasks were given.
> And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
Hah. I've had someone who didn't know the difference between local and global variables trying to come in as a fairly high rate contractor.
At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to:
- read that file in
- store it in some sort of data structure
- allow users to run commands to retrieve movie titles based on name, release year, etc.
Command-line was totally fine, you had access to the Internet, and as much time as you wanted.
At least 50% of people couldn't do it. One candidate spent hours staring at the screen before slipping out with a note left behind, "I apologize for wasting your time"
- read that file in
- store it in some sort of data structure
- allow users to run commands to retrieve movie titles based on name, release year, etc.
Command-line was totally fine, you had access to the Internet, and as much time as you wanted.
At least 50% of people couldn't do it. One candidate spent hours staring at the screen before slipping out with a note left behind, "I apologize for wasting your time"
Brilliant!
I may wind up stealing this as an alternative test for more advanced programmers; everything here can be done using the Python Standard library.
And kudos to those of you who suggested in-memory storage vs. writing it out to a table.
I may wind up stealing this as an alternative test for more advanced programmers; everything here can be done using the Python Standard library.
And kudos to those of you who suggested in-memory storage vs. writing it out to a table.
Weird thing is I was writing the code in my head a I read the instructions. Hard to believe people would fail that but years of hiring have shown its true.
If I had access to Python and the REPL, preferably ipython, I don't think I'd even need the Internet.
Yup - our really good developers would do this end to end in < 40 minutes and without needing anything.
But the range of times was stunning. There was a lot of people that managed to pass, but it was a three or four hour exercise (I'm willing to chalk some of that up to nerves or overthinking the problem).
But the range of times was stunning. There was a lot of people that managed to pass, but it was a three or four hour exercise (I'm willing to chalk some of that up to nerves or overthinking the problem).
How would you do this without basically writing your own database from scratch?
> How would you do this without basically writing your own database from scratch?
It obviously is, for a suitable loose use of the term, "writing your own database from scratch" (unless you are using an existing library, for which many languages have ones that can be leveraged in the stdlib, including often ones that bring in SQLite). But doing a database of this extremely minimal complexity, or leveraging existing libraries to provide the functionality, is a pretty basic task that anyone expecting to get employed to do software development should be able to do with the conditions described.
It obviously is, for a suitable loose use of the term, "writing your own database from scratch" (unless you are using an existing library, for which many languages have ones that can be leveraged in the stdlib, including often ones that bring in SQLite). But doing a database of this extremely minimal complexity, or leveraging existing libraries to provide the functionality, is a pretty basic task that anyone expecting to get employed to do software development should be able to do with the conditions described.
I absolutely agree with this. Moreover, this basic approach of giving the candidate a reasonable set of requirements, a quiet space, and as much time as necessary is hands-down the best way I can think of to asses competency. It's how I was assessed by a company at which I just accepted a SRE position. There was a homework project, a few "personality" interviews, and then a work day for which I was compensated. I was stressed out with performance anxiety leading up to this naturally, but it ended up being a blast.
I was looking for a couple of months before I went through the process with my current employer, and some of the experiences were just horrible: one company put me through 7 interviews with a single engineer each time, lasting 30-45 minutes, and then brushed me off with a two sentence email. Another wanted me to design an algorithm in 20 minutes while they watched via screen share, and if I couldn't do it in 20 minutes I wasn't good enough for them. Several asked me to take timed tests with prominent counters flashing in the corner. It's just stupid.
So I think personally we should support employers who understand how software is made, and are willing to create the right conditions for you to really practice your craft, and then judge what you've made and how you interacted with potential team mates.
I was looking for a couple of months before I went through the process with my current employer, and some of the experiences were just horrible: one company put me through 7 interviews with a single engineer each time, lasting 30-45 minutes, and then brushed me off with a two sentence email. Another wanted me to design an algorithm in 20 minutes while they watched via screen share, and if I couldn't do it in 20 minutes I wasn't good enough for them. Several asked me to take timed tests with prominent counters flashing in the corner. It's just stupid.
So I think personally we should support employers who understand how software is made, and are willing to create the right conditions for you to really practice your craft, and then judge what you've made and how you interacted with potential team mates.
Store it in memory? I doubt the amount of data they provided for a test problem was so tremendous that it required a database.
In itself this is a good (dis)qualifier; if I give someone a problem and tell them the data will never exceed 10k rows, I expect them to be practical and not waste time setting up a database.
In itself this is a good (dis)qualifier; if I give someone a problem and tell them the data will never exceed 10k rows, I expect them to be practical and not waste time setting up a database.
The flat line in the bathtub curve is where given "data will never exceed 10k rows" implies no database. On the inexperienced end, people don't understand that 10k rows doesn't require a database. On the experienced end, candidates probably oughtn't to believe it.
Absent an instruction to specifically "do not use a database", I feel like even 10K rows suggests the use a database as the data structure and then the DB query interfaces as the interface.
I don't see why you wouldn't use a database for a problem that it's particularly good at addressing.
I don't see why you wouldn't use a database for a problem that it's particularly good at addressing.
As I think I said elsewhere, we allowed people to use a database if they wanted to (and could install it themselves on the dev VM we gave them), but then we would include looking at how they designed the schema, how much thought did they put into connection handling, etc.
But most of the people who successfully passed this didn't use a database, it just wasn't enough data to be meaningful - thousands of rows at most.
But most of the people who successfully passed this didn't use a database, it just wasn't enough data to be meaningful - thousands of rows at most.
Yeah, or you could use the opportunity to demonstrate that you know how to roll your own data structures, provided you've clarified that the dataset isn't likely to grow. Instead of showing them you know how to install a database.
Well, as other posters have commented you sort of do, but since we let you use libraries and the like, you had lots of options:
- sqlite
- Storable (perl)
- serialize some other data structure to disk
- in-memory
I seem to recall one or two people over the years who wanted to install a relational database as part of the code to store stuff - we were fine with that as long as you then showed all the right behaviors for dealing with relational databases (using transactions, catching errors, etc.)
But most people read it in and store it in memory - there was only a few thousand rows.
- sqlite
- Storable (perl)
- serialize some other data structure to disk
- in-memory
I seem to recall one or two people over the years who wanted to install a relational database as part of the code to store stuff - we were fine with that as long as you then showed all the right behaviors for dealing with relational databases (using transactions, catching errors, etc.)
But most people read it in and store it in memory - there was only a few thousand rows.
I guess my intuition was right. I was mostly curious if there was some other clever way of handling this. Mostly related to being able to query the data arbitrarily
I don't even remember how sophisticated the querying had to be - I think it was something like:
- find and display all movies by the specified year
- substring text searches in the title
Maybe one other. But it wasn't even approaching anything really sophisticated. We just wanted to see that people could write a basic logic flow, read-and-write data application.
Then for the people who did finish it, we looked at the code. Was it well commented, well thought out, did it have error handling (what if the input file doesn't exist? What if something eats your data file while it's running?), what assumptions did they make.
So the base test was basically a sniff test - if you can't do this, you're not a good enough developer to work here. If you can do it, we'll look at the quality of the result to assess how senior you are.
- find and display all movies by the specified year
- substring text searches in the title
Maybe one other. But it wasn't even approaching anything really sophisticated. We just wanted to see that people could write a basic logic flow, read-and-write data application.
Then for the people who did finish it, we looked at the code. Was it well commented, well thought out, did it have error handling (what if the input file doesn't exist? What if something eats your data file while it's running?), what assumptions did they make.
So the base test was basically a sniff test - if you can't do this, you're not a good enough developer to work here. If you can do it, we'll look at the quality of the result to assess how senior you are.
By implementing only that 1% of a real database's functionality that this task requires. Consider: you have only one table, no updates or deletes or transactions, fixed schema, and very, very simple queries.
So it's just a matter of parsing the CSV into some native data structure in your favorite language and then computing sort indices of the columns by which rows might be queried.
So it's just a matter of parsing the CSV into some native data structure in your favorite language and then computing sort indices of the columns by which rows might be queried.
And sadly you don't even need to create sort indices. Just reading the data into a list of tuples and a few list comprehensions would provide all the querying needed (it wouldn't be efficient but most candidates can't even get that far)
Admittedly a database would make the querying more efficient (this is actually probably a good use case for Mongo), but you could just keep a dictionary for each query-able field if you want better than O(n).
Only once they ask for efficient Levenstein-distance-supporting search do you need to use any brainpower.
N.b. if you choose to parse CSV from scratch, make sure to handle commas in quoted text as well as escaped quotes. The better approach is to grab a library or code snippet and call it a day.
Only once they ask for efficient Levenstein-distance-supporting search do you need to use any brainpower.
N.b. if you choose to parse CSV from scratch, make sure to handle commas in quoted text as well as escaped quotes. The better approach is to grab a library or code snippet and call it a day.
You don't have to, you can use sqlite for that.
For example in python: 1. Load the CSV file using the csv lib in a list of dictionary 2. Fill a sqlite database with the list 3. Read wathever the user asked for (ex: movies longer than 100 minutes and release date before 1999) and build a SQL query 4. Display results
For example in python: 1. Load the CSV file using the csv lib in a list of dictionary 2. Fill a sqlite database with the list 3. Read wathever the user asked for (ex: movies longer than 100 minutes and release date before 1999) and build a SQL query 4. Display results
Well - I'd probably write my own database from scratch. If the list was short enough and time tight enough, I might just let it be an array stored in memory, but I guess that would cause performance problems after more than a couple hundred lines.
for interviews I'd say even straight dumping data into the file system and retrieving later when the user needs it would be a somewhat valid approach. It's more important that the candidate is able to explain the reason he choose this approach over holding everything in memory (writing/retrieval overhead vs. memory limitation, etc), given the data size/structure of the assignment.
If candidates reason well about design decisions of their implementation, perfect or not, it at least tells me they are reliable developers who do not jump into coding before thinking carefully.
If candidates reason well about design decisions of their implementation, perfect or not, it at least tells me they are reliable developers who do not jump into coding before thinking carefully.
create a Movie class, for each line read in from the CSV file create a new Movie object and add it to a list. queries would search the list of Movies?
> Hiring Manager Perspective: Everyone lies, sorry.
Yeah, and honestly, that includes hiring managers.
I've rejected offers because the hiring managers level of deception exceeded my tolerance for bullshit.
> About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard.
Yes, I don't remember the syntax from 5+ languages well enough to write it in on a whiteboard. Yet somehow, I'm able to use 3-4 on a daily basis to handle millions of dollars in transactions.
So...I really think whiteboards, once again, are really the wrong way to test people. Code samples and discussing them work much, much better for everyone.
I may be biased...whiteboards, I get rejected 50% of the time. I also find, honestly, that if I ask two technical questions of the people giving the whiteboard test of similar difficulty...they rarely can answer more than 1 acceptably so I've found the failure rate to be pretty consistent with the rate they fail me.
Code samples? I get offers 90% of the time.
Yeah, and honestly, that includes hiring managers.
I've rejected offers because the hiring managers level of deception exceeded my tolerance for bullshit.
> About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard.
Yes, I don't remember the syntax from 5+ languages well enough to write it in on a whiteboard. Yet somehow, I'm able to use 3-4 on a daily basis to handle millions of dollars in transactions.
So...I really think whiteboards, once again, are really the wrong way to test people. Code samples and discussing them work much, much better for everyone.
I may be biased...whiteboards, I get rejected 50% of the time. I also find, honestly, that if I ask two technical questions of the people giving the whiteboard test of similar difficulty...they rarely can answer more than 1 acceptably so I've found the failure rate to be pretty consistent with the rate they fail me.
Code samples? I get offers 90% of the time.
>Yeah, and honestly, that includes hiring managers.
Not just the example you gave -- they also lie whenever they list something as "required" and then hire the go-getter who's missing some of the skills.
Not just the example you gave -- they also lie whenever they list something as "required" and then hire the go-getter who's missing some of the skills.
> As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.
Yeah, many of these kinds of blog posts strike me as being out of touch with what hiring is like. So don't ask about algorithms, don't ask to write code, don't ask to use a whiteboard and ignore if the candidate can't handle the pressure of a standard interview? How are you expected to weed out unsuitable candidates?
Yeah, many of these kinds of blog posts strike me as being out of touch with what hiring is like. So don't ask about algorithms, don't ask to write code, don't ask to use a whiteboard and ignore if the candidate can't handle the pressure of a standard interview? How are you expected to weed out unsuitable candidates?
It's quite easy, just use bias. (No, not really)
How are you expected to weed out unsuitable candidates?
Here are my rules:
1. Phone screen coding is optional. If someone is vouched for by a reliable source, you don't fizzbuzz them.
2. The phone-screen question, if used, should not presume any type of formal university CS education (i.e., asking for algorithm regurgitation is right out). Not every good programmer has a university CS degree (many of the best don't), and even among those who do, the longer they've been out of school the less of that stuff they'll remember. Their brain has long since paged the CS 101 algorithms out or even cleared them entirely to make room for the working set of things that actually turned out to be relevant to coding for a living.
3. Good phone-screen questions have solutions in under ten lines of code. Ideal phone-screen questions have solutions in under five, or may even be one-liners in your company's preferred programming language.
4. Once a candidate is past the phone screen, or once you've decided they can skip it, you get to ask them exactly one more question that involves writing code.
5. The final code question must be realistic both as a problem and as a set of conditions. Your employees write solutions to real problems, in editors or IDEs, so to find out whether someone could succeed as your employee that's what you should test. Being able/unable to solve contrived problems by coding on a whiteboard is a completely unrelated skill and does not indicate or rule out ability to solve real problems in an editor or an IDE.
6. The final code question should be a "homework", designed to take a baseline-qualified candidate approximately an hour or two to complete, but to be completed at the candidate's leisure (i.e., set a deadline a day or two after you give them the problem). They should not have to solve it perfectly in 20 minutes on a whiteboard. They should be able to use common/standard libraries. They should be able to use Google or look things up in books they have lying around. They should be able to try running their code and correct errors that turn up when they do. They should be able to do those things because those are job-relevant skills and job-relevant skills are the things you want to test, remember?
7. The interview portion of the final code question should be a collaborative review of the code, discussing design decisions, tradeoffs, and areas where it could be improved/expanded/etc. Being able to present, discuss and review code with others is a job-relevant skill.
8. In a real dev job, at most 15-20% of a developer's time is spent in directly writing code to accomplish a task. The remaining 80-85% is spent in determining requirements, researching approaches to problems, making design decisions, soliciting feedback from peers, reviewing existing or new-but-peer-written code, writing tests, writing documentation, and performing all the other mental and bureaucratic tasks which accompany the act of coding. In light of which, time spent directly writing code to solve interview questions is not permitted to exceed 15-20% of the total time taken by the interview process. The remaining 80-85% should be focused on getting to know the candidate well enough to determine how they'll do with the tasks that will take up 80-85% of their time on the actual job.
I've done my best to phrase this politely. It's based on (as of this point) 15 years of getting paid to write code and having been on both sides of the interview at multiple companies and for multiple positions at multiple points in that time span. But if it helps, feel free to put it in terms the typical tech interviewer is familiar with and think of this as a sort of fizzbuzz for interviewers/managers: anyone who can't figure out how to implement these things may not be qualified to be an interviewer or manager.
Here are my rules:
1. Phone screen coding is optional. If someone is vouched for by a reliable source, you don't fizzbuzz them.
2. The phone-screen question, if used, should not presume any type of formal university CS education (i.e., asking for algorithm regurgitation is right out). Not every good programmer has a university CS degree (many of the best don't), and even among those who do, the longer they've been out of school the less of that stuff they'll remember. Their brain has long since paged the CS 101 algorithms out or even cleared them entirely to make room for the working set of things that actually turned out to be relevant to coding for a living.
3. Good phone-screen questions have solutions in under ten lines of code. Ideal phone-screen questions have solutions in under five, or may even be one-liners in your company's preferred programming language.
4. Once a candidate is past the phone screen, or once you've decided they can skip it, you get to ask them exactly one more question that involves writing code.
5. The final code question must be realistic both as a problem and as a set of conditions. Your employees write solutions to real problems, in editors or IDEs, so to find out whether someone could succeed as your employee that's what you should test. Being able/unable to solve contrived problems by coding on a whiteboard is a completely unrelated skill and does not indicate or rule out ability to solve real problems in an editor or an IDE.
6. The final code question should be a "homework", designed to take a baseline-qualified candidate approximately an hour or two to complete, but to be completed at the candidate's leisure (i.e., set a deadline a day or two after you give them the problem). They should not have to solve it perfectly in 20 minutes on a whiteboard. They should be able to use common/standard libraries. They should be able to use Google or look things up in books they have lying around. They should be able to try running their code and correct errors that turn up when they do. They should be able to do those things because those are job-relevant skills and job-relevant skills are the things you want to test, remember?
7. The interview portion of the final code question should be a collaborative review of the code, discussing design decisions, tradeoffs, and areas where it could be improved/expanded/etc. Being able to present, discuss and review code with others is a job-relevant skill.
8. In a real dev job, at most 15-20% of a developer's time is spent in directly writing code to accomplish a task. The remaining 80-85% is spent in determining requirements, researching approaches to problems, making design decisions, soliciting feedback from peers, reviewing existing or new-but-peer-written code, writing tests, writing documentation, and performing all the other mental and bureaucratic tasks which accompany the act of coding. In light of which, time spent directly writing code to solve interview questions is not permitted to exceed 15-20% of the total time taken by the interview process. The remaining 80-85% should be focused on getting to know the candidate well enough to determine how they'll do with the tasks that will take up 80-85% of their time on the actual job.
I've done my best to phrase this politely. It's based on (as of this point) 15 years of getting paid to write code and having been on both sides of the interview at multiple companies and for multiple positions at multiple points in that time span. But if it helps, feel free to put it in terms the typical tech interviewer is familiar with and think of this as a sort of fizzbuzz for interviewers/managers: anyone who can't figure out how to implement these things may not be qualified to be an interviewer or manager.
This has other sides as well:
* Excelling through the test never to hear from the company again.
* Being (as admitted by the manager in the interview) one of two qualified candidates, the other one being from a somewhere a few hours away by plane, and then get a really cheap offer.
* being asked in a disbelieving tone if I can still code after working as a system engineer for a while. (yeah, give me an assignment already.)
I'd love to be in more interviews where I could win just by coding small small samples or discuss code on the whiteboard (that is as long as nobody is nitpicking about things that any decent IDE will catch.)
* Excelling through the test never to hear from the company again.
* Being (as admitted by the manager in the interview) one of two qualified candidates, the other one being from a somewhere a few hours away by plane, and then get a really cheap offer.
* being asked in a disbelieving tone if I can still code after working as a system engineer for a while. (yeah, give me an assignment already.)
I'd love to be in more interviews where I could win just by coding small small samples or discuss code on the whiteboard (that is as long as nobody is nitpicking about things that any decent IDE will catch.)
I've had the same experience. Someone listed 2 years Scala experience on a resume, but couldn't explain Unit, None, null, and Nothing to me. Or the guy this week who had several years of ops experience and when asked "how can you tell what indexes are being used in a SQL query" didn't even know about EXPLAIN.
Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map implementation," because sometimes "you put a thing in the map and then get it back out later" is good enough for 99% of startup engineering tasks.
Somewhere out there is a sweet middle ground, but it seems not one agrees where it really is.
Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map implementation," because sometimes "you put a thing in the map and then get it back out later" is good enough for 99% of startup engineering tasks.
Somewhere out there is a sweet middle ground, but it seems not one agrees where it really is.
That latter bit in the Amazon interview really pissed me off. They saw my resume, and it didn't include a degree in CS. They had a cheap opportunity to ask me questions about data structures (phone interview). So why the hell do they wait until the "fly me across the country" interview to ask questions about implementations of priority queue?
To be honest though, just because you can get by without knowing how hash maps are implemented, doesn't mean it isn't useful to know - and if another candidate does know, they would sooner hire them.
Further, they may be looking for factors that correlates with other, hard-to-measure factors. Even such as reading a "common interview questions" book - it correlates with focused pragmatism...
Further, they may be looking for factors that correlates with other, hard-to-measure factors. Even such as reading a "common interview questions" book - it correlates with focused pragmatism...
I'm not saying it's not useful to know or that having that knowledge might make someone a better candidate, but it seems like that alone shouldn't be reason enough to reject someone.
And I disagree that looking up the answers to common interview questions is focused pragmatism. I don't bother, even with the knowledge that it would help me get a job. I spend my time working on side projects or learning practical things. I think I will never in my life have implement a hash map, and that knowing it's all O(1) operations is sufficient. But also I guess I don't want to work for a company that is interested in my ability to jump through hoops. (shrug)
And I disagree that looking up the answers to common interview questions is focused pragmatism. I don't bother, even with the knowledge that it would help me get a job. I spend my time working on side projects or learning practical things. I think I will never in my life have implement a hash map, and that knowing it's all O(1) operations is sufficient. But also I guess I don't want to work for a company that is interested in my ability to jump through hoops. (shrug)
I hear you. I'm terrified by the kinds of interviews that want programming trivia. In the last three years I've never had to code a binary search tree. But I should be able to show you I'm very comfortable with Python.
Devil's advocate: Asking highly academic questions allows employers to be ageist without explicitly stating it, since college grads are likely to be the most familiar with them. This lets them select for younger candidates with less experience and thus drive down developer salary.
(Standard disclaimer: Some development positions actually require the academic knowledge mentioned. Most of the time, though, a good developer will use a well-tested library instead of rolling their own.
(Standard disclaimer: Some development positions actually require the academic knowledge mentioned. Most of the time, though, a good developer will use a well-tested library instead of rolling their own.
Why would they want or need to be ageist about it? If it's just about paying low salaries, surely all they need to do to accomplish that is offer low salaries?
(If anything my experience is that older developers have a stronger tendency towards implementing academically known datastructures themselves, whereas younger developers are more likely to make more use of libraries)
(If anything my experience is that older developers have a stronger tendency towards implementing academically known datastructures themselves, whereas younger developers are more likely to make more use of libraries)
Longer hours, less willing to stand up to borderline abusive labor practices?
How about you show me how comfortable you are with python by coding up a quick binary tree implementation?
Python isn't the only capability you're typically being evaluated for, though. A binary search tree is a very simple thing. I think it's reasonable to expect a candidate to come up with a basic implementation of a binary search tree, especially if you are giving him/she hints when he/she gets stuck -- an interview should be a two-way conversation. If you can't come up with something approaching a binary search tree in an hour and with my help, how can I expect you to design a reasonably complex system when the business needs it?
Now if you are asked to come up with a red black tree without any help, now that is a different story. A red black tree's implementation details are hard to derive given a set of requirements. A binary search tree, not so much.
Now if you are asked to come up with a red black tree without any help, now that is a different story. A red black tree's implementation details are hard to derive given a set of requirements. A binary search tree, not so much.
As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it.
Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.
Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.
They might not be trivia, but they're not presented in the same manner as someone would be doing on the job and/or the candidate isn't given the same access to tools they normally have when working and/or there's an 'on the spot' requirement to answer the question.
I don't store everything in my head anymore. I have a general understanding of the concept and a mental pointer in the form of the search term to put in google to refresh how to implement the thing.
I have to implement 10-20 concepts across 5-10 languages or APIs or technologies every single day usually, my brain doesn't work like a database where every record that's inserted is there permanently until I update or delete it. The stuff I'm not using regularly gets fuzzier and fuzzier and goes back to "general concept mode" if I'm not actively using it.
So when someone asks me to write a full iOS app during an interview when I've been making Microsoft business apps for the past year, even though I've written and released multiple full iOS apps at previous jobs, I can't just sit down and produce a perfectly working app like a robot, especially if I didn't have much time to prepare for the interview (that recruiter contacted me three days earlier and didn't tell me he set up an interview until 8pm the night before).
With technical questions it's even worse, because I could have been spending days and days refreshing my knowledge but you happen to choose one of the things I didn't think to refresh my brain on. And so I waffle on the answer and you go "oooh, looks like he doesn't know anything". No, I've got a full decade of making apps and software, in lead roles, in multiple industries with a bunch of different technologies. I know plenty. I just didn't have that question fresh in my head.
Then you pass, and lose out on someone you would have benefited from greatly in favor of the recent grad student that hasn't made anything but toy programs yet got tested on all those concepts within the past six months so it's fresh in their heads.
I don't store everything in my head anymore. I have a general understanding of the concept and a mental pointer in the form of the search term to put in google to refresh how to implement the thing.
I have to implement 10-20 concepts across 5-10 languages or APIs or technologies every single day usually, my brain doesn't work like a database where every record that's inserted is there permanently until I update or delete it. The stuff I'm not using regularly gets fuzzier and fuzzier and goes back to "general concept mode" if I'm not actively using it.
So when someone asks me to write a full iOS app during an interview when I've been making Microsoft business apps for the past year, even though I've written and released multiple full iOS apps at previous jobs, I can't just sit down and produce a perfectly working app like a robot, especially if I didn't have much time to prepare for the interview (that recruiter contacted me three days earlier and didn't tell me he set up an interview until 8pm the night before).
With technical questions it's even worse, because I could have been spending days and days refreshing my knowledge but you happen to choose one of the things I didn't think to refresh my brain on. And so I waffle on the answer and you go "oooh, looks like he doesn't know anything". No, I've got a full decade of making apps and software, in lead roles, in multiple industries with a bunch of different technologies. I know plenty. I just didn't have that question fresh in my head.
Then you pass, and lose out on someone you would have benefited from greatly in favor of the recent grad student that hasn't made anything but toy programs yet got tested on all those concepts within the past six months so it's fresh in their heads.
Couldn't agree more.
That's usually not how it works though. You're more likely to be laughed out of the room for asking such a silly question, despite the fact the (presumably technical) interviewer could do no better without the teacher's copy in front of them.
An aside, but I think interviews like this should allow Internet connections. Give the candidate a minute to look something up and digest it in their own way. It should be obvious whether they'll get the concept or just recite the Wikipedia definition. Just as important is how they do their research, and how they draw connections between foreign and familiar concepts given a blueprint of the former.
An aside, but I think interviews like this should allow Internet connections. Give the candidate a minute to look something up and digest it in their own way. It should be obvious whether they'll get the concept or just recite the Wikipedia definition. Just as important is how they do their research, and how they draw connections between foreign and familiar concepts given a blueprint of the former.
"As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it."
Maybe. Or you would scoff, turn your nose up, mutter "noob" under your breath, and move on, knowing you're not going to hire me.
I'm sure you yourself would do as you said, but I can't be so sure about random interviewer person.
Maybe. Or you would scoff, turn your nose up, mutter "noob" under your breath, and move on, knowing you're not going to hire me.
I'm sure you yourself would do as you said, but I can't be so sure about random interviewer person.
Tech interviewing is awful. Don't give me excuses for why you do awful things, or try to say "well, it's candidates' fault for having to lie and dissemble to get through the process we created".
Plenty of known-smart, known-qualified people are criticizing tech interview processes. They're criticizing the dehumanizing approaches. They're criticizing the way it wastes the time of everyone involved. They're criticizing the way it produces huge false-negative rates.
And they're right. Many of the people criticizing tech interviewing are precisely the kind of people you say you want to hire but then design processes to exclude. You don't get to shift the blame on that one; if you're really a hiring manager, you should be finding ways to fix, not ways to make excuses for, the tech interview process.
Plenty of known-smart, known-qualified people are criticizing tech interview processes. They're criticizing the dehumanizing approaches. They're criticizing the way it wastes the time of everyone involved. They're criticizing the way it produces huge false-negative rates.
And they're right. Many of the people criticizing tech interviewing are precisely the kind of people you say you want to hire but then design processes to exclude. You don't get to shift the blame on that one; if you're really a hiring manager, you should be finding ways to fix, not ways to make excuses for, the tech interview process.
It's possible to do technical interviewing well. I've done a lot of terrible ones, but at my current job the technical interviews were highly relevant to my work, and not trivia or puzzle questions. We used a laptop instead of a whiteboard. And even though I didn't get everything 100% "right", there was plenty of discussion, so they could see that I knew what I was doing. So they offered me a job. It wasn't an easy interview, but it worked well in my case. And since the other members of the team are very good at what they do, it looks like it's worked for the rest of the company as well.
Doing what you're doing will probably work, in that you'll get decent candidates. But this approach only works for one kind of good developer -- the kind who can survive this kind of interview. Silicon Valley's diversity problem is made worse by interview styles that give false negatives for excellent candidates who lack confidence or just don't think the same way. My thesis is that this test, by giving frequent false negatives, is resulting in a worse pool of final hires than a broader process.
What would you suggest instead that would decrease the false negatives without allowing the false positives to explode? The parent poster named a couple of different things s/he tried that didn't work.
Sometimes the best available option is mediocre. ("It has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.")
Sometimes the best available option is mediocre. ("It has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.")
You make a good point. In practice, we've not found a reliable way to weed out the false positives that result (I would not characterize it as an "explosion", but there are definitely some). However, we've stuck with this process because we firmly believe that the benefits of having the excellent people we've hired who would not have passed a standard interview outweigh the costs of getting rid of the others.
I've recently got into the interviewing for devs game. Now we're a perl fairly specialised shop, and we only hire experienced people so that makes things relatively easy (candidates need to demonstrate a depth of knowledge, and . The pool of people around is relatively shallow too. We don't actually need to ask people technically detailed questions about specific algorithms. We have a conversation. From that conversation you can learn a lot. How do you do async programming (answer you structure the code to make it easy for it to scale)? What experience do you have with RDBMSs? (we're looking for higher level answers). What's the difference between jquery and prototype? How do you deal with conflict? What's the most important thing about coding style? And you let the conversation flow depending on what they say and how they answer the questions.
One of my favorite questions is asking people their least favorite and favorite languages then asking people to give one of their favorite features in the least favorite language, and least favorite features in their favorite language. Shows that they've actually spent time thinking about their tools. You get a surprising amount of insight from it, depending on the answer.
This question would throw me for a loop because I don't have anything I think of as my least favorite language.
I could pretend that Python was my favorite language, but that's more that I'm comfortable with it than any sort of actual feeling that I should prefer it over others. That is, I use it out of inertia and familiarity, not out of some sense that I've found something.
I could pretend that Python was my favorite language, but that's more that I'm comfortable with it than any sort of actual feeling that I should prefer it over others. That is, I use it out of inertia and familiarity, not out of some sense that I've found something.
See, but that's a reasonable answer. I might take that and pivot to like "if you had to design an ideal language, drawing from the strengths of the ones you've worked with, what would you think most important?". The idea is to get you talking about things you've worked with to show familiarity and critical thought about your tools.
Yes that's a good question, I wouldn't like to have that without notice in an interview :)
I hate the question -- I do think about my tools, constantly, but whenever I've been faced with that question, I don't have a "best" and "worst" lined up, and have to think about the question for a few minutes to recall all the moments of frustration, and so anything I give on-the-spot will sound stupid.
I hate that one because I think Scala basically gets it right, and so I can't really give a good answer to least favourite feature in it. It's my favourite language precisely because I don't think there's anything massively wrong with it!
Doesn't that risk hiring someone who says the right high-level things (maybe they've read some books) but can't actually do anything at the concrete implementation level?
Yes this is true. But I'd be hoping they'd also have something on github or the cpan, or other places to show their general thought processes. Or at minimum a credible recent employer and references to back it up.
> in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard
That's one of the most inadvertently funny things I've read on news.yc in a long time!
That's one of the most inadvertently funny things I've read on news.yc in a long time!
> Everyone lies, sorry.
I have an issue with this - i don't lie. Not in CV, not in interviews. We're not managers, we cannot talk our way out of tasks given to us, and most of us who are worth at least a pinch of salt are not desperate to get job X.
But I understand that if your experience is as it is, this is probably correct approach.
I have an issue with this - i don't lie. Not in CV, not in interviews. We're not managers, we cannot talk our way out of tasks given to us, and most of us who are worth at least a pinch of salt are not desperate to get job X.
But I understand that if your experience is as it is, this is probably correct approach.
> I have an issue with this - i don't lie.
Well, I don't either. That makes it much better for me that people use a test that separates liars from honest people.
Yes, the phrasing is bad, but it is a very understandable hyperbole.
Well, I don't either. That makes it much better for me that people use a test that separates liars from honest people.
Yes, the phrasing is bad, but it is a very understandable hyperbole.
Unless handwriting is a big part of the job irl, it shouldn't be for the interview. White board for drawing a db schema or something, maybe, but programmers type.
Also, it can be hard to generate code on the fly in an uncomfortable situation, and breaking the ice is important. I've often wondered if asking individuals to debug, test and fix, or to refactor code, might not be a use way to get a high level look at their product, and ease them into programming mode so when they get to actually writing a function for your next question they are tuned up and ready to go.
Also, it can be hard to generate code on the fly in an uncomfortable situation, and breaking the ice is important. I've often wondered if asking individuals to debug, test and fix, or to refactor code, might not be a use way to get a high level look at their product, and ease them into programming mode so when they get to actually writing a function for your next question they are tuned up and ready to go.
I honestly can't think of a time I lied during a job interview. Am I doing it wrong?
It's usually over-promoting a skill on your resume. It might not be nefarious or intentional, but it's a communications gap. What you mean by "experience in," and what the manager wants you to mean by "experience in," are two totally different things.
Example, if you read a SQL book a couple of years ago, you would say you have experience in SQL. You've forgotten most of it, but you are familiar. If a manager reads that same thing, he or she might think, "Oh, proficient in CRUD queries but not overly complex ones." Manager gives you a quiz on SQL, but since you don't have Google in front of you, you flail because you haven't messed with it in a long time.
It's not really lying, it's just a communications gap. I'm not saying there isn't outright misrepresentation of skills, but most of the time it isn't intentional.
Example, if you read a SQL book a couple of years ago, you would say you have experience in SQL. You've forgotten most of it, but you are familiar. If a manager reads that same thing, he or she might think, "Oh, proficient in CRUD queries but not overly complex ones." Manager gives you a quiz on SQL, but since you don't have Google in front of you, you flail because you haven't messed with it in a long time.
It's not really lying, it's just a communications gap. I'm not saying there isn't outright misrepresentation of skills, but most of the time it isn't intentional.
With a truly technical manager, this is honestly one of the fastest ways to torpedo your credibility.
Anything listed on your resume is fair game for questions, especially if you claim it as a skill. "Reading a book" is not a skill; reading a book and using the contents in that book for several real world projects probably qualifies. Especially if you can describe what you did in detail.
Harsh reality: I value everything in that section of the resume at the value of the weakest component that I find. So when we discover that your knowledge of SQL is reading a few tutorials on w3schools ten years ago, I rate EVERYTHING ELSE in that section at the same level (ouch!).
So the safe way to play this is don't list anything that you can't hold a 5 - 10 minute conversation about and explain at least the basics of how the technology works, citing real examples of where you used it (paid or unpaid, I don't care about that, as long as you're clear about what you did).
Yeah. Most of your competitors won't do this. They'll fill out the bottom of their resume with junk. But um... there's a reason they're still looking....
Incidentally my own (technical) resume has exactly two lines of IT skills... each of which I can do a 30+ min speech on. Never had a problem in that area during an interview...
Anything listed on your resume is fair game for questions, especially if you claim it as a skill. "Reading a book" is not a skill; reading a book and using the contents in that book for several real world projects probably qualifies. Especially if you can describe what you did in detail.
Harsh reality: I value everything in that section of the resume at the value of the weakest component that I find. So when we discover that your knowledge of SQL is reading a few tutorials on w3schools ten years ago, I rate EVERYTHING ELSE in that section at the same level (ouch!).
So the safe way to play this is don't list anything that you can't hold a 5 - 10 minute conversation about and explain at least the basics of how the technology works, citing real examples of where you used it (paid or unpaid, I don't care about that, as long as you're clear about what you did).
Yeah. Most of your competitors won't do this. They'll fill out the bottom of their resume with junk. But um... there's a reason they're still looking....
Incidentally my own (technical) resume has exactly two lines of IT skills... each of which I can do a 30+ min speech on. Never had a problem in that area during an interview...
We do interviews in person where I ask a few basic questions and listen for the answer, then assign a somewhat complex problem to be solved in a pre-prepared iOS project. Google fully allowed. I'm not even looking for a 100% functional solution or even particularly elegant code, I want to see how a candidate reacts to pressure and how resourceful they are.
I would say the majority of our hires don't complete it and I always explain that's fine, the point is to observe the process they used to create whatever they created.
I would say the majority of our hires don't complete it and I always explain that's fine, the point is to observe the process they used to create whatever they created.
Don't feel too bad, once HR sent a guy to one of my tech interviews who was a male nude model with no programming experience or knowledge - or anything core to the company for that matter.
[deleted]
[deleted]
Hmm now I feel bad about asking questions on transaction isolation levels.
As someone who is going through many technical interviews right now, and failing all of them, I love this article. (It was actually brought to my attention last week.)
My technical ability is readily apparent to those who have viewed my work, and by virtue of those who have praised it. I don't claim to be the best programmer in the world, just a competent one. I've also been programming for over 20 years, that might have something to do with it.
However, I suck at interviews, in any way shape or form (personality tests, technical tests, you name it). Yet I've aced every job ever given to me, and people love to work with me (even in spite of my salty attitude).
To think that you can determine what it is like to work with me over the span of a year within the span of an hour is completely and utterly ridiculous.
As it turns out, the little sub-problems they give are the most trivial part of programming. The hard part, the part it takes many years to get any good at, is coherently organizing, documenting, and ensuring the stability of a larger system, particularly concurrently with other programmers. Or designing an algorithm that you can't just Google. Or making a really tough decision about what features to cut or what direction to pivot. Or organizing a vision of what will add the most value for the customer. Or...etc
Being an introvert with a monotone voice, general lack of expression, and deadpan sarcastic humor does wonders for personality tests. Most people's default reaction to me (in interviews or otherwise) is that I am a total dick. Which I am, but the kind you don't mind hanging around.
I don't do well with programming that has a one hour deadline. But give me a day and I can produce the typical output a programmer would within a day.
If I spent all my time practicing for interviews, I'd probably be better at them (with stuff like Top Coder or Interview Cake or whatever). And I think giving these things a whirl is well worth it (not for the sake of winning in interviews). But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks (sorry, writing a red-black tree on a white board within an hour never happens to me in the real world).
My technical ability is readily apparent to those who have viewed my work, and by virtue of those who have praised it. I don't claim to be the best programmer in the world, just a competent one. I've also been programming for over 20 years, that might have something to do with it.
However, I suck at interviews, in any way shape or form (personality tests, technical tests, you name it). Yet I've aced every job ever given to me, and people love to work with me (even in spite of my salty attitude).
To think that you can determine what it is like to work with me over the span of a year within the span of an hour is completely and utterly ridiculous.
As it turns out, the little sub-problems they give are the most trivial part of programming. The hard part, the part it takes many years to get any good at, is coherently organizing, documenting, and ensuring the stability of a larger system, particularly concurrently with other programmers. Or designing an algorithm that you can't just Google. Or making a really tough decision about what features to cut or what direction to pivot. Or organizing a vision of what will add the most value for the customer. Or...etc
Being an introvert with a monotone voice, general lack of expression, and deadpan sarcastic humor does wonders for personality tests. Most people's default reaction to me (in interviews or otherwise) is that I am a total dick. Which I am, but the kind you don't mind hanging around.
I don't do well with programming that has a one hour deadline. But give me a day and I can produce the typical output a programmer would within a day.
If I spent all my time practicing for interviews, I'd probably be better at them (with stuff like Top Coder or Interview Cake or whatever). And I think giving these things a whirl is well worth it (not for the sake of winning in interviews). But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks (sorry, writing a red-black tree on a white board within an hour never happens to me in the real world).
But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks
You have to look at the programming career as requiring two skills: the first is programming, and the second is finding a job. That might suck, but it's the nature of a career where you change jobs every three years or so.
You have to look at the programming career as requiring two skills: the first is programming, and the second is finding a job. That might suck, but it's the nature of a career where you change jobs every three years or so.
Oh, I agree with you, you are totally right. I am mostly speaking from a hypothetical "I wish the world did not operate this way" type of tone. :)
Sadly true. What sucks is having to choose between working on a fun side project or practicing algorithm or coding interviews (LeetCode, Hacker Rank). I honestly really dislike doing the latter, but I know I have to.
Yes, I find it ironical that I was way better at coding tests 15 years ago straight out of University. Nowadays I think longer and write less code. It works better.
One great example is Haseeb, who spent two years of all his life programming. He now commands a $250k salary (which, I say more power to him for exploiting our current interview system).
I don't doubt that Haseeb is an excellent programmer. But not everyone has two years to devote to mastering the interview system like him, and there are plenty of skills you won't get just by doing competitive programming.
http://haseebq.com/farewell-app-academy-hello-airbnb-part-i/
I don't doubt that Haseeb is an excellent programmer. But not everyone has two years to devote to mastering the interview system like him, and there are plenty of skills you won't get just by doing competitive programming.
http://haseebq.com/farewell-app-academy-hello-airbnb-part-i/
Wow. I used to know Haseeb during his poker days 8-10 years ago, when he was still playing for dimes/quarters and we were all still using MSN. Can't believe I'm hearing his name again in this context, I had no idea he got into software.
He's probably a bad example to make your point with. Haseeb had some moral failings, but he is truly on another level in terms of intellect/drive/vision, and the interviewers at Airbnb probably didn't have a hard time recognizing that.
I can't stress enough how smart that guy is. He leaves an impression.
He's probably a bad example to make your point with. Haseeb had some moral failings, but he is truly on another level in terms of intellect/drive/vision, and the interviewers at Airbnb probably didn't have a hard time recognizing that.
I can't stress enough how smart that guy is. He leaves an impression.
Small world indeed. :) If it came across otherwise, I have nothing but positive things to say about Haseeb. Still, as with any coder I might praise, any human has gaps in their skillset - and I imagine Haseeb has a few; there is only so much you can learn in 2 years.
I say this based on my personal reflection, so I could be wrong. The coder I was 10 years ago was laughably bad compared to the coder I am now, and I spent pretty much every one of those years doing 80+ hours of programming per week.
That said, if I had to hire someone fresh out of college, or someone like Haseeb, the choice would easily be Haseeb. :)
I say this based on my personal reflection, so I could be wrong. The coder I was 10 years ago was laughably bad compared to the coder I am now, and I spent pretty much every one of those years doing 80+ hours of programming per week.
That said, if I had to hire someone fresh out of college, or someone like Haseeb, the choice would easily be Haseeb. :)
That was a very fascinating read, and completely illusion-shattering regarding the skill tech companies have in giving offers to good candidates. Social proof provided 90% of his increase in market value. I am not doubting that he is a very skilled developer, but this was certainly not the key reason why he got such a good offer :)
It's ALWAYS about who you know. Always.
That's not what I got from the story -- he mentions how he got warm referrals (the "who you know") to employers that went tepid quickly after the interview ... but then the same ones suddenly wanted him once he claimed (truthfully, though without proof) that he had standing, big offers from other employers.
"In the end, I didn’t get a single offer through a raw application. Every single offer came through a referral of some kind. (This I did not expect, and strongly influences the advice I’d give to a job-seeker.)"
" Haseeb Qureshi says: 04/23/2016 at 9:53 am
I’ll be writing more about this in my subsequent blog post. But if you have no connections at all in SV, then I might say that if you’re set on SV as a place to work (sounds like you’re on the fence?) I’d recommend mass applying, and also moving here to start interacting with folks and getting to know people. Building a network is so, so valuable for getting a foot in the door."
Unless this guy is some type of programming prodigy, who in only two years of self learning, somehow blew away all top companies, only to be turned down, then what happened was that he has friends in high places that helped sway their decision.
To be completely honest, the entire article smells like a marketing campaign for TripleByte and AppAcademy. Google wanting to put him on the C++ team, after two years coding in Rails? Get the hell out of here.
" Haseeb Qureshi says: 04/23/2016 at 9:53 am
I’ll be writing more about this in my subsequent blog post. But if you have no connections at all in SV, then I might say that if you’re set on SV as a place to work (sounds like you’re on the fence?) I’d recommend mass applying, and also moving here to start interacting with folks and getting to know people. Building a network is so, so valuable for getting a foot in the door."
Unless this guy is some type of programming prodigy, who in only two years of self learning, somehow blew away all top companies, only to be turned down, then what happened was that he has friends in high places that helped sway their decision.
To be completely honest, the entire article smells like a marketing campaign for TripleByte and AppAcademy. Google wanting to put him on the C++ team, after two years coding in Rails? Get the hell out of here.
Ah, right, I forgot about that part. Even so, the point remains that it isn't only about who you know, because he had those connections and leads still went stale, until he gamed the system.
But I would agree that it reveals how confused and manipulation-prone the hiring process is; if they're hiring someone for critical, technical C++ work after only two years experience on mostly-Rails, they really don't know what they want. Ditto for upping their offers so significantly based on things that shouldn't matter that much.
I'm likewise skeptical about how Airbnb would tolerate him revealing sensitive details of a negotiation like that in ways that reflect very badly on them and weakens their bargaining position on future hires. Sure, you don't want to fire an employee just for disclosing his compensation (major legal issues there), but his post went way beyond that.
But I would agree that it reveals how confused and manipulation-prone the hiring process is; if they're hiring someone for critical, technical C++ work after only two years experience on mostly-Rails, they really don't know what they want. Ditto for upping their offers so significantly based on things that shouldn't matter that much.
I'm likewise skeptical about how Airbnb would tolerate him revealing sensitive details of a negotiation like that in ways that reflect very badly on them and weakens their bargaining position on future hires. Sure, you don't want to fire an employee just for disclosing his compensation (major legal issues there), but his post went way beyond that.
Seriously, something is suspicious here. These companies aren't stupid.
Did Voxel Quest (http://www.voxelquest.com/) not work out financially? :( If I had my company I'd hire you in a heartbeat. Might be stupidly obvious, but pinging your network might help – I can't be the only one who would want such a talented programmer on their team. Good luck in your search!
Please read my most recent two blog entries on http://www.voxelquest.com where I talk about the current state of things. :)
I have pinged my network, and am very grateful for all the job offers that have come of it. However, at least half those offers have come with technical interviews that basically ignore my work experience, or in one case the recruiter could not even determine why my experience was relevant (even though it was). Some offers involved getting paid to continue working on Voxel Quest. However, one such offer was in a remote country where the US dollar is much stronger, and I could not have operated under the salary they were offering (at least, not without moving to their country, which is very far away).
At this point I am trying to figure out the "best" path, and that involves many factors, one of which is trying to ease up on the stress I have put my family through. By insistence I have put up Patreon although I am not yet touching the money until I know what my future job is and what that means for VQ (and as mentioned I'm also refunding all the money put into VQ).
I have pinged my network, and am very grateful for all the job offers that have come of it. However, at least half those offers have come with technical interviews that basically ignore my work experience, or in one case the recruiter could not even determine why my experience was relevant (even though it was). Some offers involved getting paid to continue working on Voxel Quest. However, one such offer was in a remote country where the US dollar is much stronger, and I could not have operated under the salary they were offering (at least, not without moving to their country, which is very far away).
At this point I am trying to figure out the "best" path, and that involves many factors, one of which is trying to ease up on the stress I have put my family through. By insistence I have put up Patreon although I am not yet touching the money until I know what my future job is and what that means for VQ (and as mentioned I'm also refunding all the money put into VQ).
It speaks for broken hiring when even skillers like you can't get a job.
I always thought I just wasn't as good as I think when I didn't get a job, but I know your work and it is amazing, so hiring companies just don't know what they doing anymore
I always thought I just wasn't as good as I think when I didn't get a job, but I know your work and it is amazing, so hiring companies just don't know what they doing anymore
Hiring right now is a shitshow of old wives' tales, cargo-culted practices from big name tech companies, shady recruiters, mismatched incentives, interviewers who have no experience or training in interviewing, gimmicky apps trying to somehow gamify technical interviewing and endless whining back and forth on HN and Medium.
I'm sure a lot of developers who are currently employed are put off applying elsewhere because the whole process has become so demanding and unpleasant and disrespectful.
One company I applied to for example asked to do a take-home test, maybe 2 hours. I did the test, only to be told it was the first stage of a long and gruelling process involving a further 8 hour take-home project (unpaid, of course) followed my several rounds of technical and non-technical interviews. I immediately withdrew my application. When would I have the time to do 8 hours - it was timed for some bizarre reason, so it had to be done in a single block of time - on a project? Maybe for my own projects, sure, but that's my spare time.
Interviewers and recruiters are, after all, being paid to sit there, while interviewees are - unless they're unemployed - taking precious time off to travel, maybe stay overnight in a hotel, sit through hours of gruelling interviews and tests, all for a job that may or may not offer anything much better than what they've already got. And yet the penny hasn't yet dropped that maybe your shitty process is the reason you haven't found anyone yet?
I'm not sure what the solution is, but I'm convinced that it wasn't this bad 5 or 10 years ago - maybe if you were interviewing at Google or Microsoft, but not if you were applying for a bog standard dev role at a startup or SME.
I'm sure a lot of developers who are currently employed are put off applying elsewhere because the whole process has become so demanding and unpleasant and disrespectful.
One company I applied to for example asked to do a take-home test, maybe 2 hours. I did the test, only to be told it was the first stage of a long and gruelling process involving a further 8 hour take-home project (unpaid, of course) followed my several rounds of technical and non-technical interviews. I immediately withdrew my application. When would I have the time to do 8 hours - it was timed for some bizarre reason, so it had to be done in a single block of time - on a project? Maybe for my own projects, sure, but that's my spare time.
Interviewers and recruiters are, after all, being paid to sit there, while interviewees are - unless they're unemployed - taking precious time off to travel, maybe stay overnight in a hotel, sit through hours of gruelling interviews and tests, all for a job that may or may not offer anything much better than what they've already got. And yet the penny hasn't yet dropped that maybe your shitty process is the reason you haven't found anyone yet?
I'm not sure what the solution is, but I'm convinced that it wasn't this bad 5 or 10 years ago - maybe if you were interviewing at Google or Microsoft, but not if you were applying for a bog standard dev role at a startup or SME.
Nailed it. :)
Recruiting is now based on some unproven theories that companies utilize as if they were the 10 commandments. Written by some nontechnical MBAs.
We should unite together and form an organization that blacklists companies with incompetent hiring practices. :)
We should unite together and form an organization that blacklists companies with incompetent hiring practices. :)
oh do our own hiring company lol ;)
What could be the root cause of this change ? An oversupply of good candidates?
[deleted]
Thanks! It honestly does help, because in my current state I find myself heavily second-guessing my own value. That said, I have found the humility to be enlightening :)
[deleted]
With one of many job applications I did, I received a small coding exercise before getting to the actual interview.
It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa.
Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code.
What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code.
So you're saying that doing investigation work, finding an existing working solution and applying that solution is not a good answer for you?
Sorry but that's how I work. I find a problem; I investigate for a solution; if there is one I use it and implement it; if not then I will write one.
The moral of the story is: interviewing is fundamentally wrong and doesn't help you find a good candidate. There are millions of good solutions to one problem in programming. Asking for a solution you want to see and not a solution that solves the problem will never help. Then why don't you clone yourself and have an army of developers which work the same way and produce the same code with the same flaws over and over and over.
It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa.
Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code.
What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code.
So you're saying that doing investigation work, finding an existing working solution and applying that solution is not a good answer for you?
Sorry but that's how I work. I find a problem; I investigate for a solution; if there is one I use it and implement it; if not then I will write one.
The moral of the story is: interviewing is fundamentally wrong and doesn't help you find a good candidate. There are millions of good solutions to one problem in programming. Asking for a solution you want to see and not a solution that solves the problem will never help. Then why don't you clone yourself and have an army of developers which work the same way and produce the same code with the same flaws over and over and over.
Did you actually think they wanted a roman-numeral converter? It should be obvious that the roman-numeral converter was a proxy to see how well you could reason through solving a programming problem. Surely you knew that was what they were after. That you seem incredulous that they didn't accept your clearly low-utility response is baffling.
Now, if you were signalling to them that googling a solution is the extent of your programming ability, then perhaps you were doing them a favor.
Now, if you were signalling to them that googling a solution is the extent of your programming ability, then perhaps you were doing them a favor.
A solution is a solution. Proving that you can search for a solution and use it is a positive thing. There are loads of people who can't do even that. It wasn't like copy-paste. You still have to understand how to write the code that uses the API, you still have to get the input from the console and write the output to it.
And if I follow your trail of thought, then I hope you're not using stackoverflow when you do your job, because that means you are relying on others to solve a problem for you. Does your boss know about this?
I wonder how many times you copy-pasted anything.
And just for your information I still provided a second solution for them after they frown back the first one.
But hey, sorry if I think solving a problem doesn't mean I have to write everything from scratch.
And if I follow your trail of thought, then I hope you're not using stackoverflow when you do your job, because that means you are relying on others to solve a problem for you. Does your boss know about this?
I wonder how many times you copy-pasted anything.
And just for your information I still provided a second solution for them after they frown back the first one.
But hey, sorry if I think solving a problem doesn't mean I have to write everything from scratch.
You're in an interview, you know they're looking for signals to your programming ability. You should offer them the maximally-informative signal without having to be prodded. Sure, knowing to search for an existing solution first is an asset, but that should be more-or-less a given. If you didn't want to assume it was a given you could have just mentioned that in the real world you would simply google for an API or an existing method as you were coding up the solution to their question. It just seems counter to the entire process of interviewing to expect essentially an API call to be acceptable in that context, so your apparent expectation that it would be doesn't seem reasonable at all.
To be honest this was like 4 years ago. I thought it was a good thing to show that I can get things done in way it costs less effort and time.
I was wrong, I moved on, so did they.
If I would have a similar test today I wouldn't go down the same route, because I know what they would expect.
Maybe it was my sysadmin past talking back then. Trying to find a good existing solution for the problem.
I was wrong, I moved on, so did they.
If I would have a similar test today I wouldn't go down the same route, because I know what they would expect.
Maybe it was my sysadmin past talking back then. Trying to find a good existing solution for the problem.
Interviewing is about putting on the dance. Juggle some balls on a unicycle etc. It's a rite of passage to what may be a cool job but you have to jump through the hoops like a dolphin.
That sounds pretty cool. I hope at the end they wont try to feed me with raw fish.
And there is the part 'may be a cool job'. Sometimes that part is a lie.
Yes come to us and you will be working with the newest tech and learn new things...
Oh did we forgot to mention we use CVS, Java 1.6 and Expoler 8? You want to use something else? No can't do sweety.
And there is the part 'may be a cool job'. Sometimes that part is a lie.
Yes come to us and you will be working with the newest tech and learn new things...
Oh did we forgot to mention we use CVS, Java 1.6 and Expoler 8? You want to use something else? No can't do sweety.
I am over using the newest tech. Just want to work on interesting problems. JS fatigue etc. I'm glad I don't do web dev anymore!
Me to supposed mechanic: "Can you repair my car?"
Mechanic: gets out the yellow pages and calls a real mechanic.
Me: ok I'll hire that guy you just called
They're not hiring someone to search. They're hiring someone to code. You proved you could search but not that you could code
Mechanic: gets out the yellow pages and calls a real mechanic.
Me: ok I'll hire that guy you just called
They're not hiring someone to search. They're hiring someone to code. You proved you could search but not that you could code
Me to supposed mechanic: "Can you fix my car?"
Mechanic: "Yes, of course!" - he gets up and collects loads of bits and pieces, metal bars and stuff, then starts to hammer away to create a car part.
Me: "What the hell are you doing?"
Mechanic: "I'm building the part for your car."
Me: "Don't you have a spare or something?"
Mechanic: "Well I don't, but there are spares I could order."
Me: "Then do it man, order one."
Mechanic: "Nah, I like to build everything by myself."
Anyway, using an API doesn't mean you don't have to code.
I was wrong, I learned, next time will be different.
Mechanic: "Yes, of course!" - he gets up and collects loads of bits and pieces, metal bars and stuff, then starts to hammer away to create a car part.
Me: "What the hell are you doing?"
Mechanic: "I'm building the part for your car."
Me: "Don't you have a spare or something?"
Mechanic: "Well I don't, but there are spares I could order."
Me: "Then do it man, order one."
Mechanic: "Nah, I like to build everything by myself."
Anyway, using an API doesn't mean you don't have to code.
I was wrong, I learned, next time will be different.
I'm sure I personally have failed programming tests by doing too much (or not enough) "enterprise" programming in particular stuff that requires things like parsing a CSV file. Do you use a third party library, roll your own, just use string.split(",")? All three are good responses, personally unless the sample data has embedded quotes I've just added comments saying that I'd use a particular library[1] for this normally but I've used string.split as a quick and dirty hack.
At work we've stopped doing take away tests in part for just this reason. We do have a small pair programming test (fix some SOLID code smells in a small 10 line program) and we also don't expect folks to fix all of the problems within that code.
As a pair programming exercise you can almost walk someone through the first problem with the code (there are two big problems[2] plus four minor issues that you could find) and also you can guide the scale of the response they have to the issues (For example I might prompt them and say if you use mocking frameworks in your current job lets use that and you can talk me through how to use it)
We've had pretty good success with this and does seem to avoid some of talks a good talk but can't do developers.
[1] Getting the library onto the interviewers machine might be a really big issue their firewall might block access / maybe I can't send binaries to you due to your AV
[2] Since it's only 10 lines of code the issues are the sort of thing in the "real" world you might ignore but repeated across a code base would be a problem.
At work we've stopped doing take away tests in part for just this reason. We do have a small pair programming test (fix some SOLID code smells in a small 10 line program) and we also don't expect folks to fix all of the problems within that code.
As a pair programming exercise you can almost walk someone through the first problem with the code (there are two big problems[2] plus four minor issues that you could find) and also you can guide the scale of the response they have to the issues (For example I might prompt them and say if you use mocking frameworks in your current job lets use that and you can talk me through how to use it)
We've had pretty good success with this and does seem to avoid some of talks a good talk but can't do developers.
[1] Getting the library onto the interviewers machine might be a really big issue their firewall might block access / maybe I can't send binaries to you due to your AV
[2] Since it's only 10 lines of code the issues are the sort of thing in the "real" world you might ignore but repeated across a code base would be a problem.
What if that shop builds race cars and trophy trucks? Are you okay with the part being replaced being of higher quality and finish than the original? What about some advanced alloy that would not have been financially do-able for a manufacturer to use?
When hiring someone with "fabrication skills" into a machine shop, you certainly don't expect them to order a part during the interview when you just asked them to make a part on the lathe. Which position are you interviewing for, machinist or administrator/purchasing?
When hiring someone with "fabrication skills" into a machine shop, you certainly don't expect them to order a part during the interview when you just asked them to make a part on the lathe. Which position are you interviewing for, machinist or administrator/purchasing?
I'm going to hazard a guess that you don't have any manufacturing experience due to shibboleths: you said "fabrication" but you meant turning, not sheet-metal bending. Did I guess right?
This is a common interview tactic: trying to figure out if someone belongs to a group known to have particular skills by their choice of words or similar.
This is a common interview tactic: trying to figure out if someone belongs to a group known to have particular skills by their choice of words or similar.
Turning parts on a lathe (and machining/milling) fit in my definition of "fabrication skills". (Mechanical engineer and a few hundred hours in the machine shop, but not a full-time machinist by any means.)
The issue is many companies have NIH syndrome, sometimes for a generally good reason.
in the same circumstances I would have noted my find and copied the relevant code into my project, not because I'd do that in personal projects, but because companies only care about integrating their requirements with as few external dependencies as possible.
in the same circumstances I would have noted my find and copied the relevant code into my project, not because I'd do that in personal projects, but because companies only care about integrating their requirements with as few external dependencies as possible.
Yes, that is a problem as well. They don't want to use libraries from the outside, so they develop a lot of stuff in-house. Which will have specific requirements and getting someone up to speed takes longer then using an existing API, which is well known and used by millions of other companies and developers.
Also most of the times these in-house APIs are developed by if not one, but a handful of people. So if they leave, you are stuck with code which nobody understands and you keep on adding on top of it and breaking it in many ways.
Not to mention your developers will be stuck and get experience with code not used anywhere else. If you want to cripple their prospect to get better jobs and experience, this is the way to go.
It is a vicious cycle and it seems nobody is willing to break it.
Also most of the times these in-house APIs are developed by if not one, but a handful of people. So if they leave, you are stuck with code which nobody understands and you keep on adding on top of it and breaking it in many ways.
Not to mention your developers will be stuck and get experience with code not used anywhere else. If you want to cripple their prospect to get better jobs and experience, this is the way to go.
It is a vicious cycle and it seems nobody is willing to break it.
Interviews like this are a two-way thing. In this case, I'd pick up the vibe that this was a company cursed with NIH and withdraw my application (unless I was desperate for a job or some other overriding factor, of course).
Technical interviews (much as I hate the whiteboarding bullshit) do give some insight to the interviewee about the kind of work and codebase they'll be dealing with - like the time an interviewer told me "We're really enthusiastic about MongoDB!" - OK, thanks for the coffee, I'll see myself out....
Technical interviews (much as I hate the whiteboarding bullshit) do give some insight to the interviewee about the kind of work and codebase they'll be dealing with - like the time an interviewer told me "We're really enthusiastic about MongoDB!" - OK, thanks for the coffee, I'll see myself out....
Admittedly my situation is different than probably 95% of the HN readers that develop code. I write mostly Java code for my university job. I develop code about 30% of the time. The code I write and maintain are mostly ETL / Middleware solutions that stay in-house. I have an associate that is learning Java and will take over when I retire in 5 years. I have no one telling me what I can and can't use. My bosses expect me to make sure that the license for the libraries I use are compatible with our culture and risk profile. And most are apache 2 licenses.
Without the use of libraries I could not get my job done. I rely on Apache Camel and Apache Httpcomponents heavily. In fact I am replacing a home grown Middleware solution with one that uses Camel right this month because the homegrown solution is just not extensible. I use other libraries as well like Jdom2.
The risk in these libraries going stale exists but is low enough to outweigh the risk of me writing crappy code because my expertise is not that great in writing middleware, xml parsers and the like. My applications work as intended. My management is happy. I am productive in their eyes.
I don't have a NIH attitude.
Edit: added this statement.
At 62 years old I think I am glad I don't foresee the need to change jobs and go through the "modern" developer interview process. I feel for those that have to do this dance.
Without the use of libraries I could not get my job done. I rely on Apache Camel and Apache Httpcomponents heavily. In fact I am replacing a home grown Middleware solution with one that uses Camel right this month because the homegrown solution is just not extensible. I use other libraries as well like Jdom2.
The risk in these libraries going stale exists but is low enough to outweigh the risk of me writing crappy code because my expertise is not that great in writing middleware, xml parsers and the like. My applications work as intended. My management is happy. I am productive in their eyes.
I don't have a NIH attitude.
Edit: added this statement.
At 62 years old I think I am glad I don't foresee the need to change jobs and go through the "modern" developer interview process. I feel for those that have to do this dance.
> What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code.
This could have been poor communication on their part, or it could have been a test of your communication. Was there an opportunity to ask about requirements before coding up a solution?
When I interview (usually in person), I encourage candidates to ask questions. I'd certainly never ding anyone for asking "can I use <library X / programming language Y / tool Z>?" but my answer might be no.
I'm not a total jerk. When I see candidates make a bad assumption, I'll try to correct them, but depending on the assumption and their communication style that might take 10+ minutes (of 45). I don't want interviews to be about speed, but losing that much time (maybe more than once!) hurts for sure. I'm probably thinking of another candidate who asked the right questions, described an efficient algorithm and its time/memory complexity, implemented it, debugged it, and moved on to something else.
Ideally, interviews are a microcosm of the job. And at least in concept, that principle holds here: on the job, people often rush the requirements and design work, which wastes much more time than it saves and/or causes the project to fail.
This could have been poor communication on their part, or it could have been a test of your communication. Was there an opportunity to ask about requirements before coding up a solution?
When I interview (usually in person), I encourage candidates to ask questions. I'd certainly never ding anyone for asking "can I use <library X / programming language Y / tool Z>?" but my answer might be no.
I'm not a total jerk. When I see candidates make a bad assumption, I'll try to correct them, but depending on the assumption and their communication style that might take 10+ minutes (of 45). I don't want interviews to be about speed, but losing that much time (maybe more than once!) hurts for sure. I'm probably thinking of another candidate who asked the right questions, described an efficient algorithm and its time/memory complexity, implemented it, debugged it, and moved on to something else.
Ideally, interviews are a microcosm of the job. And at least in concept, that principle holds here: on the job, people often rush the requirements and design work, which wastes much more time than it saves and/or causes the project to fail.
I disagree. You need to be able to find existing working solutions and use them, sure.
But you also need to be able to do this kind of thing yourself if you can't find an existing solution, because that also happens all the time. It's that ability that they were testing. That's perfectly valid.
They should however have told you that before the test.
But you also need to be able to do this kind of thing yourself if you can't find an existing solution, because that also happens all the time. It's that ability that they were testing. That's perfectly valid.
They should however have told you that before the test.
> They should however have told you that before the test.
He should have been able to figure that out before the test. It was a test of his problem solving abilities, not his Google-fu.
He should have been able to figure that out before the test. It was a test of his problem solving abilities, not his Google-fu.
Goggle-fu - I like that. It should go on my resume.
Still as I wrote on one of the other replies. Yes, you use an API, but you still provide evidence of coding, because you have to write the application, which calls the API.
It was a small piece of code, which took a number from the command line and spat out in the other format. You still have to know everything else to get it to work. Reading input, writing output, etc...
Still as I wrote on one of the other replies. Yes, you use an API, but you still provide evidence of coding, because you have to write the application, which calls the API.
It was a small piece of code, which took a number from the command line and spat out in the other format. You still have to know everything else to get it to work. Reading input, writing output, etc...
He did solve the problem.
Only in the most literal sense. The developer who thinks that their job only consists of translating very precise literal instructions to another set of precise instructions will very soon be out of work. That is a thing that is easy to automate. The developer's value lays in being able to translate vague and very context dependent instructions to precise instructions. This guy clearly failed at this.
Yes, they should have been more specific.
Problem solving skills go a long way especially in programming.
But then the question is how far should you go down the rabbit-hole.
For example, how many variables can someone use? How optimized should the code be, regarding memory and speed? Are you looking at the code to be understandable? Should I use comments? Should I use for or while?
Problem solving skills go a long way especially in programming.
But then the question is how far should you go down the rabbit-hole.
For example, how many variables can someone use? How optimized should the code be, regarding memory and speed? Are you looking at the code to be understandable? Should I use comments? Should I use for or while?
fwiw, I think there are reasonable ways to approach these kinds of issues that will work with any interviewer you'd actually want to work with:
> For example, how many variables can someone use?
I've never heard of an interviewer explicitly limiting this, but if you have enough variables that you're asking, it might be a sign you've missed a more elegant solution to the problem...
> How optimized should the code be, regarding memory and speed?
Don't spend a lot of time on something before you know if it's what they want. You shouldn't go all the way through debugging the naive solution before you know if they're looking for something optimal; you shouldn't look for a very complex but theoretically optimal solution if they looking for fizz/buzz level of complexity.
To make it more concrete, many of my candidates just say something like "I could put everything into an array, sort it, and print it", maybe even adding "in O(n) memory and O(n log n) time". When that happens, I write down "quickly got naive solution", ask "what if we don't have O(n) memory?", and wait for them to (or help them) come up with something else. That's great from my perspective, as is asking me explicitly how much RAM is available / how large the input may be / if I want an optimal solution or an easy-to-understand one.
> Are you looking at the code to be understandable? Should I use comments?
In general, they're probably looking for it to be understandable, but they should know if you're coding under time constraints on a whiteboard that it's hard to revise quickly, that you can't fit a lot of stuff there, and that it's a lot faster to say aloud what you might otherwise put in a comment. If they don't make allowances for that, you'd probably hate working with them anyway...
Consequently, understandability might be more be about picking a meaningful variable name or thinking for a moment if you actually need to special-case some path before adding that extra if statement. Maybe drawing a quick diagram of your data structure.
And if you have extra time (a judgement call: maybe if you have a working solution, they aren't trying to move you on to another problem, you have don't have anything more to ask them), you could refine a bit.
> Should I use for or while?
They should know you haven't had the chance to read their internal style guide. They shouldn't care about this.
I also think they should give you significant leeway for minor syntax errors (saying, missing a ";"). There's a line somewhere between that kind of nitpicking and needing to see that you actually understand the language's syntax. It differs a little by interviewer. If you're anywhere close to the line, they should point out what's bothering them (perhaps saying "the compiler says ...") and give you an opportunity to correct it. If they don't, again they're probably kind of a jerk.
> For example, how many variables can someone use?
I've never heard of an interviewer explicitly limiting this, but if you have enough variables that you're asking, it might be a sign you've missed a more elegant solution to the problem...
> How optimized should the code be, regarding memory and speed?
Don't spend a lot of time on something before you know if it's what they want. You shouldn't go all the way through debugging the naive solution before you know if they're looking for something optimal; you shouldn't look for a very complex but theoretically optimal solution if they looking for fizz/buzz level of complexity.
To make it more concrete, many of my candidates just say something like "I could put everything into an array, sort it, and print it", maybe even adding "in O(n) memory and O(n log n) time". When that happens, I write down "quickly got naive solution", ask "what if we don't have O(n) memory?", and wait for them to (or help them) come up with something else. That's great from my perspective, as is asking me explicitly how much RAM is available / how large the input may be / if I want an optimal solution or an easy-to-understand one.
> Are you looking at the code to be understandable? Should I use comments?
In general, they're probably looking for it to be understandable, but they should know if you're coding under time constraints on a whiteboard that it's hard to revise quickly, that you can't fit a lot of stuff there, and that it's a lot faster to say aloud what you might otherwise put in a comment. If they don't make allowances for that, you'd probably hate working with them anyway...
Consequently, understandability might be more be about picking a meaningful variable name or thinking for a moment if you actually need to special-case some path before adding that extra if statement. Maybe drawing a quick diagram of your data structure.
And if you have extra time (a judgement call: maybe if you have a working solution, they aren't trying to move you on to another problem, you have don't have anything more to ask them), you could refine a bit.
> Should I use for or while?
They should know you haven't had the chance to read their internal style guide. They shouldn't care about this.
I also think they should give you significant leeway for minor syntax errors (saying, missing a ";"). There's a line somewhere between that kind of nitpicking and needing to see that you actually understand the language's syntax. It differs a little by interviewer. If you're anywhere close to the line, they should point out what's bothering them (perhaps saying "the compiler says ...") and give you an opportunity to correct it. If they don't, again they're probably kind of a jerk.
I agree with all you are saying so much that some months ago I had to write about it: https://www.linkedin.com/pulse/william-versus-technical-inte...
The TL;DR of my (short, truth be told) blog post is the moral of your story.
The TL;DR of my (short, truth be told) blog post is the moral of your story.
Thank god, it's not just me then.
I had an interview where the guy was staring at me like I was interrogated. I had to solve a problem of concatenating to arrays of integers and putting them in ascending order.
I was literally frozen and couldn't think and stood there like an idiot for 5 minutes whilst the guys was just staring at me, not making a sound.
I don't have to tell you I felt destroyed after that. I felt I was a good for nothing idiot and should go shovel dirt then develop software. I still shiver a bit when I think back.
The other things that I hate are the always reoccurring questions. Like what's an array; what's a map; what are the differences; etc...
Come on I've been developing for quite a while now. I've been a sysadmin before that. I'm working in IT for more then 10 years now. Do you really feel the need asking all these things?
I had an interview where the guy was staring at me like I was interrogated. I had to solve a problem of concatenating to arrays of integers and putting them in ascending order.
I was literally frozen and couldn't think and stood there like an idiot for 5 minutes whilst the guys was just staring at me, not making a sound.
I don't have to tell you I felt destroyed after that. I felt I was a good for nothing idiot and should go shovel dirt then develop software. I still shiver a bit when I think back.
The other things that I hate are the always reoccurring questions. Like what's an array; what's a map; what are the differences; etc...
Come on I've been developing for quite a while now. I've been a sysadmin before that. I'm working in IT for more then 10 years now. Do you really feel the need asking all these things?
You have to think about what they are trying to test. If it's "Do they know how to quickly find an answer to a known problem?", then your route is correct.
If it's "Could they take a problem that hasn't been solved before and solve it themselves?", then you're not really demonstrating that.
Unless I'm told otherwise, I would assume that a coding challenge would be more of the latter.
Of course, it's not how you'd solve it in real life. But that's like saying you should be allowed a calculator in a mental maths exam because you'd never try to to 27324/623 in your head these days.
If it's "Could they take a problem that hasn't been solved before and solve it themselves?", then you're not really demonstrating that.
Unless I'm told otherwise, I would assume that a coding challenge would be more of the latter.
Of course, it's not how you'd solve it in real life. But that's like saying you should be allowed a calculator in a mental maths exam because you'd never try to to 27324/623 in your head these days.
I was thinking, but clearly my trail of thought wasn't the good one.
Anyway, lessons learned. I hope...
[deleted]
You really didn't know what they wanted? You think they wanted you to find a library that did it?
He's a developer, not a telepath.
In tests like this you make it clear what's allowed - "use the standard library, no external dependencies" etc. Because in a normal working situation, his solution is perfectly valid.
If I were interviewing him it certainly wouldn't be a dealbreaker. I'd probably want to discuss more about pros and cons of in-house vs using libraries, because you tend to find out more about the skills and qualities of a developer from human conversation than scribbling on a whiteboard.
In tests like this you make it clear what's allowed - "use the standard library, no external dependencies" etc. Because in a normal working situation, his solution is perfectly valid.
If I were interviewing him it certainly wouldn't be a dealbreaker. I'd probably want to discuss more about pros and cons of in-house vs using libraries, because you tend to find out more about the skills and qualities of a developer from human conversation than scribbling on a whiteboard.
In an interview you are trying to show that you understand the problem. Not just get the right answer.
How do I know that? What is the interviewer looking for?
Maybe in company A they are looking for developers who come up with a solution on their own and don't rely on external libraries or Google. Maybe company B don't like developers reinventing wheels and prefer they at least research prior art first.
I don't know what kind of culture your company has, but at the very least out of courtesy you can signal what the requirements are in your test.
Maybe in company A they are looking for developers who come up with a solution on their own and don't rely on external libraries or Google. Maybe company B don't like developers reinventing wheels and prefer they at least research prior art first.
I don't know what kind of culture your company has, but at the very least out of courtesy you can signal what the requirements are in your test.
Alas, there are interviews where the correct solution is using a library and writing your own is wrong, because it shows a NIH attitude.
One has to ask, but then the mere act of asking might also annoy some interviewers.
One has to ask, but then the mere act of asking might also annoy some interviewers.
Yes, call me stupid.
I thought showing resilience by searching for an existing solution and implementing it, instead of reinventing the wheel, will give them a good impression. Clearly I was wrong.
But, when you come across a problem, what is the first thing you do? Try to find a solution and use that, or start from scratch every time? This costs money, time and manpower. Having someone who can solve a problem the fastest way possible without compromising the quality by using a known API which is used and tested by millions of others is the most effective way.
In my book it is a good solution. Believe me I worked with people who couldn't even do that and they are developers.
I thought showing resilience by searching for an existing solution and implementing it, instead of reinventing the wheel, will give them a good impression. Clearly I was wrong.
But, when you come across a problem, what is the first thing you do? Try to find a solution and use that, or start from scratch every time? This costs money, time and manpower. Having someone who can solve a problem the fastest way possible without compromising the quality by using a known API which is used and tested by millions of others is the most effective way.
In my book it is a good solution. Believe me I worked with people who couldn't even do that and they are developers.
As long as they didn't state you can't use external libs it IS a good solution.
Their response lets their team dynamic and environment shine through. They came across an unexpected but valid solution and instead of accepting their question was beaten within the rules they rejected it. I'd wager they didn't fix the wording of the question afterwords either.
Their response lets their team dynamic and environment shine through. They came across an unexpected but valid solution and instead of accepting their question was beaten within the rules they rejected it. I'd wager they didn't fix the wording of the question afterwords either.
Don't call it "stupid".
Reading people is a skill like any other, that must be learned like any other. Most people get lots of practice when young, but not getting this practice does not make you "stupid", it makes you lacking on a specific skill.
Reading people is a skill like any other, that must be learned like any other. Most people get lots of practice when young, but not getting this practice does not make you "stupid", it makes you lacking on a specific skill.
No, they clearly wanted to see you write code. They didn't want to see how well you could download a library. That's why they gave you the test in the first place.
Interviewing is hard.. I always hated the idea of judging someone based on a 1 hour chat (I was always the tech interviewer or first screen). I also hate that interviewers aim to challenge the candidate with hard technical questions that they might have or might have not had experience with.
So what I do is ask the candidate to tell me about their experience, past projects, and also frankly ask them "what are you most comfortable talking about" and continue diving from here. When they talk about a topic they claim to be experienced with, you can really see what they worth. When someone can't fluently discuss something his claims to be knowledgeable in (yes that happened), that's a bad sign.
So what I do is ask the candidate to tell me about their experience, past projects, and also frankly ask them "what are you most comfortable talking about" and continue diving from here. When they talk about a topic they claim to be experienced with, you can really see what they worth. When someone can't fluently discuss something his claims to be knowledgeable in (yes that happened), that's a bad sign.
When I interview, I try to find out what the person is good at. Everyone who comes to interview is good at something (even if it's just good at getting interviews).
Sometimes their skill-set overlaps with what we need, sometimes it doesn't. But the focus is figuring out what they are good at, rather than an abstract test.
Sometimes their skill-set overlaps with what we need, sometimes it doesn't. But the focus is figuring out what they are good at, rather than an abstract test.
That companies now insist on running the Google-style whiteboard-algorithms-coding-skill-testing-question type of interview tells me that there is no shortage of programmers to hire.
Because as far as I understand it we use that process at Google because we can afford a lot of false negatives because we are inundated with a lot of resumes.
Smaller companies and startups surely are not, and finding candidates must be harder. Unless the job market is saturated with candidates.
Many perfectly good, maybe even excellent, candidates will just falter and fail in a whiteboard coding interview. I do, and many people I've interviewed have. Coding on the spot using pen and paper sucks. I think by coding. Give me Emacs and a REPL, and let me go away and think for a bit, and I'll produce something way better.
Smaller companies should think twice before trying to emulate Google, Facebook, Microsoft, etc. In a small company social cohesion is very important, so rapport and personality are very important, cultural factors are important, experience in dealing with similar types of environments, familiarity with technical stack.
That's how I used to interview before coming to Google, anyways. It seems like the industry has turned in very large part to this hostile "prove yourself" methodology...
Because as far as I understand it we use that process at Google because we can afford a lot of false negatives because we are inundated with a lot of resumes.
Smaller companies and startups surely are not, and finding candidates must be harder. Unless the job market is saturated with candidates.
Many perfectly good, maybe even excellent, candidates will just falter and fail in a whiteboard coding interview. I do, and many people I've interviewed have. Coding on the spot using pen and paper sucks. I think by coding. Give me Emacs and a REPL, and let me go away and think for a bit, and I'll produce something way better.
Smaller companies should think twice before trying to emulate Google, Facebook, Microsoft, etc. In a small company social cohesion is very important, so rapport and personality are very important, cultural factors are important, experience in dealing with similar types of environments, familiarity with technical stack.
That's how I used to interview before coming to Google, anyways. It seems like the industry has turned in very large part to this hostile "prove yourself" methodology...
I would gather if companies like the ones you mentioned adopted new ways of interviewing, or at least randomized it in way that it couldn't be easily cloned, other companies would follow suit or adopt their own style. The challenge is that every companies wants the "best" engineers and believes they deserve it... So in their minds, they do what they think the "best" do.
I have heard more than a handful of CTO's and companies sling this expression around as if using this phrase put them in company with the likes of Elen Musk. It's a joke to me really. I look forward to the day one of these guys says, hey, lets be original.
Contrary to your point, I believe there is a shortage of qualified programmers... or at least senior ones that can solve hard problems independently. Smaller companies need devs that can solve problems independently, with minimal oversight. Copying Google and Facebook is what they think the path is to get there.
I have heard more than a handful of CTO's and companies sling this expression around as if using this phrase put them in company with the likes of Elen Musk. It's a joke to me really. I look forward to the day one of these guys says, hey, lets be original.
Contrary to your point, I believe there is a shortage of qualified programmers... or at least senior ones that can solve hard problems independently. Smaller companies need devs that can solve problems independently, with minimal oversight. Copying Google and Facebook is what they think the path is to get there.
If there was really a shortage of qualified programmers, companies would be working to improve their interview practices.
From this thread, and my own experience, things are going the opposite way. Companies appear to be able to afford to use more and more arbitrary filters. Which indicates an excess supply of great candidates!
From this thread, and my own experience, things are going the opposite way. Companies appear to be able to afford to use more and more arbitrary filters. Which indicates an excess supply of great candidates!
Every time I read one of these articles, the author invariably ends up recommending solutions that have glaring holes, just as large as the ones he spends the entire time attacking.
In this case, the author begins the entire essay by telling us that we shouldn't hire on the basis of what someone already knows. One of his first solutions later presented is the exact opposite of this: find out about their level of existing knowledge, regarding specific technologies and frameworks.
He then goes on to rile against "team fit," because of its potential for bias. But his entire solution basically comes down to behavioral interviews, which are notorious for how bias-prone they are.
His solution basically tells us that we shouldn't consider fancy degrees or companies. And yet, in the span of 30-60 minutes, we should be able to form accurate judgement on how much talent and drive someone has, and what they will be able to do in the next 3 years? Sorry, but unless you're the Steve Jobs of character reading, there's no way you can do the above accurately. Everyone lies on interviews. They pad their accomplishments, and inflate what they have previously done. The only thing you achieve through such a discussion, is figuring out how good a talker someone is.
The following article sums up everything that is wrong with almost every "Hiring is Broken" critique ever. Every single approach people have ever thought up, is broken in so many ways, as ably demonstrated by many others. Unless someone has hard data to show why one technique's pros outweigh its cons, such discussions are almost always pointless.
http://www.thecaucus.net/#/content/caucus/tech_blog/684
In this case, the author begins the entire essay by telling us that we shouldn't hire on the basis of what someone already knows. One of his first solutions later presented is the exact opposite of this: find out about their level of existing knowledge, regarding specific technologies and frameworks.
He then goes on to rile against "team fit," because of its potential for bias. But his entire solution basically comes down to behavioral interviews, which are notorious for how bias-prone they are.
His solution basically tells us that we shouldn't consider fancy degrees or companies. And yet, in the span of 30-60 minutes, we should be able to form accurate judgement on how much talent and drive someone has, and what they will be able to do in the next 3 years? Sorry, but unless you're the Steve Jobs of character reading, there's no way you can do the above accurately. Everyone lies on interviews. They pad their accomplishments, and inflate what they have previously done. The only thing you achieve through such a discussion, is figuring out how good a talker someone is.
The following article sums up everything that is wrong with almost every "Hiring is Broken" critique ever. Every single approach people have ever thought up, is broken in so many ways, as ably demonstrated by many others. Unless someone has hard data to show why one technique's pros outweigh its cons, such discussions are almost always pointless.
http://www.thecaucus.net/#/content/caucus/tech_blog/684
Over the years and across 100's of technical interviews, I've found that I get the best results from asking smaller numbers of easier problem-solving-with-code questions that require the candidate to demonstrate basic skills. I'm the guy who makes sure that the candidate can clearly get over a low bar.
I do this because the candidate pool is swimming with people with great-looking degrees and long resumes and fine references who can talk all day long about computer programming but who simply cannot program a digital computer.
So I ask a 5-minute easy warm-up question and then a 40-minute harder problem. I pace things slowly and give them all the time that they need. I happily answer any questions they may have about the problems, which can all be stated clearly in short sentences. I do not care what programming language they use or whether their syntax would compile or how descriptive their variable names are.
Essentially, I'm trying to not generate a "false negative" result. If you can't do my easy stuff, I really don't want to work with you. If you're a great candidate, you'll have fun with this and take it away in interesting directions.
(Sample easy question: Given two closed intervals [a,b] and [c,d], determine whether they overlap.)
I do this because the candidate pool is swimming with people with great-looking degrees and long resumes and fine references who can talk all day long about computer programming but who simply cannot program a digital computer.
So I ask a 5-minute easy warm-up question and then a 40-minute harder problem. I pace things slowly and give them all the time that they need. I happily answer any questions they may have about the problems, which can all be stated clearly in short sentences. I do not care what programming language they use or whether their syntax would compile or how descriptive their variable names are.
Essentially, I'm trying to not generate a "false negative" result. If you can't do my easy stuff, I really don't want to work with you. If you're a great candidate, you'll have fun with this and take it away in interesting directions.
(Sample easy question: Given two closed intervals [a,b] and [c,d], determine whether they overlap.)
[Disclaimer: I run http://Interviewkickstart.com, which helps candidates suck less at technical interviewing.]
I have conducted countless technical interviews in my lifetime. I agree with the author; it's very difficult to actually become a good interviewer. The skill to judge someone's life and career of several years in 30 to 60 minutes is not something that comes easily. Alas, it's all too assumed to be easy.
When you start, for quite some interviews, you are very likely on either extreme viz. either too strict or too lenient. It takes a while to calibrate your standard, and not give in to an extreme. And that too, only if you introspect, or when someone draws your attention to your interview results.
Many companies don't have a culture which values interviewing as a skill. Rarely if so, I come across a company which has a process of shadowing and reverse-shadowing in an interview, which they take seriously. It is viewed as a cost center, when it's actually a profit-center when done right. And due to my business, I have come across plenty of them. At least in the valley.
I have conducted countless technical interviews in my lifetime. I agree with the author; it's very difficult to actually become a good interviewer. The skill to judge someone's life and career of several years in 30 to 60 minutes is not something that comes easily. Alas, it's all too assumed to be easy.
When you start, for quite some interviews, you are very likely on either extreme viz. either too strict or too lenient. It takes a while to calibrate your standard, and not give in to an extreme. And that too, only if you introspect, or when someone draws your attention to your interview results.
Many companies don't have a culture which values interviewing as a skill. Rarely if so, I come across a company which has a process of shadowing and reverse-shadowing in an interview, which they take seriously. It is viewed as a cost center, when it's actually a profit-center when done right. And due to my business, I have come across plenty of them. At least in the valley.
Oh man, I thought they were on to me, but no, it's for the givers of technical interviews. Phew.
I chuckled :)
My optimal hiring process:
1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume.
2. Phone screen...ask them simple technical and project questions directly from their resume. They wrote it so they should know it. Generally, bullshitters are exposed right away. Time investment: 20-30 mins
3. Take home project. A somewhat simple but non-trivial project like: Write an autocomplete search script using a large text document as your dictionary. This will test their understanding of algos and software engineering best practices. Time investment: 10 mins to review the code
4. They talk with 3-4 other engineers. Those engineers now have a simple project to compare candidates and to question the candidate with. "Why did you choose this algo?", "How did you break down this problem?". Each engineer can ask whatever they want. Time investment: 30 mins.
5. Final engineering huddle. Compare candidates, pros and cons. Gut feelings. Etc. Time investment: 30 mins.
The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code?
The project also spares the rest of the team from wasting time interviewing non-serious candidates.
1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume.
2. Phone screen...ask them simple technical and project questions directly from their resume. They wrote it so they should know it. Generally, bullshitters are exposed right away. Time investment: 20-30 mins
3. Take home project. A somewhat simple but non-trivial project like: Write an autocomplete search script using a large text document as your dictionary. This will test their understanding of algos and software engineering best practices. Time investment: 10 mins to review the code
4. They talk with 3-4 other engineers. Those engineers now have a simple project to compare candidates and to question the candidate with. "Why did you choose this algo?", "How did you break down this problem?". Each engineer can ask whatever they want. Time investment: 30 mins.
5. Final engineering huddle. Compare candidates, pros and cons. Gut feelings. Etc. Time investment: 30 mins.
The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code?
The project also spares the rest of the team from wasting time interviewing non-serious candidates.
> Time investment: 10 mins to review the code
This is what really irks me about take home exercises. The candidate spends 2-4 hours (or 12 and say they did it in 2) and the interviewer has no real commitment to reading and understanding it. 10 minutes to review the code? I would expect a video call where we go over the code together.
All interviewing I do, I do while talking to them and give them ample time to explain it back to me.
The candidate is investing their time. You should have enough respect to invest your time too.
This is what really irks me about take home exercises. The candidate spends 2-4 hours (or 12 and say they did it in 2) and the interviewer has no real commitment to reading and understanding it. 10 minutes to review the code? I would expect a video call where we go over the code together.
All interviewing I do, I do while talking to them and give them ample time to explain it back to me.
The candidate is investing their time. You should have enough respect to invest your time too.
> This is what really irks me about take home exercises.
The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.
> I would expect a video call where we go over the code together.
Thats what the next step is for.
The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.
> I would expect a video call where we go over the code together.
Thats what the next step is for.
> Time investment: 10 mins to review the code
I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code?
> The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code?
Honestly, you don't get to see much if that person has a day job.
You don't know who wrote it, if they had a friend review it, if they spent two or twenty hours on the project. You don't know anything about them by reading this project.
If it is shit, yes, you probably shouldn't hire them. But if it is good code...
1) The user might be doing something your devs don't understand, because they are bad devs, not because they suck.
2) "Good code" is fairly subjective. I've written some pretty good code and been shot down for "not using a graphing database."
I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code?
> The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code?
Honestly, you don't get to see much if that person has a day job.
You don't know who wrote it, if they had a friend review it, if they spent two or twenty hours on the project. You don't know anything about them by reading this project.
If it is shit, yes, you probably shouldn't hire them. But if it is good code...
1) The user might be doing something your devs don't understand, because they are bad devs, not because they suck.
2) "Good code" is fairly subjective. I've written some pretty good code and been shot down for "not using a graphing database."
> I never think this is fair.
The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.
> You don't know anything about them by reading this project.
You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.
> You don't know anything about them by reading this project.
You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
> The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.
Mostly, you're determining who had more time to spend on the project.
> You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
You're adding another thing to rule candidates out but not in. The problem with exclusion is it becomes more and more likely to rule out good candidates.
Mostly, you're determining who had more time to spend on the project.
> You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
You're adding another thing to rule candidates out but not in. The problem with exclusion is it becomes more and more likely to rule out good candidates.
> Don't hire for a fancy degree.
There are some companied coming to my college for hiring. The first criteria they put was 70% aggregate marks (60% for some companies).
I have seen people who doesn’t know how to write even a small program getting hired, while people with good programming skills are not even eligible to attend the interview.
Going through 200-300 candidates in an interview might be a tedious job, I am not sure. What other choice do they have?
There are some companied coming to my college for hiring. The first criteria they put was 70% aggregate marks (60% for some companies).
I have seen people who doesn’t know how to write even a small program getting hired, while people with good programming skills are not even eligible to attend the interview.
Going through 200-300 candidates in an interview might be a tedious job, I am not sure. What other choice do they have?
Had a coworker from a university, didn't even know how to write a while loop.
He didn't last long to say the least.
Of course we will never know, if he could have been a good programmer or not, but it was baffling to see people fresh out of uni with zero knowledge.
He didn't last long to say the least.
Of course we will never know, if he could have been a good programmer or not, but it was baffling to see people fresh out of uni with zero knowledge.
I think the idea is that the "smart" person will be able to learn what they need to on the job quicker. The person with lower grades may be a better developer but right now of school I think most employees are hiring based on potential and culture fit vs actually development ability.
The whole hiring process is a nightmare for both parties.
Two things I've learned about hiring / interviews: it's both very difficult and imprecise.
Process is more like dating than laboratory science; a race to establish rapport (a combination of comfort and trust). To get hired you must sufficiently possess an arbitrary blend of credentials and testing/interview performance.
Whatever it takes to make the hiring manager comfortable and trusting. Some want 10x-ers only, are soothed by strong technical chops/coding test performance, others select for culture and ability to learn. YMMV as selection criteria based on job description, sector, company stage, weather/etc.
This is why personal referrals are so powerful: trust is established MUCH faster, other flaws will be overlooked.
Two things I've learned about hiring / interviews: it's both very difficult and imprecise.
Process is more like dating than laboratory science; a race to establish rapport (a combination of comfort and trust). To get hired you must sufficiently possess an arbitrary blend of credentials and testing/interview performance.
Whatever it takes to make the hiring manager comfortable and trusting. Some want 10x-ers only, are soothed by strong technical chops/coding test performance, others select for culture and ability to learn. YMMV as selection criteria based on job description, sector, company stage, weather/etc.
This is why personal referrals are so powerful: trust is established MUCH faster, other flaws will be overlooked.
The problem with his interviews is that it's even more easily gamed. It doesn't really take a genius to go through their employment history and memorize blurbs that show learning technologies, applying it successfully while being humble and nice for one day.
If an interview like that can be gamed by "memorizing blurbs" then it wasn't done correctly. A properly conducted interview will see the interviewer tugging at threads to go deeper. At some point they will crack because memorization won't be enough. Unless of course they are anpathological liar, but those are rare enough that I would ignore the posssibility at the interview stage.
You're right, I exaggerated but I don't think this is a hard game. People spend several months right now on studying interviews. The topics are wide and scope enormous, hence so many complaints; some companies test you on languages, others on algorithms, data structures, dynamic programming, bit manipulations, SQL queries, scalability, unix internals, I could go on and on. On the other hand, there's only so many paths these past history conversations can go, and you know where they can poke at.
>while being humble and nice for one day
Employers need to screen for this more. So many horrible people making it into workplaces and ruining work cultures.
Employers need to screen for this more. So many horrible people making it into workplaces and ruining work cultures.
Some people are just bad at giving interviews. If someone is so bad at interviewing they will eliminate a candidate because they slipped up a little with a programming teaser, they're still going to be bad at interviewing if they try another technique.
I'm completely happy doing programming puzzles in interviews myself as I've worked with people that claim to be experts in something when they aren't and some people exaggerate to the point of lying on CVs. As long as you don't penalise a candidate too much for not getting perfect answers I don't see the issue.
I'm completely happy doing programming puzzles in interviews myself as I've worked with people that claim to be experts in something when they aren't and some people exaggerate to the point of lying on CVs. As long as you don't penalise a candidate too much for not getting perfect answers I don't see the issue.
My fav way of interviewing and being interviewed is a quick assignment (nothing major like some companies want you to build an api, crud UI to drive it and then push it out to heroku for them to look at) - either at home or just leave the candidate alone in the conf room for an hour.
After that if they pass - few questions about their code, maybe drill down into some areas depending on the answers etc.
Alternatively, if someone has a project on their github profile using the tech you're looking for - few questions about that project can typically give you a go/no-go right away.
After that if they pass - few questions about their code, maybe drill down into some areas depending on the answers etc.
Alternatively, if someone has a project on their github profile using the tech you're looking for - few questions about that project can typically give you a go/no-go right away.
A lot of people are saying that technical interviews are not good because some people are not good at them but they are indeed good software developers.
Other people are saying that is impossible to judge someone in a few hours of technical interviews/exercises.
I agree with both, but what's a better alternative? How to you minimise the risk of taking hiring a bad developer? At least, it is my belief that the technical interviews minimise the risk which is far better that ending up hiring someone who is not technically strong.
Other people are saying that is impossible to judge someone in a few hours of technical interviews/exercises.
I agree with both, but what's a better alternative? How to you minimise the risk of taking hiring a bad developer? At least, it is my belief that the technical interviews minimise the risk which is far better that ending up hiring someone who is not technically strong.
What I do is ask them about previous projects. 1. What was your favorite project and why? Explain. 2. What was your least favorite project and why? Explain.
I can get a good idea of the person through those two simple questions. I throw a few simple technical questions like: What is a primary key? What is a foreign key? What is inheritance? What's the difference between a function and a procedure (Delphi days). Questions that anyone should be able to answer just by writing code.
I can get a good idea of the person through those two simple questions. I throw a few simple technical questions like: What is a primary key? What is a foreign key? What is inheritance? What's the difference between a function and a procedure (Delphi days). Questions that anyone should be able to answer just by writing code.
I think the problem is not whether you can design a 100% awesome tech interview process that will have high precision and recall. That is known. Spend enough time with the person basically to judge him rather than asking few questions to taking him to whiteboard.
But then most companies wont be able to show profits if the start spending that much resources on each candidate. Hence they optimize their processes only for precision and not for recall. That explains why a lot of people fail first few times.
But then most companies wont be able to show profits if the start spending that much resources on each candidate. Hence they optimize their processes only for precision and not for recall. That explains why a lot of people fail first few times.
I had actually written a post a few months back[1] that bares a remarkable similarity to this one. It's encouraging to see others have, and are, coming to similar conclusions. Remember that each person who learns these methods now improves a round of interviews in the future.
1: https://blog.benroux.me/4-steps-to-making-your-interview-suc...
1: https://blog.benroux.me/4-steps-to-making-your-interview-suc...
Too often, the team fit is put aside and you end up with people who does not play well with others in your team. Technical interview can be ok but I would not put too much details into it. I have been in technical interviews where people were asking questions about obscure API calls and they were expecting applicants to come up with questions that were not relevant to the job.
I totally agree with most of the points Laurie made, specially I hate the new trend of asking people for an online coding test before even talking to a person. I have worked on a ton of complex problems in life and in real world you never have to write 4 complex tree traversal algorithms using the best possible approach in under 60 minutes, never!
Someone in a similar HN thread once recommended the book "Hiring With Your Head" and then sorta did a mic drop.
I must do the same. Buy the book and implement it. It directly deals with so many issues mentioned here (great dev but crap at silly tests, great dev but a bad interviewer, etc).
I must do the same. Buy the book and implement it. It directly deals with so many issues mentioned here (great dev but crap at silly tests, great dev but a bad interviewer, etc).
[deleted]
so I seem to be alone in this.
although whiteboarding is not representative of Industry workflow, I feel that it can be used as a metric for communication. everybody knows that it's coming, and everybody knows how to practice it. if you perform poorly on whiteboarding that means you didn't practice it. it's a learned skill it's not a natural thing.
anybody I've met who complains about having trouble in whiteboarding has also never seriously practiced it.
although whiteboarding is not representative of Industry workflow, I feel that it can be used as a metric for communication. everybody knows that it's coming, and everybody knows how to practice it. if you perform poorly on whiteboarding that means you didn't practice it. it's a learned skill it's not a natural thing.
anybody I've met who complains about having trouble in whiteboarding has also never seriously practiced it.
Apart of job-related questions and general-thinking problems, tech interviews are still mostly a poor Tinder experience.
[deleted]
lol I had to do the fizzbuzz test a few weeks ago
the modulo operator was obvious to me and after the interviewer kept adding conditions to the problem, they then asked me why I didn't concatenate strings instead of my approach of returning the string in each conditional statement
so fellow engineers, without having the telepathic skills I possessed that allowed me to know exactly what traits the interviewers were looking for, would you have:
a) erased your entire correct solution to write a more efficient solution, not knowing the time constraints for this problem
b) created the most efficient and scalable fizzbuzz solution known to man at the beginning? in the 15 minutes provided
c) laughed in the interviewer's faces since it was obvious the question was irrelevant to how you would solve problems for the company on a day to day basis?
d) other
the modulo operator was obvious to me and after the interviewer kept adding conditions to the problem, they then asked me why I didn't concatenate strings instead of my approach of returning the string in each conditional statement
so fellow engineers, without having the telepathic skills I possessed that allowed me to know exactly what traits the interviewers were looking for, would you have:
a) erased your entire correct solution to write a more efficient solution, not knowing the time constraints for this problem
b) created the most efficient and scalable fizzbuzz solution known to man at the beginning? in the 15 minutes provided
c) laughed in the interviewer's faces since it was obvious the question was irrelevant to how you would solve problems for the company on a day to day basis?
d) other
I want this guy to interview me. Even if there is no job. I'm sure I'd feel a million dollars by going through the process.
Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete.
The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture, drafting, perhaps writing too.
It seems at the moment that companies are approaching programmers as if they are purely technical like an actuary or bookkeeper and are seeking to quantify artistic skill through interview tests. This is rubbing off on some programmers who begin to think of themselves in these terms.
I don't recall a single instance as a photographer where I had to quantify my technical skill, but there were hundreds of times I had to based on my artistic skill, proving I had already made a vast range of photographs with sufficient quality to 'prove' my ability and by extension proving my technical ability.
Crucially, it was the fact I had a portfolio that allowed me to prove my ability, both artistically and technically.
I see a similar need in programming. I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously.
At the moment it seems that far to many programmers are attempting to get jobs without a 'portfolio' which is why, in an creative endeavour like programming, companies that hire are trying to quantify and determine a new hires ability with these seemingly bullshit tests.
There's room for improvement in this argument and there are outliers, but I think the basic premise is sound.