You don't know you need to know the stuff you need to know until you need to know it.

A month ago I had no idea why it would be helpful to be able to know which memory location a dynamic variable is stored or created at. Now that I understand how to find out this info, I see that it has value.

For most of the stuff I mention itt, I have no clue what I'm talking about. Maybe knowing how to email encrypted files is vitally important to programmers. I would know. I've never been in a position where I had to do it.

I just mean, "a good test" is a lot more complicated than giving someone a little bit of extra time to do a task. It's much more about figuring out what tasks are good proxies for the job you're hiring them for.

For general developer jobs, one of the best proxies imo is simply an IQ test. When I was hired for my current job I had been out of the workforce since 2006. I had never touched jQuery, LINQ, ASP.NET MVC or many of the other technologies I use day to day now. That didn't really matter though since there was time available for me to quickly learn those things and I have the right kind of mind to be a programmer. I remember when I graduated from uni, probably a third of the class were never going to make good developers because they just didn't have that sort of mind.

Now that science is way less horrible than it was in my day, I'd love to see a useful job placement test for high schoolers

One of the best interviewing strategies I use is stolen from many sources, including Elon Musk.

Ask someone about a problem or challenge they came across on one of their projects. Anyone who has a strong work ethic and has come across a tough problem that took a decent amount of time on it will be able to recall it intimately.

The key I think to getting good answers is for the interviewee to feel comfortable. You need to get them out of the mindset of "let me think of a complex problem that they won't think is easy" because the question isn't about overcoming bleeding edge challenges, it is about solving day-to-day issues.

For example, you don't want the interviewee to be too embarrassed to say it took them and their team 2 weeks to troubleshoot what was breaking caching on a site. You want to hear about what steps they went through to fix it and see thought processes that are intellectually consistent with what you think is a logical thought process.

If the example is a site with broken caching, you would want to see the person testing and eliminating variables that make sense. For example, we recently had an issue where we needed to "take over" a site from the infrastructure team on it and troubleshoot caching for a week. It ended up being two Drupal modules (one that is counter to any web best practices you could write up and fought them on for weeks to not have it be on the site, a battle we lost) that caused all nodes using it to not cache. We ended up speaking with an architect that told us the issue with the troublesome module within 5 mins of reading through the site module list. However, we could still explain the process that we went through and the things we learned from this. I feel like the fact that the solution could have been known in minutes would prevent a lot of candidates from being comfortable explaining it, however I would gladly hire someone who went through a really good troubleshooting process, and eliminated variables that made sense.

So, for this one function, our teacher clearly wanted to us to do some nesting, but I figured out a way to eliminate that and have it all run as one line and to actually work. The prof was a bit taken aback by that, and yet still insisted that I should probably right it with nested loops, even though he couldn't figure out a case where it would execute improperly.

In this case, my logic process didn't work the way he wanted it to, but it provided a more efficient result. (slightly less readable than nested loops? sure, but it was pretty clear what was going on)

This makes it seem like what you're describing above actually dissuades candidates from coming up with novel ways of solving problems.

To me.

Disclaimer: As I've said and will probably repeat a hundred times this year, I'm a half-educated guy not working in the software dev field so I'm sure I don't have much of a clue what I'm talking about.

Legend,

I like that question and a slight variation. I ask about tough technical challenge in a project and how they overcame it. Follow up with what they would do differently next time or if they had more time/resources. Another good one is what they least liked about a particular technology they have used in the past. This one really shows how deep people have gone with tools/technologies.

I think this hiring discussion has been extremely interesting and I think productive so far. I'd love feedback on our process in general and insight into what you guys are doing. It's a really hard problem evaluating someone in such a short period of time under unusual pressure.

ChrisV I think an IQ test could be effective at identifying people like you who have been out of the game or junior devs with great potential, but I think it becomes much less effective for people with lots of experience. Like how do you rank someone with an IQ of 150 with minimal experience in your stack against someone with an IQ of 120 with 2 years, 5 years, 10 years?

We use a broad range of technologies at my company: HTML, CSS, Sass, vanilla JavaScript, Angular, Ruby on Rails, Python, Java, Objective C, and AWS. Everyone works on pretty much everything. The only exception is that we have one engineer that handles the bulk of the server related stuff and he doesn't touch the mobile apps.

When we interview candidates we have them meet with every member of the engineering team (5 of us) and at least one person from another department. We all probe for different things.

Two of our team do an architecture whiteboarding exercise with a candidate.
One usually starts by gauging front end knowledge
One gauges a bit of Ruby/Rails knowledge as well as some more algorithmic stuff

I touch on some Ruby/Rails stuff and then have them walk me through a feature they built in the past, something they liked working on.

I think my approach yields some interesting results. Some candidates use this as an opportunity to talk about a passion project or end up showing their excitement for problem solving. I had one guy talking about the challenges of internationalization on a european version of a glass door. Many times it's clear they're not particularly excited by software engineering or problem solving. Most people can't speak intelligently about why they made the choices they did or weigh pros and cons of different approaches when asked.

We don't expect a candidate to know everything in our stack, but we are looking for someone that can contribute somewhere from day 1. Because we use so many technologies, questions like the CSS precedence one aren't to weed out candidates, they're more to get an idea of where strengths and weaknesses are.

The guy I referenced earlier was interviewing for a senior software engineer role, had full stack developer on his resume, and much of his past experience listed JavaScript as a language used. The actual question asked was to write a constructor function as a stepping stone to talking prototypal inheritance. My colleague came out of the interview disappointed that he didn't know the syntax for declaring a function or CSS rule precedence. What I took from it was that he wasn't humble enough to admit what he doesn't know and wasn't able to make the connection logically that there are a billion <a> tags on a page but only one <a id="foo"> and that having the tag rule supersede makes no sense.

Not my question, but I actually might start using it because I really like the implications you can draw from a wrong answer or an I don't know (with help).

I'm not reading this twice but it sounds like you were given a task and then completed it optimally.

I have no idea how that relates to what I said which was wanting someone to:

Explain a problem you encountered on X project and how you and your team went about solving it?

Vs.

Tell me something badass you did in class yesterday?

In my job-hunting, the pressure curve seems to go down as I get closer to meeting the interviewers.

The home test is always kind of difficult, and often more difficult than what they really need. I think more is said about finishing it and doing it than doing it well.

The live coding sessions tend to be more low-pressure. I think they just want to see how fast I can get through a problem w/o using google and see how I handle mistakes.

The whiteboard feels like a lot more hand-holding since this isn't exactly the optimal way of coding. The conversation was about attacking the problem from different angles, dodging obvious and not-so-obvious pitfalls, and seeing if I could go down the correct road the concept they are looking for, with syntax being secondary.

In any case, I suspect that when blackize5 talks about this CSS / JS thing, the interview involved some hand-holding and exploration of thought, and the candidate failed on that and offered no feedback.

I don't understand why a front-end dev not knowing the basics of precedence and writing a function is defensible. I feel like so much of coding is writing and understanding what you are writing and why you are writing it, and that couldn't be possible unless you know the basic parts and rules of the language you are using. Then again, I retain sytnax very well, so perhaps I'm blinded by something I don't consider a strength.

The "more time/resources" one is definitely something I am going to actively remember to include.

Least liked technologies is definitely good too.

I use the 'tell me what you found most painful about X' to screen bull****ters for a lot of the open source technologies we use. For some reason people really like to exaggerate things like Hadoop / Spark / Hive / etc. Asking what was painful is a great way to separate people that downloaded it and did a simple example from people that used them to do real things.

Any tips in case I want to interview in the future? I forget stuff quickly but learn stuff quickly (especially if I've used it before). I haven't worked with Prolog for a couple of month now and would already struggle to to somewhat basic stuff. 3-5 days of relearning and I'd be a pretty solid developer though...that sort of thing is really hard to "sell". I feel like I should never forget stuff that I've worked with for long periods of time but my brain seems to erase things very quickly into some area where it's very easy to rekindle (but not easy enough to do it in a day or two of "learning")

IQ test for candidates just feels wrong to me.

I guess if it's a sort of important decider of the interview it being suggested that your IQ isn't high enough would kind of suck (ie, "I'm too stupid"). I'd really not like to be part of an interview process that left any candidate feeling ****tier than just the "damn I didn't get it" feeling. Not saying this is what's happening for sure but it's something I'd seriously be careful with. Especially if candidates realise they are doing an IQ test and ask for their results afterwards, and you have to be careful not to share other candidates results.

Also non standard implementation of an IQ test can lead to invalid results. This includes modification of phrasing of questions, omission of questions and modification of questions themselves.

They also would probably have a large bias towards native English speakers, as well as other biases.

Also you have to be careful with possible discrimination, there is some suggestion from doing a bit of reading that not giving every candidate an IQ test could be a form of discrimination.

Perhaps it's the best deciding option, I don't know as I'm not experienced in this area. But I think there's some extra things to think about when giving candidates tests like that.

I'm the same, as in forgetting syntactic stuff when I don't use a language regularly. Never felt that was a problem.
I'm just open about it and say something to the tune of "I can't remember the exact syntax - I'd have to look some things up - but this is how I'd go about it. Please do point out gross syntactic errors as we go along so they don't distract from the problem..."

Having said that, I do go through a refresher myself if I do interview for a language I haven't used in a while to bring back at least a large part of the stuff.

Hi all,

I'll preface by saying I'm new to web development. I am needing to set up a VPS hosting deal to build and host a website on a LAMP stack, and I'm considering linode.com and was curious if anyone here had any experience with them? From what I gather, they are very good, is this correct?

The website would be starting small, and will hopefully grow. To how large, I don't know, but I'm wondering how large of a website linode's different plans can accommodate?

1. How large of a site, measured in say, unique visits per day, could their 1GB service accommodate?
2. How large of a site measured in UVPD could their 8 GB service accommodate?
3. Could a site like this web forum be accommodated by their 8GB service? If so, easily, or just barely? If not, not even close, or not quite?

https://www.linode.com/pricing

Depends on how big your pages are, how much computation they are doing, how many visitors at any one time etc etc.

I'd just go for the cheapest option, then switch up as an when you need to.

The only exception to this rule imo is if you're running a startup where you might go viral overnight, in which case you'd want to be able to scale on demand or have something much larger than your needs to make sure you don't get effectively DDOSed. (Seen a lot of startups miss out on big growth from going cheapo in this way). It doesn't sound like this is the case though for you at the moment.

I can't spend very much time on the interviewing discussion until later. Regarding ChrisV's IQ comment, I think it is fair to say that his post was a way to indicate that a candidate's programming talent/aptitude are far more important factors than current skill set in many job situations. He was just pondering ways to measure/evaluate talent/aptitude.

+1. It's also a very one dimensional metric. It doesn't account for things like hard work, passion, or experience.


I'm still skeptical. There are lots of things related to good design/programming principles that I think are hard to pick up on the job. Or at least will involve a lot of teaching/training by other people through code reviews and such.

I'm especially skeptical for more senior positions.

Edit: I feel like I'm being a bit negative towards what everybody's saying about interviewing, but ultimately it reflects my one confident belief that interviewing is exceptionally hard and I've never found anything particularly good except avoiding the need to interview (which is often not possible).

Does anyone know of a simple solution to installing an entire app on a fresh machine?

For example we want to package and install postgres/nginx/python dependencies(django, DRF, etc) for a client. Currently the dev doing this uses Salt, but it's super messy. We can't use things like VM or docker.

I'm pretty newb and usually just do CRUD work, sry if this comes off as gibberish. Thanks in advance for the help!

Yes if someone took me on as a full stack web developer I'd have a steep learning curve at the very least and that is expensive especially for a senior type position. There isn't a shred of evidence that I would even enjoy such work though and I may turn out to be a very unmotivated individual which would lead to a very unproductive team member. So pay does enter into the evaluation of candidates.

How applicable are good design/programming principles across many programming paradigms? Clearly, in my view, some are and I think there is research that would back this up. To be honest, I am actually amazed at how little I've been asked about design and what I view as good programming principles.

I just wonder a lot if companies waste a lot of money in the hiring process and could be a lot more cost efficient. For example how many candidates that they reject could actually fill the roles that they are interviewing for competently/well? also, how many candidates that companies hire end up being inadequate. I guess at the end of the day I think the hiring process is often dysfunctional.

What's messy about it? Too many moving parts in the salt code base?

I hear they have to do a bunch of tweaks for the single install, so it's not scalable if they want to install to many other clients.

Also I think they want the entire install to generate 1 folder, rather than many files across different places (main culprit are the python dependencies).

The second part isn't very clear. You mean they want pg/nginx/django all installed to a specific directory? That's an unreasonable demand.

I would just use salt/ansible/whatever to provision the boxes. A web stack like that shouldn't be much more than a few lines of yaml per app once you have the components in place (salt/ansible specific stuff you only need to do once).

This.

I remember back in the first tech boom, when I had little experience, a job was posted asking you to solve a series of progressively harder brainteaser/IQ type problems -- things that test pure reasoning ability, or purport to. I spent a long time on them, sent them in, and got a call from an HR guy saying almost no one else had done so well, and then he asked me questions about my experience. And when the tech lead heard those answers, I was out, no discussion about it. At the time I thought, "What an *******." Now it makes total sense to me.