Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

291–300 of 315 posts

Re: People suck at technical interviews (2014)

#291

Earlier quoted context omitted.

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…

>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 rew…

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.

Re: People suck at technical interviews (2014)

#292

Earlier quoted context omitted.

> 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 al…

> 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.

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.

Re: People suck at technical interviews (2014)

#293
post #212

There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. 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,…

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. D…

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.

Re: People suck at technical interviews (2014)

#294
post #212

Earlier quoted context omitted.

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. D…

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…

Thanks for the thorough answer to my concerns.

Re: People suck at technical interviews (2014)

#295

Earlier quoted context omitted.

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.

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.

Re: People suck at technical interviews (2014)

#297

Earlier quoted context omitted.

"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.

We were looking for statisticians. Still not a great question, maybe. But you grab whatever is in your bag.

1/6?

Re: People suck at technical interviews (2014)

#298

Earlier quoted context omitted.

> 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 whe…

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....

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.

Re: People suck at technical interviews (2014)

#299

Earlier quoted context omitted.

"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.

We were looking for statisticians. 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

Re: People suck at technical interviews (2014)

#300
post #135

Earlier quoted context omitted.

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 ge…

> 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...

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.

Post reply on HN